Развитие Ansible: от фантастического устройства до зрелой экосистемы управления ИТ-инфраструктурой

Введение

Ansible – один из самых популярных инструментов автоматизации, но многие до сих пор используют его, ограничиваясь лишь командой ansible-playbook. С 2012 года Ansible вырос из простого инструмента в мощную экосистему, решающую проблемы с зависимостями, тестированием и централизованным управлением. Если вы все еще боретесь с конфликтами версий Python на хосте или пишете Ansible-контент без тестов – эта статья для вас.

Мы разберем современный инструментарий Ansible – от Execution Environments и Ansible Navigator до Event Driven Ansible и AWX. Вы узнаете, как эти компоненты превращают Ansible в полноценную платформу автоматизации, готовую справляться как с задачами небольших команд, так и с вызовами крупных компаний. А для начала немного истории, ведь название Ansible пришло к нам прямиком из научной фантастики…

Ansible: фантастика да и только

В 1966 году американская писательница-фантаст Урсула Ле Гуин (Ursula Kroeber Le Guin) придумала устройство под названием Ansible («Мир Роканнона», 1966) – прибор, позволяющий мгновенно передавать информацию на астрономические расстояния. Спустя десятилетия, слово Ansible вырвалось из области научной фантастики и стало названием технологии, которая изменила подход к автоматизации ИТ-инфраструктур.

Пока мир фантастики жил сам по себе, инженеры ИТ-инфраструктур искали способы автоматизировать рутинные задачи. Первые шаги в сторону автоматизации начались ещё в 90-х. В 1993 году появился CFEngine – первая масштабируемая система управления конфигурацией. За ней, спустя долгое время, последовали Puppet (2005), Chef (2009) и SaltStack (2011). Системы предлагали свои архитектурные решения, но все имели одну общую черту – работали по pull-модели, при которой на каждом управляемом сервере (узле) необходимо устанавливать агент, чтобы тот периодически забирал конфигурации с центрального узла.

Именно это и не устроило Михаэля Дехана (Michael DeHaan). В 2012 году он создает Ansible – инструмент, работающий по push-модели. Михаэль добивался максимальной простоты и гибкости – работа без агентов по стандартному SSH  ^[1]и конфигурация, описанная в виде YAML-файлов. И ему это удалось, достаточно быстро инструмент оказался очень популярным. Уже через год Михаэль основал Ansible Inc., а через два выпустил Ansible Tower – серверное приложение с расширенным функционалом и веб-интерфейсом, упрощающее использование Ansible в больших командах и корпоративной среде. Сотни компаний по всему миру, включая компании из Fortune 50, стали использовать Ansible ^[2].

Успех не остался незамеченным, и в 2015 году Red Hat приобрела Ansible Inc, сделав его частью своей экосистемы ^[3].

В 2017 году Red Hat сделала следующий шаг, открыв исходный код Ansible Tower под проектом AWX, который стал upstream-проектом, а Ansible Tower постепенно влился в новую платформу – Red Hat Ansible Automation Platform (2019 год).

Неравная борьба за популярность

С 2012 инструменты автоматизации Puppet, Chef, SaltStack и, конечно, Ansible боролись за внимание ^[4] системных инженеров, DevOps-специалистов и инфраструктурных команд.

Достаточно взглянуть на данные Google Trends ^[5], чтобы определить, что в этой гонке Ansible оказался впереди, став самым популярным инструментом автоматизации в мире.

GitHub подтверждает лидерство ^[6] – у проекта Ansible огромное число форков и более 5500 контрибьюторов:

Что важно – это сохранение динамики роста аудитории. На всем протяжении своего существования Ansible продолжает собирать звёзды на GitHub ^[7], сообщество растёт, а интерес ^[8] инженеров не угасает:

