На прошедшей в конце сентября конференции AnsibleFest 2021 мы анонсировали новую, вторую версию платформы автоматизации Ansible, над которой трудились два года. Сегодня мы дадим краткий обзор концептуальных новшеств и полезных ресурсов по Ansible Automation Platform 2, а также начнем чуть подробнее знакомиться с ее новыми функциями (и продолжим это делать в следующих статьях данной серии).

Что нового в Ansible Automation Platform 2

Прежде всего, в этой версии мы стремились улучшить фундаментальные компоненты Ansible Automation Platform и сделать так, чтобы разработчикам автоматизационного контента и администраторам платформ автоматизации было легче и проще вести автоматизацию в масштабе предприятия. Всё, что вы знаете и что вам нравится в сценариях Ansible Playbooks, по большому счету осталось неизменным. Изменилась фактическая реализация того фундамента, на основе которого сценарии автоматизации создаются, управляются и работают в больших комплексных ИТ-средах.  Очевидно, что сегодня корпоративная платформа автоматизации должна строиться и поддерживаться с прицелом на контейнерные и гибридные облачные среды.

Итак, что же принципиально нового в Ansible Automation Platform 2?

Во-первых, в рамках СПО-проекта Ansible было проведено отделение контента Ansible от исполнительной части Ansible. Для этого были созданы так называемые Ansible Content Collections, в которых модули, плагины, роли и прочие Ansible-компоненты хранятся в дискретной атомарной форме.

В последнее время мы в основном были заняты тем, что переносили большую часть контента Ansible (модули, плагины) в коллекции, которые живут и поддерживаются отдельно от опенсорсного проекта Ansible. Главный плюс здесь в том, что контент теперь обновляется независимо от самого проекта Ansible. То есть, его можно выпускаться непрерывно и асинхронно, не трогая стабильную версию компонентов Ansible, которые отвечают за выполнение автоматизаций.

Во-вторых, в Ansible Tower плоскость управления (control plane) теперь отделена от плоскости исполнения (execution plane) с переименованием соответствующих компонентов в контроллер автоматизации (automation controller) и среды исполнения автоматизаций (automation execution environments).

Ansible Tower был разделен на два компонента: контроллер автоматизации (плоскость управления) и среды исполнения автоматизации (плоскость исполнения). Это сделано для большей масштабируемости и предсказуемости автоматизаций в масштабе предприятия. Разделив Tower на два компонента, мы получили возможность запускать компоненты исполнения не только на узле управления, но и в другом месте, что важно для автоматизаций в гибридных облачных и контейнерных средах, вроде Red Hat OpenShift. В следующей версии Ansible Automation Platform с номером 2.1 появится еще один важный базисный компонент – automation mesh (считай, та же сервисная mesh-сеть, но для Ansible), который заменит собой изолированные узлы в Ansible Tower. И это уже гораздо интереснее, поскольку открывает новые варианты автоматизации, например, вплоть до edge-систем или прямоних, либо автоматизация в облаке.

В-третьих, новые инструменты, расширяющие возможности тех, кто занимается автоматизацией на предприятии.

Раньше разработка Ansible-контента в значительной степени зависела от человека, который создавал и курировал контент. Новые же инструменты, такие как Навигатор автоматизационного контента (ansible-navigator) и Построитель среды исполнения (ansible-builder), предоставляют больше согласованности при работе с контентом, который разрабатывается на рабочей станции и при этом предназначается для определенного экземпляра контроллера автоматизации. Достигается это за счет применения сред исполнения автоматизации – они гораздо более предсказуемы, переносимы и масштабируемы по сравнению с виртуальными средами (virtualenv) Python, которые используются в старой версии Ansible.

Полезные ресурсы

Ansible Automation Platform 2 предлагает улучшенную архитектуру и ряд новых полезных инструментов для масштабирования автоматизации, сохраняя при этом привычный пользовательский опыт работы с Ansible. Мы хотим дать максимум информации, чтобы вы могли быстро освоить новые функции и начать прорабатывать стратегию миграции на новую платформу Ansible (если это применимо), первая общедоступная версия которой с номером 2.1 выйдет, как ожидается, в конце этого года. Так что следите за базой знаний на портале Red Hat Customer Portal, где будут появляться последние новости и статьи. Кроме того, уже сейчас доступны следующие полезные ресурсы:

Среды исполнения автоматизаций

