Глава 4. Корпоративное управление инфраструктурой при помощи AWX

Ознакомьтесь с видеоматериалами Code in Action.

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

Большая часть кода AWX запускается в неком наборе контейнеров Docker, что делает его достаточно простым для развёртывания в большинстве сред. Тем не менее, в качестве ещё одного доказательства того, что AWX выступает дополнительным инструментом для Ansible, выступает тот факт, что он устанавливается при помощи команды ansible-playbook!

Применяя контейнеры Docker становится возможным запускать AWX в OpenShift или иных средах Kubernetes - однако для целей краткости здесь мы начнём установку в неком отдельном хосте Docker. Прежде чем мы предпримем что- то ещё, вы должны обеспечить выбор хоста со следующим:

Имея на своих местах эти инструменты, мы начинаем с простого клонирования имеющегося репозитория AWX с GitHub в тот хост, в котором оно должен быть установлен:

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

На данный момент его содержимое уже должно быть знакомым для вас - у нас есть некий файл описи и какой- то плейбук, который и устанавливает AWX! Прежде чем продолжить что- либо далее, измените имеющийся файл описи - как вы видите, имеется множество переменных, которые могут быть настроенными, причём большинство из них хорошо документировано в комментариях самого файла описи. В качестве крайнего минимума для начала я рекомендую установить такие переменные:

Таблица 4-1. некоторые переменные установки AWX

Название переменной	Рекомендуемое значение
admin_password	Это значение пароля по умолчанию для самого пользователя с правами администратора - он вам потребуется в момент самой первой регистрации, а потому убедитесь что вы установили нечто запоминающееся и безопасное!
pg_password	Это значение пароля для лежащей в основе базы данных PostgreSQL - убедитесь что вы установили нечто уникальное и безопасное.
postgres_data_dir	Это значение каталога для той локальной файловой системе, в которой будет хранить свои данные контейнер PostgreSQL - его значением по умолчанию каталог в /tmp который, в большинстве систем, будет автоматически очищаться на постоянной основе. Это часто разрушает получаемую базу данных PostgreSQL, а потому установите нечто сохранное (к примеру, /var/lib/awx/pgdocker).
project_data_dir	Для выгрузки плейбуков вручную в AWX без необходимости системы управления версиями все плейбуки обязаны располагаться где- то в имеющейся файловой системе. Чтобы предотвращать их копирование в некий контейнер, данная переменная устанавливает соответствие такой заданной локальной папки тому, что требуется внутри некого контейнера. Для всех примеров в этой книге мы будем применять установленное по умолчанию значение (папку /var/lib/awx/projects).
rabbitmq_password	Это значение пароля для лежащей в основе службы RabbitMQ - убедитесь что вы установили нечто уникальное и безопасное.
secret_key	Это значение значение секретного ключа для шифрования прав доступа в вашей базе данных PostgreSQL. Оно должно быть тем же самым при обновлениях AWX, а потому проверьте что вы сохранили его где- то в безопасности, так как он понадобится для установки в последующих инвентаризациях AWX. Сделайте что- то длинное и безопасное.

На данный момент вы уже отметили, что наш предыдущий файл содержит множество секретных значений, которые хорошо бы сами по себе запоминать в Vault, но они в действительности хранятся в явном виде в самом файле описи. Предполагается, что вы удалите свою предыдущую опись по завершению установки, и именно так и рекомендуется поступать!

После того как ваша опись отредактирована для ваших предпочтений, для установки AWX просто запустите следующую команду:

sudo ansible-playbook -i inventory install.yml
		

Это всё что требуется сделать - когда завершится исполнение плейбука, закончится и процесс установки. Если вы устанавливаете AWX впервые, вам может понадобиться дать системе несколько минут для согласования при запуске контейнеров Docker и создания схемы базы данных. Как только это будет завершено, вы сможете войти в AWX. Обратите внимание, что сам веб интерфейс AWX (а на самом деле API) работает в не зашифрованном виде по протоколу HTTP через порт 80. Оставляется для самостоятельного решения самой корпорации настраивать SSL для доступа к AWX - проще всего сделать это через отключение порта 80 в межсетевом экране от внешнего мира и поставить перед ним некую настройку разгрузки SSL. Это может быть некий балансировщик нагрузки, обратный посредник (прокси) или даже почтенная утилита stunnel. Например, если мы установили AWX в CentOS 7, мы можем осуществить такой процесс:

