инфраструктура как код недостатки

What is: Infrastructure as Code

Одним из наиболее важных трендов в IT за последние годы стало бурное развитие автоматизации и одновременно — уменьшение необходимости во вмешательстве человека и выполнении каких-либо действий. Виртуализация дала нам возможность развёртывания новых окружений для девелоперов, в которых они могли бы делать их работу без опасений затронуть Production-систему, а гипервизоры, такие как Hyper-V или VMWare позволяют вам запустить новую машину в течении считанных минут.

Само собой — развёртывание нового окружения не всегда будет настолько простым. Процесс может занимать большее время, или человека, который знает этот процесс, может не оказаться на месте. Разработчики могут запросить тестовое новое окружение, которого им придётся ждать пару недель.

Infrastructure as Code (IAC) — тип IT-инфрастуктуры, обслуживание и развёртывание которой выполняется с помощью кода, а не вручную. IAC так же называют «программируемая инфрастуктура» (programmable infrastructure).

Концепт IAC схож с написанием скриптов, которые используются для автоматизации важных IT-процессов. Однако скрипты используются в основном для автоматизации серии неизменяемых шагов, которые должны быть выполнены на множестве серверов.

В отличии от скриптов — для IAC используются высокоуровневые языки программирования или DSL, которые позволяют писать более гибкие конфигурации для развёртывания окружений и деплоя приложений.

Процесс IAC весьма схож со стандартным процессом разработки программного обеспечения разработчиками, когда разработчики используют контроль версий, тестирование кода, а деплой выполняется только для кода, прошедшего все проверки на работоспособность.

Использование кода для развёртывания приложений интересно в первую очередь разработчикам ПО: вместо того, что бы полагаться на системного администратора в вопросах развёртывания и управления новыми окружениями — девелопер может написать IAC-процесс для автоматизации этого процесса.

Для IAC имеется целый набор утилит, среди которых Vagrant, уже упомянутые Ansible, Puppet и другие, которые делают процесс создания такой инфрастуктуры ещё более простым. Кроме того, сервисы типа AWS как правило предоставляют RESTfull API, что позволяет создавать более гибкие конфигурации.

Например, IAC созданная с помощью Ansible может установить сервер MySQL, запустить его, создать пользователя, базу данных и удалить ненужные базы данных, и всё это — с помощью кода.

Рассмотрим пример Ansible-playbook:

Он выполняет установку MySQL-сервера на удалённом хосте, запускает его, создаёт пользователя и пароль, удаляет тестовую базу данных, создаёт базу ansible_example и загружает в неё дамп.

Использование же систем контроля версий позволяет вам легко отслеживать все изменения в инфрастуктуре и выполнять её откат в случае проблем после обновления конфигурации.

Ещё одна немаловажным фактом является то, что вы можете использовать свой код для развёртывания новых окружений в любой среде, быдь то локальная машина, физический сервер, машина в облаке или виртуальный бокс.

Недостатки

Несмотрят на преимущества — у IAC имеются и потенциальные недостатки. Например — разработка IAC может потребовать использования дополнительных утилит, а любые ошибки при таком проектировании могут быть быстро распространены по всем окружениям проекта, поэтому IAC должен быть всесторонне протестирован.

Другая возможная проблема — если конфигурация окружения была изменена администратором без внесения соотвествующих изменений в IAC, поэтмоу особенно важно полностью интегрировать IAC в процесс системного администрирования, во все IT и DevOps-процессы и вести документацию.

Источник

Infrastructure as Code: первое знакомство

У нас в компании идёт процесс онбординга SRE-команды. Я зашёл во всю эту историю со стороны разработки. В процессе у меня появились мысли и инсайты, которыми я хочу поделиться с другими разработчиками. В этой статье-размышлении я говорю о том, что происходит, как происходит, и как всем дальше с этим жить.

Продолжение серии статей, написанных по мотивам выступлений на нашем внутреннем мероприятии DevForum:

Мы решили сделать команду SRE, воплотив идеи google sre. Набрали программистов из своих же разработчиков и отправили их обучаться на несколько месяцев.

Перед командой стояли следующие учебные задачи:

Вводим понятие Infrastructure as code

В обычной модели мира (классическом администрировании) знания об инфраструктуре находятся в двух местах:

