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 и конфигурация, описанная в виде YAML‑файлов. И ему это удалось, достаточно быстро инструмент оказался очень популярным. Уже через год Михаэль основал Ansible Inc., а через два выпустил Ansible Tower — серверное приложение с расширенным функционалом и веб‑интерфейсом, упрощающее использование Ansible в больших командах и корпоративной среде. Сотни компаний по всему миру, включая компании из Fortune 50, стали использовать Ansible.

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

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

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

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

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

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

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

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

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

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

И как показывает практика прошлых лет, почти все они со временем переходят на более зрелые инструменты, и первым среди них обычно оказывается именно 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

• The Future of Ansible Content Delivery

• Announcing the Community Ansible 3.0.0 Package

А проект Ansible на GitHub тут.

Современная экосистема 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 можно посмотреть здесь.

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

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

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

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

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

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

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

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

Примеры YAML‑файла для сборки EE можно посмотреть здесь. А тут проект 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‑файл другому человеку и он сможет увидеть выполнение так же, как у вас в интерактивном режиме. Это удобно не только для отладки, но и для обучения и демонстрации результата.

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

Здесь примеры настройки и работы в Ansible Navigator, а тут проект ansible‑navigator на GitHub

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

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

Здесь примеры использования, а по ссылке проект ansible‑creator на GitHub.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тут ссылка на проект 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

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

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

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

• Galaxy NG

• Pulp Project

• pulp_ansible

• pulp_container

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

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

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

EDA расширяет возможности автоматизации и выступает как один из ключевых компонентов для платформ Ansible Automation Platform от Red Hat и Astra Automation от «Группы Астра» (Event‑Driven Automation).

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

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

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

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

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

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

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