Awx что это

Awx что это

Connect with the community at the following upcoming events.

Ansible Galaxy

The Ansible community hub for sharing automation with everyone.

Ansible on GitHub

AWX on GitHub

Documentation

Compare Ansible options

Get started

Ansible is powerful IT automation that you can learn quickly.

Quick start video

Resource library

Webinars & Training

Ansible events

• AnsibleFest at Red Hat Summit
• Ansible Automates
• Workshops
• All upcoming events

Partners

Interactive labs

• Compare Ansible options
• Why Ansible?
• How Ansible works
• Pricing
• Training and Certification
• Try an interactive lab
• Start a product trial

Features

• Ansible Lightspeed
• Event-Driven Ansible
• Automation execution environments
• Automation controller
• Automation mesh
• Ansible Content Collections
• Automation hub
• Automation analytics and Red Hat Insights
• Ansible content tools
• All features

• Hybrid cloud automation
• Edge automation
• Network automation
• Security automation
• Infrastructure automation
• Provisioning

• Configuration management
• Application deployment
• DevOps
• Orchestration

Infrastructure

Networks

Containers

Cloud

DevOps Tools

Security

Managed

Self-managed

• Red Hat Ansible Automation Platform via AWS Marketplace
• Red Hat Ansible Automation Platform via Google Cloud Marketplace

The AWX Project

Q: What is The AWX Project?

The AWX project—AWX for short—is an open source community project, sponsored by Red Hat, that enables users to better control their community Ansible project use in IT environments. AWX is the upstream project from which the automation controller component is ultimately derived.

Q: Why is Red Hat doing this?

Open sourcing everything is what Red Hat does. When Ansible, Inc. was acquired by Red Hat, we told our users that we would open the source code for Ansible. The AWX project is a fulfillment of that intent.

More importantly, the Ansible team—like all of Red Hat—believes deeply in the power of community-driven innovation. The Ansible project itself has more than 3,000 contributors and we believe this will continue to grow and expand. Many of the critical features we now provide for users and customers were built almost entirely by the Ansible community. We believe that the open source model will bring many innovations to the AWX Project.

Q: What’s the difference between AWX and automation controller?

AWX is designed to be a frequently released, fast-moving project where all new development happens.

Automation controller is produced by taking selected releases of AWX, hardening them for long-term supportability, and making them available to customers as a hosted service within Red Hat Ansible Automation Platform. Ansible Automation Platform is fully supported by Red Hat, while AWX is supported by the community.

This is a tested and trusted method of software development for Red Hat, which follows a similar model to Fedora and Red Hat Enterprise Linux.

Q: Where can I find support for AWX?

The community can help answer questions about AWX via IRC and the AWX mailing list .

Because AWX is designed to be a rapidly moving project, Red Hat does not provide any paid support for it. For a fully supported automation management platform, read more about Red Hat Ansible Automation Platform .

Q: Can I upgrade from one version of AWX to another?

A: Direct, in-place upgrades between AWX versions are not supported. Learn how to migrate between different instances of AWX .

Q: Under which open source license is AWX available?

The AWX source code is available under the Apache License 2.0.

Q: How can I get involved with the AWX Project?

The AWX Project is hosted on GitHub . We welcome community contributions. Read the contributor guide .

Q: Where do I report an AWX bug?

The AWX project uses GitHub for its issue tracking. You can file your issues here .

Q: How often is AWX released?

The AWX team currently plans to release new builds approximately every 2 weeks. The AWX team will flag certain builds as “stable” at their discretion. Note that the term “stable” does not imply fitness for production usage or any kind of warranty whatsoever.

Q: What is the governance structure of the AWX project?

For now, the AWX team will continue to make all decisions for the AWX project. Over time, we will evaluate our governance structure, and we will do our best to choose a structure that balances community needs with product needs.

Q: If my software runs with AWX, can I say that it is certified to run on AWX or on Red Hat Ansible Automation Platform?

No. Only Red Hat has the ability to say that software is “certified,” although you may truthfully use the AWX name to describe the relationship between your software and AWX. For more details, consult the AWX trademark guidelines .

Q: I want to build my own forked version of AWX. Can I call it AWX? Can I call it Red Hat Ansible Automation Platform?

No. You may fork AWX like any open source codebase, but you may not use Red Hat trademarks. Red Hat reserves the exclusive right to decide what products can bear those marks. Be sure to read the AWX trademark guidelines for more information.

Q: Will contributions to AWX require a “Contributor License Agreement”?

No. However, all contributions to AWX will require agreement with the Developer Certificate of Origin (DCO) at the time of submission. The text of the DCO can be read in full at developercertificate.org.

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

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

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

В этой главе мы рассмотрим следующее:

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

Технические требования

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