Таким образом инфраструктура как код (Incfastructure as Code – IaC) – это описание всей имеющейся инфраструктуры в виде кода, а также сопутствующие средства по работе с ним и воплощению из него же реальной инфраструктуры.

Итак, мы решили подключить новых SRE-инженеров, но откуда их брать? Книжка с правильными ответами (Google SRE Book) говорит нам: из разработчиков. Ведь они работают с кодом, а вы достигаете идеального состояния.

Мы много и долго искали их на кадровом рынке за пределами нашей компании. Но вынуждены признать, что не нашли ни одного под наши запросы. Пришлось пошерстить среди своих.

Проблемы Infrastructure as code

Теперь давайте посмотрим примеры того, как инфраструктура может быть зашита в код. Код хорошо написан, качественно, с комментами и отступами.

Пример кода из Terraforma.

Пример кода из Ansible.

Господа, но если бы всё было так просто! Мы же с вами в реальном мире, а он всегда готов удивить вас, преподнести сюрпризы, проблемы. Не обходится без них и здесь.

1. Первая проблема состоит в том, что в большинстве случаев IaC – это какой-то dsl.

А DSL, в свою очередь, – это описание структуры. Точнее того, что у тебя должно быть: Json, Yaml, модификации от каких-то крупных компаний, которые придумали свой dsl (в терраформе используется HCL).

Беда в том, что в нём может легко не быть таких привычных нам вещей как:

Вполне реальная ситуация, когда баш с питоном запускает какой-то процесс, в который подсовывается Json. Вы его анализируете, потом еще какой-то генератор выдает ещё 30 файлов. Для всего этого поступают входные переменные из Azure Key Vault, которые стянуты плагином к drone.io, написанным на Go, и переменные эти проходят через yaml, который получился в результате генерации из шаблонизатора jsonnet. Довольно сложно иметь строго хорошо описанный код, когда у вас настолько разнообразная среда.

Традиционная разработка в рамках одной задачи идет с одним языком. Здесь же мы работаем с большим количеством языков.

3. Третья проблема – это тулинг. Мы привыкли к крутым редакторам (Ms Visual Studio, Jetbrains Rider), которые все делают за нас. И даже, если мы затупили, они скажут, что мы не правы. Кажется, что это нормально и естественно.

Но где-то рядышком есть VSCode, в котором есть какие-то плагины, которые как-то ставятся, поддерживаются или не поддерживаются. Вышли новые версии, и их не поддержали. Банальный переход к имплементации функции (даже если она есть) становится сложной и нетривиальной проблемой. Простой ренейм переменной – это реплейс в проекте из десятка файлов. Повезёт, если он то, что надо зареплейсит. Есть, конечно, кое-где подсветка, есть автокомплишн, где-то есть форматинг (правда у меня в терраформе на винде не завелся).

На момент написания статьи vscode-terraform plugin еще не выпустили для поддержки версии 0.12, хотя она зарелижена уже как 3 месяца.

Пришло время забыть о.

Самое страшное, что мы вынуждены думать не о том как спроектировать, разложить файлики по папочкам, декомпозировать, сделать поддерживаемым, читаемым и так далее код, а о том, как бы мне корректно написать эту команду, потому что я её как-то неправильно написал.

Как новичок вы пытаетесь познать терраформ, а IDE вам в этом нисколько не помогает. Когда есть документация – зашли, посмотрели. Но если бы вы въезжали в новый язык программирования, то IDE подсказала бы, что есть такой тип, а такого нет. По крайней мере, на уровне int или string. Это часто бывает полезным.

А как же тесты?

Вы спросите: «Как же тесты, господа программисты?» Серьёзные ребята тестируют всё на проде, и это жестко. Вот пример юнитеста для терраформ-модуля с сайта Microsoft.

У них хорошая документация. Microsoft мне всегда нравились своим подходом к документации и обучению. Но не нужно быть дядюшкой Бобом, чтобы понять, что здесь не идеальный код. Обратите внимание на валидацию, вынесенную вправо.

Проблема unit-теста в том, что мы с вами можем проверить корректность Jsonа на выходе. Я кинул 5 параметров, мне выдалась портянка Json на 2000 строк. Я могу проанализировать, что здесь происходит, validate test result…

