Awx что это

Eugeneer’s Media Cloud World

Блог творческого ИТ-практика — возьми свою мысль и придай ей ускорение идеи! В фокусе: сети, безопасность, виртуализация, мультимедиа, AI.

Главная

Wednesday, 5 August 2020

AWX — первый старт.

Всем привет.

Используя время от времени Ansible ссылки из сети тебя перекидывают на AWX. Что за зверь такой? Если просто то AWX это GUI для Ansible. AWX впервые был представлен в сентябре 2017 года — это open source проект, распространяющийся под лицензией Apache-2.0 и являющийся апстримом для коммерческого проекта Ansible Tower.

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

По мере масштабирования среды до размеров предприятия то же самое происходит и с операторами Ansible. Когда все те, кто отвечает за исполнение Ansible имеют его установленным на свои собственные машины, причём все они обладают копиями установленных плейбуков, внезапно само управление таким окружением превращается в ночной кошмар! Как вы сможете знать что все применяют самые последние версии плейбуков? Откуда вы узнаете кто что запускал и каков результат? Что если изменения потребуют долгих часов? Можете ли вы передать задания Ansible в команду NOC (Network Operations Center) или это невозможно, так как им потребуется обучение тому как применять Ansible?

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

Основные возможности AWX:

• Интеграция с системами контроля версий (git/mercurial/subversion).
• Отслеживание статуса выполнения плейбуков в реальном времени.
• Настройка расписания для автоматического запуска плейбуков.
• Выполнение нескольких плейбуков в рамках одного workflow.
• Удаленное выполнение команд без плейбуков (Ansible ad hoc).
• Поддержка механизма callbackов, позволяющих новым серверам запрашивать конфигурации со своей стороны.
• Управление Inventory для Ansible, в том числе с возможностью интеграции с платформами AWS/Azure/OpenStack и т.д., а также поддержка собственных скриптов для генерации Dynamic Inventory.
• Гибкая система разграничения прав доступа. Интеграция с LDAP/SAML/Active Directory и т.д.
• Встроенная поддержка уведомлений для Email/Slack/PagerDuty/HipChat/MatterMost/IRC.
• Интеграция с внешними системами агрегации логов: Logstash/Splunk/Loggly/Sumologic.

Рекомендуемые к изменению перед установкой AWX переменные в awx/installer/inventory:
admin_password=password01

-это устанавливаемое по умолчанию значение пароля для пользователя admin — вам он потребуется для самого первого входа в систему, поэтому обеспечьте установку чего- то запоминающегося и безопасного!

pg_password=awxpass

-это значение пароля для обеспечивающей базы данных PostgreSQL — обеспечьте нечто уникальное и безопасное.

postgres_data_dir=»~/.awx/pgdocker»

-это каталог в вашей локальной файловой системе, в котором контейнер PostgreSQL будет хранить свои данные — по умолчанию он устанавливается на каталог /tmp, который в большинстве систем будет автоматически очищаться на регулярной основе. Это часто разрушает базу данных PostgreSQL, а потому настройте его на что- то особенное для AWX (например, /var/lib/awx/pgdocker).

#project_data_dir=/var/lib/awx/projects

-для выгрузки плейбуков вручную в AWX не требующих системы контроля версий, такие плейбуки должны располагаться где- то в установленной файловой системе. Чтобы избежать их копирования в некий контейнер, данная переменная соответствует значению локальной папки, определяемой для того чтобы она была расположена в контейнере, мы будем применять устанавливаемое по умолчанию значение (папку /var/lib/awx/projects).

rabbitmq_password

-это значение пароля для лежащей в основе службы RabbitMQ — убедитесь что установили нечто уникальное и безопасное.

secret_key=awxsuper

-это секретный ключ, применяемый для шифрования учётных сведений в базе данных PostgreSQL. Он должен быть одним и тем же при различных обновлениях AWX, поэтому обеспечьте его сохранность в каком- то безопасном месте, так как он потребуется при последующих каталогизациях AWX. Сделайте его каким- нибудь длинным и безопасным.

В данный момент поддерживается несколько вариантов установки, я выбрал с Docker/Docker Compose. И получил в результате 4 работающих контейнера.

sudo docker ps -a
[sudo] password for user1:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
285bcfd95af4 ansible/awx:13.0.0 «tini — /usr/bin/la…» 5 days ago Up 3 seconds 8052/tcp awx_task