Отчёты DevOps-сообщества, например, ежегодный «State of DevOps Russia ^[9]» за 2024 год, лишь подтверждают эту тенденцию в России. Ansible стабильно занимает лидирующие позиции среди инструментов управления инфраструктурой – порядка 50% компаний (респондентов) используют Ansible. Это много-много больше, чем у оппонентов Ansible. Но стоит отметить, что в 2023 году показатель был около 60%. Почему так?

«State of DevOps Russia» за 2024 год:

По нашему мнению, эта тенденция является отражением изменений в аудитории респондентов. В последние несколько лет к DevOps-практикам (а отчет именно про DevOps) начали массово приходить компании из отраслей, ранее не связанных напрямую с ИТ – промышленность, транспорт, логистика, образование. Все благодаря бурной внутренней цифровизации и развитию ИТ-инфраструктур. Эти компании начинают путь с самого начала. У них нет Ansible и CI/CD, у них – bash и shell-скрипты. Это первая ступенька. Именно поэтому доля респондентов, использующих shell-скрипты, увеличилась с 55% до 63%. Так что снижение доли Ansible, с нашей точки зрения ^[10], – это не про падение интереса к технологии. Это про расширение базы пользователей, которые только начинают свой путь.

И как показывает практика прошлых лет, почти все они со временем переходят на более зрелые инструменты, и первым среди них обычно оказывается именно Ansible. Его простота – главный козырь. Очень низкий порог входа: можно начать с пары строк на YAML, дать доступ по SSH, и автоматизация уже работает. Ansible позволяет автоматизировать любые задачи на любом масштабе: установка пакетов и приложений, настройка операционных систем и сетевых устройств, развертывание виртуальной инфраструктуры и пр.

Развод и девичья фамилия

Стоит отметить один важный момент в развитии Ansible – его архитектурное разделение. До 2021 года всё, что касалось Ansible, поставлялось в виде одного большого пакета. Внутри него были и сам движок, и модули, и поддерживаемые сообществом коллекции Ansible. Всё находилось в одном репозитории и устанавливалось одной командой. Удобно, но по мере роста популярности и количества коллекций Ansible стало понятно, что этот “груз” существенно тормозит процесс разработки основного движка.

В 2021 году разработчики приняли важное решение – разделить проект. Появились два ключевых компонента:

• Ansible Core – это сам движок, интерпретатор сценариев автоматизации (playbook), и вспомогательные инструменты;

• Ansible – это пакет, который включает в себя как Ansible Core, так и набор популярных коллекций Ansible.

Это разделение вносит небольшую путаницу, как правило, для начинающих в Ansible. Например, вы устанавливаете Ansible версии 10.4.0, а команда “ansible –version” показывает 2.17.4. Люди терялись: Это баг? Это старая версия? На деле же всё корректно: это разные версии у пакета Ansible и Ansible Core, соответственно.

Более подробно причины и этапы разделения описаны в серии статей, которые, по неизвестным причинам, теперь доступны только в веб-архиве:

• Thoughts on Restructuring the Ansible Project ^[11]

• The Future of Ansible Content Delivery ^[12]

• Announcing the Community Ansible 3.0.0 Package ^[13]

А проект Ansible на GitHub тут ^[14].

Современная экосистема Ansible

Ansible продолжил свое развитие, и на сегодня Ansible – это не просто команда ansible-playbook. Это целая экосистема:

• Ansible Navigator (2021) – TUI-интерфейс для упрощения работы с Ansible.

• Execution Environments (2021) – контейнеризированная среда, которая содержит все необходимые зависимости для выполнения playbook.

• Ansible Builder (2020) – инструмент, упрощающий сборку Execution Environments.

• Ansible Creator (2024) – утилита для инициализации структуры Ansible проектов и коллекций.

• Ansible Lint (2014)- линтер, который проверяет код автоматизации на Ansible на соответствие лучшим практикам.

• Molecule (2016)- тестирование кода автоматизации в тестовых окружениях (Docker, Vagrant).

• AWX (2016)- запуск Ansible автоматизации через графический WEB-интерфейс и API.