Сложно анализировать Json в Go. А надо писать в Go, потому что терраформ на Go – это хорошая практика того, что тестируешь в том языке, в котором ты пишешь. Сама организация кода очень слабая. При этом – это лучшая библиотека для тестирования.

Сам Microsoft пишет свои модули, тестируя их таким способом. Конечно, это Open Source. Всё, о чем я говорю вы можете прийти и починить. Я могу сесть и за недельку всё починить, заопенсорсить плагины VS-кода, терраформ, сделать плагин для райдера. Может быть, написать парочку анализаторов, прикрутить линтеры, законтрибьютить библиотеку для тестирования. Всё могу сделать. Но я не этим должен заниматься.

Лучшие практики Infrastructure as code

Едем дальше. Если в IaC нет тестов, плохо с IDE и тулингом, то должны быть хотя бы лучшие практики. Я просто пошёл в гугл-аналитику и провёл сравнение двух поисковых запросов: Terraform best practices и c# best practices.

Что мы видим? Беспощадную статистику не в нашу пользу. По количеству материала – то же самое. В C# разработке мы просто купаемся в материалах, у нас есть сверхлучшие практики, есть книги написанные экспертами, и также книжки, написанные на книжки другими экспертами, которые критикуют те книжки. Море официальной документации, статей, обучающих курсов, сейчас еще и open source разработка.

Что касается запроса по IaC: здесь вы по крупицам пытаетесь собрать инфу с докладов хайлоада или HashiConf, с официальной документации и многочисленных issue на гитхабе. Как вообще эти модули раскидывать, что с ними делать? Кажется, что это реальная проблема… Есть же комьюнити, господа, где на любой вопрос тебе дадут 10 комментов на гитхабе. Но это не точно.

К сожалению, в данный момент времени эксперты только начинают появляться. Пока их слишком мало. А само комьюнити болтается на уровне зачатков.

Куда всё это движется и что делать

Можно всё бросить и пойти обратно на C#, в мир райдера. Но нет. Зачем вы вообще стали бы этим заниматься, если не найти решение. Далее я привожу свои субъективные выводы. Можете поспорить со мной в комментариях, будет интересно.

Лично я ставлю на несколько вещей:

Может быть тема хайповая, но сам факт того, что сфера растёт, вселяет некоторую надежду.

Банальный пример: совместная работа через pair programming. Он сильно помогает разобраться. Когда у тебя есть рядом сосед, который тоже что-то пытается понять, вместе вы поймёте лучше.

Понимание о том, как делается рефакторинг помогает даже в такой ситуации производить его. То есть, ты можешь поменять не всё сразу, а поменять нейминг, потом поменять расположение, потом может выделить какую-то часть, ой, а здесь не хватает комментариев.

Заключение

Следом идёт вторая часть статьи. В ней я рассказываю о том, как мы применяли практики экстремального программирования, чтобы улучшить наш процесс обучения и работу с инфраструктурой.

Источник

Infrastructure as Code: Плюсы, Минусы и Будущее

Infrastructure as Code — ключевой элемент наиболее эффективных инженерных сетапов. То, как сейчас DevOps-инженеры взаимодействуют со своей инфраструктурой — это несомненно большой скачок вперед. Но тем не менее спорные моменты с определением и лучшими практиками IaC до сих пор есть. Эта статья стремится четко описать IaC, его преимущества и важные ограничения.

Infrastructure as Code, или сокращенно IaC, — это фундаментальный сдвиг не только для Ops в том, как они подходят к провизионированию и обслуживанию инфраструктуры, но и в разработке программного обеспечения в целом. Несмотря на то, что за последние несколько лет IaC де-факто зарекомендовал себя как отраслевой стандарт, многие до сих пор спорят о его определении, лучших практиках и ограничениях.

В этой статье вы познакомитесь с эволюцией этого подхода к инфраструктуре рабочих процессов и связанных с ним технологий. Мы объясним, откуда появился IaC, перспективы его развития, его преимущества и его главные ограничения.

От железа к облаку