90218405176c ansible/awx:13.0.0 «tini — /bin/sh -c …» 5 days ago Up 3 seconds 0.0.0.0:80->8052/tcp awx_web

f62b6f5e1b50 redis «docker-entrypoint.s…» 5 days ago Up 3 seconds 6379/tcp awx_redis
c4bb9184c35b postgres:10 «docker-entrypoint.s…» 5 days ago Up 3 seconds 5432/tcp awx_postgres

Особенности AWX.
Для того чтобы управлять Windows-хостами надо доставить в оба контейнера awx-task и awx-web pywinrm:
AWX docker commands, docker containers awx-task & awx-web:
sudo docker exec -it 285bcd95af4 /bin/bash
pip install pywinrm
А вот docker-py надо удалить.
docker_service — Unable to load docker-compose.
>sudo pip3 uninstall docker docker-py docker-compose
PS: в моем случае удалился только docker-py

Есть одна неприятная особенность при установке AWX из коробки. Переменная Рostgres_data_dir по умолчанию выставлена в /tmp/pgdocker и в какой-то момент можно получить «FATAL: could not open file „base/16384/2601“: No such file or directory», поэтому рекомендуется заранее менять эту директорию.

Если в хотите размещать плейбуки локально то при попытке указать нужную папку в джобе получите сообщение:

“WARNING: There are no available playbook directories in /var/lib/awx/projects.

Either that directory is empty, or all of the contents are already assigned to other projects. Create a new directory there and make sure the playbook files can be read by the “awx” system user, or have Tower directly retrieve your playbooks from source control using the SCM Type option above.”

Тест-драйв Ansible AWX

Ansible набирает все большую популярность, кроме того, после покупки Red Hat’ом, все-таки появилась бесплатная версия Ansible Tower — Ansible AWX.

Ansible AWX это upstream проект, на базе которого будет основываться коммерческий Ansible Tower. Для Red Hat это обычно дело, например наиболее известные проекты с открытым исходным кодом и их братья с платной поддержкой:

• Fedora — RHEL
• oVirt — RHV
• Katello — Satellite
• MIQ — CloudForms

Ansible AWX (Tower) предоставляет дашбоард состояния, разграничение прав пользователей, централизованное логирование и аудит, а так же планировщик и REST API для запуска плейбуков по расписанию или по событию.

В данной заметке будет рассмотрен пример использования ansible и AWX для настройки ntp и sshd на сервере. Предполагается, что читающий это уже знает как работать с ansible и как выглядит playbook. Поскольку ansible и docker сегодня снискали огромную популярность у разработчиков по всему миру, думаю что каждый кто это читает, как минимум слышал про ansible.

Установка Ansible AWX

Для штатной установки AWX предлагается использовать непосредственно сам ansible и docker-контейнеры, используем рекомендоманный стек, для Ubuntu 16.04 требуется предварительная настройка, а именно:

Для начала понадобится установить Ansible:

$ apt-get install software-properties-common $ apt-add-repository ppa:ansible/ansible $ apt-get update $ apt-get install ansible

$ apt-get install docker.io python-docker

После устанвки зависимостей можно установить и сам AWX:

$ git clone https://github.com/ansible/awx.git $ cd awx/installer/

В файле inventory рекомендуется заменить дефолтные значения для:

default_admin_password=password awx_secret_key=awxsecret postgres_data_dir=/tmp/pgdocker pg_password=awxpass

После конфигурации inventory запускаем деплой:

$ ansible-playbook -i inventory install.yml

Если ошибок не было, выглядить все должно примерно так:

$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e91e5c8789c1 ansible/awx_task:latest "/tini -- /bin/sh -c " 26 minutes ago Up 26 minutes 8052/tcp awx_task 131ae613e680 ansible/awx_web:latest "/tini -- /bin/sh -c " 26 minutes ago Up 26 minutes 0.0.0.0:80->8052/tcp awx_web 0778435febca memcached:alpine "docker-entrypoint.sh" 28 minutes ago Up 28 minutes 11211/tcp memcached 360a885ac3c3 rabbitmq:3 "docker-entrypoint.sh" 28 minutes ago Up 28 minutes 4369/tcp, 5671-5672/tcp, 25672/tcp rabbitmq 7d806924aae9 postgres:9.6 "docker-entrypoint.sh" 28 minutes ago Up 28 minutes 5432/tcp postgres