• Ansible VS Code Extension (2020) – расширение для редактора VS Code для удобства разработки Ansible автоматизации (автодополнение, справка, интеграция с EE)

• Pulp 3 + Galaxy NG (2020) – набор для организации персонального портала Ansible Galaxy.

• Event Driven Ansible (2022) – динамический запуск автоматизации на Ansible в ответ на события из различных источников

Архитектура платформы автоматизации на экосистеме Ansible:

Раскроем каждый инструмент в логичной для повествования очередности.

Execution Environment: выручай-контейнер

В 2021 году в мире Ansible произошло по-настоящему важное событие – появилась концепция Execution Environments. Что такое Execution Environment, или просто EE? Это изолированное окружение на базе контейнера, в который упаковано всё необходимое для выполнения playbook.

До использования EE все зависимости Ansible устанавливались на хостовую систему. Это приводило к конфликтам версий, например, когда для разных playbook требовались разные версии Python, Ansible Core, библиотек и коллекций. А также к проблемам переносимости playbook между разными операционными системами. Execution Environment всех уравнивает. Вы один раз собираете контейнер, в котором фиксируете:

• Ansible Core и коллекции;

• Python и его библиотеки;

• Прочие инструменты, например git, terraform и т.д.

И потом используете его при выполнении playbook. А с помощью Ansible Navigator (рассмотрим далее) запуск контейнера осуществляется автоматически: вы просто запускаете playbook, и он автоматически выполняется в EE (магия вне Хогвартса).

EE – это про переносимость, воспроизводимость и предсказуемость. Вы точно знаете, в каком окружении выполнится автоматизация. В результате:

• Никакой зависимости от настроек окружения хостовой системы;

• Никаких “а у меня не запускается”;

• Меньше сюрпризов в боевой эксплуатации.

Пример состава EE можно посмотреть здесь ^[15].

Ansible Builder: сборка EE без боли

Когда речь заходит о Execution Environment, часто возникает логичный вопрос:

“А как мне вообще собрать такой контейнер, в который всё уже установлено – и Python, и нужные коллекции, и модули, и линтеры, и пр.?”

Создавать EE вручную возможно, но не нужно. Для этого есть Ansible Builder – инструмент, который берёт на себя задачу по сборке образа для EE. Вы пишете небольшой YAML-файл со списком того, что нужно добавить:

• Какие коллекции подключить;

• Какие зависимости для Python;

• Какие дополнительные системные пакеты или утилиты (если нужно).

А дальше Ansible Builder превратит его в Containerfile, в котором опишет всё как нужно, сам запустит сборку образа – и вы получите готовую EE для запуска playbook.

Примеры YAML-файла для сборки EE можно посмотреть здесь ^[16]. А тут ^[17] проект ansible-builder на GitHub. 

Ansible Navigator: запуск и отладка автоматизации без боли

В 2021 году выходит новый инструмент – Ansible Navigator, который стал ответом на современные подходы, применяемые в работе с Ansible. Он объединяет многие сценарии работы, которые ранее поддерживались разрозненными CLI-командами. Это своего рода “обёртка” над привычными утилитами ansible-playbook, ansible-lint, ansible-config и пр.- теперь это всё можно запустить через ansible-navigator.

Пример запуска традиционных ansible инструментов и аналогичной команды с помощью нового ansible navigator:

Заметное нововведение для режима работы в терминале – это консольный TUI-интерфейс (Text User Interface) с интерактивным меню для выполнения и отладки playbook. Когда вы запускаете playbook через Navigator, вы не просто получаете сплошной поток логов (хотя такой режим, как и раньше, тоже возможен), вы видите всё структурировано: playbook разбит на Play и Task. Вы можете:

1. Через меню выбрать конкретный Play из playbook

   

2. “Провалиться” в Play, посмотреть результаты работы всех задач (Task):

   

3. “Провалиться” в конкретную Task, посмотреть подробный лог выполнения:

   

Навигация удобная и интуитивная (прям как в vim ;).