Еще помните железный век IT, когда вам нужно было покупать собственные серверы и компьютеры? И я уже не помню. Сейчас кажется совершенно безумным, что рост инфраструктуры мог быть ограничен циклом покупки оборудования. Поскольку доставка нового сервера занимала несколько недель, необходимость быстрой установки и настройки на нем операционной системы не стояла так остро. Люди просто вставляли диск в сервер и следовали по пунктам. Через несколько дней он становился доступен для разработчиков. Просто безумие.

С одновременным запуском и повсеместным внедрением AWS EC2 и Ruby on Rails 1.0 в 2006 году многие корпоративные группы столкнулись с проблемами масштабирования, которые ранее возникали только в крупных транснациональных организациях. Облачные вычисления и возможность без усилий запускать новые инстансы виртуальных машин принесли инженерам и предприятиям не только хорошую выгоду, но и дополнительные хлопоты. Теперь им приходилось следить за обслуживаемыми серверами, число которых постоянно росло.

Площадь инфраструктуры средней инженерной организации стала расти по мере того, как небольшое количество больших машин заменялось большим количеством меньших. В какой-то момент стало гораздо больше вещей, которые Ops требовалось провизионировать и поддерживать, и эта инфраструктура имела тенденцию быть циклической. Мы можем масштабироваться, чтобы справиться с ​​пиковой нагрузкой днем, а ночью уменьшать масштаб, чтобы сэкономить на расходах, потому что они не фиксированы. В отличие от необходимости мириться с постоянным устареванием нашего оборудования, мы теперь платим за вычислительные ресурсы почасово. Таким образом, чтобы извлечь максимальную выгоду при использовании облачного сетапа, имеет смысл задействовать только ту инфраструктуру, которая вам необходима.

Чтобы максимально эффективно использовать эту гибкость, нам потребовалась новая парадигма. Создавать тысячу тикетов каждое утро, чтобы набрать максимальную мощность, и еще тысячу тикетов ночью, чтобы снова замедлиться, при этом вручную управлять всем этим, очевидно, становится довольно сложной задачей. Возникает вопрос, как начать операционализировать этот сетап, чтобы он был надежным, устойчивым и исключал ошибки, вызванные человеческим фактором?

Infrastructure as Code

Infrastructure as Code был рожден для решения этих задач максимально систематизированным образом. IaC — это процесс управления и провизионирования датацентров и серверов с помощью машиночитаемых файлов определений, созданный как альтернатива физическому конфигурированию оборудования и оперируемым человеком инструментам. Теперь, вместо того, чтобы запускать сотню различных файлов конфигурации, IaC позволяет нам просто запускать скрипт, который каждое утро поднимает тысячу дополнительных машин, а вечером автоматически сокращает инфраструктуру до приемлемого вечернего масштаба.

С момента запуска AWS Cloudformation в 2009 году IaC быстро стал неотъемлемой практикой DevOps, незаменимой в жизненном цикле конкурентоспособной доставки программного обеспечения. Он позволяет командам инженеров быстро создавать и версионировать инфраструктуру тем же способом, что и обычный код, и отслеживать эти версии во избежание несогласованности между средами. Обычно команды осуществляют это следующим образом:

Разработчики определяют и пишут инфраструктурные спецификации (infrastructure specs) на специфичном для предметной области языке

Созданные файлы отправляются в API управления, мастер-сервер или репозиторий кода

Затем инструмент IaC, такой как Pulumi, выполняет все действия, которые нужны для создания и настройки необходимых вычислительных ресурсов

И вуаля, ваша инфраструктура внезапно начинает работать на вас, а не наоборот.

Традиционно существует два подхода к IaC, декларативный или императивный, и два возможных метода, push и pull. Декларативный подход описывает конечную цель и определяет требуемое состояние ваших ресурсов. Этот подход отвечает на вопрос о том, что нужно создать, например, «Мне нужны две виртуальные машины». Императивный подход отвечает на вопрос о том, как нужно изменить инфраструктуру для достижения конкретной цели, обычно выдавая последовательность различных команд. Ansible playbooks — отличный пример императивного подхода. Разница между методом push и pull заключается в том, каким образом серверам сообщается информация о конфигурации. В pull режиме каждый сервер будет пулить свою конфигурацию из мастер-сервера, а в push режиме мастер-сервер сам распушивает конфигурацию по целевой системе.