Перед авторизацией в веб-интерфейсе необходимо дождаться в логах контейнера awx_task строк такого вида:

$ docker logs -f awx_task . >>> >>> Default organization added. Demo Credential, Inventory, and Job Template added. Successfully registered instance awx (changed: True) Creating instance group tower Added instance awx to tower (changed: True)

Дальше можно зайти в веб-интерфейс и аутентифицироваться используя логин и пароль заданные в inventory.

Настройка проекта в Ansible AWX

После того как Ansible AWX установлен и доступен сконфигурируем его для настройки ntp и sshd на серверах, причем так, чтобы конфигурация применялась каждые 15 минут, аналогично системам управления конфигурациями puppet или chef.
Ansible очень популярен среди разработчиков для деплоя приложений, но, то чего ему действительно не хваатет, как инструменту управления конфигурациями — постоянства и настойчивости.
Что я имею ввиду — разовый деплой сервиса средствами ansible нельзя назвать процессом управления конфигурациями, поскольку он разовый. Запуск агента (задания, если быть точным, поскольку агента у ansible нет) должен происходить регулярно и при этом должна применяться целевая конфигурация. Т.е. шансов кому-то зайти на сервер и поправить что-то руками давать не нужно. В противном случае получается довольно прискорбная картина и запускать playbook через некоторое время становится опасно.

Проект

Краеугольным камнем Ansible AWX является сущность — проект. Это коллекция плейбуков, опционально там же могут располагаться и роли. Проект может синхронизироваться с SCM (Source Code Management), например git, или статично хостится в определенном каталоге сервера.
Первый вариант является предпочтительным, посколько AWX умеет перед применением плейбука синхронизировать с SCM самую актуальную версию.
Рассмотрим создание проекта на примере ansible-playbooks:

Прежде всего нам потребуется какой-то playbook, их, кстати говоря, в проекте может быть много, сколько угодно много. Создадим default.yaml, который будет назначать всем хостам интересующие нас роли ntp и sshd:

- hosts: all roles: - ntp - sshd

$ cd roles $ git submodule add https://github.com/R4scal/ansible-role-ntp ntp $ git submodule add https://github.com/R4scal/ansible-role-sshd sshd

Учетные данные

Следующим шагом на пути к цели управления конфигурациями с помощью Ansible AWX является настройка учетных данных, с помощью которых ansible сможет аутентифицироваться/авторизовываться на серверах. Правильнее всего, снова с моей точки зрения, делать это по средством ssh-ключей. Для этого стоит сгененрировать пару ключей (публичный и приватный).
Созданный приватный ключ, вместе с паролем, необходимо разместить в AWX так как это отражено на скриншоте. Публичный ключ распространяем по серверам, которые будут управляться посредством ansible.

$ ssh-keygen -b 4096

Inventory

Итак, мы почти у цели, теперь нужно настроить inventory. Именно здесь живут все серверы и настройки ролей. Настраивать роли можно непосредственно на уровне inventory, а так же на уровне групп и даже отдельных хостов.
Поскольку AWX обладает механизмом разграничения привелегий, доступ к inventory настраивается как для отдельных пользователей, так и для команд (teams), что довольно удобно.

Задания

Мы на финишной прямой, создаем шаблон задания. Для этого нам потребуется указать все созданое выше, проект и playbook в нем, учетные данные для авторизации на серверах и inventory на который требуется применить конфигурацию.
Так же в этом интерфейсе можно можно настроить насколько подробными будут логи ansible и ограничить выполняемое содержимое playbook используя функционал тегов. После того как шаблон задания создан можно выполнить его вручную и, если ошибок нет, создать планировщик.
На этом все. Ansible AWX обладает гораздо большим функционалом и возможностями, нежели описанные здесь. С полным функционалом можно ознакомиться в официальной документации.
AWX делает возможным использование ansible не только как инструмент деплоя, но и как полноценный средство управления конфигурациями, на мой взгяд это очень хорошо, ведь ansible для освоения гораздо проще своих старших братьев (puppet или chef), а значит порог вхождения для него ниже. Но за простоту приходится платить производительностью, применение конфигурации средствами ansible на сегодняшний день в разы медленнее puppet или chef.

От установки AWX до запуска первого плейбука — настройка централизованного управления Ansible