Одной из самых важных особенностей Ansible Navigator – поддержка работы с EE. Все, что нужно, это определить нужный параметр, и Ansible Navigator автоматически запустит выполнение playbook внутри EE. Интерактивный режим позволит вывести список доступных EE, подсветить используемую и исследовать её на предмет установленных коллекций Ansible.

Вдобавок улучшены механизмы отладки. При каждом запуске playbook Ansible Navigator автоматически сохраняет replay-файл – это подробный лог в формате JSON. Раньше приходилось делать скриншоты, специально сохранять и копировать логи, объяснять, какая задача упала. Теперь просто отправили replay-файл другому человеку и он сможет увидеть выполнение так же, как у вас в интерактивном режиме. Это удобно не только для отладки, но и для обучения ^[18] и демонстрации результата.

Отдельно необходимо обратить внимание, что функциональность Ansible Navigator очень полезна на этапе разработки и отладки автоматизации. Но инструмент также может использоваться и для удобного запуска playbook. Именно поэтому Ansible Navigator можно назвать утилитой ansible-playbook следующего поколения. Он делает работу с Ansible более наглядной (TUI-интерфейс), предсказуемой (запуск в EE) и удобной для отладки (replay-файлы).

Здесь ^[19] примеры настройки и работы в Ansible Navigator, а тут ^[20] проект ansible-navigator на GitHub 

Ansible Creator: таблетка от страха чистого листа

Максимально простая и понятная утилита. Чтобы не начинать проект автоматизации на Ansible с нуля, придумали Ansible Creator, который сразу создаёт структуру проекта или коллекции с шаблонами и примерами.

Здесь ^[21] примеры использования, а по ссылке ^[22] проект ansible-creator на GitHub.

Ansible Lint: не пиши лапши

Cамый мудрый (читай старый) инструмент из экосистемы Ansible. Он называется как линтер, выглядит как линтер и работает как линтер. Сомнений нет – это классический линтер, который проверяет код на соответствие лучшим практикам Ansible. В философии ansible-lint playbook, роли и коллекции должны читаться как документация – понятно и однозначно. Вы же хотите через год с легкостью разобраться в собственном коде? Используйте линтер, с ним шансы значительно увеличиваются.

Также вы можете полностью положиться на его рекомендации в вопросе адаптации Ansible-контента к нововведениям в Ansible. Как это происходит? Инструмент выявляет устаревшие (deprecated) функции или практики и предупреждает об их удалении или изменении в будущих релизах Ansible. Это помогает менее болезненно и более контролируемо переходить на новые версии Ansible.

Подробности о возможностях с примерами использования ansible-lint смотрите здесь ^[23]. Тут ^[24] ссылка на проект ansible-linter на GitHub.

Ansible Molecule: любишь кодить, люби и тесты писать

Если уж разрабатываете роли, playbook и коллекции, то обязательно проверьте, что ваш код работает как надо. Ansible Molecule – отличный инструмент для тестирования. Позволяет в одну команду:

• развернуть инфраструктуру для подготовки окружения;

• отыграть Ansible роль или playbook;

• протестировать успешность выполнения;

• и почистить за собой, удалив развернутую инфраструктуру.

Поддерживает подготовку нужного окружения на базе различных ОС и дистрибутивов через Vagrant, контейнеры, облачных провайдеров и системы виртуализации, повышая вариативность тестовых условий. Для тестирования корректности выполнения ролей или playbook используются либо стандартные модули Ansible, либо, более продвинутый уровень, фреймворк Testinfra. Инструмент Ansible Molecule может быть встроен в пайплайн CI/CD для автоматизированного запуска тестирования.

Подробности, примеры и как начать смотрите здесь ^[25]. Тут ^[26] ссылка на поект Molecule на GitHub.

Ansible VS Code Extension + VS Code Dev Container: быстрый старт Ansible-автоматизатора