В течение последних десяти лет набор инструментов IaC постоянно эволюционировал, и, вероятно, потребовалась бы целая статья, чтобы дать исчерпывающий обзор всех различных вариантов реализации этого подхода в ее конкретной инфраструктуре. Однако мы составили краткую хронологию основных инструментов, перечисленных по дате релиза:

Источник

«Инфраструктура как код» в автоматизации сервисов CI/CD

Привет! Меня зовут Игорь Николаев, я пью за любовь работаю в отделе автоматизации процессов разработки Мир Plat.Form в НСПК. В этой статье я поделюсь тем, как наш отдел решал задачу по автоматизации предоставления различных ресурсов для команд разработки. Эта задача свойственна организациям с большим количеством проектов, инфраструктура которых состоит из распределенных и, возможно, слабо связанных сетевых сегментов.

В статье описан PoC (Proof of concept) решения задачи выделения ресурсов в рамках сервисов CI/CD (Continuous Integration & Continuous Delivery) и предоставления привилегий для пользователей этих сервисов.

Описание

Про тиражирование стоит сказать подробнее, у нас есть несколько сетевых сегментов с разными сервисами CI/CD, и иногда они имеют минимум сетевой связанности. Система должна с минимальными затратами обслуживать несколько окружений, которые могут отличаться друг от друга.

Что мы выбрали для PoC:

Как подход был выбран IaC (Infrastructure-as-Code) с описанием желаемых состояний в виде yaml файлов.
Python — язык для написания автоматизации (подходящий вариант для прототипа);
Bitbucket — веб-сервис для хостинга проектов и их совместной разработки;
Jenkins — сервис непрерывной интеграции (необходим нам для визуализации выполнения задач).

Как пилотные системы для автоматизации были выбраны:

Active Directory — всем известные службы каталогов (нам понадобятся группы и пользователи);
Bitbucket — часто запрашивают создание проектов, предоставление привилегий;
Nexus 3 OSS (не реклама, нет страницы в Wiki) — корпоративная система хранения артефактов, при появлении проектов создаются персональные репозитории проекта и выдаются привилегии.

Разговор об автоматизации следует начать с описания общей концепции.

В Bitbucket есть две важные сущности: проект(project) и репозиторий (repository), который входит в состав проекта. Для описания доступов в рамках концепта мы решили ограничиться доступами к проекту (более сегментированное предоставление привилегий (на репозиторий) в рамках концепта не потребуется).

У project в Bitbucket есть параметр project key, который понадобится для дальнейших манипуляций, мы взяли его за связующую основу. Именно он и будет являться названием директории в git-репозитории meta. В директории проекта будут размещаться meta-файлы (карты) проекта описанные в формате yaml.

Проектов в Мир Plat.Form много, и у каждого есть своя специфика. Возникает мысль держать в одном месте информацию о группах, инструментах, требуемых проекту, стендах (наборах серверов) и прочего, что имеет отношение к проекту. Для этого отлично подходит git репозиторий.

Какие задачи это решает?

Структура meta репозитория git:

DEV — наименование сетевого сегмента
project1 — ключ проекта в Bitbucket
project1_meta.yaml — карта проекта
examples — директория примера описания

Такая структура позволит описать несколько различных сетевых сегментов, при этом сохраняя гибкую возможность изменений и различий между ними.

Скрипты автоматизации в рамках концепта будут находиться в проекте в отдельных репозиториях (названия не принципиальны):

О назначении первых трех репозиториев легко догадаться. Последний репозиторий jjb-core — репозиторий в котором мы будем хранить описание Jenkins Job в виде рецептов для Jenkins Job builder (о нем будет рассказано ниже).

Автоматизация Microsoft AD

Active Directory используется во многих организациях. Большое количество рабочих процессов организаций начинаются именно с него. У нас в Мир Plat.Form все сотрудники имеют учетные записи в AD и включены в различные группы.

За AD отвечает подразделение инфраструктуры. Для наших нужд была выделена техническая учетная запись (ТУЗ), которой делегировано управление одним из Organization unit (OU). Именно в нем с помощью простой автоматизации мы будем создавать группы и наполнять их пользователями.

Часть содержимого project1_meta.yaml, которая отвечает за AD:

