Заключительная статья серии. В ней мы расскажем о таких компонентах новой версии платформы Ansible, как Private Automation Hub и Automation Content Navigator, а также поговорим о том, что надо принять во внимание при планировании миграции.
Private Automation Hub
В состав Ansible Automation Platform 2 входит Private Automation Hub 4.3. Он нужен для того, чтобы разработчики могли сотрудничать друг с другом и с операторами системы автоматизации, выкладывая в общий доступ создаваемый ими контент автоматизации. Хаб также помогает упорядочить доставку кода Ansible внутри организации.
Private Automation Hub 4.3 в первую очередь обеспечивает поддержку сред выполнения автоматизаций. Среды выполнения – это стандартизированный способ определения, создания и дистрибуции сред, в которых выполняются автоматизации. В двух словах, среды выполнения автоматизации представляют собой контейнерные образы, которые значительно упрощают администрирование платформы Ansible, подробнее мы говорили о них в первой статье этой серии.
Private Automation Hub – это локальный репозиторий контейнерных образов сред выполнения для тех, кто автоматизирует физические или виртуальные серверы с помощью платформы Ansible.
Для кого предназначен Private Automation Hub?
Хаб предназначен для того, чтобы собирать и хранить контент автоматизации, создаваемый разработчиками, и предоставлять его операторам. Разработчику он помогает делиться создаваемыми им средами выполнения, куда можно легко упаковать всё необходимое и получить на выходе готовую автоматизацию, с другими разработчиками или операторами, чтобы они применяли эти наработки в своей деятельности. Контроллер автоматизации может напрямую синхронизироваться с Хабом, скачивать из него необходимые среды выполнения и регулировать доступ.
Основной пользователь Хаба – это администратор или оператор, отвечающий за сбор и дистрибуцию контента автоматизации на предприятии, его обычно называют инженером по дистрибуции или инженером по релизам. Представьте себе диаграмму Венна для создателей контента и операторов / администраторов. Хаб предназначен для того, кто взаимодействует с обоими кругами на этой диаграмме (или может находиться в любом из них в зависимости от организационной структуры).
Разработчики – создают плейбуки Ansible, роли,модули, коллекции.
Архитекторы – расширяют использование автоматизации на уровне различных команд для поддержки ИТ-процессов и оптимизации внедрения.
Операторы – отвечают за проверку работоспособности платформы и фреймворков автоматизации.
Во многих организациях некоторые или все эти роли совмещаются, а определенные задачи автоматизации могут передаваться на аутсорсинг.
Использование Private Automation Hub
Как видно на диаграмме выше, разработчики автоматизаций создают контент, как и в предыдущей версии платформы Ansible. В свою очередь, утилита командной строки ansible-builder создает среду выполнения на основе вашего файла execution-enviornment.yml, как описано здесь. А затем создатели автоматизаций могут публиковать своей контент на Private Automation Hub.
Практический пример
Покажем, как скачать поддерживаемую среду выполнения автоматизации из Red Hat Ecosystem Catalog (registry.redhat.io), пометить ее как локальную и затем отправить в Private Automation Hub.
Для начала надо авторизоваться на registry.redhat.io.
В Red Hat Enterprise Linux 8 это делается так:
$ podman login registry.redhat.io
Username: seanc@redhat.com
Password: ********************
Login Succeeded!
$Теперь можно скачать одну из поддерживаемых сред выполнения для использования в Ansible Automation Platform 2. Есть три варианта такой среды:
Минимальная (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.
Совместимая (ee-29-rhel8) – содержит Ansible 2.9 и все требуемые зависимости Ansible. Лучше всего подходит для тех, кто планирует мигрировать с Ansible Automation Platform 1.2 на версию 2.0, и соответственно с Ansible 2.9 на Ansible 2.11+.
В нашем примере мы скачаем среду выполнения ee-minimal-rhel8. Отметим, что на Private Automation Hub может храниться несколько сред выполнения. Кроме того, разработчики автоматизаций могут создавать там собственные среды с помощью ansible-builder, подробнее см. здесь.
$ podman pull registry.redhat.io/<container image name>:<tag>
$ podman pull registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8:2.0.0-11
Trying to pull registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8:2.0.0-11...
Getting image source signatures
Checking if image destination supports signatures
Copying blob 4644f822544e skipped: already exists
Copying blob 4d0d850cd4ad skipped: already exists
Copying blob 96965a3a8424 skipped: already exists
Copying blob 3bbba07a88b0 skipped: already exists
Copying blob 895c54e89fd8 [--------------------------------------] 0.0b / 0.0b
Copying config 408bd0e3a5 done
Writing manifest to image destination
Storing signatures
408bd0e3a56123cabe76a5afaa16c7487173e74f745f6051a139813d702a0cТеперь выведем на экран список всех скачанных сред выполнения с помощью команды podman images.
$ podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.redhat.io/ansible-automation-platform-20 early-access/ee-supported-rhel8 latest 408bd0e3a561 6 days ago 920 MBСкачав образы из интернета, пометим их как образы, которые должны использоваться в реестре контейнеров нашего Private Automation Hub:
$ podman tag registry.redhat.io/[container image name]:[tag] [automation hub URL]/[container image name]Для нашего инстанса Private Automation Hub еще не настроен DNS, поэтому вместо имени будем использовать IP-адрес его хоста:
$ podman tag registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8 192.168.1.5/example_eeНовый тег контейнерного образа – example_ee:
$ podman tag registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8 192.168.1.5/example_eeДля авторизации Private Automation Hub будем использовать учетные данные, заданные на этапе инсталляции:
$ podman login -u=[username] -p=[password] [automation-hub-url]В нашем случае это выглядит так:
$ podman login --tls-verify=false -u="admin" -p="mypassword" 192.168.1.5
Login Succeeded!Опция --tls-verify=false нужна здесь, поскольку у нас не задан DNS и TLS-сертификаты.
И, наконец, выполняем публикацию:
$ podman push [automation-hub-url]/[container image name]Для нашей среды на экране это будет выглядеть примерно так:
$ podman push --tls-verify=false 192.168.1.5/example_ee
Getting image source signatures
Copying blob d7ecef9dcc97 done
Copying blob 9132e95b7c1b done
Copying blob bc7bdf0ec1b9 done
Copying blob 0122cc8a95bd done
Copying blob 12a68283d0e0 done
Copying config 408bd0e3a5 done
Writing manifest to image destination
Storing signatures
$ podman --version
podman version 3.2.2Войдем на веб-консоль и увидим, что там появился новый реестр Container Registry, а в нем – наш example_ee:
Синхронизация Private Automation Hub с Automation Controller
Для синхронизации сред выполнения создадим учетные данные Container Registry.
URL для авторизации – это DNS-имя или IP-адрес хоста нашего Private Automation Hub (без https).
Затем идем в боковое меню Execution Environments, создаем новую среду выполнения и прописываем только что заданные учетные данные. Как заполнять другие поля см. здесь.
И наконец, в шаблоне задания (боковое меню Templates) назначаем среду выполнения, как показано в красной рамке на картинке ниже:
Что дальше?
Документация:
Automation controller - Use an execution environment in jobs
Private automation hub - Managing containers in private automation hub
Automation Content Navigator
В новой версии платформы инструмент ansible-navigator пришел на смену старому ansible-playbook и другим утилитам командной строки вида ansible-*.
Дело, конечно, не ограничивается только сменой имени, ansible-navigator представляет собой основное приложение для разработки и выполнения автоматизаций. Старый Ansible-playbook был одной из первых утилит, используемых в среде автоматизации Ansible. Унаследовав от него простоту использования, Automation Content Navigator позволяет более детально отследить выполнение автоматизаций. Помимо отладки автоматизаций, ansible-navigator с помощью соответствующих подкоманд позволяет проверять различные аспекты среды, включая среды выполнения автоматизации, объекты inventory и collection, а также модули и многое другое.
Для кого предназначен Automation Content Navigator?
Он предназначен главным образом для разработчиков автоматизаций. Это могут быть те, кто создает автоматизированные задачи из доступных модулей, либо те, кто переносит роли в Коллекции, либо те, кто разрабатывает модули с нуля. Content navigator выполнен в виде текстового пользовательского интерфейса и отлично смотрится в терминальном сеансе даже при работе в популярных редакторах кода с включенными терминальными панелями.
Стартовый экран текстового пользовательского интерфейса (TUI)
Если запустить Навигатор без дополнительных опций, то вы увидите стартовый экран с различными подкомандами.
Навигация здесь довольно простая, а внизу экрана есть подсказки по горячим клавишам. Подкоманды вводятся в vim-образном формате: :<команда>.
Изучаем локальную среду
У каждого проекта может быть своя собственная конфигурация Навигатора (файл ansible-navigator.yml). Общими параметрами конфигурации могут быть имена образов среды выполнения, необходимых для проекта, а также параметры конфигурации Ansible, такие как форки, уровни ведения журналов, параметры создания артефактов и т.д. Настройка Навигатора с привязкой к проектам позволяет другим участникам легко выполнять ветвление, создавать форки и иным образом расширять проекты автоматизации.
ansible-navigator:
ansible:
inventories:
- hosts
execution-environment:
enabled: true
container-engine: podman
image: ansible-automation-platform-20-ee-supported-rhel8
pull-policy: missingНавигатор также имеет встроенные подкоманды, с помощью которых разработчики могут легко исследовать среду. Например, здесь есть две очень полезные подкоманды: :inventory – для просмотра inventory проекта и :collections, позволяющая отобразить список коллекций, доступных в указанной среде выполнения. Если раскрыть любую коллекцию в этом списке, то можно увидеть список всех содержащихся в ней модулей, а также документацию и примеры использования.
Выполнение автоматизаций
Команда ansible-navigator run <playbook> запускает playbooks, предварительно скачивая среду выполнения по умолчанию. Для запуска без скачивания используется опция --ee false.
Обратите внимание, как меняется интерфейс при переходе от обзорного экрана к экрану со списком выполняемых сценариев.
Нажатие клавиши с цифрой, соответствующей номеру сценария в этом списке, открывает экран, где отображаются запущенные задачи вместе с текущей запущенной задачей.
Отсюда уже можно проинспектировать любую задачу на предмет дополнительной информации, включая сведения о неудачной попытке выполнения.
Если предпочитаете более традиционный вариант с просмотром выполнения в реальном времени, просто введите команду :st.
Что дальше?
Навигатор устанавливается с помощью RPM, подробнее см. документацию Ansible Automation Platform.
Соображения по миграции
Ansible Automation Platform 2 – это обновленная архитектура, новые инструменты и улучшенный (хотя и привычный) интерфейс. При миграции на нее стоит учесть довольно много аспектов, которые будут рассмотрены ниже с позиций различных сторон, отвечающих за планирование и осуществление миграции. Однако мы отнюдь не претендуем на универсальность, поскольку учесть специфику всех и каждой ИТ-среды и организации невозможно.
Что следует учесть перед миграцией
Мы понимаем, что на оценку и планирование миграции влияет множество факторов, специфичных для каждой конкретной ситуации. Мы постарались выделить критические факторы, позволяющие определить готовность к миграции и то, какой подход лучше всего подойдет вашей организации.
Оценка имеющейся среды
Важно провести предварительную техническую оценку уже имеющейся среды Ansible, поскольку в ней могут быть очень специфические и уникальные конфигурации. Мы рекомендуем выполнить на этом этапе следующие действия:
Проанализировать имеющуюся систему Ansible Automation Platform, включая схемы развертывания, интеграции и все ее особенности, которые могут усложнить миграцию.
Определить, какие изменения требуется внести в вашу среду для соответствия техническим требованиям Ansible Automation Platform 2.
Оценить готовность заинтересованных сторон к планированию и проведению миграции.
Проверить соответствие требованиям, применение политик безопасности, а также аудит.
Если вы хотите основательнее углубиться в эти вопросы, советуем обратиться к следующим материалам:
А если я не могу провести полноценную миграцию прямо сейчас?
Вполне возможно, что полноценная миграция для вас пока нецелесообразна. Не беда! Ansible Automation Platform 2 можно внедрять поэтапно, такой метод позволяет ИТ-командам освоиться с новыми инструментами и сократить число задач, которые надо будет выполнить во время миграции.
Мы рекомендуем оценить приведенные ниже задачи и по возможности реализовать их в рамках подготовки к полноценному развертыванию Ansible Automation Platform 2.
Задачи с низким риском | Задачи со средним риском | Задачи с высоким риском |
• Разработать и протестировать плейбуки на базе среды выполнения 2.9. • Создать кастомные среды выполнения, исходя из имеющихся виртуальных сред Python. • Задействовать ansible-navigator и ansible-builder в рабочих процессах. • Интегрировать Red Hat Insights for Ansible для выявления и приоритизации первоочередных автоматизаций. • Создать тестовую среду Ansible Automation Platform 2 для разработчиков и операторов. | • Обновить контент для использования Collections (FQCN). • Установить и настроить Private Automation Hub и использовать контент уже из него. | • Обновиться до последней версии Ansible Automation Platform 1.2. Риски зависят от того, с какой версии AAP 1.x будет выполняться обновление. • Обновить ноды AnsibleTower до RHEL 8. • Заменить изолированные ноды на контейнерные группы. При миграции непосредственно с AAP 1.2 на AAP 2.1 этот шаг не требуется. |
Если вы хотите основательнее углубиться в эти вопросы, советуем обратиться к следующим материалам:
Соображения по стратегии миграции
Допустим, вы провели предварительную оценку и пришли к выводу о целесообразность перехода на AAP 2. Следующий этап – разработка архитектуры, низкоуровневый дизайн и план реализации. Мы рекомендуем учесть на этом этапе следующие моменты.
Миграция имеющегося Ansible-контента
План миграции должен включать в себя оценку используемого сейчас контента автоматизации (роли, коллекции, плейбуки и модули) и его проверку на совместимость с AAP 2. Эта оценка, как минимум, должна включать следующее:
Тестирование и обновление контента автоматизации для поддержки Ansible 2.9 или выше.
Технические аспекты замены выполнения автоматизаций с помощью Ansible Engine 2.9 и идущего вместе с ним контента на среды выполнения с ядром Ansible и сертифицированными / поддерживаемыми Коллекциями.
При использовании Ansible Engine 2.9 миграция на Ansible Content Collections не обязательна, однако рекомендуется перейти на Коллекции как можно быстрее.
Планирование, тестирование и перенос виртуальных сред Python (venvs) в среды выполнения.
Определитесь, нужны ли кастомные среды выполнения, отталкиваясь от зависимостей, необходимых для успешного выполнения вашего Ansible-контента.
Ansible Automation Platform 2 предоставляет инструменты для помощи в миграции.
Отсортируйте имеющийся контент автоматизации по схеме «сохранить / переработать / отказаться» при переходе исключительно на использование Коллекций, либо откажитесь от контента, который больше не используется.
Интеграция с операционной моделью и средой
План миграции также должен прорабатывать вопрос интеграции с имеющимися системами, также оценивать влияние миграции на текущую операционную модель. Ниже приведены рекомендации, которые следует включить в план.
Процессы продвижения контента
Какая схема версионирования контейнеров среды выполнения подходит для моей модели? Например, test, stage, latest и номер релиза.
Определитесь со структурой репозитория на Private Automation Hub (реестра контейнеров), например, отдельные репозитории Ansible Content Collections для тестирования, разработки и продакшн.
Стоит ли развернуть свой Private Automation Hub или лучше прибегнуть к внешним сервисам?
Внедрение платформы
Какая поддержка необходима заинтересованным сторонам для того, чтобы они приняли и начали использовать платформу, и как вы будете подключать сотрудников к работе с этой системой?
Какое обучение и подготовка потребуются?
Кто будет отвечать за управление средами выполнения и коллекциями контента? Будет ли это управление осуществляться централизованно либо на уровне бизнес-подразделений или ИТ-команд?
Управление жизненным циклом сред выполнения
Как будет организовано управление и дистрибуция файлов определения для ansible-builder?
Как будут обновляться и защищаться среды выполнения? Какова будет процедуры реагирования на ситуации, когда требуется пропатчить уязвимости или не допустить нарушения комплаенса?
Управление жизненным циклом платформы
Как будут развертываться новые кластеры и обеспечиваться выполнение системных требований?
Как будет выполняться модернизация кластеров и с какой регулярностью я смогу это делать?
Каковы нефункциональные требования, и как они повлияет на дизайн системы автоматизации? Например, как будет организовано резервное копирование, управление конфигурациями, аварийное восстановление (DR) и высокая доступность (HA).
Модель дистрибуции контента
Какой дизайн контроллера автоматизации оптимален для моей ситуации? Например, многокластерная схема или схема с одним кластером.
Как организовать дистрибуцию контента при наличии нескольких регионов (multi-geo)?
Наблюдаемость, журналы и метрики
Какие метрики позволят оценить успешность платформы?
Какие изменения потребуются, чтобы организовать должный аудит платформы?
Как платформа будет интегрироваться с имеющимися системами журналирования и отчетности?
Что дальше
Обновленная обзорная страница продукта на сайте ansible.com – поможет узнать больше о новых функциях и компонентах Ansible Automation Platform. Также мы подготовили новое интерактивное руководство по функциям продукта.
Если готовы опробовать новую версию Ansible на практике, то у нас есть для этого интерактивные лабы.
Также рекомендуем бесплатный вебинар «Red Hat Ansible Automation Platform предлагает новые способы автоматизации», который прошел 4 ноября и выложен в записи.
При наличии действующей подписки Red Hat можно зайти на страницу раннего доступа на портале Red Hat Customer Portal, где собраны официальные ресурсы по новой версии Ansible, включая официальную документацию по продукту.
