awx dashboard

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

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

Ansible это 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 и сегодня снискали огромную популярность у разработчиков по всему миру, думаю что каждый кто это читает, как минимум слышал про 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:

$  clone https://github.com/ansible/awx. $ 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

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

Проект

awx projectКраеугольным камнем 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 

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

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

 $ ssh-keygen -b 4096 

Inventory

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

Задания

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

Добавить комментарий