Количество серверов в нашей инфраструктуре уже перевалило за 800, хотя еще год назад их было около 500. Для работы с этим всем активно используются решения от Red Hat. Про FreeIPA — для организации и управления доступами для Linux-серверов — мы уже писали, сейчас же я хочу затронуть тему управления конфигурациями. Для этих целей у нас юзается Ansible, а с недавних пор к нему добавился AWX — представленное полгода назад решение для централизованного управления плейбуками, расписанием их запусков, управления инвентори, учетными данными для доступа к серверам, а также механизм callback’ов для запроса конфигураций со стороны сервера.

Из-за ряда вещей мы не сразу смогли интегрировать его для работы с нашим основным проектом War Robots, но полей для проверки AWX нашлось предостаточно. Во-первых, в компании ведутся разработки новых проектов, которым нужны dev/stage-окружения и, само собой, production-окружения в перспективе. А недавно к этому добавился еще и проект для внутренней аналитики, которому потребовался полностью новый кластер.

AWX был представлен в сентябре 2017 года — это бесплатный open source проект, распространяющийся под лицензией Apache-2.0 и являющийся апстримом для коммерческого проекта Ansible Tower. В целом, тут тот же принцип, что и у других проектов Red Hat: Red Hat Cloud Forms — ManageIQ; RHEV — Ovirt; Red Hat Identify Managment — FreeIPA и так далее.

Данная статья представляет из себя руководство — от установки AWX до запуска первого плейбука. Но сначала перечислим основные возможности AWX:

• Интеграция с системами контроля версий (git/mercurial/subversion).
• Отслеживание статуса выполнения плейбуков в реальном времени.
• Настройка расписания для автоматического запуска плейбуков.
• Выполнение нескольких плейбуков в рамках одного workflow.
• Удаленное выполнение команд без плейбуков (Ansible ad hoc).
• Поддержка механизма callbackов, позволяющих новым серверам запрашивать конфигурации со своей стороны.
• Управление Inventory для ансибла, в том числе с возможностью интеграции с платформами AWS/Azure/OpenStack и т.д., а также поддержка собственных скриптов для генерации Dynamic Inventory.
• Гибкая система разграничения прав доступа. Интеграция с LDAP/SAML/Active Directory и т.д.
• Встроенная поддержка уведомлений для Email/Slack/PagerDuty/HipChat/MatterMost/IRC.
• Интеграция с внешними системами агрегации логов: Logstash/Splunk/Loggly/Sumologic.

Установка

В данный момент поддерживается несколько вариантов установки:

1. Kubernetes.
2. Openshift.
3. Docker/Docker Compose.

Устанавливать всё будем на Centos 7. Установка Докера также описана в официальной документации, поэтому в статье ее трогать не будем.

Далее нам нужно установить ansible и модуль docker-py. Это можно сделать из pip:

pip install ansible pip install docker-py

Клонируем репозиторий AWX:

git clone https://github.com/ansible/awx.git cd awx/installer

Правим файл inventory. В первую очередь, рекомендую поправить переменную postgres_data_dir. По умолчанию она равна /tmp/pgdocker, но если оставить в таком виде — через некоторое время можно потерять postgresql базу, которую использует AWX.

Если вы хотите использовать внешнюю базу, укажите переменные:

pg_hostname pg_username pg_password pg_database pg_port

После этого запускаем:

ansible-playbook -i inventory install.yml

Эта команда запустит выполнение плейбука, который загрузит нужные docker-образы и запустит контейнеры непосредственно с AWX и дополнительными компонентами: Postgres, MemCached, RabbitMQ.

После завершения выполнения плейбука мы должны увидеть следующие контейнеры:

docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b1bd94f83420 ansible/awx_task:latest "/tini -- /bin/sh . " 6 days ago Up 6 days 8052/tcp awx_task abf30fd81335 ansible/awx_web:latest "/tini -- /bin/sh . " 6 days ago Up 6 days 0.0.0.0:80->8052/tcp awx_web b13ee3c7cbb7 memcached:alpine "docker-entrypoint. " 2 months ago Up 6 days 11211/tcp memcached 3c4cac5a4ce5 rabbitmq:3 "docker-entrypoint. " 2 months ago Up 6 days 4369/tcp, 5671-5672/tcp, 25672/tcp rabbitmq b717c6019e02 postgres:9.6 "docker-entrypoint. " 2 months ago Up 6 days 5432/tcp postgres