С распространением ИТ-автоматизации на предприятии растет число сред автоматизации, предназначенных для тех или иных команд и сценариев. И управлять этим средами становится все сложнее, особенно когда процесс начинает масштабироваться до уровня корпоративной ИТ-среды в целом. И поскольку автоматизация теперь является критически важной частью рабочих процессов, Ansible Automation Platform 2 помогает решить эту проблему следующим образом:

  • Администратор Ansible Automation Platform получает возможность предоставлять и управлять средами исполнения автоматизации (подробнее см. ниже) для различных групп ИТ-специалистов, например, для сетевиков и облачников. Для каждой из таких групп согласно её роли задается лишь соответствующий контент автоматизации, но используется один и тот же базовый образ, а не полноценная отдельная среда автоматизации.

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

  • Команды автоматизации получают возможность задавать, создавать и обновлять свои среды автоматизации без привлечения администратора платформы автоматизации для внесения в нее изменений.

  • Создание и распространение сред исполнения выполняется через частный хаб автоматизаций (Private Automation Hub), что обеспечивает согласованность и удобство использования таких сред различными командами.

  • Сторонние разработчики и партнеры получают возможность создавать свои собственные среды исполнения автоматизации для своих пользователей и заказчиков с помощью недавно выпущенного инструмента командной строки ansible-builder.

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

Для успеха ИТ-автоматизации она должна быть согласованной и надежной. У одного из наших заказчиков была отдельная группа администраторов Ansible Automation Platform, которые поддерживали более 40 виртуальных сред для различных команд внутри организации. Эти команды использовали разные версии Ansible, и, например, сетевикам требовались разные наборы контента автоматизации (и зависимости) под конкретные устройства, а разработчики создавали свои собственные среды для тестирования тех или иных приложений.

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

Именно для таких кейсов в Ansible Automation Platform 2 и появились среды исполнения автоматизации. Это атомарные образы, на которых и исполняются все автоматизации. Среды исполнения автоматизации содержат следующие вещи:

  • RHEL UBI 8

  • Ansible 2.9 или Ansible Core 2.11

  • Python 3.8

  • Необходимые коллекции Ansible Content Collections

  • Коллекции python или зависимости по бинарным компонентам

Такой подход позволяет стандартизировать то, как создаются и распространяются среды, в которых выполняется автоматизация. В двух словах, среды исполнения автоматизации – это контейнерные образы, упрощающие работу администраторов платформы Ansible.

Роль сред исполнения автоматизации в Ansible Automation Platform 2.0

Архитектура контроллера автоматизации 4.0
Архитектура контроллера автоматизации 4.0

Среды исполнения автоматизации – это одна из составляющих концепции Red Hat по разделению плоскости управления и плоскости исполнения с целью сделать платформу более масштабируемой для разработчиков и администраторов, которым нужно, чтобы автоматизации согласованно работали на разных платформах. Поэтому теперь все пользовательские зависимости задаются на этапе разработки автоматизации, а не при ее администрировании или развертывании. Разделение функций исполнения и функций управления позволяет ускорить циклы разработки, а также повысить масштабируемость, надежность и переносимость автоматизаций между вычислительными средами. Среды исполнения автоматизации – это то, благодаря чему Ansible Automation Platform теперь поддерживает распределенные архитектуры и позволяет выполнять автоматизацию в масштабе предприятия.

Что такое ansible-builder

Итак, теперь вы знаете, что такое среды исполнения автоматизации, в чем их преимущества и какова их роль в Ansible Automation Platform 2. Осталось научиться их создавать.

Чтобы разработчики контента и администраторы платформы Ansible могли воспользоваться преимущества этих сред, мы создали инструмент под названием ansible-builder, который создает среды исполнения на основе сведений о зависимостях, которые заданы в различных коллекциях Ansible Content Collection, а также задаются пользователем.