Если вы занимаетесь разработкой Ansible-контента, т.е. пишете playbook, роли и коллекции, то, среди редакторов кода, VS Code – это однозначно ваш выбор номер один. А его расширение для Ansible – настоящая находка, которая добавляет в VS Code интеллекта ^[27]:

• Подсветка синтаксиса, автодополнение и автоматическая проверка линетром;

• Быстрый, в один клик, переход на документацию Ansible-модуля, которая как правило всегда идет с примерами;

• Интеграция с инструментами Ansible Navigator и EE.

А еще под VS Code есть расширение DevContainer, которое позволяет быстро подготовить окружение для разработчика, используя контейнеризацию. Например, можно взять готовый образ контейнера, в который упакованы все ранее перечисленные инструменты из экосистемы Ansible (Builder, Navigator, Creator и пр.) и с помощью связки VS Code + DevContainer быстро запустить окружение разработчика на Ansible, без необходимости установки всех утилит и Python на хостовую машину. На хостовой машине, помимо VS Code и расширений, нужен только podman/docker. А благодаря WSL такое окружение с легкостью запускается на Windows.

В результате получаете готовое, изолированное и воспроизводимое окружение разработчика, которое запускается за минуты. А работа с Ansible-контентом становится проще и быстрее.

Если интересно, как быстро настроить среду разработчика автоматизации на Ansible начните отсюда ^[28].

Тут ^[29] ссылка на проект расширения Ansible для VS Code на GitHub.

AWX: ЦУП для автоматизации на Ansible

Несмотря на богатство экосистемы Ansible консольными утилитами, особенно хорошо известной является утилита ansible-playbook как базовый инструмент для запуска автоматизации. Очень частый сценарии использования ansible-playbook – это персональный инструмент, установленный на рабочую станцию или сервер, с которых выполняется запуск. Но по мере роста команды, инфраструктуры и критичности процессов автоматизации встает задача централизованного управления. Необходимо отслеживать кто запустил, хранить следы запуска, управлять доступом к автоматизации, обеспечивать отказоустойчивость и надежность подсистемы автоматизации.

AWX – это уже серьёзный серверный компонент. Через графический WEB-интерфейс, API или CLI он позволяет централизованно запускать и отслеживать выполнение Ansible-автоматизации на тысячах и десятках тысяч узлов управляемой инфраструктуры. AWX умеет работать в кластере для отказоустойчивости и горизонтального масштабирования и подходит для инфраструктур больших и маленьких.

В больших командах важно, чтобы инженер видел и запускал только определенные автоматизации и по отношению к тем элементам управляемой инфраструктуры, за которые он отвечает. Это легко реализовать в AWX благодаря гибкой ролевой модели доступа и интеграции с внешними системами учетных данных (LDAP, SAML, OIDC).

В AWX можно настроить запуск автоматизации по расписанию – как cron, только централизованно, в едином интерфейсе и с возможностью мониторинга и контроля выполнения. А можно выставить отдельные автоматизации в цепочку и запускать одной кнопкой, добавляя в цепочку логику ^[30] по успешности и неуспешности выполнения или точки подтверждения со стороны ответственного.

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

