Полный обзор AWX для Ansible: возможности, назначение и логика работы

AWX — это веб-интерфейс, REST API и механизм управления для Ansible, который делает автоматизацию удобнее и управляемее. Он является основой для Red Hat Ansible Automation Platform (AAP) и предоставляет мощные возможности для администрирования инфраструктуры.

🔹 Возможности AWX

Управление инвентарем
- Подключение к динамическим инвентарям (например, AWS, GCP, VMware).
- Группировка хостов и управление ими через GUI.
- Импорт инвентаря из статических файлов (INI, YAML, JSON).
Планирование и выполнение заданий
- Запуск плейбуков по расписанию.
- Возможность ручного запуска через интерфейс.
- Параллельное выполнение нескольких задач.
Контроль доступа и безопасность
- Ролевая модель управления (RBAC).
- Поддержка интеграции с LDAP, SAML, OAuth.
- Гибкие политики доступа к ресурсам.
Логирование и мониторинг
- Детальный журнал выполнения задач.
- Интеграция с Grafana, Prometheus, ELK.
- Уведомления (Slack, Email, Webhook).
CI/CD и интеграция с SCM
- Автоматический запуск плейбуков при изменении кода (Git, SVN).
- Подключение к GitHub, GitLab, Bitbucket.
- Поддержка Webhook'ов.
Шаблоны заданий
- Создание преднастроенных сценариев (например, деплой новых серверов).
- Переменные, передаваемые при запуске.
- Включение опроса подтверждения перед выполнением критических задач.

🔹 Как работает AWX?

Инвентарь — список управляемых серверов.
Проект — источник Ansible-скриптов (обычно Git-репозиторий).
Шаблон задания — описание того, какие плейбуки и с какими параметрами запускать.
Запуск задания — выполнение Ansible-плейбука на указанных серверах.
Мониторинг — просмотр логов выполнения, уведомления, статистика.

🔹 Применение

Автоматизация развертывания серверов и приложений.
Конфигурационное управление и обновления.
Оркестрация процессов (DevOps, CI/CD).
Интеграция с ITSM (ServiceNow, Jira).

✅ Зависимые роли в Ansible (если одна роль зависит от успешного выполнения другой)

В Ansible можно сделать зависимые роли несколькими способами:

Использование dependencies в meta/main.yml
- Внутри роли можно указать зависимости от других ролей, и они будут выполняться до запуска основной роли.
- Однако они не могут зависеть от условий (т.е. если предыдущая роль выполнилась без ошибок).
Пример roles/main/meta/main.yml:
```
dependencies:
  - role: role1
  - role: role2
```
В этом случае role1 → role2 → main выполнятся автоматически.

Условное выполнение роли (через include_role)

Используется в playbook.yml для контроля выполнения.
Можно проверять статус выполнения предыдущей роли.

Пример playbook.yml:

- hosts: all
  tasks:
    - name: Выполнить role1
      include_role:
        name: role1
      register: result_role1  # Сохраняем результат выполнения
    
    - name: Выполнить role2, если role1 прошла без ошибок
      include_role:
        name: role2
      when: result_role1 is succeeded

Если role1 завершится без ошибок, то запустится role2.
Если role1 упадёт, то role2 не выполнится.

🔹 Можно ли делать что-то вроде пайплайнов?

Да, но Ansible не имеет встроенного механизма для создания "пайплайнов", как в GitLab CI/CD или Jenkins. Однако ты можешь:

Организовать логику пайплайна через Playbook'и
Например, разбить выполнение на этапы:

- hosts: all
  tasks:
    - name: Подготовка окружения
      include_role:
        name: prepare_env

    - name: Деплой приложения
      include_role:
        name: deploy_app
      when: "'prepare_env' in ansible_run_tags"

    - name: Тестирование
      include_role:
        name: run_tests
      when: "'deploy_app' in ansible_run_tags"

Каждый шаг запускается последовательно.
Можно использовать переменные или tags для контроля выполнения.

