Руководство пользователя и администратора для AWX (Ansible AWX)
Подробное
описание каждого раздела в интерфейсе AWX (Ansible AWX) — это веб-интерфейс и REST API для управления задачами Ansible. Этот список соответствует основному
меню в AWX.
📊 Views
🏠 Dashboard
Назначение:
Общая панель, отображающая:
- Количество выполненных/запланированных задач,
- Статистику
по шаблонам, пользователям и инвентарям,
- Быстрый
доступ к основным действиям.
⚙️ Jobs
Назначение:
Список всех выполненных, запланированных и активных работ (jobs):
- Запуски шаблонов задач,
- Проверка статусов,
- Повторный запуск задач.
📅 Schedules
Назначение:
Управление расписаниями запуска задач:
- Периодические запуски шаблонов,
- Настройка
временных зон и повторений.
🔁 Activity Stream
Назначение:
Журнал действий:
- Кто и
когда что изменил или запустил,
- Отслеживание
аудита действий в системе.
✅ Workflow Approvals
Назначение:
Раздел для утверждения или отклонения задач в рамках workflow templates (шаблонов рабочих процессов), если
настроено требование на подтверждение.
📁 Resources
📄 Templates
Назначение:
Шаблоны задач:
- Простые Job Templates
(одиночные задачи),
- Workflow Templates
(связанные последовательности задач),
- Запускаются
вручную или по расписанию.
🔐 Credentials
Назначение:
Хранилище учётных данных:
- SSH-ключи,
- Пароли,
- Токены API и другие типы доступа для инвентарей, проектов и
удалённых систем.
🗂️ Projects
Назначение:
Ссылки на хранилища с Ansible playbook'ами:
- Git, Mercurial, Subversion и др.,
- AWX синхронизирует их для запуска задач.
🗺️ Inventories
Назначение:
Инвентари — наборы хостов, на которых выполняются задачи:
- Могут быть
статическими (вручную добавлены),
- Или
динамическими (AWS, GCP, Azure и др.).
🖥️ Hosts
Назначение:
Управление отдельными хостами внутри инвентарей:
- Проверка доступности,
- Применение меток,
- Диагностика ошибок запуска задач.
🧑🤝🧑 Access
🏢 Organizations
Назначение:
Разделение пользователей, инвентарей, проектов и шаблонов на логические группы
(организации). Каждая организация может управляться
отдельно.
👤 Users
Назначение:
Создание и управление пользователями:
- Назначение прав доступа,
- Сброс паролей,
- Привязка к
организациям и командам.
👥 Teams
Назначение:
Группы пользователей, которым можно массово назначать доступ к ресурсам:
- Удобно при
распределении прав по ролям.
🛠️ Administration
🔐 Credential Types
Назначение:
Создание пользовательских типов учётных данных:
- Для
нестандартных сервисов или форматов доступа.
🔔 Notifications
Назначение:
Настройка уведомлений:
- Email, Slack, Webhook и др.,
- Автоматическая
отправка после выполнения задач, ошибок и т.п.
🧹 Management Jobs
Назначение:
Специальные задачи для обслуживания AWX:
- Очистка журналов,
- Синхронизация проектов или инвентарей.
🏭 Instance Groups
Назначение:
Группы экземпляров (узлов выполнения):
- Используются для масштабирования AWX,
- Распределение
задач по разным серверам.
🖥️ Instances
Назначение:
Отдельные серверы (инстансы), участвующие в выполнении задач:
- Мониторинг
их статуса и загрузки.
🧩 Applications
Назначение:
Регистрация внешних приложений OAuth2:
- Позволяет
сторонним системам получать доступ к AWX через API.
⚙️ Execution Environments
Назначение:
Контейнеры с установленными зависимостями для выполнения задач:
- Используются вместо традиционных virtualenv,
- Позволяют
изолировать окружения под разные задачи.
🌐 Topology View
Назначение:
Визуальная карта инстансов и групп:
- Отображает архитектуру кластера AWX.
⚙️ Settings
Назначение:
Глобальные настройки системы:
- Аутентификация (LDAP, SAML),
- Интеграции,
- Настройки email, логирования и т.п.
Чтобы добавить Schedules (расписание запуска задач) в AWX, нужно выполнить несколько шагов. Расписание можно
создать только для Job Template или Workflow Template. Вот
подробная пошаговая инструкция:
📅 Как добавить расписание (Schedule) в AWX:
✅
1. Перейдите в раздел Templates
- В левом
меню нажмите Templates.
- Выберите
нужный Job Template или Workflow Template, для которого хотите создать расписание.
✅
2. Откройте шаблон
- Нажмите на имя шаблона.
- В верхней
панели нажмите вкладку Schedules.
✅
3. Нажмите кнопку Add (➕)
- Откроется форма создания расписания.
✅
4. Заполните форму:
|
Поле |
Описание |
|
Name |
Укажите имя
расписания. Например: Ежедневный запуск в 9:00. |
|
Start date / time |
Установите
дату и время первого запуска. |
|
Time zone |
Выберите
нужную временную зону (по умолчанию UTC). |
|
Repeat frequency |
Выберите частоту запуска: |
- None —
однократный запуск,
- Minute, Hour, Day, Week, Month, Year —
повторение с нужным интервалом. | | Ends | Можно
задать дату окончания действия расписания или оставить бесконечно. |
✅ 5. (Необязательно) Настройка Prompted Variables
Если шаблон
требует ввод переменных (например, выбор инвентаря, учётных данных и т.п.):
- В этом
окне вы сможете указать значения для запуска по расписанию.
✅
6. Сохраните расписание
- Нажмите Save.
✅ Готово!
После
сохранения расписание будет отображаться в списке. AWX автоматически запустит задачу в заданное время.
Ниже подробная
инструкция по созданию нового Job Template в AWX, а также пояснение всех параметров
формы Create New Job Template.
🔧 Что такое Job Template?
Job Template в AWX — это шаблон запуска Ansible playbook'а. Он связывает
вместе:
- инвентарь (набор хостов),
- playbook (код Ansible),
- проект (репозиторий с playbook'ами),
- учетные данные,
- переменные,
и другие параметры, необходимые для запуска задачи.
📝 Как создать Job Template
- Перейдите в меню Templates.
- Нажмите Add → выберите Job Template.
- Заполните
форму. Ниже разбор каждого поля:
📄 Разбор параметров формы Create New Job Template
Name (обязательно)
Название
шаблона, которое будет отображаться в списке. Например:
Установка Nginx, Резервное копирование БД.
Description (опционально)
Краткое
описание назначения шаблона. Например:
Запускает playbook nginx_install.yml на staging-серверах.
Job Type (обязательно)
Тип работы:
- Run –
обычный запуск playbook,
- Check – dry
run (в режиме only check),
- Scan – для безопасности (используется редко).
🟨 Чаще всего
используется Run.
☑️ Prompt on launch
Если
активировать — позволяет вводить или переопределять значение этого поля во
время запуска.
Например:
- выбрать другой инвентарь,
- задать
переменные вручную и т.п.
Inventory (обязательно)
Инвентарь
(список хостов), на которые будет применяться playbook.
Project (обязательно)
Проект
(репозиторий), в котором находится нужный playbook.
Может быть Git, Mercurial,
Subversion и др.
Execution Environment
Контейнер, в
котором будет выполнен playbook.
Можно выбрать окружение с нужными зависимостями (например, Python-модули, ansible-galaxy и т.п.).
Playbook (обязательно)
Файл playbook из указанного проекта.
AWX автоматически покажет список .yml-файлов из проекта.
Credentials
Учётные данные,
необходимые для подключения к целевым хостам:
- SSH-ключи,
- Пароли,
- Токены API и т.п.
Можно добавить
несколько credentials (например, одну для подключения,
другую — для облака).
Labels
Метки для
фильтрации, группировки и организации шаблонов.
Variables
Переменные,
используемые внутри playbook:
yaml
CopyEdit
my_var:
true
environment:
"staging"
Можно задать YAML с переменными.
Forks
Количество
параллельных процессов Ansible для запуска задач.
Обычно по умолчанию 0 (означает значение из настроек Ansible).
Limit
Фильтр для
выполнения задачи только на части хостов из инвентаря:
Например:
web_servers или hostname1,hostname2.
Verbosity
Уровень
подробности вывода Ansible:
- 0 – Normal,
- 1 – Verbose,
- 2–5 –
Детальный отладочный вывод.
Job Slicing
Позволяет
разбить задачу на несколько "срезов" (slices), которые будут выполняться
параллельно.
Удобно для масштабных задач с тысячами хостов.
Например: Job Slicing = 4 разделит инвентарь на 4 части.
Timeout
Максимальное
время выполнения задачи (в минутах).
Если превышено — задача будет остановлена.
Show Changes
Если включено —
Ansible покажет, какие строки были изменены (diff).
Полезно для отладки.
Instance Groups
Выбор группы
инстансов, на которых будет выполняться задача.
Позволяет направлять разные задачи на разные сервера AWX.
Job Tags
Выполнять только
указанные теги внутри playbook.
Skip Tags
Пропустить
указанные теги во время выполнения playbook.
✅
Options (чекбоксы):
|
Название |
Назначение |
|
Privilege Escalation |
Использовать become: true
(sudo). |
|
Provisioning Callbacks |
Позволяет
запускать задачу через внешний триггер (например, из CI/CD). |
|
Enable Webhook |
Подключить GitHub/GitLab webhook для
автоматического запуска при коммитах. |
|
Concurrent Jobs |
Разрешить
запускать несколько инстансов этой задачи одновременно. |
|
Enable Fact Storage |
Сохранять Ansible facts после выполнения задачи. |
|
Prevent Instance Group Fallback |
Запретить AWX использовать другие instance groups при нехватке
ресурсов. |
✅
После заполнения всех полей:
- Нажмите Save,
- Шаблон
появится в списке Templates,
- Его можно
будет запускать вручную или по расписанию (через
Schedules).
Давай разберём
подробно, что такое Workflow Template, как его создать в AWX, и что означает каждый параметр при создании.
🔧 Что такое Workflow Template?
Workflow Template — это шаблон, который позволяет объединять несколько
задач (Job Templates, Project Sync, Inventory Sync и др.) в цепочку,
определяя:
- последовательность выполнения,
- условия
(например, если задача успешна — запускается одна ветка, если провалена — другая),
- автоматизацию
сложных процессов (CI/CD, деплой,
тестирование, откат).
Он работает как
визуальный редактор задач и может включать:
- запуск job templates,
- синхронизацию проектов и инвентарей,
- approvals (согласования),
- ветвления по условиям.
➕
Как создать Workflow Template
- Перейдите в раздел Templates.
- Нажмите Add → Workflow Template.
- Заполните
форму. Ниже — разбор всех параметров.
📝 Разбор
параметров Create New Workflow Template
Name *
Название
шаблона. Например:
CI/CD-пайплайн для staging, Установка и проверка приложений.
Description
Опциональное
описание, поясняющее назначение шаблона.
Organization
Организация, к
которой относится шаблон.
Организации позволяют разграничивать доступ, ресурсы и пользователей.
Inventory
Инвентарь
(список хостов), доступный по умолчанию.
Можно переопределить при запуске, если включен флаг Prompt on launch.
☑️
Prompt on launch (у Inventory)
Если
активирован, пользователь сможет выбрать другой инвентарь при запуске workflow.
Limit
Фильтрация
инвентаря — запуск только на части хостов.
Например: web_servers или srv01.
☑️
Prompt on launch (у Limit)
Позволяет
задать значение Limit вручную при запуске workflow.
Source control branch
Если в шаблонах
используются проекты из Git — можно указать ветку (main, dev и т.п.), которая будет использоваться
по умолчанию.
☑️
Prompt on launch (у Source control branch)
Позволяет
выбрать ветку при запуске вручную.
Labels
Метки для
классификации шаблона. Удобно для фильтрации, поиска, автоматизации.
☑️
Prompt on launch (у Labels)
Если включено —
метки можно будет задать при запуске.
Variables
Переменные,
доступные на уровне workflow, передающиеся в подзадачи.
Формат — YAML:
yaml
CopyEdit
env:
staging
deploy_type:
full
☑️
Prompt on launch (у Variables)
Позволяет
задать или изменить переменные при запуске.
Job Tags / Skip Tags
Позволяют
фильтровать выполнение playbook-ов по тегам:
- Job Tags — запускать только
указанные теги,
- Skip Tags — пропустить выполнение задач с
этими тегами.
Применяется ко
всем Job Templates в workflow, если не переопределено.
☑️
Prompt on launch (у Tags)
Позволяет
указать теги при запуске.
✅
Параметры из секции Options
Enable Webhook
Включает
возможность запускать workflow автоматически по событию из
репозитория:
- Поддержка GitHub и GitLab.
- В шаблоне
появится вкладка Webhooks для
настройки URL и ключа.
Enable Concurrent Jobs
Разрешает
одновременные запуски одного и того же workflow шаблона (если не включено — новые
запуски будут ждать завершения предыдущих).
✅
После заполнения формы:
- Нажмите Save — шаблон будет создан.
- Откроется визуальный
редактор workflow, где
можно добавлять узлы.
🧩 Как добавлять узлы в Workflow
- Нажмите Start (зелёный кружок).
- Выберите тип узла:
- Job Template
— запуск Ansible playbook,
- Project Sync
— синхронизация проекта,
- Inventory Sync
— синхронизация инвентаря,
- Approval
— ручное подтверждение,
- Workflow Template
— вложенный workflow.
- После выбора узла:
- Настройте Success path и Failure path,
- Можно
создавать условия, ответвления и параллельные ветки.
💡 Логика работы Workflow Template
- Старт → запускается первая задача.
- В
зависимости от результата (Success, Failure, Always)
запускается следующая ветка.
- Можно
комбинировать: деплой → тестирование → подтверждение → откат.
- Гибкий
контроль исполнения, автоматизация сложных цепочек.
Разберём, что
такое Credentials в AWX, зачем они нужны, как их создавать и
где они применяются.
🔐 Что такое Credential в AWX?
Credential — это набор учётных данных
(ключей, паролей, токенов и т.д.), необходимых для подключения к:
- хостам (через SSH),
- облачным
платформам (AWS, GCP, Azure),
- Git-репозиториям,
- API других систем,
- а также
для выполнения задач и взаимодействия с внешними сервисами.
📍 Где используются Credentials?
Credentials нужны для:
|
Действие |
Credential |
|
🔧 Запуск playbook'а на серверах |
SSH-ключ или пароль |
|
☁️ Подключение
к AWS, Azure, GCP |
Специальные cloud credentials |
|
🛠️ Синхронизация проекта из Git |
Git Token или SSH key |
|
🔐 Применение к
Ansible Vault |
Vault password |
|
🌍
Использование API внешнего сервиса |
API Token или OAuth2 |
|
⚙️ Подключение к vCenter, Red Hat Satellite, и т.п. |
Специфические логины/пароли |
➕ Как создать Credential: пошагово
1. Перейдите в раздел Credentials
В левом меню AWX → нажмите Credentials.
2.
Нажмите Add → Add Credential
3. Заполните форму. Ниже — полный разбор полей.
📝 Разбор параметров Create New Credential
|
Поле |
Назначение |
Name
*
Произвольное
имя, например:
SSH
для staging, GitHub Token, AWS доступ.
Description
Краткое описание назначения.
Organization
Организация, в
рамках которой доступна credential.
Если пользователи из другой организации — credential будет для них недоступен.
Credential Type *
Тип учетной
записи. Задаёт структуру ввода. Примеры:
- Machine — подключение к Linux-хостам по
SSH,
- Source Control
— доступ к Git (SSH-ключ или токен),
- Vault —
пароль для Ansible Vault,
- Amazon Web Services
— доступ к AWS (ключ + секрет),
- Microsoft Azure
— доступ к Azure API,
- Red Hat Ansible Automation Hub — для galaxy collections,
- OpenShift,
vCenter, и др.
Можно создать пользовательский
тип в разделе Credential Types.
Inputs — поля, специфичные для выбранного
типа:
Пример
для Machine (SSH):
|
Поле |
Что
вводить |
|
Username |
root, ansible, ubuntu и т.д. |
|
Password |
Если используется парольная
аутентификация |
|
Private Key |
SSH-ключ (в формате OpenSSH) |
|
Passphrase |
Если приватный ключ защищён |
|
Privilege Escalation |
Параметры become / sudo |
Пример
для Source Control:
|
Поле |
Что
вводить |
|
Username |
Логин в Git |
|
Password / Token |
Пароль или personal access token |
|
SSH Private Key |
Если используется SSH-доступ |
Пример
для AWS:
|
Поле |
Что
вводить |
|
Access Key |
AWS Access Key ID |
|
Secret Key |
AWS Secret Access Key |
|
Region |
По умолчанию us-east-1 и т.п. |
Options
Дополнительные настройки:
- сделать credential read-only,
- запретить переиспользование,
- зашифровать значения.
4.
Нажмите Save
✅ Где потом использовать Credential?
Созданные credentials можно использовать в:
|
Раздел |
Где
применяется |
|
Job Templates |
Для
подключения к хостам или облакам |
|
Projects |
Для доступа к
Git-репозиториям |
|
Inventory Sources |
Для
динамических инвентарей (AWS, GCP и др.) |
|
Workflow Templates |
При передаче credentials в подзадачи |
|
Schedules |
Если шаблон
запрашивает credential при запуске |
📌 Примеры:
▶️
SSH Credential для запуска playbook:
- Type: Machine
- Username: ansible
- SSH Private Key:
вставляем приватный ключ
▶️ GitHub Token для доступа к приватному
репозиторию:
- Type: Source Control
- Username: <необязательно>
- Password: GitHub
PAT (Personal Access Token)
▶️
AWS Credential:
- Type: Amazon Web Services
- Access Key + Secret Key
Вот подробное
описание всех типов Credential Type в AWX, с пояснением, в каких случаях они используются и
какие параметры заполняются. Я сгруппировал их по категориям, чтобы было
удобно ориентироваться.
🟩 Облачные платформы и
внешние API
Amazon
Web Services
🔸 Для доступа к AWS API (динамические инвентари, cloud-модули
Ansible).
Параметры:
- Access Key *
— AWS Access Key ID
- Secret Key *
— AWS Secret Access Key
- STS Token — временный токен, если
используется STS
Google Compute Engine
🔸 Для подключения к GCP и управления ресурсами.
Параметры:
- Service Account JSON file
— файл с ключом (подтягивает данные)
- Service Account Email Address *
- Project
- RSA Private Key *
Microsoft
Azure Resource Manager
🔸 Для подключения к Azure и управления ресурсами.
Параметры:
- Subscription ID *
- Client ID,
Client Secret,
Tenant ID
- Username,
Password
(альтернативно)
- Azure Cloud Environment
(по умолчанию AzureCloud)
Microsoft
Azure Key Vault
🔸 Для доступа к Azure Key Vault (хранение секретов).
Параметры:
- Vault URL *
- Client ID *,
Client Secret *,
Tenant ID *
- Cloud Environment
(например, AzureCloud)
OpenStack
🔸 Используется для динамического
инвентаря, управления облаком.
Параметры:
- Username *,
Password *
- Host * (Auth
URL)
- Project *,
Domain Name,
Region Name
🟨
Контейнеры и оркестрация
Container Registry
🔸 Для доступа к контейнерным
репозиториям (например, quay.io, DockerHub).
Параметры:
- Authentication URL *
- Username,
Password or Token
- Verify SSL
(опционально)
OpenShift
or Kubernetes API Bearer Token
🔸 Для подключения к кластеру Kubernetes или OpenShift.
Параметры:
- API Endpoint *
- API Bearer Token *
- Certificate Authority
- Verify SSL
🟦
DevOps / Source Control
Source Control
🔸 Используется для доступа к Git-репозиториям.
Параметры:
- Username,
Password
или SCM Private Key
GitHub
Personal Access Token
🔸 Для приватных репозиториев GitHub.
Параметры:
- Token *
GitLab
Personal Access Token
🔸 Для приватных репозиториев GitLab.
Параметры:
- Token *
Ansible
Galaxy / Automation Hub API Token
🔸 Для доступа к коллекциям Ansible.
Параметры:
- Galaxy Server URL *
- Auth Server URL
- API Token
🟧
HashiCorp Vault и секреты
HashiCorp
Vault Secret Lookup
🔸 Получение секретов из Vault.
Параметры:
- Server URL *,
Token, AppRole, Username,
Password,
Kubernetes role
- TLS, Client Certificate,
API Version *
HashiCorp
Vault Signed SSH
🔸 Получение подписанных SSH-сертификатов через Vault.
Параметры
аналогичны предыдущему, но используется для SSH.
Vault
🔸 Обычный Ansible Vault (хранение зашифрованных данных).
Параметры:
- Vault Password *
- Vault Identifier
(если несколько vault'ов)
🟥
Enterprise Password Vaults (секретные менеджеры)
CyberArk
Central Credential Provider Lookup
🔸 Получение секретов из CyberArk CCP.
Параметры:
- CCP URL *,
App ID *,
Web Service ID,
Client Key,
Certificate,
Verify SSL
CyberArk
Conjur Secrets Manager Lookup
🔸 Для интеграции с Conjur (тоже CyberArk).
Параметры:
- Conjur URL *,
Account *,
API Key *,
Username *,
Certificate
Centrify
Vault Credential Provider Lookup
🔸 Получение секретов из Centrify Vault.
Параметры:
- Tenant URL *,
API User *,
API Password *,
OAuth2, Scope
Thycotic
DevOps Secrets Vault
🔸 Доступ к облачному Thycotic Vault.
Параметры:
- Tenant, TLD, Client ID,
Client Secret,
URL Template
Thycotic
Secret Server
🔸 Для подключения к on-prem Secret Server от Thycotic.
Параметры:
- Server URL *,
Username *,
Password,
Domain
🟪
Интеграции с Red Hat
Red Hat Satellite 6
🔸 Для управления инфраструктурой через Satellite.
Параметры:
- URL *, Username *,
Password *
Red
Hat Virtualization
🔸 Доступ к RHV (oVirt).
Параметры:
- Host *, Username *,
Password *,
CA File
Red
Hat Ansible Automation Platform
🔸 Для подключения к внешнему AAP.
Параметры:
- URL *, Username,
Password,
OAuth Token,
Verify SSL
⚙️
Системные/универсальные
Machine
🔸 Используется для SSH-доступа к Linux/Unix-серверам.
Параметры:
- Username,
Password,
SSH Private Key,
Passphrase
- Privilege Escalation (sudo)
Network
🔸 Для сетевого оборудования (Cisco, Juniper и т.п.).
Параметры:
- Username *,
Password,
Private Key,
Authorize,
Authorize Password
GPG Public Key
🔸 Используется для шифрования GPG.
Параметры:
- GPG Public Key *
Insights
🔸 Для подключения к Red Hat Insights.
Параметры:
- Username *,
Password *
VMware vCenter
🔸 Для управления виртуализацией через vCenter.
Параметры:
- Host *, Username *,
Password *
В AWX Project — это сущность, которая указывает, откуда брать ваши Ansible-плейбуки. Проект может ссылаться на внешнюю систему
управления версиями (Git, Subversion и т.д.) или на локальный каталог на
сервере. Ниже подробно опишу все поля при создании проекта, включая все
доступные опции для разных типов источников.
🧱 Создание нового проекта
(Create New Project)
Основные
поля:
|
Поле |
Назначение |
|
Name * |
Название
проекта. Используется для идентификации. |
|
Description |
Описание проекта — свободный
текст. |
|
Organization * |
Организация,
к которой относится проект. Необходима для разграничения доступа и управления
ресурсами. |
|
Execution Environment |
Указывает
окружение выполнения, в котором будут запускаться задания, использующие
плейбуки из проекта. |
|
Content Signature Validation
Credential |
(необязательное)
Учетные данные, используемые для валидации цифровой подписи содержимого
(например, GPG-подписи файлов). |
|
Source Control Type * |
Тип источника
для загрузки плейбуков. Ниже перечислены все возможные варианты. |
📂 Source Control Type — тип источника
🔸 Manual
- Use Case: когда вы
вручную копируете плейбуки на сервер.
- Project Base Path:
/var/lib/awx/projects/
— путь к директории с плейбуками.
- Playbook Directory *:
подпапка в base path, содержащая *.yml файлы.
- Важно: права на
папку и файлы должны принадлежать пользователю awx.
🟠 Warning: если директория пуста или все
содержимое уже назначено другим проектам, вы увидите предупреждение.
🔸 Git
- Use Case: самый
частый вариант. Используется для подключения к git-репозиторию (например,
GitHub, GitLab).
- Source Control URL *:
ссылка на git-репозиторий (https://, ssh://, git@...)
- Source Control Branch/Tag/Commit: по умолчанию main или master. Можно указать конкретную ветку, тег или хеш коммита.
- Source Control Refspec: при необходимости можно указать нестандартные refspec для fetch операций.
- Source Control Credential: учетные данные для доступа к приватным репозиториям.
- Options:
- Clean — удаляет неотслеживаемые файлы перед обновлением.
- Delete — полностью очищает папку перед обновлением.
- Track submodules —
клонирует и сабмодули.
- Update Revision on Launch — при каждом запуске job template будет происходить git pull.
- Allow Branch Override — позволяет переопределить ветку при запуске job
template.
🔸 Subversion (SVN)
- Use Case: если
используется репозиторий SVN.
- Source Control URL *:
ссылка на SVN-репозиторий.
- Revision #: номер ревизии. Если пусто — будет использоваться
последняя.
- Source Control Credential: учетные данные, если SVN приватный.
- Options — такие же, как у Git, за
исключением сабмодулей.
🔸 Red Hat Insights
- Use Case:
получение плейбуков с сервиса Red Hat Insights.
- Insights Credential *:
требуются учетные данные для доступа к Insights.
- Options:
- Clean
- Delete
- Update Revision on Launch
🔸 Remote Archive
- Use Case: загрузка
ZIP-архива с плейбуками.
- Source Control URL *:
прямая ссылка на архив (http, https, ftp).
- Source Control Credential: если доступ к архиву требует аутентификацию.
- Options:
- Clean
- Delete
- Update Revision on Launch
- Allow Branch Override — используется условно (например,
если вы хотите переопределять ссылку или версию архива через переменные).
✅ После создания проекта
После
сохранения:
- AWX синхронизирует проект, подтягивая плейбуки.
- Если
указано Update Revision on Launch, то
проект будет автоматически обновляться при запуске Job Template.
- Проект
становится доступен для выбора в шаблонах заданий (Job Templates и Workflow Templates).
Хочешь — могу
сразу расписать рекомендации по выбору источника и best practices для каждого типа.
4o
You said:
Опиши как
создавать Inventories и отличия типов в каких случаях какой
тип инвентори использовать Name Add inventory Add smart inventory Add constructed inventory 1 - 6 of 6 Name Sync Status Type Organization Actions
ChatGPT said:
В AWX Inventory (инвентори) — это список хостов, с которыми будут
работать ваши Ansible-плейбуки. Инвентори могут быть разных
типов, каждый из которых подходит под конкретные сценарии.
Ниже подробно
разберем, как создавать инвентори, в чем разница между типами, и в
каких случаях что использовать.
🏗️ Типы инвентори и их отличия
|
Тип |
Назначение |
Когда
использовать |
|
Inventory (статический) |
Ручной список
хостов и групп |
Простые
проекты с постоянными серверами |
|
Smart Inventory (умный) |
Хосты
выбираются по фильтру из других инвентори |
Когда нужно
объединить часть хостов из разных инвентори |
|
Constructed Inventory |
Хосты
строятся динамически по правилам Jinja2 |
При работе с
динамическими параметрами или объединением разных источников |
📘 Создание Inventory (Add inventory)
Поля:
|
Поле |
Назначение |
|
Name |
Название инвентори |
|
Description |
Описание (опционально) |
|
Organization |
Организация,
к которой принадлежит инвентори |
|
Variables |
Глобальные
переменные для всех хостов инвентори |
|
Instance Groups |
Ограничение,
какие ноды могут использовать это инвентори |
📌 После создания ты сможешь добавлять:
- Хосты (IP/DNS)
- Группы хостов
- Переменные к каждому хосту/группе
💡 Создание Smart Inventory (Add smart inventory)
Smart Inventory позволяет строить "умные"
выборки хостов из других инвентори по условиям фильтрации.
Пример:
Ты хочешь
выбрать все хосты из группы prod с переменной env: production.
Поля:
|
Поле |
Назначение |
|
Name |
Название умного инвентори |
|
Description |
Описание |
|
Organization |
Организация |
|
Host Filter |
Условие выбора (например, groups__name=prod
или variables__env=production) |
|
Variables |
Переменные на
уровне всей выборки |
📌 Умный инвентори не хранит хосты
напрямую — он просто делает фильтрацию по имеющимся хостам во всех Inventory.
⚙️ Создание Constructed Inventory
Constructed Inventory позволяет строить инвентори
динамически на основе динамических источников и Jinja2-выражений.
Используется, например, при:
- Импорте
данных из AWS, Azure, GCP
- Вычислении переменных на лету
- Генерации
хостнеймов, меток и других данных
Особенности:
- Требует
указания source (например, AWS, GitHub, SCM, GCP)
- Есть настройки: Credential, Region, Filters
- Используются Constructed Variables — Jinja2
выражения
- Можно указать hostnames, group_by, labels
и т.д.
Пример переменной:
jinja2
CopyEdit
env_{{
instance.tags.environment }}
🔄 Состояние Sync (Sync Status)
В колонке Sync Status отображается статус синхронизации для
динамических инвентори:
|
Статус |
Значение |
|
✅ Success |
Инвентори успешно обновлен |
|
⚠️ Failed |
Ошибка при загрузке данных |
|
⏳ Waiting |
Задача синхронизации ожидает
выполнения |
🧭 Когда использовать какой
тип инвентори
|
Сценарий |
Рекомендованный
тип |
|
Небольшой
список серверов, редко меняются |
Обычный (статический) Inventory |
|
Хосты в
облаке (AWS, Azure, GCP) |
Constructed Inventory с облачным
источником |
|
Хочешь
выбирать хосты с определённой меткой |
Smart Inventory |
|
Нужно
объединить хосты из разных Inventory |
Smart или Constructed Inventory |
|
Хочешь
строить группы и переменные на лету |
Constructed Inventory |
Разберём назначение
каждого параметра инвентори и в каких случаях он используется.
🔹 Основная информация
|
Поле |
Назначение |
|
Name* |
Имя источника
инвентори — будет отображаться в интерфейсе. Например:
Inventory from Git |
|
Description |
Дополнительное описание источника
(необязательно) |
|
Execution Environment |
Выбор среды
выполнения, в которой будет происходить обработка (например, контейнер с ansible) |
🔸 Source (тип источника)
Source — указывает, откуда подгружается
инвентори. Варианты:
- Sourced from a Project — из проекта, где есть inventory.yml, hosts и т.д.
- Amazon EC2, Azure, GCP и др. —
для подключения к облачным источникам
- Custom Script — если
хочешь сам написать, откуда тянуть
На скрине выбран тип Sourced from
a Project.
🔹 Source details (детали источника)
|
Поле |
Назначение |
Пример
/ Когда использовать |
|
Credential |
Учётные
данные для доступа к источнику (если требуется). Например, GitHub token или AWS ключи |
Git-проект с авторизацией |
|
Project* |
Проект, из
которого будет браться inventory-файл |
Выбери заранее созданный Project |
|
Inventory file* |
Путь к inventory-файлу внутри проекта. Например:
inventories/prod.yml |
Файл должен
существовать в проекте |
|
Verbosity |
Уровень
логирования при синхронизации. От 0 (Normal) до 5 (Debug) |
Для отладки
или подробной информации |
|
Host Filter |
Фильтр по
хостам (по переменным), работает как --limit. Пример: env=prod |
Чтобы взять
только часть хостов |
|
Enabled Variable |
Имя
переменной, которая определяет, включен ли хост (true/false) |
Например: enabled |
|
Enabled Value |
Значение
переменной, при котором хост считается включённым |
Например: true |
🔸 Update Options (опции обновления)
|
Опция |
Назначение |
|
✅ Overwrite |
Удаляет все
старые хосты, если их больше нет в источнике |
|
✅ Overwrite variables |
Заменяет
переменные хостов новыми из источника |
|
✅ Update on launch |
Автоматически
обновлять инвентори перед каждым запуском Job Template |
❗Если Update on launch не выбран — инвентори обновляется
только вручную или по расписанию.
🔹 Cache timeout (seconds)
|
Поле |
Назначение |
|
Cache timeout (seconds) |
Время, в
течение которого используется закэшированная копия инвентори |
💡 Пример настройки:
- Source: Sourced
from a Project
- Project: prod-env
- Inventory file: inventories/prod.yaml
- Credential: если приватный репозиторий GitHub
- Host Filter: region==eu-central-1
- Enabled Variable: enabled
- Enabled Value: true
- Overwrite: ✅
- Update on launch: ✅
Раздел Settings в AWX позволяет гибко настраивать поведение
платформы. Ниже — подробное описание всех категорий и их параметров:
🔐 Authentication
Настройки
аутентификации для различных провайдеров и систем безопасности.
Enable simplified login
Позволяет
упростить вход пользователей, скрыв выбор источника логина (например, LDAP, GitHub и др.), если активен только один.
Azure
AD settings
Интеграция с Azure Active Directory.
Параметры:
- CLIENT ID —
идентификатор приложения в Azure
- SECRET
— секрет клиента
- TENANT ID
— идентификатор арендатора (Azure tenant)
- AUTHORIZATION URL / TOKEN URL / USER INFO URL — URL для
получения токенов и информации о пользователе
- Используется
для входа пользователей через Microsoft SSO
GitHub
settings
Интеграция входа через GitHub OAuth.
Параметры:
- Client ID
и Client Secret — данные от OAuth-приложения GitHub
- Organization Map —
соответствие между организациями GitHub и AWX
- Используется
для входа пользователей через GitHub и
привязки их к организациям и ролям
Google
OAuth 2 settings
OAuth2 авторизация через Google.
Параметры аналогичны GitHub:
- Client ID,
Secret, Allowed domains
- Для SSO пользователей Google Workspace или Gmail
LDAP
settings
Интеграция с корпоративным Active
Directory/LDAP сервером.
Параметры:
- Server URI,
Bind DN, Password, User search, Group search, User
DN template, Mapping полей пользователей и групп
- Используется для корпоративной аутентификации
RADIUS settings
Поддержка RADIUS-серверов.
Параметры:
- RADIUS Server,
Secret, Port, NAS Identifier
- Используется
в системах, где требуется централизованная проверка пользователей
(например, через FreeRADIUS)
SAML
settings
Настройка SSO через SAML (например,
с ADFS, Keycloak, Okta).
Параметры:
- Entity ID,
SSO URL, X509 сертификат, Attribute mapping
- Позволяет
авторизовываться через внешние федеративные системы
TACACS+ settings
Аутентификация
через TACACS+ (используется в сетевых средах Cisco и пр.).
Параметры:
- Server,
Port, Secret, Timeout, Authentication Type
Generic
OIDC settings
Общая настройка OpenID Connect
провайдеров.
Параметры:
- Client ID,
Secret, Issuer URL, Scopes, Claims Mapping
⚙️ Jobs
Управление
поведением и ограничениями запусков job-шаблонов.
Jobs
settings
- Ansible Environment Variables — список переменных окружения, применяемых к
задачам
- Job execution isolation — включение Podman или chroot для изоляции
- Job slicing
— настройки дробления задач
- Default execution environment — окружение по умолчанию
- Default job timeout
— тайм-аут выполнения
- Maximum forks
— ограничение количества процессов
- Callback Key — ключи
для обратных вызовов (для API или
внешних вызовов)
🖥 System
Глобальные
системные настройки.
Miscellaneous
System settings
- Base URL — адрес
для доступа к UI/API
- Task system timeout — ограничение времени выполнения фоновых задач
- Session timeout — время
бездействия до выхода пользователя
- Allowed hosts
— список разрешённых хостов
Miscellaneous
Authentication settings
- Disable local login — отключение логина локального администратора
- Login redirect override — переадресация после логина
Logging
settings
- Logging aggregator host/port — интеграция с системами логирования (ELK, Splunk,
rsyslog)
- Log level
— уровень логов: DEBUG, INFO, WARNING
- Log aggregator type
— тип передачи логов: TCP, UDP, HTTP
- Log formatter — формат
логов: JSON, стандартный и пр.
🎨 User Interface
Настройки
внешнего вида и поведения интерфейса.
User
Interface settings
- Custom logo / favicon
— настройка логотипа
- Theme settings
— выбор темы
- Enable analytics —
включение отправки телеметрии Red Hat
- Login banner — текст,
отображаемый на экране входа
🧪 Troubleshooting
Параметры
отладки и анализа работы системы.
Troubleshooting
settings
- Enable debug logging — активация отладочных логов
- Enable activity stream — логирование действий пользователей
- System tracking —
отслеживание изменений инвентаря, шаблонов и пользователей
- Task timeout debugging — логирование зависших задач
Комментарии
Отправить комментарий