Получение AWX поднятым и исполняемым

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

• RBAC ( Rich role-based access control , Богатый контроль доступа на основе ролей)
• Интеграцию с централизованными службами регистрации (например, LDAP или Active Directory)
• Безопасное управление правами доступа
• Возможность проведения аудита
• Подотчётность
• Пониженный барьер для входа новых операторов
• Улучшенное управление контролем версий плейбуков

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

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

• Полностью установленный и работающий Docker
• Модуль docker-py для вашей версии Python
• Доступ к Docker Hub
• Ansible 2.4 или более новый
• Git 1.8.4 или более новый

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

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

Наша предыдущая команда клонирует самый последний выпуск AWX — если вы желаете клонировать один из имеющихся выпусков, просмотрите раздел Releases и отыщите нужную вам версию.

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

Это значение пароля по умолчанию для самого пользователя с правами администратора — он вам потребуется в момент самой первой регистрации, а потому убедитесь что вы установили нечто запоминающееся и безопасное!

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

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

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

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

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

1. Прежде всего мы установим NGINX (обратите внимание, что это потребует репозитория EPEL установленным и включённым для CentOS 7):

 sudo yum install nginx 

• Сертификат: /etc/pki/tls/certs/mastery.example.com.crt
• Общедоступный ключ: /etc/pki/tls/private/mastery.example.com.key

Если у вас нет сертификата SSL, вы запросто можете сгенерировать некий с самостоятельной подписью для выполнения данного примера при помощи такой команды:

 openssl req -x509 -nodes -newkey rsa:4096 -keyout /etc/pki/tls/private/mastery.example.com.key -out /etc/pki/tls/certs/mastery.example.com.crt -days 3650 -subj "/C=GB/CN=mastery.example.com" 

 server < listen 443 ssl; server_name mastery.example.com; ssl on; ssl_certificate /etc/pki/tls/certs/mastery.example.com.crt; ssl_certificate_key /etc/pki/tls/private/mastery.example.com.key; location / < proxy_pass http://127.0.0.1:80; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >> 

 server < listen 81 default_server; listen [::]:81 default_server; 

 sudo systemctl enable nginx.service sudo systemctl start nginx.service 

 sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --reload 

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

Когда вы впервые зарегистрируетесь в 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 в полосе меню с левой стороны. Затем кликните по зелёной кнопке + рядом с верхним правым углом данного окна - это создаст для нас новый пустой проект.

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

NAME

Уникальное название для отличия данного проекта от прочих

SCM TYPE

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

PLAYBOOK DIRECTORY

Это название заданного нами ранее в этой главе каталога, причём в нём помещается наш файл example.yaml .

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

Рисунок 4.1

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

Определение учёта

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

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

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

Прежде чем вы приступите к заданию хостов или групп, вам надлежит сохранить свою пустую опись.

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

Рисунок 4.2

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

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

Рисунок 4.3

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

Рисунок 4.4

Видимый в большинстве экранов описей блок VARIABLES ожидает задание переменных в формате YAML или JSON, а не в формате INI, который мы использовали в своей косандной строке. Ту строку, которую мы ранее задавали как ansible_ssh_user=james , теперь нам следует вводить как ansible_ssh_user: james , если выбран формат YAML.

Отлично! Мы только что создали свою первую опись в 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 :

Рисунок 4.5

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

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

Определение шаблона

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

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

1. Кликните по Templates в меню с левой стороны.
2. Кликните по зелёному + для создания некого нового шаблона.
3. Из возникшего ниспадающего списка выберите Job Template .
4. В качестве минимума для запуска нашего первого задания вам потребуется определить следующие поля в своём экране NEW JOB TEMPLATE :

Таблица 4-3. Необходимые для заполнения нового шаблона задания

Название поля	Значение	Замечания
NAME	Mastery Template	Уникальное название для идентификации данного задания.
JOB TYPE	Run	Значением по умолчанию здесь выступает Run , что и является именно тем что мы намерены делать. Мы также можем выбрать Check , что запустит этот плейбук применяя все заданные параметры без выполнения каких бы то ни было изменений в самих хостах описи.
INVENTORY	Mastery Demo	Нажмите на иконку увеличительного стекла в этом поле и затем выберите ту опись, которую вы создали ранее в данном процессе.
PROJECT	Mastery Examples	Нажмите на иконку увеличительного стекла в этом поле и затем выберите тот проект, которую вы создали ранее в этой главе, который содержит образец нашего плейбука.
PLAYBOOK	После того как заполнено значение поля PROJECT , ниспадающее меню PLAYBOOK автоматически заполняется списком всех файлов с расширениями *.yaml или *.yml , которые выявляются в самом источнике PROJECT . Обратите внимание, что если ваш проект был подключён к некому SCM, этот список будет пустым.
CREDENTIAL	Mastery Login	Кликните по иконке увеличительного стекла в этом поле и выберите те полномочия, которые мы создали ранее.

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