Теперь мы располагаем полностью настроенной службой AWX и пользователи должны иметь возможность осуществлять к ней доступ при помощи SSL! Как уже обсуждалось, имеется множество способов включения шифрования SSL для нашей службы AWX, и наш предыдущий код лишь приводится в качестве одного из примеров.

Когда вы впервые зарегистрируетесь в AWX, вам будет предоставлен экран инструментальной панели и внизу слева некая панель меню. Именно через эту панель меню мы изучим AWX и выполним свои первые действия по настройке. Также следует отметить, что при самой первой установке AWX заполняется некий образец содержимого чтобы помочь вам побыстрее освоиться. Не стесняйтесь исследовать это демонстрационное содержимое, так как примеры отличаются от тех, что приводились ранее в книге.

Давайте начнём с получения своего самого первого плейбука интегрированным и запущенным в AWX.

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

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

Прежде чем мы начнём, нам понадобится некий образец плейбука для его применения в наших примерах по мере нашего продвижения по этой главе. Прежде всего в самом хосте AVX создайте некую папку для своего проекта - если вы следуете рекомендованным ранее в главе предположениям, это будет /var/lib/awx/projects.

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

sudo mkdir /var/lib/awx/projects/mastery
		

Теперь мы помещаем в эту папку приводимый ниже код с названием example.yaml:

--
- name: AWX example playbook
  hosts: all
  gather_facts: false

  tasks:
    - name: Create temporary directory
      file:
        path: /tmp/mastery
        state: directory

    - name: Create a file with example text
      lineinfile:
        path: /tmp/mastery/mastery.txt
        line: 'Created with Ansible Mastery!'
        create: yes
 	   

Сделав это мы можем продолжить определение проекта.

В терминах AWX проект просто представляет собой некий набор собранных вместе плейбуков Ansible. Такие коллекции плейбуков часто выбираются из системы SCM (Source Control Management) и фактически именно это и является рекомендуемым способом корпоративного размещения плейбуков Ansible. Применение SCM означает что все работают с одной и той же версией кода и отслеживаются все изменения - все жизненно важные элементы в некой корпоративной среде.

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

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

Зарегистрируйтесь в своём интерфейсе AWX при помощи учётной записи admin, кликните по ссылке projects в полосе меню с левой стороны. Затем кликните по зелёной кнопке + рядом с верхним правым углом данного окна - это создаст для нас новый пустой проект.

На данный момент нам не следует беспокоиться относительно всех имеющихся полей (дополнительно о некоторых чуть позднее) - тем не менее, нам требуется настроить следующее:

Таблица 4-2. Необходимые для заполнения поля проекта

Название поля	Значение	Замечания
NAME	Mastery Examples	Уникальное название для отличия данного проекта от прочих
SCM TYPE	Manual	Ссылается на исходный код определённого плейбука - обратите внимание что в ниспадающем перечне доступны и прочие возможности. Manual относится к плейбукам для данного локального диска.
PLAYBOOK DIRECTORY	mastery	Это название заданного нами ранее в этой главе каталога, причём в нём помещается наш файл example.yaml.

Окончательный результат должен выглядеть как- то так:

Кликните по зелёной кнопке SAVE для сохранения своих изменений. Именно так вы определили свой самый первый проект в AWX! Начиная отсюда мы можем определять опись.

Инвентаризация в AWX работает так же как и прочие описи, с которыми мы работали ранее в своей командной строке. Они могут быть либо статическими, либо динамическими, могут составляться из групп и/ или индивидуальных хостов, а также могут иметь переменные, определяемые как глобальные на основе для группы или для хоста - мы теперь просто определяем их через некий интерфейс пользователя.

Кликните по элементу Inventories в полосе меню с левой стороны. Как и в случае проекта, мы желаем определить нечто новое, а потому кликните по зелёной кнопке + рядом с правым верхним углом окна и появится ниспадающий перечень. В этом списке выберите Inventory.

Когда появится окно определения NEW INVENTORY, введите некое название для этой описи (например, Mastery Demo), а затем кликните по зелёной кнопке SAVE.

По завершению этого вы должны получить некий экран, который выглядит примерно так:

Теперь обратите внимание на кнопки поверх самой панели описи - DETAILS, PERMISSIONS, GROUPS, HOSTS, SOURCES и COMPLETED JOBS. Вы обнаружите подобные этим кнопки почти на всех панелях в интерфейсе пользователя AWX и действительно, мы уже видели их когда определяли свой первый проект ранее (только нам не требовалось применять их на том этапе). Они работают как закладки и кликая по каждой из них мы загружаем в свою панель содержимое для того чтобы на свои места разместилась работа по конфигурированию.

Чтобы оставить свой образец простым, мы определим лиш один хост в группе для которого следует запускать наш пример плейбукаю Кликнув по кнопке закладки GROUPS, а затем кликнув по зелёному + мы добавляем новую группу. Задайте этой группе некое название и кликните по SAVE, как это показано на следующем снимке экрана:

Теперь кликните по кнопке закладки HOSTS, а затем нажмите на зелёный + и выберите из появившегося ниспадающего меню новый хост. Введите соответствующий IP адрес своего хоста AWX в поле HOST NAME и нажмите SAVE - окончательный результат должен выглядеть как- то так:

Отлично! Мы только что создали свою первую опись в AWX. Если бы мы создавали эту опись из командной строки, она бы выглядела следующим образом:

[Mastery Group]
192.168.81.149
 	   

Это может показаться слишком простым, однако это прокладывает нам необходимый путь для запуска самого первого нашего плейбука. Далее давайте взглянем на понятие прав доступа в AWX.

Одним из способов, коим AWX предлагает себя в корпоративные решения, состоит в безопасном хранении полномочий. Основываясь на своей природе и типичных вариантах применения Ansible зачастую предоставляет "ключи от дома где деньги лежат" в виде ключей SSH или паролей, которые имеют уровень полномочий root или иного администратора. Даже будучи закодированными в Vault, сам исполняющий данный плейбук пользователь будет обладать таким зашифрованным паролем, а следовательно сможет обладать необходимыми правами доступа. Очевидно, это может быть нежелательным сценарием, наличие многих людей с неконтролируемым доступом к полномочиям администратора, но к счастью для нас AWX разрешает эту проблему.

Давайте воспользуемся простым примером - допустим мой тестовый хост, который был ранее определён в нашей описи, имеет пароль root определённый как Mastery123!. Как нам его безопасно сохранить?

Прежде всего перейдём к элементу меню Credentials, а затем кликнем по зелёному +, как мы это уже делали ранее для создания чего- нибудь. Задайте этим полномочиям некое подабающее название (например, Mastery Login), а затем кликните по увеличительному стеклу вслед за полем CREDENTIAL TYPE. Вы обнаружите множество различных типов полномочий, которые способен хранить AWX, причём для регистрации в машине, как в нашем случае, мы бы желали выбрать тип Machine. После установки типа полномочий вы обнаружите что ваш экран изменился и появились соответствующие поля для создания прав доступа к машине. Мы можем задать соответствующую регистрационную запись на основе значения ключа SSH и различных иных параметров, однако в нашем случае простейшего примера мы просто устанавливаем соответствующие значения для USERNAME и PASSWORD:

Теперь SAVE свои полномочия. После того как они сохранены, вы обнаружите что значение пароля исчезнет и будет замещено строкой ENCRYPTED. Теперь невозможно выполнить выборку пароля (или ключа SSH, или иных чувствительных данных) через наш интерфейс пользователя AWX - вы можете видеть, что вы способны REPLACE существующее значение, но не можете его видеть. Единственным способом получения полномочий было бы одновременное подключение к лежащей в основе базе данных и применение соответствующего ключа шифрования на момент установки. Как уже обсуждалось ранее, это в любом случае должно быть безопасным, а следовательно, пока операторы AWX не получают доступа root к самой машине AWX, рассматриваемые полномочия остаются в безопасности и под контролем.

Таким образом, AWX защитил ваши чувствительные данные доступа неким образом, который не полностью отличается от Vault Ansible (обратите внимание, что Vault Ansible продолжает оставаться инструментом командной строки в AWX точно так же, как он мог бы применяться и в командной строке Ansible, причём создание и изменение Vault продолжают оставаться действием командной строки). Теперь давайте перейдём к нашему окончательному шагу, необходимому для запуска нашего самого первого плейбука из AWX - определению шаблона.