Следить за процессом установки AWX можно следующим образом:

docker logs -f awx_task

AWX будет доступен по адресу сервера на 80 порту (если вы не поменяли порт в файле inventory).

Логин и пароль по умолчанию:

Admin:password

Использование и примеры

Теперь перейдем непосредственно к AWX, но сначала немного разберемся с тем, как всё организовано.

В первую очередь нас интересует раздел Projects. Projects в терминологии AWX означает набор плейбуков, которые расположены локально на сервере с AWX или в репозитории.

Создадим наш первый Project:

— Name: имя проекта, пускай это будет firstproject.
— Organization: в AWX это сущность, которая используется для разграничения доступа. К Organization могут относиться инвентори, пользователи, группы пользователей, плейбуки. Выберем Default.
— SCM TYPE: тип репозитория, может быть либо локальная директория, либо одна из систем контроля версий на выбор: git, mercurial, subversion.
— SCM Url: урл для репозитория.
— SCM branch/tag/commit: опционально можно указать необходимый branch/tag/commit.
— В поле SCM credentials можно выбрать реквизиты, которые будут использоваться для доступа к репозиторию.

Также можно отметить галочками чекбоксы:

— Clean: удалить все локальные изменения перед обновлением.
— Delete on Update: при обновлении Project’а удалять локальную копию и заново загружать новую копию репозитория.
— Update on Launch: при каждом запуске плейбука из этого Project’а обновлять локальную копию репозитория до актуальной версии. Можно использовать в связке с Delete on Update, но это может привести к более долгому выполнению плейбука, так как каждый раз потребуется ждать окончания синхронизации с репозиторием.

Выберем Clean и Update on Launch. Нажимаем Save и после этого создание нашего первого Project’а завершено.

Перейдем в раздел Projects и для нашего Project’а нажмем на кнопку Start an scm update. Дождемся завершения первой загрузки нашего репозитория (следить за статусом обновления можно в разделе Jobs).

Посмотрим на плейбук, который находится в нашем репозитории. На Хабре есть множество статей, в которых рассказывается об Ансибле и структуре его плейбуков/ролей поэтому подробно расписывать этот момент не станем (вот несколько статей для примера: 1, 2, 3).

firstproject/ ├── ansible.cfg ├── group_vars/ ├── host_vars/ ├── roles/ │ └── requirements.yml └── run.yml

Файлы .yml, расположенные в корне директории firstproject, AWX воспримет как плейбуки.

Содержимое файла run.yml:

--- - name: Test Role hosts: - all gather_facts: true roles: - roleawx

То есть просто запускаем roleawx, предварительно собрав факты. Hosts указываем all, так как указать хосты и хост группы можно в самом AWX.

Дальше интересный момент — содержимое файла roles/requirements.yml:

- src: git@gitlab.example.com:ansible-roles/roleawx.git scm: git

При синхронизации Project’а AWX сам установит все роли в директорию roles в соответствии с файлом requirements.yml. В данном случае он установит роль roleawx из git репозитория.

Создадим роль с помощью команды:

ansible-galaxy init roleawx

Структура роли будет такой:

roleawx/ ├── README.md ├── defaults │ └── main.yml ├── files ├── handlers │ └── main.yml ├── meta │ └── main.yml ├── tasks │ └── main.yml ├── templates ├── tests │ ├── inventory │ └── test.yml └── vars └── main.yml

Содержимое файла tasks/main.yml:

--- # tasks file for roleawx - name: Test Message debug: msg: "AWX and Ansible"

Для начала просто выведем сообщение «AWX and Ansible».

Обратите внимание, для того чтобы AWX автоматически установил роли, указанные в файле requirements.yml, в самой роли должен быть корректно сформирован файл meta/main.yml (если вы создали шаблон для роли с помощью ansible-galaxy init, то с meta/main.yml всё хорошо и AWX сможет загрузить эту роль).

Итак, у нас есть репозиторий с плейбуком, есть репозиторий с ролью. А так же у нас есть несколько виртуальных машин с адресами 192.168.10.233, 192.168.10.234 и 192.168.10.239.

Перед тем, как запустить наш плейбук, нам надо сделать так, чтобы Ansible смог попасть с сервера AWX на наши хосты (в нашем случае по SSH). Мы можем указать пароли прямо в переменных внутри плейбука, но это неинтересно. AWX умеет управлять реквизитами для доступа к серверам и мы этим воспользуемся.