Стоит напомнить, что именно с AWX, а точнее его предшественника Ansible Tower, фактически начался коммерческий путь Ansible. На сегодня AWX является ключевым проектом для таких коммерческих платформ автоматизации, как Ansible Automation Platform от Red Hat и Astra Automation от “Группы Астра” (https://astra-automation.ru/ ^[31]), в которых AWX представлен под компонентом Automation Controller ^[32].

Тут ^[33] ссылка на проект AWX на GitHub.

Pulp + Galaxy NG (2020): Ansible Galaxy на личной прикормке

Всем, кто работает с Ansible, знаком WEB-портал Ansible Galaxy – это огромная библиотека, основной ресурс для публикации, хранения и распространения коллекций Ansible. Портал предоставляет удобный интерфейс для поиска коллекций, просмотра их содержимого и ознакомления с документацией и примерами использования. При установке коллекций Ansible консольная утилита ansible-galaxy по-умолчанию ищет их именно на этом портале. Ansible Galaxy – это важный ресурс и источник контента при разработке на Ansible, настолько же важный, как и портал с библиотеками для любого языка программирования. Представьте, вы разрабатываете на Python без использования PyPI?

Но Ansible Galaxy остается публичным ресурсом. Чтобы добавить больше контроля в процесс работы с коллекциями Ansible нужно подумать об организации внутреннего ресурса, который избавит от внешних зависимостей, позволит лучше управлять версиями, уменьшит время загрузки коллекций и в конце концов повысит общий уровень безопасности.

Технический стек Ansible Galaxy известен. Первое – это pulp – система управления репозиториями для хранения пакетов и артефактов. Pulp модульный – добавляете необходимый плагин и работаете с контентом, который вас интересует. Есть плагин для организации репозитория коллекций Ansible (pulp_ansible) и есть плагин для организации реестра контейнеров (pulp_container). И есть Galaxy NG – это плагин к Pulp, который используется для организации Ansible Galaxy портала.

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

• Собственные самописные коллекции Ansible для решения внутренних задач

• Добавленные на внутренний портал и проверенные коллекции из Ansible Galaxy

Т.е. не изменяя своему опыту ^[34] работы с Ansible, вы сможете работать полностью в закрытом сегменте.

Именно на таком стеке технологий работают компоненты Automation Hub ^[35] и Private Automation Hub ^[36] платформы Astra Automation.

Ссылки на проекты на GitHub:

• Galaxy NG ^[37]

• Pulp Project ^[38] 

• pulp_ansible ^[39] 

• pulp_container ^[40] 

Event-Driven Ansible: работа на рефлексах

Всем, кто знаком с Ansible, известно, что классический путь – это запуск playbook вручную или по расписанию. В 2022 году появился Event-Driven Ansible (далее EDA), который добавил совершенно новый подход: playbook запускаются не по расписанию, не вручную, а в ответ на события. EDA получает события или сигналы от различных источников (системы мониторинга, SIEM, брокеры сообщений и пр), анализирует их и запускает нужную автоматизацию в реальном времени. Иными словами, он превращает Ansible из инструмента “по требованию” в инструмент “по событию”. Всегда когда есть событие, на которое известны последующие действия, EDA будет полезным.

Источник, что считать событием и какое действие выполнить в ответ, описываются через rulebook (свод правил). Сценарии применения разнообразны – реакция ^[41] на инциденты, автоматическое создание виртуальной инфраструктуры и масштабирование, участие в процессах CI/CD и пр.

EDA расширяет возможности автоматизации и выступает как один из ключевых компонентов для платформ Ansible Automation Platform от Red Hat и Astra Automation от “Группы Астра” (Event-Driven Automation ^[42]).

Тут ^[43] ссылка на проект Event Driven Ansible Controller на GitHub.

Вместо финала: немного маркетинга

Как вы видите, Ansible уже давно не один инструмент, а постоянно развивающаяся экосистема взаимосвязанных проектов. Репозитории проектов ^[44] полностью открыты и доступны на GitHub, но собрать их воедино, обеспечить совместимость, безопасность и поддержку в масштабах предприятия – нетривиальная задача. Именно для решения этой задачи и создаются коммерческие enterprise-платформы.

В условиях российских реалий и требований к импортозамещению мы взяли обширную экосистему Ansible за основу и разработали платформу Astra Automation. Платформа не просто объединяет проверенные upstream-проекты, но и адаптирована под задачи российского бизнеса: обеспечивает совместимость с российскими ОС (Astra Linux), предоставляет готовые коллекции Ansible для российских решений и гарантирует полную техническую поддержку на русском языке.

Таким образом, знакомство с экосистемой Ansible – это первый шаг. А для тех, кому нужен готовый, поддерживаемый и безопасный инструмент для корпоративного использования, следующим логичным этапом становится внедрение платформы вроде Astra Automation.

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

История Ansible продолжается …