READY — булево значение и позволяет, в случае необходимости, выключить автоматизацию обработки данного мета файла
TEAM — секция, описывающая сущность проекта
ROLES — произвольные названия ролей на проекте, отображающие суть
GLOBAL_PRIVELEGES — секция описывает, какая роль будет обладать какими привилегиями
Пример мета репозитория

В рамках предоставления прав для окружения разработки, чтобы не усложнять пример, остановимся на 3х основных ролях: owner, developer, qa (в целом, количество и наименование ролей является произвольным). Для дальнейшей автоматизации эти роли позволят покрыть большую часть повседневных потребностей (у нас сразу появились роль tech, для ТУЗ, но для примера обойдемся без нее).

В рамках OU проекта будем автоматически, на основании meta-файлов проекта, создавать необходимые SG (Security group) и наполнять их пользователями.

На схеме структура выглядит так:

В AD используем плоскую иерархическую структуру, это позволит ее легко обслуживать, и выглядит она весьма наглядно.

Скрипт автоматизации получился очень простой. Он позволяет отслеживать изменения в составе групп (добавление/удаление пользователей) и создавать OU/SG.

Для запуска потребуется установить зависимости из requirements.txt (ldap3, PyYAML).

Автоматизация Sonatype Nexus3 OSS

Что такое Nexus? Nexus — это менеджер репозиториев, позволяющий обслуживать разные типы и форматы репозиториев через единый интерфейс (Maven, Docker, NPM и другие).

На момент написания статьи версия была OSS 3.25.1-04

Почему именно Nexus?

Есть community версия, которая обладает богатым функционалом, достаточным для выполнения большинства задач, связанных с хранением артефактов и проксирования внешних репозиториев.

Процесс хранения артефактов является важным при проектировании конвейера тестирования и развертывания.

Что потребуется автоматизировать?

Blobstore
Все двоичные файлы, загружаемые через proxy репозитории (мы не предоставляем прямого доступа к интернет репозиториям, используем исключительно прокисрование через nexus), опубликованные в hosted (локальные репозитории) репозитории хранятся в хранилищах Blob-объектов, связанном с репозиторием. В базовом развертывании Nexus, с одним узлом, обычно связаны с локальным каталогом на файловой системе, как правило, а каталоге sonatype-work.
Nexus версии >= 3.19 поддерживает два типа хранилищ File и S3.

Как мы видим, по умолчанию нам уже доступно хранилище default. Из информации выше мы можем понять, что данный blob находится на диске и ему доступен весь объем дискового раздела, на котором находится директория sonatype-work.

Проблематика

В целом, все логично, но есть минимум две проблемы, о которых следует задуматься:

Простое решение

Первое, что приходит в голову — это создание отдельных blob stores. Очевидно, это не решает проблему расположения на одном дисковом разделе. Подходящим решением является «нарезать» разделы для каждого проекта. Забегая вперед, это решит еще и вопрос мониторинга и отправки уведомлений ответственным за проект. Удобное решение второго пункта описанных проблем.
По первому пункту наиболее правильным решением является создание отдельных blob store для каждого репозитория.

UI создания Blob stores:

Nexus позволяет настроить Soft quota, штука сомнительная. Она уведомляет о том, что с местом что-то не так, но не производит каких-либо действий. При правильном применении шагов, описанных выше, удается добиться большего функционала (Появляется простой способ отслеживания объема и обращений к диску, а переполнение не создает неприятности «соседям»).

В поле path мы можем указать раздел, который примонтирован, например, как nfs.
Что позволяет держать раздел непосредственно на сетевом хранилище. Это может снизить скорость, но дает ряд преимуществ с точки зрения простоты.

Nexus у нас запускается в Docker, для этого используется compose файл. Для подключения новых точек монтирования, простым решением будет добавить в compose файле монтирование родительского каталога точек монтирования.

Repositories
Nexus позволяет создавать репозитории почти всех распространенных форматов. Если идти в сторону идеального хранения, то целесообразно для каждого проекта создавать минимум release и snapshot репозиторий, хотя идеальный вариант может содержать еще и release-candidat репозиторий. Это позволит настроить удобный механизм чистки репозиториев.