Перейдем во вкладку Credentials и нажмем кнопку Add:

— Name: укажем имя для наших реквизитов.
— Credential Type: здесь можно выбрать тип реквизитов. Нас интересует Machine, чтобы использовать их для доступа к нашим серверам. Помимо этого AWX предлагает множество разных типов реквизитов доступа, которые можно использовать для интеграции с различными сервисами, такими как scm (git, svn, mercurial), Red Hat Insight, AWS, Azure, Red Hat Satellite, RHEV, Vmware, OpenStack. А ещё можно создавать свои собственные типы credentials.
— Имя пользователя: выберем root.
— Пароль: оставляем пустым, так как мы будем использовать доступ по ключу.
— PRIVATE KEY PASSPHRASE: пароль для ключа, если ключ создан с паролем. В нашем случае ключ без пароля, поэтому поле оставляем пустым.
— PRIVILEGE ESCALATION METHOD: метод повышения привилегий. Например: sudo, su, pfexec и и т.д.
— PRIVILEGE ESCALATION USERNAME: пользователь, под которым Ansible должен получить привилегии.
— PRIVILEGE ESCALATION PASSWORD: пароль для повышения привилегий.

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

Обратите внимание: у ряда полей есть чекбокс Prompt on launch. При активации этого чекбокса соответствующее ему поле будет предложено заполнить вручную при каждом запуске плейбука, с которым ассоциированы данные реквизиты. Таким образом можно не сохранять пароль внутри AWX, а запрашивать его при каждом запуске плейбука.

Итак, мы создали Project и реквизиты для доступа к серверам. Теперь нам необходим Inventory.

Перейдем в раздел Inventory, нажимаем кнопку Add. На выбор будет предложено создать:

— Inventory: обычный Inventory.
— Smart Inventory: позволяет генерировать inventory на основе уже существующих хостов, основываясь на каких-либо параметрах, например, на типе операционной системы.

Создадим обычный Inventory:

— В поле Name указываем имя.
— Выбираем Default Organization.
— В поле Variables можно указать переменные, которые в дальнейшем будут доступны из плейбука.

--- awxinvvar: "Test"

Остальные вкладки неактивны, пока мы не сохраним наш Inventory.

Сохраняем и возвращаемся в раздел Inventory. Наш Inventory появился в списке. Перейдем в него: после создания верхние вкладки стали активны.

— Permissions: здесь контролируется, кто из пользователей или групп пользователей имеет доступ к Inventory.
— Groups: список хост-групп.
— Hosts: список хостов.
— Sources: список источников для Inventory. Можно выгружать инвентори из AWS/Azure/OpenStack/RHEV и ещё ряда сервисов, можно указать инвентори файл, который находится внутри нашего Project’а или же указать в качестве источника свой собственный скрипт, который генерирует Dynamic Inventory.
— Completed Jobs: список запущенных плейбуков, ассоциированных с хостами из текущего Inventory.

Наш Inventory заполняем руками, так как у нас мало хостов. Перейдем во вкладку Hosts и создадим несколько хостов:

— В поле Host Name можно указать IP-адрес сервера или его DNS-имя.
— В поле Variables попробуем переопределить переменную awxinvvar для одного из наших хостов:

--- awxinvvar: "Host1"

После создания хостов перейдем во вкладку Groups и создадим группы для наших хостов:

Точно так же укажем имя группы и переопределим переменную awxinvvar для одной из групп.

Возвращаемся во вкладку Hosts, выбираем один из хостов из списка, переходим на вкладку Groups для этого хоста и нажмем Associate Group:

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

Кстати, на вкладках Hosts и Groups также доступна кнопка Run command. Это аналог ad-hoc команд в Ansible, которые позволяют выполнить действия на удаленных хостах, без плейбука.

Давайте попробуем. Выберем наши хосты из списка, выберем ключ для доступа по SSH, который создали ранее и попробуем выполнить команду date c помощью модуля shell:

Нажимаем Launch. Нас должно перекинуть на страницу, на которой мы сможем в реальном времени следить за выполнением. Также все запуски плейбуков/ad-hoc команд видны в разделе Jobs.

Наша ad-hoc команда успешно выполнилась.

