Глава 3. Оптимизация управления инфраструктурой при помощи AWX

Данная глава содержит примеры на основе таких технологий:

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

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

Все обсуждаемые в этой книге примеры доступны в GitHub.

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

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

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

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

$ ansible-playbook -i hosts --ask-pass simple.yml
		

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

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

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

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

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

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

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

В случае некого предприятия, локально сохраняемые индивидуально плейбуки могут быть некой проблемой ждущей своего возникновения. Например, когда пользователь A обновляет какой- то плейбук критически важным исправлением, как вы можете обеспечить что пользователь B обладает доступом к этому коду? В идеале такой код должен храниться в некой системе контроля версий (к примеру, в GitHub) и его локальная копия обновляется для каждого отдельного запуска.

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

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

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

Для действенного управления со стороны некой средой Linux предприятия, он обязан обладать неким видом полномочий доступа ко всем управляемым им серверам. Аутентификация SSH обычно делается безопасной либо на основании ключей SSH, либо паролями, а для большой команды операторов Ansible это означает, что все должны обладать доступом к таким паролям и частным ключам SSH, так как они необходимы для запуска Ansible. Не лишним будет сказать, что это представляет некую угрозу для безопасности!

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

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

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

Существуют мириады инструментов с которыми способен интегрироваться AWX - например, оба продукта Red Hat Satellite 6 и CloudForms products (а также их аналоги с открытым исходным кодом Katello и ManageIQ) предоставляют естественную интеграцию как с AWX, так и с Ansible Tower. Это всего лишь два примера, причём всё это возможно потому что всё что мы будем изучать по мере прохождения данной главы также доступно и через некий API, а также интерфейс командной строки.

Это допускает интеграцию AWX с широким разнообразием служб, либо вы даже имеете возможность написания некого плейбука из AWX как результат какого- то прочего действия, просто вызывая соответствующий API. Имеющийся интерфейс командной строки (носящий название tower-cli, от соответствующего коммерческого продукта Ansible Tower) также невероятно полезен, в особенности когда речь идёт о программируемом наполнении данными AWX. Например, когда вы желаете добавить некий хост в статическую опись, вы можете делать это через интерфейс веб пользователя (как мы это продемонстрируем позднее), через API, либо применяя CLI. Последние два метода сами по себе невероятно удачно укладываются в интеграцию с прочими службами- к примеру, некое CMDB (Configuration Management Database, управление настройками базы данных) может активно доставлять новые хосты в опись при помощи API без какой бы то ни было необходимости минимальных действий со стороны своего пользователя.

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

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

Установка AWX достаточно прямолинейна после того как вы правильно разместите по местам всё предварительно необходимое. На самом деле, одним из основных предварительных требований для AWX выступает Ansible, что доазывает дополняющую природу данной технологии. Большая часть необходимого кода AWX запускается в неком наборе контейнеров Docker, что превращает его в простейшее развёртывание для большинства сред Linux.

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

Эти предварительные требования обычно сразу доступны в большинстве систем Linux. Теперь мы выполним следующие шаги для начала своей установки:

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

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

Применение безопасного HTTP для AWX также достигается решением различными способами в различных средах. Большинство сред Docker будут обладать неким видом балансировщика нагрузки перед ними в помощь обработке их природы со множеством хостов и, как результат, шифрование SSL может быть выгружено туда. Также имеется возможность создания безопасности для единственного хоста Docker, такого как только что собранный нами, установив нечто, способное к обратному посредничеству (reverse proxy, например, nginx) и настроив его на обработку необходимого шифрования SSL.

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

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

Когда мы запускаем некий образец плейбука из своей командной строки, мы создаём свой файл описи, а затем свой плейбук, а потом запускаем его при помощи команды ansible-playbook. Всё это,конечно же, предполагает что у нас уже установлено соединение с необходимой удалённой системой либо через интерактивное задание некого пароля, либо через установку ключей SSH.

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

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

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

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

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

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

Приводимый в запросе код используется для установки образца стека LAMP в некой машине RHEL или CentOS 7 и он доступен для просмотра здесь.

Для запуска данной демонстрации вам понадобится машина CentOS 7. Мой демонстрационный хост носит название centos-testhost и если бы я определял файл описи для своей командной строки, он бы выглядел следующим образом:

[webservers]
centos-testhost

[dbservers]
centos-testhost
 	   

Для того чтобы повторить это в GUI AWX, выполните следующую последовательность:

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

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

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

Повторите этот процесс для определения группы dbservers. Позаботьтесь о том чтобы не создать эту группу в качестве подчинённой для группы webservers, что достаточно просто сделать. Вы обратите внимание на след хлебных крошек в вершине своего предыдущего снимка экрана - воспользуйтесь возвратом навигации на самом верхнем уровне нашей новой описи кликнув по Hands on Inventory (или выбранному вами названию).