Вместе с Ansible Automation Platform 2 в реестре Red Hat Container Registry появился набор готовых и поддерживаемых сред исполнения автоматизации. Вы можете использовать эти образы в различных целях, они предоставляются в рамках подписки на Ansible Automation Platform. Поддерживаемые среды исполнения автоматизации хостятся в родительском репозитории под названием ansible-automation-platform-20-early-access на сайте registry.access.redhat.com. Сейчас там доступны следующие готовые среды:

  • Минимальная (ee-minimal-rhel8) – содержит Ansible-2.11 и собрана на базе Red Hat Universal Base Image 8 и python-3.8. Этот образ не содержит коллекций. Его можно использовать в качестве базового для создания сред исполнения автоматизации со своими собственными коллекциями или коллекциями Ansible Certified Content Collections, доступными на сайте Automation Hub.

  • Поддерживаемая (ee-supported-rhel8) –  дефолтный образ, идущий с контроллером автоматизации. Представляет собой минимальный образ, плюс Ansible Content Collections, поддерживаемые Red Hat.

  • Ansible 2.9 (ee-29-rhel8) – содержит Ansible-2.9 и все необходимые зависимости Ansible. Лучше всего подходит для миграции на Ansible Automation Platform 2.0 с Ansible Automation Platform 1.2.

Для создания своих сред исполнения автоматизации поверх штатных образов Ansible Automation Platform 2 используется Построитель среды исполнения ansible-builder.

Подробнее о нем и о том, как с ним работать том, можно почитать в блоге проекта Ansible и в документации.

Для кого предназначен ansible-builder

Средами исполнения автоматизации пользуются как разработчики Ansible-контента, так и администраторы платформы автоматизации. Поэтому и те, и другие должны понимать, как создавать такие среды с помощью ansible-builder. Их могут создавать разработчики и предоставляться администраторам, или наоборот, но в любом случае, надо помнить, что конечная цель состоит в том, чтобы и на машине разработчика, и в продакшн использовалась одна и та же среда исполнения, чтобы больше не надо было вручную поддерживать много разных виртуальных сред python.

Подводим итоги

Ansible Automation Platform 2 включает множество новых функций, которые дополняют концепцию сред исполнения автоматизации и позволяют сделать, например, следующие вещи:

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

  • Предоставить сторонним разработчикам и партнерам возможность создавать собственные среды исполнения автоматизации для своих пользователей и заказчиков с помощью недавно выпущенного инструмента командной строки ansible-builder.

В следующих статьях этой серии мы подробнее расскажем о контроллере автоматизации, о частном хабе, о навигаторе по автоматизационному контенту, а также поделимся соображениями по миграции на Ansible Automation Platform 2.

Комментарии (9)


  1. amarao
    16.10.2021 12:10
    +8

    Я очень плотно использую ансибл, но я не понимаю зачем всё это. Т.е. я читаю английский блог, пытаюсь понять "нафига" и не могу. Что оно полезное делает? Пакует коллекции с правильным питоном и ансиблом в image? Это ж один Dockerfile на пять строчек.

    Вы можете объяснить человеческим языком, какая от этого польза?


    1. shibanovan
      16.10.2021 12:21
      +2

      Тоже внимательно и медленно прочитал статю и вообще не понял, чем оно лучше чем просто ansible.


      1. evg_krsk
        17.10.2021 16:46
        +1

        Тем что отделы выделены, они не могут не работать, не сдавать KPI.


    1. ggo
      18.10.2021 10:50

      Наверно есть возможность создавать проприетарные ansible-образы, и продавать их.


    1. DANic
      18.10.2021 11:01

      Согласен, по тексту статьи не понятно что такое Ansible Automation Platform и зачем он нужен

      Познакомиться можно с AWX

      https://github.com/ansible/awx

      AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.

      Тогда становиться понятно что это GUI для запуска плейбуков (если очень упрощенно)

      А со второй версии выделили в отдельную сущность EE (Execution Environment)

      Теперь можно использовать один контролер

      И ранить каждый плейбук в своем EE в котором в свою очередь уже предустановлены python и ansible зависимости


      1. amarao
        18.10.2021 12:35
        +2

        Последний раз, когда я смотрел на AWX и его экиваленты, я обнаружил, что инвентори там имеют какой-то очень странный статус и пушают полиси, которого я не ожидал. Если бы это был просто web-ui для ansible-specific CI, то оно бы зашло как инструмент. А бороться чужой полиси во имя UI... Зачем, когда есть пачка CI'ев вокруг?


        1. strangeman
          22.10.2021 14:26

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

          В итоге взяли Rundeck и счастливы.


  1. allexx
    18.10.2021 14:11

    "можно выпускаться непрерывно и асинхронно", быть может все же независимо чем асинхронно.


  1. stalker_by
    29.10.2021 00:14

    Мало того что оригинальный текст писал не DevOps а маркетолог, так ещё и переводил тех-писатель без технического опыта. Или переводить "control plane" как "плоскость управления" это нынче модно?