Projects и Job Templates
Тема дорожной карты · Ansible
Проекты AWX — это механизм, с помощью которого AWX связывается с источником Ansible-playbook, как правило Git-репозиторием, и синхронизирует это содержимое для использования в шаблонах заданий. Когда проект настроен с Git URL, AWX выполняет scm_update для клонирования или получения последней ревизии в локальный каталог проекта, гарантируя, что каждый запуск задания выполняет актуальную версию кода. Проекты AWX поддерживают Git, Subversion и локальные пути с ручным управлением; их можно настроить на автоматическое обновление перед каждым запуском задания или по расписанию. Организация содержимого автоматизации в отдельные проекты AWX по командам или прикладным областям — важная практика для поддержания чёткого разграничения ответственности и применения разрешений RBAC на нужном уровне детализации.
Как это работает
Projects и Job Templates (теперь Red Hat Ansible Automation Platform / AAP) и его upstream AWX дают веб-UI + REST API поверх Ansible: scheduled jobs, RBAC, audit log, workflow-цепочки (job A → если success → job B), управление credentials, источники inventory. Гоняет Ansible-плейбуки в контейнерах (execution environments) со своими collections + зависимостями, отделённо от контроллера.
Когда применять
AWX или AAP — когда (а) больше 2-3 инженеров гоняют плейбуки (нужны RBAC + аудит), (б) хотите scheduled / triggered автоматизацию, (в) важна ChatOps / self-service интеграция. Для RF-инфры AWX self-hosted на control-VM — практичный выбор. AAP требует Red Hat-лицензии. Маленькие команды остаются с ansible-playbook из CI-раннеров.
Типичные ошибки
Ловушки Projects и Job Templates: сложность деплоя AWX (Kubernetes-based, нетривиальная установка); путаница execution environment (плейбук падает не из-за кода, а из-за пинов collection в EE); утечка credentials через job output (маскируйте sensitive). Планируйте capacity — AWX любит много ядер + RAM для параллельных job.