Рисунок 4.6

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

Рисунок 4.7

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

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

Выход за основы

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

RBAC (Role-based access control)

До сих пор мы рассматривали применение 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.

Как основное высеченное на камне правило, более конкретные полномочия подавляют менее определённые. Таким образом, уровень Project будет иметь преимущества над уровнями Team или User . Обратите внимание, что для элементов, для которых даже нет Permission через некого User или Team , такая персона не сможет видеть даже эти элементы при регистрации через такой интерфейс пользователя. Единственным исключением из этих правил выступают System Administrators , которые способны видеть всё и выполнять любые действия. Назначайте со знанием меры этот тип учётным записям User !

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

Рисунок 4.8

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

Аудит

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

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

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

Рисунок 4.9

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

Опрос

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

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

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

Рисунок 4.10

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

Шаблоны рабочего процесса

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

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

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

Рисунок 4.11

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

Уведомления

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

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

Рисунок 4.12

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

Выводы

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

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

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

Тест-драйв 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.

Ansible AWX — открытый Ansible Tower

После долгого ожидания, наконец-то открылся Ansible Tower, под названием AWX.

Проект AWX - открытый проект спонсируемый Red Hat, позволяющий пользователям лучше контроллировать свою инфраструктуру.

AWX это upstream проект, на котором будет основываться коммерчески поддерживаемый Tower, по тому же принципу что и Fedora-RHEL, oVirt-RHV, MIQ-CloudForms и т.д.

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

Исходники AWX будут доступны под лицензией Apache License 2.0.

Команда AWX на данный момент планирует выпускать новые релизы примерно каждые две недели. Некоторые релизы будут обозначены как «стабильные» (что конечно не означает что их рекомендуют к использованию в продакшене).

Ну и прямая цитата из оригинала:

Q: WHY IS RED HAT DOING THIS?

Because this is what Red Hat does.

dyasny ★★★★★
07.09.17 18:22:10 MSK
Проверено: Shaman007 ( 07.09.17 22:11:23 MSK )
← 1 2 →

dhameoelin ★★★★★
( 07.09.17 22:13:52 MSK )

Не пришлось щупать нигде Tower, но судя по отзывам тех, кто щупал, хочу резюмировать - ГОДНОТА!

Pinkbyte ★★★★★
( 07.09.17 22:19:07 MSK )
alpha ★★★★★
( 07.09.17 22:46:38 MSK )

Могли бы и написать что это такое, а то придется по ссылкам лезть 🙁

mx__ ★★★★★
( 07.09.17 22:47:24 MSK )

Ну и что такое AWX?

skvitek ★★★
( 07.09.17 22:49:47 MSK )
Ответ на: комментарий от mx__ 07.09.17 22:47:24 MSK

Написано же - открытая версия ansible tower. Если не в теме что это такое, то скорее всего оно тебе не нужно

dyasny ★★★★★
( 07.09.17 23:03:37 MSK ) автор топика
Ответ на: комментарий от skvitek 07.09.17 22:49:47 MSK

dyasny ★★★★★
( 07.09.17 23:03:48 MSK ) автор топика

А rpm-ки тоже есть уже или пока в процессе?

alpha ★★★★★
( 07.09.17 23:07:15 MSK )
Ответ на: комментарий от alpha 07.09.17 23:07:15 MSK

из того что я видел на гитхабе есть контейнер и плейбук который все устанавливает

dyasny ★★★★★
( 07.09.17 23:14:38 MSK ) автор топика
Ответ на: комментарий от skvitek 07.09.17 22:49:47 MSK

В двух словах - панель управления запусками ansible playbooks

alpha ★★★★★
( 07.09.17 23:25:18 MSK )

Indexator ★★★
( 08.09.17 00:22:57 MSK )

Я буквально на днях думал о том, есть ли какие-то открытые реализации одминки для Ansible наподобие Tower, а тут такой царский подгон! ��

Все же Красношляпка - красавчики! ��

Indexator ★★★
( 08.09.17 00:34:34 MSK )
Ответ на: комментарий от Indexator 08.09.17 00:34:34 MSK

Вообще много всякого есть для Ansible. Например, Semaphore https://github.com/ansible-semaphore/semaphore. Но конечно он не дотягивает до Tower.

ipeacocks ★★★★★
( 08.09.17 00:40:53 MSK )
Ответ на: комментарий от dyasny 07.09.17 23:03:37 MSK

это твоя новость не нужна. Неужели трудно в одном предложении описать?

И да, прикрути что ли спеллчекер. Полноценная новость в таком виде — просто позорище.

