Тест-драйв 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 требуется предварительная настройка, а именно:

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

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

2. Так же, как уже оговаривалось, потребуется работающий Docker:

   $ 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:

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

   - hosts: all
   
     roles:
       - ntp
       - sshd
   

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

2. Наиболее резонно, с моей точки зрения, размещать актуальные версии ролей непосредственно в проекте. А если использовать в качетсве SCM git, то это еще и очень удобно благодара функционалу submodule:

   $ 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.