Использовать AWX (или Ansible Tower)
- Он поддерживает Workflows — визуальное построение пайплайнов из ролей и задач.
- Можно задать зависимости, условия и параллельное выполнение.
Интегрировать с CI/CD (GitLab, Jenkins)
- Ansible можно запускать как часть пайплайна, например:
```
deploy:
  script:
    - ansible-playbook -i inventory playbook.yml
```
- А в GitLab CI/CD можно использовать when: on_success для контроля выполнения.

Если нужна простая зависимость между ролями, используй `include_role` с `when`.
Если хочешь пайплайны, то лучше использовать AWX (Ansible Tower) или интеграцию с Jenkins/GitLab CI/CD.

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

🔹 AWX: Подробный разбор разделов

🏠 Dashboard (Панель управления)

Что здесь есть?

Краткая статистика по заданиям (Jobs), пользователям, инвентарю и организациям.

График запущенных заданий.

Статусы хостов (успешные/неуспешные).

Быстрые ссылки на важные элементы (Templates, Inventories, etc.).

Как использовать?
Используется для мониторинга состояния AWX, быстрого доступа к активным задачам и анализа работы системы.

📌 Jobs (Задания)

Что здесь есть?

История выполненных задач (playbook'ов).

Статус (успешно, с ошибками, в очереди и т. д.).

Логи выполнения.

Как использовать?
Можно посмотреть результаты выполнения Ansible-скриптов, перезапустить неудавшиеся задачи, анализировать ошибки.

📅 Schedules (Расписание)

Что здесь есть?

Планировщик задач (запуск плейбуков по расписанию).

Настройка повторяющихся задач (ежедневно, еженедельно, CRON).

Как использовать?
Позволяет автоматизировать выполнение задач (например, раз в день делать бэкап).

📜 Activity Stream (Журнал активности)

Что здесь есть?

Лог всех действий в системе (кто и что делал).

Фильтрация по пользователям, объектам, времени.

Как использовать?
Отслеживание изменений, мониторинг активности пользователей.

✔️ Workflow Approvals (Согласование рабочих процессов)

Что здесь есть?

Управление заданиями, требующими одобрения.

Возможность разрешить/запретить выполнение определённого этапа в пайплайне.

Как использовать?
Если в компании требуется проверка перед выполнением критичных задач (например, деплой в продакшен), можно включить ручное одобрение.

🔥 Resources (Ресурсы)

📌 Templates (Шаблоны заданий)

Что здесь есть?

Готовые сценарии запуска (указываются playbook, инвентарь, переменные).

Типы: Job Template (обычные плейбуки), Workflow Template (цепочка задач).

Как использовать?
Создание стандартных операций (например, развернуть сервер, обновить ПО).

🔑 Credentials (Учетные данные)

Что здесь есть?

SSH-ключи, токены API, пароли.

Интеграция с Git, AWS, GCP, Azure.

Как использовать?
Хранение и защита учетных данных, необходимых для работы Ansible (доступ к серверам, облакам).

📂 Projects (Проекты)

Что здесь есть?

Источник Ansible-плейбуков (обычно репозиторий Git).

Возможность синхронизации (автообновление при изменениях в Git).

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

📌 Inventories (Инвентарь)

Что здесь есть?

Список управляемых серверов (статический, динамический).

Группы хостов.

Как использовать?
Настраивается список серверов для автоматизации (например, веб-серверы, базы данных).

🖥️ Hosts (Хосты)

Что здесь есть?

Список отдельных серверов из инвентаря.

Их состояние (доступен/не доступен).

Как использовать?
Можно вручную управлять конкретными хостами.

🔹 Access (Доступ)

🏢 Organizations (Организации)

Что здесь есть?

Разделение пользователей и ресурсов на организации.

У каждого пользователя свои права доступа.

Как использовать?
Позволяет настраивать изолированные группы пользователей с разными правами.

👤 Users (Пользователи)

Что здесь есть?

Список пользователей, их роли.

Вход через LDAP, OAuth, SAML.

Как использовать?
Добавление, редактирование пользователей, управление их правами.

👥 Teams (Команды)

Что здесь есть?

Группы пользователей с общими настройками.

Как использовать?
Позволяет управлять доступом к ресурсам сразу для нескольких пользователей.

🔥 Administration (Администрирование)

🔐 Credential Types (Типы учетных данных)

Что здесь есть?

Настройка собственных типов аутентификации (например, кастомные API-токены).

Как использовать?
Если стандартные креды не подходят, можно создать свои.

📣 Notifications (Уведомления)

Что здесь есть?

Настройка отправки сообщений (Slack, Email, Webhooks).

Как использовать?
Можно получать уведомления о статусе выполнения задач.

⚙️ Management Jobs (Системные задания)

Что здесь есть?

Очистка базы данных.

Удаление старых логов.

Как использовать?
Плановое обслуживание AWX.

💾 Instance Groups (Группы инстансов)

Что здесь есть?

Разделение нагрузки между серверами AWX.

Как использовать?
Для масштабирования AWX на несколько серверов.

🖥️ Instances (Инстансы)

Что здесь есть?

Список активных серверов AWX.

Как использовать?
Мониторинг работоспособности AWX.

🔑 Applications (Приложения)

Что здесь есть?

API-токены для внешних сервисов.

Как использовать?
Если AWX интегрируется с другим ПО, например, CI/CD.

📦 Execution Environments (Среды выполнения)

Что здесь есть?

Контейнерные образы с Ansible.

Как использовать?
Позволяет запускать задачи в разных средах (например, Python 3.8 vs Python 3.11).

🌍 Topology View (Топология)

Что здесь есть?

Визуализация структуры AWX.

Как использовать?
Для наглядного понимания архитектуры AWX.

⚙️ Settings (Настройки)

Что здесь есть?

Глобальные параметры системы.

Настройки аутентификации, API, безопасности.

🔹 Пошаговая настройка AWX

✅ 1. Создаём организации

(Необязательно, если всё в одной организации)
Если хочешь, можно создать несколько организаций, например, "Development" и "Operations".

📍 Как создать организацию:

Перейди в Organizations → Add (добавить).
Назови, например, MyCompany.

✅ 2. Создаём группы пользователей

Переходим в Access → Teams и создаём команды:

DevOps (доступ ко всему).
QA (только к QA-серверам).
DEV (только к DEV-серверам).

📍 Как создать команду:

Teams → Add (добавить).
Вводим имя (DevOps, QA, DEV).
Выбираем организацию.
Нажимаем "Save".

✅ 3. Добавляем пользователей и назначаем им роли

Переходим в Users и создаём пользователей.

📍 Как добавить пользователя в команду:

Заходим в Users → Add.
Вводим имя, email, пароль (если используешь локальные аккаунты).
Нажимаем "Save".
Переходим в Teams → Выбираем команду (QA, DEV, DevOps).
Добавляем пользователя в команду.
Присваиваем роль (например, Member или Admin, если нужен полный доступ).

✅ 4. Создаём инвентарь и группы хостов

Теперь делаем разделение серверов.

📍 Как создать инвентарь:

Заходим в Inventories → Add.
Назовём его Company Servers.

📍 Как создать группы хостов внутри инвентаря:

Открываем инвентарь Company Servers.
Переходим во вкладку Groups.
Нажимаем Add и создаём группы:
- qa-servers (для QA)
- dev-servers (для DEV)
- prod-servers (если нужно для Production)
Добавляем хосты в каждую группу.

📍 Как добавить хост в группу:

Заходим в группу (qa-servers).
Нажимаем Add Host.
Вводим IP или имя сервера.

✅ 5. Настраиваем доступ к инвентарю для команд

Теперь дадим командам доступ только к нужным серверам.

📍 Как настроить права:

Переходим в Inventories → Открываем Company Servers.
Вкладка Access → Add.
Добавляем:
- DevOps → Роль Admin (полный доступ).
- QA → Роль Use (Use позволяет выполнять плейбуки, но не менять инвентарь).
- DEV → Роль Use (доступ только к Dev-серверам).

💡 Важно!

DevOps может всё.
QA видит только qa-servers.
DEV видит только dev-servers.

✅ 6. Удаляем ненужные аккаунты и группы

Если есть старые пользователи или команды, которые не нужны:
📍 Как удалить:

Заходим в Users/Teams/Inventories, выбираем объект и нажимаем Delete.

✅ 7. (Дополнительно) Группировка серверов по версиям ОС и сервисам

Если надо дальше группировать сервера по ОС и сервисам:

📍 Как сделать подгруппы:

Открываем Inventories → Company Servers.
Открываем Groups и создаём новые группы:
- ubuntu-servers, centos-servers
- database-servers, web-servers

Внутри qa-servers и dev-servers можно сделать вложенные группы:

qa-servers:
  children:
    ubuntu-servers:
    database-servers:
dev-servers:
  children:
    centos-servers:
    web-servers:

Теперь можно давать разный доступ к разным типам серверов (например, DBA команде доступ только к database-servers).

🚀 Готово! Теперь у нас:

✅ DevOps имеет полный доступ.
✅ QA видит только QA-сервера.
✅ DEV видит только DEV-сервера.
✅ Хосты сгруппированы по окружению, ОС и типу сервиса.

Если надо добавить сложные фильтры или автоматизацию, можем помочь! 😃

Не могу разобраться, как вообще выполнить плейбук в AWX для указанного Inventory.

Да, это частый вопрос! В AWX выполнение плейбука связано с понятием Job Template (Шаблон задания). Просто инвентори сам по себе ничего не запускает — нужно создать "задание", которое связывает плейбук, инвентори, учетку доступа, и т.д.

Вот пошаговая инструкция, как запустить плейбук через AWX для определенного инвентори:

🔧 Что нужно подготовить заранее:

Project — это указание на репозиторий с плейбуками (например, GitHub/Bitbucket/SCM).
Inventory — твой набор хостов.
Credentials — учетные данные для подключения к хостам (например, SSH-ключ).
Job Template — шаблон, который связывает все вышеуказанное.

🧭 Пошагово:

1. Создай Project (Проект с плейбуками)

AWX → Projects → Add

Name: любое.
Organization: выбери или создай.
Source Control Type: Git (или другое).
Source Control URL: ссылка на Git-репозиторий с твоими playbook'ами.
Branch (если надо).
Playbook directory — обычно project_root/playbook.yml.

Нажми Save, потом Sync (синхронизировать репозиторий).

2. Убедись, что есть Inventory

Ты уже создал его, но проверь:

AWX → Inventories → Твой инвентори → Hosts / Groups

Если хосты не вручную, то проверь, синхронизировались ли источники (Sources).

3. Создай Credential (Учетные данные)

AWX → Credentials → Add

Name: любое.
Credential Type: Machine.
Username: root или ansible, или кто там по SSH.
SSH Private Key: вставь приватный ключ (если по ключу).

4. Создай Job Template (Шаблон задания)

AWX → Job Templates → Add

Поле	Что указать
Name	любое название.
Job Type	Обычно `Run`.
Inventory	выбери свой инвентори.
Project	выбери созданный ранее проект.
Playbook	выбери нужный `.yml`-файл из проекта.
Credentials	добавь учетные данные.

Можешь указать теги, лимиты, переменные и т.д.

Нажми Save.

5. Запусти!

Теперь нажми Rocket (🚀) на шаблоне, и он запустит выполнение!

На вкладке Jobs ты увидишь статус запуска и лог. Там можно отследить вывод выполнения — прямо как ansible-playbook в консоли.

💡 Подсказки

Если нет выбора Playbook в шаблоне — значит проект не синхронизировался.
Если нет хостов — проверь, есть ли они в Inventory и есть ли Source Sync.
Ошибки подключения — часто из-за неправильного Credential (SSH/пароль).
Если в playbook'е используется --limit, его можно задать через поле "Limit" в Job Template.

Системное администрирование без паники