demidrol ★★★★★
( 08.09.17 00:52:33 MSK )
Ответ на: комментарий от alpha 07.09.17 23:25:18 MSK

Ясно, спасибо. Очередное «ненужно».

skvitek ★★★
( 08.09.17 01:23:10 MSK )
Ответ на: комментарий от ipeacocks 08.09.17 00:40:53 MSK
anonymous
( 08.09.17 02:25:24 MSK )
Ответ на: комментарий от demidrol 08.09.17 00:52:33 MSK

тебе не нужна - проходи мимо.

dyasny ★★★★★
( 08.09.17 03:06:23 MSK ) автор топика
buratino ★★★★★
( 08.09.17 03:17:09 MSK )

Тыкал Ansible Tower. На момент, когда тыкал - он был уг. Возможно, сейчас отдебажат на нищебродах и можно будет внедрять. 🙂

devilinside
( 08.09.17 06:17:19 MSK )

Because this is what Red Hat does.

Высочайшее разрешение на использование в Крыму-то хоть выдали?

dave ★★★★★
( 08.09.17 06:37:20 MSK )
Ответ на: комментарий от devilinside 08.09.17 06:17:19 MSK

Тыкал Ansible Tower. На момент, когда тыкал - он был уг. Возможно, сейчас отдебажат на нищебродах и можно будет внедрять. 🙂

и как давно его тыкал? Я смотрел триал около года назад, он устраивал во всем, кроме цены 🙂 Может ты просто не осилил?

JB ★★★★★
( 08.09.17 08:09:04 MSK )
Ответ на: комментарий от ipeacocks 08.09.17 00:40:53 MSK

Вообще много всякого есть для Ansible. Например, Semaphore https://github.com/ansible-semaphore/semaphore. Но конечно он не дотягивает до Tower.

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

JB ★★★★★
( 08.09.17 08:09:27 MSK )
Ответ на: комментарий от dyasny 07.09.17 23:14:38 MSK

контейнеры делают людей слишком ленивыми

JB ★★★★★
( 08.09.17 08:13:23 MSK )
Ответ на: комментарий от dyasny 07.09.17 23:03:37 MSK

Пришлось почитать раз ни кто толком не объясняет.

Вот описываю для тех кому лень читать инет.

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

2. Товер - это веб рожа к этой Ansible, для тех кто не может кли, и оно уже за деньги.

3. Сабж это веб рожу сделали фрии .

mx__ ★★★★★
( 08.09.17 08:58:13 MSK )
Последнее исправление: mx__ 08.09.17 08:59:00 MSK (всего исправлений: 2)

Ответ на: комментарий от mx__ 08.09.17 08:58:13 MSK

хз зачем нужно было делать еще одну.

Chef и Puppet требуют установки клиента. Ansible сам коннектится к таргетам по SSH, Telnet. Это и минус и плюс. С одной стороны - позволяет конфигурить более широкий набор оборудования, с другой - нет проверки актуальности конфигов.

MadMax ★
( 08.09.17 09:13:07 MSK )
Ответ на: комментарий от mx__ 08.09.17 08:58:13 MSK

у ansible и puppet совершенно разные схемы работы. Ansible это просто выполнение определенных действий, а puppet - декларативный язык описания состояния

JB ★★★★★
( 08.09.17 09:37:33 MSK )

Q: Does Red Hat recommend AWX for production environments?
No.

anonymous
( 08.09.17 09:51:46 MSK )
Ответ на: комментарий от mx__ 08.09.17 08:58:13 MSK

Разный подход, Ansible - push, Puppet - pull, c Ansible не работал, а Puppet описывает к которому нужно привести клиентскую машину в манифестах, синтаксис и подход написания которых как в Ruby, например вам необходимо на всех машинах класса CentOs/RedHat/Fedora добавить пользователя задав ему пароль, дав домашнюю директорию и права и допустим всем подобным осям установить определенные пакеты, можно эту конфигурацию описать вот как-то так:

case $::osfamily < 'redhat': < package < ['tree', 'vim', 'tmux', 'openssh-server', 'openssh-clients', 'epel-rel ease', 'htop']: ensure =>installed, > user < 'adm': ensure =>present, name => 'admin', home => '/home/admin', managehome => true, shell => '/bin/bash', password => 't.xOjwLFMiZbc', groups => wheel, > file < 'bashrc': ensure =>file, path => '/home/admin/.bashrc', source => 'puppet:///files/test/rhelbashrc', owner => 'admin', group => 'admin', mode => '0644', > > >

После этого клиенты в через определенное заданное время сами заберут настройки и все применят. Очень удобная вещь если вам необходимо например что-то срочно поставить на много-много машин с одним конфигом, отдельные ноды тоже можно описывать; Резюмируя: хороший инструмент.