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

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 постоянно эволюционировал, и, вероятно, потребовалась бы целая статья, чтобы дать исчерпывающий обзор всех различных вариантов реализации этого подхода в ее конкретной инфраструктуре. Однако мы составили краткую хронологию основных инструментов, перечисленных по дате релиза:

Источник

Что такое «Инфраструктура как код»?

Инфраструктура как код (IaC) — это управление инфраструктурой (сетями, виртуальными машинами, подсистемами балансировки нагрузки и топологией подключения) в описательной модели с использованием той же версии, что и группа DevOps, используемая для исходного кода. Подобно принципу, согласно которому один и тот же исходный код создает один и тот же двоичный файл, модель IaC при каждом применении формирует одну и ту же среду. IaC является ключевым DevOps методикой и используется в сочетании с непрерывной поставкой.

IaC решает реальные проблемы

Инфраструктура по мере развития кода для решения проблемы с отклонением среды в конвейере выпуска. Без IaC команды должны поддерживать настройки отдельных сред развертывания. Со временем каждая среда становится « _снежинка_», то есть уникальной конфигурацией, которая не может быть воспроизведена автоматически. Несогласованность между средами приводит к проблемам во время развертывания. Администрирование и обслуживание инфраструктуры связано с выполняемыми вручную процессами, которые сложно отследить и которые приводят к возникновению ошибок.

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

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

IaC предоставляет реальные преимущества

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

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

Предпочитать декларативные определения

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

Для декларативного IaC не существует единого стандартного синтаксиса. Различные платформы поддерживают разные и зачастую несколько форматов файлов, таких как YAML, JSON и XML. В результате решение о выборе синтаксиса для описания IaC обычно сводится к требованиям целевой платформы.

Использование IaC в Azure

Azure обеспечивает собственную поддержку IaC с помощью Azure Resource Manager. Команды могут определять декларативные шаблоны, указывающие инфраструктуру, необходимую для развертывания своих решений.

Источник

Infrastructure as code: обзор опенсорсных инструментов

Давайте взглянем на текущее положение вещей в индустрии высоких технологий. Все только и говорят, что о DevOps да об облаке, но задачи, связанные с управлением ресурсами сервера и инфраструктуры, определенно пока не входят в разряд легких задач. Если мы выкатываем изменение только на один сервер, это, вероятно, будет не так уж сложно. Но как бы вы справились с заливкой но десятки или сотни серверов? Многие команды по-прежнему практикуют развертывание ресурсов инфраструктуры в облаке вручную, а эта практика зачастую увеличивает вероятность сбоя по мере каждого нового обновления и создает сложные ситуации, из которых нужно восстанавливаться, если что-то пойдет не так.

DevOps может подразумевать несколько разных вещей. DevOps несет культурную трансформацию, которая нацелена то, чтобы каждый инженер чувствовал себя продуктивным и гибким. DevOps также может означать достижение высокой частоты развертываний, при которой сохраняется стабильность. Для обеспечения автоматизации наиболее важной частью DevOps, вероятно, является создание потока ценности (value stream). Чтобы решить эту задачу, многие люди часто рассматривают возможность использования конвейера, такого как Jenkins или GitHub Actions. В то же время в современной экосистеме DevOps наблюдается быстрый рост относительно новой области под названием Infrastructure as Code (инфраструктура как код), так же известной в своей короткой форме — IAC.

IAC, или Infrastructure as Code, представляет собой процесс подготовки (provisioning) и управления компьютерными центрами обработки данных с помощью машиночитаемых файлов определений, а не физической конфигурации оборудования или интерактивных инструментов конфигурации. Хотя область IAC является относительно новой по сравнению с конвейером автоматизации DevOps, уже существует достаточно много IAC-инструментов, и новые технологии продолжают развиваться даже в этот самый момент. И я рад сообщить вам, что большинство из них — проекты с открытым исходным кодом. В этой статье я хочу представить вам некоторые из наиболее известных и широко используемых IAC-инструментов, распространяемых по опенсорсным лицензиям.

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

Agent vs Agentless

(с агентами/без агентов)

IAC-инструмент может требовать запуска агента на каждом сервере, который вы хотите настроить. Если нет, то такой инструмент называется «agentless».

Mutable vs Immutable

Некоторые инструменты, такие как Terraform, занимаются не изменением уже подготовленной (provisioned) инфраструктуры, а развертывают новый сервер, что означает, что они следуют парадигме неизменяемой (immutable) инфраструктуры. Другие инструменты, такие как Ansible, Chef, SaltStack и Puppet, могут изменять существующие ресурсы, а это означает, что эти инструменты следуют парадигме изменяемой (mutable) инфраструктуры.

Procedural vs Declarative

Процедурные языки, такие как Ansible и Chef, позволяют описывать с помощью кода поэтапное выполнение, в то время как декларативные языки, такие как Terraform, SaltStack и Puppet, позволяют просто указать желаемое состояние.

Master vs Masterless

(с мастером/без мастера)