Давайте теперь попробуем запустить наш плейбук. Перейдем в раздел Templates, нажмем кнопку Add, выберем Job Template.

В терминологии AWX Template — это набор параметров, которые используются для запуска плейбука. В минимальном виде необходимо указать имя шаблона, выбрать project, выбрать playbook, выбрать inventory.

Выглядит создание шаблона так:

— Name и Description: имя и описание шаблона.
— Job Type: Run или Check. То есть запуск плейбука или только проверка плейбука (dry-run) без внесения изменений.
— Inventory: Inventory, с которым будет запускаться плейбук.
— Project и Playbook: предназначены для выбора Project’а с плейбуками и конкретного плейбука из Project’а.
— Limit: список хостов и групп, на которых будет запущен плейбук.
— Verbosity: насколько подробно Ansible будет выводить результат выполнения (аналог ключей -v -vv -vvv).
— Job tags: список тегов — задачи, с которыми должны быть запущены. Если не указывать, будет выполнены все задачи описанные в ролях.
— Skip tags: список тегов — задачи, с которыми не будут выполняться.
— Labels: метки, которые будут ассоциироваться с данным шаблоном. Можно использовать для фильтрации в самом AWX.
— Show diff: показывать изменения, которые делает Ансибл (аналог ключа —diff).

Сохраняем проект, возвращаемся в раздел Templates, и запускаем наш плейбук (кнопка в виде ракеты):

Ура, наш плейбук запустился, загрузил нужные роли и успешно отработал. Кстати, на этой же странице вы можете загрузить результат выполнения плейбука. Также имеется возможность поиска по выводу плейбука.

Помните, мы добавили переменную awxinvvar в нескольких местах? Давайте попробуем вывести её в и посмотреть, что получится.

Добавляем в нашу роль в файл tasks/main.yml следующее:

 - name: Print var debug: msg: ">"

И снова запускаем наш template.

Плейбук видит нашу переменную, которую мы определили в Inventory и корректно её переопределяет в соответствии с приоритетом применения переменных.

Переменные, кстати, можно хранить и в репозитории в директориях host_vars group_vars, если вам так удобнее. Правда, в таком случае они не будут отображаться в Inventory в самом AWX.

Вместо заключения

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

Примечание: новые релизы сейчас выходят часто и могут возникнуть проблемы при обновлении. Делайте бэкапы!

Данное руководство написано для ознакомления с базовыми функциями AWX, а если будет интересно — напишем про дополнительный полезный функционал, вроде интеграции с источниками для Dynamic Inventory, механизм Callback’ов и т.д.

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

• Блог компании Pixonic
• Системное администрирование
• IT-инфраструктура
• Серверное администрирование
• DevOps

Установка Ansible AWX

В предыдущей публикации я рассказывал о том, как выполняется установка Ansible. Однако, этот вариант предоставляет лишь CLI консоль без какого либо графического интерфейса. Чтобы получить Ansible с графическим интерфейсом есть несколько вариантов – либо использовать коммерческий Ansible Tower, либо использовать open source решение – Ansible AWX.

Есть несколько вариантов установки Ansible AWX – установка через AWX operator или установка через Docker. Вариант с Docker проще, т.к. он не требует наличия Kubernetes в вашей инфраструктуре. Хотя для целей тестирования его вполне можно развернуть на minikube.

В этой публикации я буду расскажу про вариант установки через Docker. В качестве операционной системы я буду использовать Ubuntu Server 22.04.

Предварительные требования

Все предварительные требования приведены в репозитории продукта.

Кратко перечислю основные из них:

1. Для клонирования репозитория нужен git.

2. Установленный Docker.

3. Также нужен Docker Compose.

4. Для процесса установки еще нужен Ansible.

5. Также нужна утилита OpenSSL.

Давайте установим все необходимые компоненты. О ток, как выполнить установку Ansible я рассказывал в предыдущей публикации.

Для установки оставшихся компонентов выполните следующую команду:

sudo apt install -y git docker.io docker-compose openssl

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

Дополнительно разрешим текущему пользователю запускать команды docker без sudo:

sudo usermod -aG docker $USER

После этого нужно завершить текущую сессию в терминале и установить новую сессию.

Также убедитесь, что на вашем сервере установлены пакеты setuptools-scm и buildx. Они потребуются для сборки.

Установка Ansible AWX