Определенно, release репозиторий должен во многих случаях иметь максимальную глубину хранения, как требование, в релизах не должно оказаться «мусора». Напротив, с репозиториями snapshot мы должны иметь возможность очищать без опасений в любое удобное время и без рисков.

Ко всем форматам репозиториев доступ осуществляется по 80 и/или 443 портам, за исключением docker. Репозиторий Docker, для доступа к нему, должен иметь персональный порт. Это приводит к некоторым сложностям. Каждый раз публикуя новый порт, мы должны добавлять его публикацию в compose файле.

LDAP
Nexus имеет возможность реализации подключения к LDAP и использования его в качестве аутентификации пользователей. В нашем случае мы используем группы пользователей для предоставления прав.

Roles
Для удобства роли создаются под проект, лучше идти от минимума, и для себя мы выбрали три роли для каждого проекта:
qa — обладают правами достаточными для read
developers — read, write
owners — read, write, delete
Группы из AD матчатся в локальные группы Nexus.

API
Начиная с версии Nexus OSS 3.19 появилось весьма удобное API для управления Nexus, это значимое нововведение, которое многие пользователи ждали позволит нам управлять Nexus и приводить его в нужное состояние.

На момент написания статьи API, по большей части, в статусе beta, но не смотря на это, работает без больших проблем и позволяет автоматизировать почти все необходимое.

Часть содержимого project1_meta.yaml, которая отвечает за nexus:

На основании такого файла система автоматизации создает все обслуживаемые сущности. В наших командах принято, что teamlead отвечает за наполнение файла проекта, однако, создать его может любой желающий. После создания pull request следует согласование вовлеченными в процесс участниками, после мерджа с master веткой, отрабатывает автоматизация.

Стоит отметить, мы стремимся сделать процесс максимально простым для пользователя, что влечет к использованию шаблонов конфигураций, которые описаны в виде примитивных моделей. Система позволяет переопределить умолчания в случае возникновения необходимости в описании карты проекта.

Пример кода модели для maven hosted repository:

Данный подход позволяет сократить описание создаваемой сущности до минимума.
Идеологически, все что может использовать значения по умолчанию должно их использовать, но при необходимости может быть заменено в файле карты проекта.

Автоматизация Atlassian Bitbucket

Для концепта достаточно будет автоматизировать создание проекта и предоставление привилегий к нему.

Часть содержимого project1_meta.yaml, которая отвечает за Bitbucket:

Это все, что потребуется при заведении нового проекта. Project key будет взят из названия yaml файла (в данном примере — project1).

Как это выглядит в UI:

Jenkins Job Builder

JJB является python утилитой для описания сущностей jenkins в виде yaml манифестов, которые преобразуются в понятные jenkins API запросы. Это позволяет великолепно решать задачу управления большим количеством однотипных задач.

Jenkins в данном контексте является интерфейсом для отображения успешности выполняемых задач автоматизации и контроля над ними. Сами задачи на первом этапе планируем выполнять по расписанию, например, каждый час. Это позволит избавиться большой части неконтролируемых ручных изменений и будет каждый час приводить систему к описанному состоянию.

Структура репозитория jjb-core:

Каждая директория содержит описание Jenkins job состоящее из двух файлов.

Yaml файл описывает шаблон jenkins job имеет следующее наполнение:

Файл groovy — это простой jenkinsfile:

Все это описывает создание следующей структуры Jenkins:

Общий алгоритм работы автоматизации:

Результат и развитие

Результатом данного концепта стало появление базовой автоматизации описанных процессов. Интерфейс взаимодействия в виде yaml карт проектов оказался весьма удобен, появились запросы на улучшения. Главными показателями успешности стали простота и скорость предоставления необходимых проектам ресурсов. Показатель скорости улучшился в разы по сравнению с ручным подходом. Все стало однотипным, понятным и повторяемым. Избавились от ручных ошибок.

На текущий момент описанный PoC перешел в стадию промышленной эксплуатации и претерпел значительные доработки. Мы переписали core систему автоматизации, к которой в виде плагинов подключаются модули для автоматизации новых сервисов. Появились тесты.
Всего автоматизацией обслуживается около 50 проектов и подключаются новые. Планируем тиражирование в другие сетевые сегменты.

Источник