Некое задание шаблона - давайте определим его полное название - это некий способ сбора воедино всего что мы создали перед этим в элементах конфигурации, совместно с прочими иными параметрами, для запуска некого определённого плейбука для какой- то описи. Представляйте себе это как если бы вы запускали ansible-playbook в командной строке.

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

Это в результате должно привести к некому экрану, который выглядит примерно так:

Имея все эти поля заполненными, как на нашем предыдущем снимке экрана, кликните по кнопке SAVE. Наши поздравления! Вы теперь готовы запустить свой первый плейбук из AWX. Для этого перейдите обратно к списку Templates и коикните на маленькую иконку, снабжающую справа только что созданный нами шаблон. Сразу после того как вы это сделали, вы увидите исполнение своего задания и обнаружите вывод из ansible-playbook, который будет знаком вам по полученной командной строке, которая показана на следующем снимке экрана:

В левой части экрана JOBS вы можете видеть панель DETAILS, в которой перечислены ранее заданные нами основные параметры, такие как PROJECT и JOB TEMPLATE, совместно с полезными сведениями для целей аудита, например, от какого именно пользователя данное задание было LAUNCHED BY и значение времени когда это задание было STARTED и FINISHED. С правой стороны вы можете наблюдать сырой вывод из ansible-playbook. Вы можете получать доступ к экрану JOBS в любой момент времени кликнув по элементу меню Jobs в основной панели меню и просматривать все выполненные задания - это исключительная возможность для аудита различных действий, для которых AWX выполнил оркестровку, в особенности в средах со множеством пользователей.

Хотя имеется ещё многое из того, на что способен AWX, эти фундаментальные этапы яфвляются средоточием большинства задач, которые вы пожелаете осуществлять в AWX. Более того, получив понимание такого применения и последовательности будет хорошим началом изучения того как применять AWX. В нашем следующем разделе мы рассмотрим некие дополнительные моменты, которые вы можете выполнять при помощи AWX.

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

До сих пор мы рассматривали применение AWX лишь с точки зрения некого встроенного пользователя admin. Естественно, одним из основных свойств AWX является RBAC, и это достигается применением users и teams. Команда обычно является группой пользователей, а пользователи могут быть участниками одной или более команд.

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

Сам RBAC внутри AWX богат; например, некому определённому пользователю может быть придана роль ADMIN внутри одной группы и роли MEMBER или READ в иных.

Учётные записи пользователя самого по себе могут быть установленными в System Administrators, Normal Users или System Auditors.

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

Например, некому определённому пользователю со значением типа Normal User может быть назначена роль ADMIN внутри назначенной ему Team. Однако ему также может быть затем назначена роль со значением READ для некого конкретного Project, что лишает силы более общей роли ADMIN Team. Поэтому, когда он зарегистрируется, он увидит запрос для Project, но не сможет заменять его или исполнять какие бы то ни было задачи; например, некие обновления из SCM.

Когда дело доходит до RBAC, там имеется много интересного, а как только вы его освоите, вы запросто сможете создавать безопасные и жёстко закрытые развёртывания AWX, в которых у каждого будет иметься лишь требуемый ему уровень доступа.

AWX содержит некий элемент конфигурации с названием organization. Это некий набор inventories, projects, job templates и teams (которые, в свою очередь, группируют users). Следовательно, если у вас имеются две различные части корпорации, которые имеют совершенно различные требования, но всё ещё требуют применения AWX, они могут совместно использовать некий отдельный экземпляр AWX без необходимости перекрытия конфигурации в самом интерфейсе пользователя достоинствами организаций.

В то время как пользователи с типом системного администратора имеют доступ ко всем организациям, обычные пользователи будут видеть только сами организации и связанные с ними грани, а это на самом деле реально мощный способ разделения доступа к различным частям развёртывания AWX корпорации.

В качестве примера, когда мы создавали ранее в этой главе свою опись, вы могли заметить что мы игнорировали имеющееся поле ORGANIZATION (которое оставалось установленным по умолчанию - только для той организации, которая имелась в некой новой установке AWX). Если бы мы создали некую новую организацию с названием Mastery, тогда все кто не был участником этой организации не имел бы возможности видеть такую опись, причём вне зависимости от имеющихся у него полномочий или привилегий (единственно исключение для тех, кто имел тип пользователя System Administrators, которые могут видеть всё).

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