Первый шаг – это клонирование репозитория продукта. Я склонирую самую актуальную версию:

 git clone --depth 1 https://github.com/ansible/awx

roman@ansible:~$ git clone --depth 1 https://github.com/ansible/awx Cloning into 'awx'. remote: Enumerating objects: 3914, done. remote: Counting objects: 100% (3914/3914), done. remote: Compressing objects: 100% (3038/3038), done. remote: Total 3914 (delta 836), reused 1893 (delta 510), pack-reused 0 Receiving objects: 100% (3914/3914), 16.93 MiB | 9.12 MiB/s, done. Resolving deltas: 100% (836/836), done. roman@ansible:~$ 

Перейдем в директорию проекта:

cd awx

Теперь нужно скорректировать инвентаризационный ф

nano tools/docker-compose/inventory

Укажем пароль для базы данных PostgreSQL и необходимые секреты:

 GNU nano 6.2 tools/docker-compose/inventory * localhost ansible_connection=local ansible_python_interpreter="/usr/bin/env python3" [all:vars] # AWX-Managed Database Settings # If left blank, these will be generated upon install. # Values are written out to tools/docker-compose/_sources/secrets/ pg_password="Qwerty123" broadcast_websocket_secret="Qwerty123" secret_key="Qwerty123"

Для теста я укажу пароли от которых серьезные администраторы должны покраснеть. Вы можете использовать внешнюю базу данных PostgreSQL. Для этого необходимо задать вот эти переменные: pg_host , pg_hostname и pg_username . Но я буду использовать базу данных из контейнера.

Далее необходимо собрать образ системы Ansible AWX:

sudo make docker-compose-build

Дождитесь окончания процесса сборки Docker образов. На моем тестовом сервере этот процесс занял примерно 5 минут. В случае успешного завершения сборки у вас должен отобразиться соответствующий образ Docker в перечне всех образов:

docker images

roman@ansible:~/awx$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE ghcr.io/ansible/awx_devel devel 882452ec2ea3 42 seconds ago 2.01GB roman@ansible:~/awx$

Теперь запустим сборку всех остальных компонентов системы. Я передам дополнительный аргумент COMPOSE_UP_OPTS=-d для того, чтобы запустить все контейнеры в фоне, а не в активном терминале:

make docker-compose COMPOSE_UP_OPTS=-d

Дождитесь окончания процесса сборки образов. На этот этап на моем тестовом сервере ушло примерно минута.

Теперь нужно подготовить UI:

docker exec tools_awx_1 make clean-ui ui-devel

Дождитесь окончания процесса сборки UI. Опять же на моем тестовом сервере мне понадобилось около 5 минут.

Один из заключительных шагов – это создание пользователя:

docker exec -ti tools_awx_1 awx-manage createsuperuser

roman@ansible:~/awx$ docker exec -ti tools_awx_1 awx-manage createsuperuser Username (leave blank to use 'awx'): Email address: Password: Password (again): Superuser created successfully. roman@ansible:~/awx$ 

Я оставлю стандартное имя – awx и укажу пароль пользователя.

Важный шаг – настроить политику перезапуска контейнеров. В противном случае после перезапуска docker хоста контейнеры не запустятся автоматически и вы не сможете получить доступ к Ansible AWX:

docker update --restart unless-stopped tools_awx_1 docker update --restart unless-stopped tools_postgres_1 docker update --restart unless-stopped tools_redis_1

Опционально можно загрузить демо данные:

docker exec tools_awx_1 awx-manage create_preload_data

Установка Ansible AWX завершена. Теперь можно перейти к оценки результатов нашего с вами труда.

Веб интерфейс администрирования

Веб интерфейс администрирования Ansible AWX доступен по следующему адресу (только с поправкой на IP-адрес вашего сервера):

https://10.10.10.106:8043

Вот так выглядит страница с запросом учетных данных:

Укажите учетные данные того пользователя, которого вы создали в процессе настройки продукта. После успешной аутентификации вы должны увидеть стартовую страницу панели администрирования Ansible AWX:

На этом я завершаю публикацию по процессу установки Ansible AWX. Постараюсь еще подготовить пару статей по первоначальной настройки и примерам использования данного продукта.

Установка Ansible AWX : 9 комментариев

Branson :

sudo make docker-compose-build
Здесь не удалось запустить сборку:
make: *** Нет правила для сборки цели «docker-compose-build».