Часть 4: Ansible Tower
Возможно, вы помните, что в январе я написал трилогию блогов, посвященную использованию Ansible, в качестве удобного руководства, которое поможет вам начать работу. Я решил вернуться к этому сейчас и написать еще одну часть о Ansible Tower.
За 6 с лишним месяцев с тех пор, как я написал части 1 , 2 и 3 моего руководства «Приступая к работе с Ansible», его посетили более 10 000 уникальных посетителей. Я очень впечатлен этим одним. Я построил конвейеры инициализации и развертывания на основе ANBIL для еще двух компаний, обе из которых основаны на моей отправной точке Parallax, над которой я работаю с января. Это само по себе собирало звезды и вилки на Github.
И так, к четвертой части: Ansible Tower.
Ansible Tower — это веб-интерфейс пользователя для Ansible , разработанный компанией за проектом Ansible.
Он предоставляет простую в использовании панель мониторинга и контроль доступа на основе ролей, так что отдельным группам легче получить доступ к использованию Ansible для своих развертываний, не прибегая к помощи специально созданных инженеров по сборке / групп DevOps.
В Tower также встроен API REST, который помогает в задачах автоматизации (мы вернемся к этому в части 5).
В этом руководстве я собираюсь настроить сервер под управлением Ansible Tower и подключить его к системе Active Directory. Вы можете использовать любой каталог LDAP, но Active Directory, вероятно, наиболее часто встречается в корпоративных развертываниях.
Предпосылки:
Сервер Ansible Tower (я использую среду VMware, поэтому оба моих сервера являются виртуальными машинами)
1 ядро, 1 ГБ оперативной памяти Ubuntu 12.04 LTS Server, 64-разрядный
Сервер Active Directory (я использую Windows Server 2012 R2)
2 ядра, 4 ГБ оперативной памяти
Официально Tower поддерживает CentOS 6, RedHat Enterprise Linux 6, Ubuntu Server 12.04 LTS и Ubuntu Server 14.04 LTS.
Установка Tower требует подключения к Интернету, поскольку она загружается с их серверов репо.
Мне удалось выполнить автономную установку, но вам нужно настроить какую-то систему для зеркалирования их репозиториев и изменить некоторые настройки в файле Ansible Installer.
Я * настоятельно * рекомендую вам выделить сервер (vm или другой) для Ansible Tower, поскольку установщик перепишет pg_hba.conf и supervisord.conf в соответствии с его потребностями. Все проще, если вы предоставите ему собственную среду для запуска.
Вы * могли бы * сделать это в Докере, хотя я не пробовал, и готов поспорить, что вы напрашиваетесь на неприятности.
Я предполагаю, что вы уже знаете об установке Windows Server 2012 и создании контроллера домена. (Если есть существенный призыв к этому, я мог бы написать отдельный пост в блоге об этом …)
Шаги установки:
SSH на сервер Tower и загрузите файл ansible-tower-setup-latest.gz в каталог ~.
sudo apt-get install python-dev python-yaml python-paramiko python-jinja2 python-pip sshpass sudo pip install ansible
cd ansible-tower-setup-$VERSION
(где $ VERSION — версия Ansible, которой он не подвергался. Mine’s 1.4.11.)
Неудивительно, что установщик Ansible Tower на самом деле является Ansible Playbook (hosts включает в себя 127.0.0.1, и все это определено в group_vars / all и site.yml) — Отлично, да?
Отредактируйте group_vars / all, чтобы установить некоторые нормальные значения по умолчанию — в основном изменяя пароли от того, с чем они поставляются.
pg_password: AWsecret admin_password: password rabbitmq_password: "AWXbunnies"
** Важно ** — Вам действительно нужно изменить эти значения по умолчанию, иначе теоретически возможно, что вы сможете раскрыть свои секреты миру!
В документации сказано, что если вы делаете интеграцию с LDAP, вы должны настроить это сейчас.
На самом деле я собираюсь сделать интеграцию LDAP на более позднем этапе.
sudo ./setup.sh
Если вам повезет, вы должны получить следующее сообщение.
The setup process completed successfully.
Установив Ansible Tower, вы можете открыть веб-браузер и перейти на http: //
Скорее всего, вы получите ошибку с неподписанным сертификатом, но мы можем это исправить позже.
Sidenote по SSL.
Все это делается через Apache2, поэтому файл, который вы хотите отредактировать:
/etc/apache2/conf.d/awx-httpd-443.conf
SSLCertificateFile /etc/awx/awx.cert SSLCertificateKeyFile /etc/awx/awx.key
Теперь вы можете войти в Tower с именем пользователя: admin и любым паролем, который вы указали в group_vars / all во время установки.
Что касается фактического начала работы с Ansible Tower, я настоятельно рекомендую вам ознакомиться с руководством пользователя в формате PDF, на которое я ссылался ранее. Есть хороший пример быстрого старта, и действительно легко импортировать ваши автономные книги.
При импорте книги воспроизведения вручную или с помощью какого-либо механизма управления исходным кодом важно помнить, что в файле YAML книги воспроизведения вы задаете hosts: all , потому что определение хоста теперь будет контролироваться Tower, поэтому, если вы забудете сделать это, вы, вероятно, обнаружите, что ничего не происходит, когда вы запускаете работу.
Теперь для интересной части … (и давайте посмотрим правде в глаза, это бит, который вы все ждали)
Интеграция Ansible Tower с LDAP / Active Directory
Во-первых, убедитесь, что вы можете a) пропинговать сервер AD и b) установить к нему соединение LDAP.
ping — это просто. Просто пропингуйте его по имени хоста (если вы настроили DNS или файл hosts)
LDAP тоже довольно прост, просто подключитесь к нему через порт 389. Если вы получили отказ в соединении, вам нужно проверить настройки брандмауэра Windows.
На сервере Tower откройте:
/etc/awx/settings.py
После строки 80 (или около того) есть раздел о настройках LDAP.
Настройки, которые вы хотите изменить (и некоторые вменяемые примеры):
AUTH_LDAP_SERVER_URI = ''
установите это в строку подключения ldap для вашего сервера:
AUTH_LDAP_SERVER_URI = 'ldap://ad0.wibblesplat.com:389'
На сервере AD откройте «Пользователи и компьютеры» и создайте пользователя в управляемых учетных записях служб с именем «Ansible Tower» и назначьте ему соответственно непонятный пароль. Отметьте это как «Пароль никогда не истекает».
Мы будем использовать этого пользователя для формирования Bind DN для аутентификации LDAP.
Я также создал другую учетную запись в AD-> Users, как «Таблицы Бобби» — с sAMAccountName для bobby.tables и простым паролем. Мы будем использовать это, чтобы проверить, что интеграция работает позже.
Нам понадобится полный путь DN для файла конфигурации, поэтому откройте Powershell и запустите
`dsquery user`
В возвращаемом списке найдите DN LDAP вновь созданного пользователя:
“CN=Ansible Tower,CN=Managed Service Accounts,DC=wibblesplat,DC=com”
Вернитесь в /etc/awx/settings.py и установите:
AUTH_LDAP_BIND_DN = 'CN=Ansible Tower,CN=Managed Service Accounts,DC=wibblesplat,DC=com'
# Пароль используется для привязки над учетной записью пользователя.
AUTH_LDAP_BIND_PASSWORD = 'P4ssW0Rd%!' AUTH_LDAP_USER_SEARCH = LDAPSearch( ‘CN=Users,DC=wibblesplat,DC=com', # Base DN ldap.SCOPE_SUBTREE, # SCOPE_BASE, SCOPE_ONELEVEL, SCOPE_SUBTREE '(sAMAccountName=%(user)s)', # Query )
Вам нужно отредактировать атрибут AUTH_LDAP_USER_SEARCH, чтобы правильно установить базовый DN вашего сайта. Если вы храните своих пользователей в подразделении, вы можете указать это здесь.
AUTH_LDAP_GROUP_SEARCH = LDAPSearch( 'CN=Users,DC=wibblesplat,DC=com', # Base DN ldap.SCOPE_SUBTREE, # SCOPE_BASE, SCOPE_ONELEVEL, SCOPE_SUBTREE '(objectClass=group)', # Query )
Опять же, вы хотите указать здесь базовый DN вашего сайта для групп, и снова, если вы храните свои группы в подразделении, вы можете указать это.
Это интересная настройка:
# Group DN required to login. If specified, user must be a member of this # group to login via LDAP. If not set, everyone in LDAP that matches the # user search defined above will be able to login via AWX. Only one # require group is supported. #AUTH_LDAP_REQUIRE_GROUP = 'CN=ansible-tower-users,CN=Users,DC=wibblesplat,DC=com' # Group DN denied from login. If specified, user will not be allowed to login # if a member of this group. Only one deny group is supported. #AUTH_LDAP_DENY_GROUP = 'CN=ansible-tower-denied,CN=Users,DC=wibblesplat,DC=com'
По сути, вы можете выбрать группу, и если пользователь не входит в эту группу, он не входит.
Оба они указаны в качестве DN группы:
Групповые DN легко обнаружить с помощью
dsquery group
из Powershell на вашем сервере AD.
Еще одна умная настройка. Можно назначить пользователям флаг «is_superuser» в Tower, основываясь на членстве в группах AD / LDAP:
AUTH_LDAP_USER_FLAGS_BY_GROUP =
Наконец, последний параметр позволяет сопоставить организации Tower (организации) с группами AD / LDAP:
AUTH_LDAP_ORGANIZATION_MAP = < 'Test Org': < 'admins': 'CN=Domain Admins,CN=Users,DC=wibblesplat,DC=com', 'users': ['CN=ansible-tower-users,CN=Users,DC=wibblesplat,DC=com'], 'remove_users' : False, 'remove_admins' : False, >, #'Test Org 2': < # 'admins': ['CN=Administrators,CN=Builtin,DC=example,DC=com'], # 'users': True, # 'remove_users' : False, # 'remove_admins' : False, #>, >
Передать изменения так же просто, как перезапустить Apache и сервисы AWX.
Сначала перезапустите сервисы AWX с помощью
supervisorctl restart all
Теперь перезапустите Apache с помощью:
service apache2 restart
Я создал две группы в
CN=Users,DC=wibblesplat,DC=com
Называется «пользователи ансибл-башни» и «пользователи ансайбл-башни».
Я создал двух пользователей: «Таблицы Бобби (bobby.tables)» — для пользователей ansible-tower , и «Evil Emily (evil.emily)» — для пользователя ansible-tower-denied .
Когда я перезапустил службы Ansible и попытался войти с помощью bobby.tables , я вошел .
Когда я просматриваю организации, я вижу тестовую организацию (в соответствии с отображением) и таблицы Бобби в этой организации.
Когда я пытаюсь войти в систему как evil.emily, я получаю сообщение «Невозможно войти с предоставленными учетными данными». — Это то, что мы ожидаем, так как этот пользователь находится в группе запрета доступа.
Используя Ansible Tower
Что касается использования Tower, я действительно не хочу перефразировать то, что Ansible уже сказал в их Руководстве пользователя PDF.
Однако я пройдусь по шагам, чтобы импортировать и развернуть Parallax на тестовом сервере.
Для этой цели я создал тестовую виртуальную машину в своей среде разработки под управлением Ubuntu 14.04. Я собираюсь настроить Tower для управления этой виртуальной машиной, загрузить книги игр Parallax с Github и создать шаблон задания для запуска их на тестовом сервере.
В этом примере я вошел в систему под учетной записью суперпользователя «admin», хотя с правильными разрешениями, настроенными в Tower, с использованием Active Directory или назначением разрешений вручную, это можно сделать как на индивидуальном, так и на командном уровне.
Несколько быстрых определений:
Организации : — Это единица верхнего уровня иерархической организации в Башне. Организация содержит пользователей , команды , проекты и запасы . Несколько организаций могут быть использованы для создания нескольких арендаторов на сервере Tower.
Пользователи : — Это логины в Башню. Они либо создаются вручную, либо отображаются из LDAP. У пользователей есть Свойства (имя, адрес электронной почты, имя пользователя и т. Д.), Учетные данные (используются для подключения к службам и серверам), Разрешения (для предоставления им контроля доступа на основе ролей к инвентарям и развертываниям), Организации (организации, членами которых они являются. ) и команды (полезно для разделения организаций на группы пользователей, проекты, учетные данные и разрешения).
Команды : — Команда является подразделением организации. Представьте, что у вас есть команда Networks, у которой есть свои собственные серверы. У вас также может быть команда разработчиков, которой нужна среда разработки. Создание команд означает, что сети управляют своими, а разработчики управляют своими, не зная конфигураций друг друга.
Разрешения : — Они связывают пользователей и команды с запасами и рабочими местами. У вас есть разрешения инвентаризации и развертывания.
Разрешения на инвентаризацию дают пользователям и командам возможность изменять инвентаризации, группы и хосты.
Разрешения на развертывание дают пользователям и командам возможность запускать задания, которые вносят изменения «Запускать задания», или запускать задания, проверяющие состояние «Проверять задания»
Учетные данные : — это пароли и ключи доступа, которые Tower должен иметь возможность использовать ssh (или использовать другие протоколы) для подключения к узлам, которыми он управляет.
Существует несколько типов учетных данных, которыми Tower может управлять и использовать:
Пароль SSH — обычный старый пароль, основанный на пароле.
Закрытый ключ SSH — используется для аутентификации SSH на основе ключей.
Закрытый ключ SSH с парольной фразой — используется для защиты закрытого ключа парольной фразой. Фраза-пароль может быть сохранена в базе данных. Если это не так, Tower попросит вас ввести пароль, когда он должен использовать учетные данные.
Пароль Sudo — Требуется, если sudo должен быть запущен и требуется пароль для авторизации.
Учетные данные AWS — надежно хранит ключ доступа AWS и секретный ключ в базе данных Tower.
Учетные данные Rackspace — хранит имя пользователя и секретный ключ Rackspace.
Учетные данные SCM — хранит учетные данные, используемые для доступа к хранилищам исходного кода для хранения и извлечения проектов.
Проекты : — Здесь живут твои книги. Вы можете добавить их вручную, клонируя в
/var/lib/awx/projects
или используя Git, SVN или Mercurial и заставляя Tower автоматически выполнять клонирование перед каждым запуском задания (или по расписанию).
Запасы : — Они эффективно заменяют группировку в файле хостов каталога Playbook. Вы можете определить группы хостов, а затем настроить отдельные хосты в этих группах. Из этого можно назначить специфичные для хоста переменные или инвентаризационные переменные.
Группы : — Они живут в Инвентаризациях и позволяют собирать группы схожих хостов, к которым вы можете применить игровую книгу.
Хосты : — Они живут в группах и определяют IP-адрес / имя хоста узла, а также некоторые переменные хоста.
Шаблоны заданий : — Это в основном определение задания Ansible, которое связывает воедино Инвентарь (и его хосты / группы), Проект (и его Playbooks ), Учетные данные и некоторые дополнительные переменные. Здесь вы также можете указать теги (например, —tags в командной строке ansible-playbook).
Шаблоны заданий также могут принимать обратные вызовы HTTP, что позволяет вновь подготовленному хосту связываться с сервером Tower и запрашивать инициализацию. Мы вернемся к этой концепции в части 5.
Задания : — это то, что происходит, когда создается экземпляр шаблона задания, и он запускает playbook для набора хостов из соответствующего инвентаря.
Запуск параллакса с башней
Первое, что нам нужно сделать (если вы уже не сделали это или не создали автоматически при отображении LDAP), это создать Организацию . — Опять же, лучше всего обратиться к существующей документации Ansible Tower, указанной выше, для лучшего способа сделать это.
На самом деле я подключил свою тестовую организацию через интерфейс LDAP, поэтому следующим шагом будет создание команды.
Я назвал свою команду » DevOps «
Я собираюсь назначить им полномочия сейчас.
Перейдите к командам / DevOps
В разделе «Учетные данные» нажмите [+]
Выберите тип «Машина»
— На сервере где-нибудь запустите ssh-keygen и сгенерируйте ключ RSA. Скопируйте закрытый ключ в буфер обмена и вставьте его в поле SSH Private Key.
Прокрутите вниз и нажмите Сохранить.
В верхнем меню с вкладками нажмите «Проекты», затем нажмите [+]
Дайте проекту осмысленное имя и описание. Введите тип SCM как Git
Под URL-адресом SCM укажите публичный адрес Github для Parallax, а в разделе SCM Branch установите «tower»
Установите для параметров обновления SCM значение «Обновлять при запуске» — это выполнит обновление git перед запуском задания, поэтому вы всегда будете получать последнюю версию от Git.
Это вызовет задание, которое клонирует последнюю версию из Git и сохранит ее в каталоге Projects. Если это не удается, вам может потребоваться выполнить:
chown -R awx /var/lib/awx/projects
Далее создайте инвентарь .
Довольно просто — название, описание, организация.
Выберите этот инвентарь и создайте группу. Можно импортировать группы из EC2, выбрав вкладку «Источник» при создании новой группы.
Выберите группу, которую вы только что создали, и создайте хост под ней с IP-адресом / именем хоста вашего тестового сервера.
На этом этапе вы можете назначить переменные для каждого хоста.
Почти там!
Нажмите « Шаблоны заданий » и создайте новый шаблон задания. Как я уже говорил, они действительно связывают все это вместе.
Дайте ему имя, затем выберите свой Инвентарь , Проект , Playbook и Credential .
Чтобы запустить его, нажмите Rocketship из списка шаблонов работ.
Вы будете перенаправлены на страницу вакансий, где будет показана ваша последняя работа в очереди.
Если у вас нет очень загруженного сервера Tower, он не будет долго стоять в очереди. Нажмите кнопку «Обновить» в разделе «Очередь» для перезагрузки, и вы должны увидеть, что она перемещена в «Активная».
Вы можете щелкнуть по заданию для обновления его статуса или просто терпеливо ждать его завершения.
Когда работа будет завершена, у вас будет красная точка или зеленая точка, указывающая статус работы.
Вот и все. Вы установили Ansible Tower, интегрировали его с Active Directory и создали свое первое задание по развертыванию Parallax с Tower.
Представляем Ansible Automation Platform 2
На прошедшей в конце сентября конференции 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.com – поможет узнать больше о новых функциях и компонентах Ansible Automation Platform. Также мы подготовили новое интерактивное руководство по функциям продукта.
- Если готовы опробовать новую версию Ansible на практике, то у нас есть для этого интерактивные лабы.
- Также рекомендуем бесплатный вебинар «Red Hat Ansible Automation Platform предлагает новые способы автоматизации», который пройдет 2 ноября и затем будет выложен в записи.
- При наличии действующей подписки Red Hat можно зайти на страницу раннего доступа на портале Red Hat Customer Portal, где собраны официальные ресурсы по новой версии Ansible, включая официальную документацию по продукту.
Среды исполнения автоматизаций
С распространением ИТ-автоматизации на предприятии растет число сред автоматизации, предназначенных для тех или иных команд и сценариев. И управлять этим средами становится все сложнее, особенно когда процесс начинает масштабироваться до уровня корпоративной ИТ-среды в целом. И поскольку автоматизация теперь является критически важной частью рабочих процессов, 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
Среды исполнения автоматизации – это одна из составляющих концепции 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.
Вебинар Ansible Tower: Глубокое Погружение
Ansible Automation Platform – это флагманский набор продуктов от компании Red Hat, который является простым и мощным инструментарием автоматизации ИТ. Мы расскажем и научим вас работать с основными компонентами Ansible Automation Platform.
Часть 1 – Базовые сущности автоматизации, начало работы с Ansible
Часть 2 – Базовые навыки работы с Anisble Tower
Часть 3 – глубокое погружение в Ansible Tower, состоится 21 апреля.
Ansible Tower, как корпоративное средство автоматизации, позволяет вам переложить рутинные задачи со своих плеч на плечи Ansible. Но любые крупные организации имеют свои особенности и требования, которым необходимо соответствовать. И именно про этот функционал мы с вами и поговорим.
Мы рассмотрим, что такое workflow и как группа плейбуков становится мощным инструментом автоматизации. Мы узнаем, как работать с instance groups и для чего может быть нужен данный функционал. А самое главное, мы посмотрим на REST API Ansible Tower, так как это главная особенность продукта, которая превращает его из отдельно стоящего средства автоматизации в шестерёнку в механизме вашей организации.
Вебинар Ansible Tower: Глубокое Погружение
Ansible Automation Platform — это флагманский набор продуктов от компании Red Hat, который является простым и мощным инструментарием автоматизации ИТ. Мы расскажем и научим Вас работать с основными компонентами Ansible Automation Platform.
Часть 1 — Базовые сущности автоматизации, начало работы с Ansible
Часть 2 — Базовые навыки работы с Anisble Tower
Часть 3 — глубокое погружение в Ansible Tower, состоится 21 апреля.
Ansible Tower, как корпоративное средство автоматизации, позволяет вам переложить рутинные задачи со своих плеч на плечи Ansible. Но любые крупные организации имеют свои особенности и требования, которым необходимо соответствовать. И именно про этот функционал мы с вами и поговорим.
Мы рассмотрим, что такое workflow и как группа плейбуков становится мощным инструментом автоматизации. Мы узнаем, как работать с instance groups и для чего может быть нужен данный функционал. А самое главное, мы посмотрим на REST API Ansible Tower, так как это главная особенность продукта, которая превращает его из отдельно стоящего средства автоматизации в шестерёнку в механизме вашей организации.
Регистрируйтесь и приходите на третью часть цикла вебинаров про автоматизацию!