Здесь процесс почти полностью совпадает, за исключением того, что когда у вас наступает время для добавления своего хоста во вновь создаваемую группу (шаг 6 в вашем предыдущей последовательности), выберите Existing Host, так как мы повторно применяем свой единственный хост для обеих групп в данном примере. Получаемый в результате экран должен выглядеть как- то так:

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

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

Хотя в этой книге мы и не станет углубляться в RBAC (Role-Based Access Control, Основанное на ролях управлеие доступом), проекты обслуживают роль и так. В приводимых ранее снимках экранов вы заметили некую кнопку PERMISSIONS вверху ряда панелей. Она представлена на протяжении определённых UI и применяется для определения того какие из пользователей могут обладать каким доступом и к каким элементам настроек. Например, если у вас имеется команда DBA (Database Administrators), которые должны иметь лишь доступ к тем плейбукам, которые относятся к серверам баз данных для серверов, вы можете создать некую опись серверов баз данных и предоставить к ним доступ только DBA. Аналогично, вы можете поместить все связанные с DBA плейбуки в один проект и снова предоставить учётные сведения для данного проекта только этой команде. Таким образом AWX формирует некую часть своих добрых процессов внутри некого предприятия, причём делая Ansible более доступным и обеспечивая что верные элементы доступны лишь для правильного персонала.

Для продолжения своего простого примера, давайте создадим какой- то новый проект, ссылающийся на наш пример кода Anible:

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

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

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

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

Шаблоны AWX вытаскивают все прочие созданные вами до сих пор элементы настроек - по существу, шаблон является надлежащим определением AWX всех тех параметров, которые вы определяете в командной строке вслед за самой командой ansible-playbook.

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

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

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

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

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

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

Мы рассмотрели как AWX может способствовать нам с запуском задач вручную - но что если мы желаем действительно подхода к автоматизации без ручного вмешетальства? Мы изучим управление задачами в своём следующем разделе данной главы.

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

Например, вы можете написать некий плейбук Ansible, чтобы обеспечивать что соответствующий демон SSH не допускает удалённой регистрации root, ибо это рассматривается как хороший практический приём безопасности. Естественно, любой системный администратор с полномочиями root запросто сможет зарегистрироваться и включить это снова; тем не менее, регулярный запуск некого плейбука Ansible для включения данного принуждения обеспечит что никто (из добрых или иных побуждений) не отключит его обратно. Имеющаяся идемпотентная природа изменений Ansible означает, что там, где эта настройка уже размещена, Ansible не будет выполнять никакие изменения, а следовательно запуск такого плейбука безопасен, лёгкий для системных ресурсов и не разрушительный.

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

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

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

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

Теперь если вы загляните в панель Jobs вы должны обнаружить что ваш шаблон начал запускаться в установленное расписанием время. Когда вы проанализируете завершение задания (или реальное выполнение), вы должны обнаружить что он был запущен по тому названию в расписании, которое было создано ранее, а не по имени учётной записи пользователя, такого как admin (которое мы наблюдали при запуске вручную). Здесь мы представляем некий снимок экрана, который отображает пример завершённого задания, которое было запущено нашим созданным ранее расписанием Scheduled install:

Если вы желаете просмотреть все установленные расписанием задания, которые предстоят для вашего экземпляра AWX, вы можете просто кликнуть по элементу меню Schedules в левой полосе меню и будет загружен некий экран, который перечислит все настроенные расписания для вашего экземпляра AWX. Для тех из вас, кто знаком с администрированием Linux, это выглядит как перечисление заданий cron. Некий пример такого экрана отображен на снимке экрана внизу:

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

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

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

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

В этой главе вы изучили чем важен AWX для окружения Linux предприятия и как применять ряд его ключевых функций. Далее вы провели практическую установку отдельного узла AWX прежде чем осуществили практический пример повсеместного запуска плейбука напрямую из GitHub для настройки стека LAMP в сервере CentOS 7. Наконец, вы изучили планирование заданий для автоматизации задач повседневного сопровождения при помощи Ansible.

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

Для более глубокого понимания Ansible, включая AWX, будьте добры ознакомиться с Mastering Ansible, Third Edition — James Freeman и Jesse Keating {Прим. пер.: рекомендуем также свой перевод этого 3 издания Полного руководства Ansible Джеймса Фримана и Джесса Китинга}.

Для получения лучшего представления о контроле версий при помощи Git и наилучших практических приёмах его использования, будьте добры ознакомиться с Git Best Practices Guide, Eric Pidoux.

Для понимания того как выполнять доступ через API AWX и работать с ним, ознакомьтесь, пожалуйста, с https://docs.ansible.com/ansible-tower/latest/html/towerapi/index.html.

Если вы желаете освоить контроль AWX с применением инструментария tower-cli, обратитесь, пожалуйста, к официальной документации.