Языки, такие как Chef, требуют, чтобы вы запускали отдельный главный сервер (master), чтобы обеспечить дополнительное управление и постоянные состояния. Другие языки, такие как Ansible и Terraform, не нуждаются в определении мастера.

Configuration vs Provisioning

Ansible, Chef, SaltStack и Puppet известны как инструменты управления конфигурацией, что означает, что их основная цель — настроить ресурсы. Другие инструменты, такие как Terraform и Pulumi, являются инструментами обеспечения (provisioning), а это означает, что их основная цель — предоставлять ресурсы. Однако по мере того, как инструменты развиваются, их функционал может начать пересекаться.

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

Источник

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. Он сильно помогает разобраться. Когда у тебя есть рядом сосед, который тоже что-то пытается понять, вместе вы поймёте лучше.

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

Заключение

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

Источник

Создаем инфраструктуру как код с GitLab и Ansible

Вся мощь GitLab CI в демонстрации плейбуков Ansible при подходе «инфраструктура как код».

GitLab CI — это эффективный инструмент для самых разных сценариев, включая инфраструктуру как код. GitLab можно использовать с разными инструментами, но в этой демонстрации мы возьмем Ansible, потому что именно его чаще всего используют разработчики при подходе «инфраструктура как код». Вот демо с двумя маршрутизаторами из курса по сетям Ansible.

Прелесть GitLab CI в том, что код из плейбука Ansible можно изменять и поставлять, не устанавливая никаких зависимостей локально. Демо-проект, который вызывает обновление строк SNMP на всех устройствах каждый месяц в соответствии с нашей политикой безопасности, можно полностью выполнить на GitLab.com, нашем сервисе размещения кода.

Для начала откройте плейбук Ansible, где есть 4 задачи:

В этом демо мы сосредоточимся на настройке строк SNMP, для которой нужно выполнить несколько простых шагов.

Начинаем с доски задач

Любой план на GitLab начинается одинаково: с задачи. Итак, первый шаг рабочего процесса GitLab — проверить доску задач в проекте ansible-demo. На доске задач ansible-demo мы уже видим задачу: изменить строки SNMP на всех маршрутизаторах. В задаче есть ссылка на wiki-страницу политики безопасности GitLab, где сказано, что строки SNMP нужно обновлять каждый месяц, и для операций «только для чтения» и «чтение и запись» должны быть разные строки.

Политика безопасности GitLab предписывает обновлять строки SNMP каждый месяц.

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

Команды для настройки строк SNMP доступны в плейбуке Ansible.

Потом вернитесь к задаче, назначьте ее себе и смените ярлык с to-do на doing на правой панели или просто перетащите задачу на доске из одного столбца в другой.

Создание мердж-реквеста

Теперь нужно создать из задачи мердж-реквест. Убедитесь, что у мердж-реквеста есть флаг Work in Progress (WIP), чтобы он не попал в мастер преждевременно. Вместо локального подключения мы используем GitLab Web IDE, потому что изменения в строках SNMP незначительны.

Коммит изменений

Вы обновили строку SNMP по инструкции, а теперь нужно закоммитить изменения. Откройте параллельное сравнение изменений, чтобы убедиться, что мердж-реквест содержит последний коммит.

Инструмент параллельного сравнения наглядно показывает изменения.

Результаты

Коммит изменений автоматически запустит пайплайн GitLab CI. Он выполнит следующие задачи:

Мы видим прогресс и выходные данные каждого задания в пайплайне GitLab CI, который обновляет SNMP.

Выходные данные вашей задачи показывают, что обновления SNMP в искусственной среде прошли успешно.

Все эти задачи будут запущены и задокументированы в мердж-реквесте.

Галочки показывают, что задача в пайплайне GitLab CI выполнена.

Затем войдите в маршрутизаторы для демо и посмотрите изменения.

Изменения строк SNMP RO и RW отражены в маршрутизаторах.

Ревью мердж-реквеста

Можно выполнить дополнительный шаг — одобрение мердж-реквеста. Если вы настроите одобрение, несколько пользователей смогут проверить изменения, прежде чем они попадут в продакшен.

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

Передача в мастер

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

Когда вы разрешите статус WIP, мердж-реквест можно будет отправить в мастер, а задачу — закрыть.

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

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

Магия GitLab CI

Все это возможно благодаря магии GitLab CI. Пайплайны GitLab CI — это ряды последовательных задач, которые выполняют все необходимое для тестирования и реализации кода Ansible.

GitLab CI запускается с базовым образом. В этом случае мы используем образ Docker, который содержит весь необходимый код и зависимости Ansible. Укажите команды, которые будут выполняться на каждом этапе, и зависимости.

Простой файл YAML содержит три этапа GitLab CI.

Этап демонстрации GitLab CI, на котором выполняется плейбук Ansible.

Мы заглянули внутрь пайплайна и увидели, как можно использовать GitLab CI, чтобы создать инфраструктуру как код, даже не устанавливая зависимости Ansible на компьютер. Это лишь один пример того, как можно использовать GitLab CI, чтобы реализовать инфраструктуру как код. Полное руководство смотрите в видео:

Источник