На странице определений для любого Project или Templates просто обратите внимание на кнопку закладки Schedules и после этого вы получите богатый диапазон доступных вам вариантов расписаний - приводимый ниже снимок экрана отображает некий пример расписания для шаблона задания, который мы создали ранее:

Обратите внимание на разнообразие доступных вариантов для составления вашего расписания - мы настроили это задание на запуск каждые два дня и прекращать после пяти запусков. Некая подробная разбивка этого расписания показывается внизу самого снимка экрана чтобы помочь вам что это соответствует вашим потребностям.

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

Просто перейдите к элементу меню Jobs и выведите список всех ранее запущенных заданий (для которых у данного пользователя имеются полномочия к просмотру) для их отображения. Даже имеется возможность повтора ранее завершённых заданий непосредственно в этом экране простым нажатием на иконку запуска ракеты вслед за имеющимся в запросе заданием. Отметим, что это немедленно запустит такое задание с теми же самыми параметрами, с которыми оно было запущено в самый последний раз!

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

Наш предыдущий снимок экрана показывает пример такого экрана заданий, взятого из только что настроенного экземпляра AWX, применяемого в этой книге. На этом снимке экрана вы отчётливо можете видеть те задания, которые мы исполняли ранее.

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

Ответ на это даёт осмотр, и для каждого созданного вами шаблона задания вы можете обнаружить некую кнопку закладки, помеченную сверху как ADD SURVEY. Опрос, на самом деле, некая определяемая администратором анкета (как следует из названия!), в котором выполняется проверка ввода обычного пользователя, а далее, когда он принят, в переменных Ansible сохраняются введённые значения.

Допустим, мы желаем перехватывать получаемое значение переменной http_port для некого шаблона задания при его запуске, тогда мы могли бы создать следующий опрос:

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

Запуск плейбука, в особенности из AWX, может быть сложным. Например, может быть желательным вначале обновление некого проекта из SCM и каких- то динамических описей. Затем мы можем запустить некий шаблон задания чтобы раскрутить какой- то код обновления. Однако, если он завершается неудачей, почти наверняка буде желательно выполнить откат всех изменений (либо предпринять лечебные действия). Когда вы кликаете по теперь известному вам зелёному + для добавления некого нового шаблона, вы обнаружите в своём ниспадающем меню два варианта - шаблон задания (с которым мы только что работали) и шаблон рабочего процесса.

После того как все необходимые поля для нашего шаблона рабочего процесса заполнены и он сохранён, у вас будет иметься возможность кликнуть по кнопке закладки WORKFLOW VISUALIZER. На самом деле это собирает некий простой поток, слева направо, для тех задач, которые выполняет AWX. Например, приводимый далее снимок экрана отображает некий рабочий процесс, в котором, изначально, наш демонстрационный проект осуществляет синхронизацию со своим SCM.

Если данный шаг успешен (что обозначается соответствующей зелёной ссылкой к следующему блоку), наш демонстрационный шаблон задания запускается. Если и он в свою очередь завершается успешнр, тогда запускается имеющийся шаблон хозяина. Если один из этапов завершается неудачей, тогда наш рабочий процесс в этом месте останавливается, хотя на любом этапе и может быть задано некое действие On Failure. Расширенное обсуждение рабочих процессы, опять же, выходит за рамки данной книги, но их представление здесь не лишнее, так как следует обратить внимание на их развитие. некий образец показан на приводимом снимке экрана:

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

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

Например, приводимый ниже снимок экрана показывает нам предварительно настроенный набор шаблона хозяина для электронной почты списку заданных получателей в случае возникновения событий отказа. В случае успешного выполнения никакие уведомления не осуществляются (хотя, конечно же, это можно изменить!):

Все заданные в AWX NOTIFICATIONS появляются в соответствующей закладке NOTIFICATIONS - их не приходится добавлять после определения. Они просто переключаются самим пользователем в уведомления SUCCESS и FAILURE значениями ON или OFF для каждой из служб уведомления.

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

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

Здесь мы вернёмся к самому языку Ansible и рассмотрим преимущества системы шаблонов Jinja2.