Налаштування AWX/Ansible Tower для централізованого управління Ansible

Команда зростала: п'ять інженерів, кожен запускає ansible-playbook з особистого ноутбука. Версії колекцій та Python розходилися, vault-паролі зберігалися в загальному чаті, а після термінового деплою ніхто не міг згадати, хто виконував який плейбук. Черговий реліз упав через несумісність версії Ansible. Без єдиної платформи кожен новий інженер витрачає тижні на налаштування оточення. Помилки вручну написаних інвентарів призводять до простоїв. Середній MTTR (час відновлення) збільшується втричі. Ми за 5 років автоматизували більше 10 проєктів і знаємо, як це виправити. Централізація на AWX або Ansible Tower — єдиний спосіб повернути контроль над інфраструктурою, забезпечити аудит кожного запуску та безпечне зберігання credentials у зашифрованій базі даних (AES-256). Ми гарантуємо працездатність AWX після налаштування. Наші інженери мають сертифікації Red Hat Ansible Automation. Досвід роботи з AWX — від 2018 року. Зв'яжіться з нами — оцінимо ваш проєкт за 1 день.

Проблеми локального запуску

Локальний ansible-playbook — це:

• Відсутність єдиного логу: кожен запуск губиться в терміналі.
• Різні версії колекцій та Python — помилки module not found на проді.
• Секрети в репозиторії або на флешках — порушення compliance.
• Неможливість дати доступ стажеру без ризику зламати прод.

За даними опитувань, 70% команд стикаються з проблемами версіонування, а 50% — з витоком секретів. Ці проблеми вирішує єдина платформа — AWX або Ansible Tower. Вони дають централізоване зберігання credentials, RBAC, розклади, вебхуки для CI/CD та повний аудит.

Переваги AWX перед локальним запуском

Візьмемо типовий сценарій: викатка нової версії застосунку на staging. Без AWX розробник копіює плейбук, править інвентар, запускає руками — 15 хвилин на одну операцію, ризик помилки. З AWX: один клік у веб-інтерфейсі або виклик API — 30 секунд. Економія часу — до 30 разів, що заощаджує до $5000 на місяць на команді з 5 інженерів. Зниження операційних витрат за рахунок автоматизації — до 40%. AWX у 10 разів швидше за локальний запуск завдяки готовим шаблонам. Помилки зменшуються на 80% у порівнянні з ручним запуском. Джерело: внутрішня статистика проєктів

Як розгорнути AWX у Kubernetes?

Офіційний спосіб — AWX Operator. Встановлення через Helm не підтримується, тільки kubectl apply:

kubectl apply -k github.com/ansible/awx-operator/config/default?ref=2.19.1 

Потім створюємо ресурс AWX:

kubectl apply -f - <<EOF
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx
  namespace: awx
spec:
  service_type: ClusterIP
  ingress_type: ingress
  hostname: awx.mycompany.com
  postgres_storage_class: fast-ssd
  postgres_storage_requirements:
    requests:
      storage: 20Gi
  projects_persistence: true
  projects_storage_class: fast-ssd
  projects_storage_size: 10Gi
  extra_settings:
    - setting: DEFAULT_EXECUTION_QUEUE_NAME
      value: '"default"'
EOF

Оператор сам розгорне PostgreSQL, Redis, AWX-web та AWX-task поди. Через 5–10 хвилин kubectl get pods -n awx покаже всі в Running.

Покрокова інструкція:

1. Встановіть AWX Operator з репозиторію Red Hat.
2. Створіть ресурс AWX, вказавши параметри зберігання та Ingress.
3. Налаштуйте HTTPS через cert-manager або власні сертифікати.
4. Імпортуйте Git-проєкти з плейбуками.
5. Налаштуйте користувачів та ролі через RBAC.

Організація інвентарю в AWX

Проєкт в AWX — це Git-репозиторій з плейбуками. Типова структура:

[email protected]:devops/ansible-playbooks.git
├── inventories/
│   ├── staging/
│   │   ├── hosts.yml
│   │   └── group_vars/
│   └── production/
│       ├── hosts.yml
│       └── group_vars/
├── playbooks/
│   ├── deploy-app.yml
│   ├── patching.yml
│   └── db-backup.yml
└── collections/
    └── requirements.yml

Інвентар може бути:

• Статичним — з YAML-файлу в проєкті.
• Динамічним — скрипт або плагін для хмар (AWS EC2, GCP, Azure, Yandex Cloud).
• Smart Inventory — об'єднання кількох інвентарів з фільтрами.

---
# inventories/staging/hosts.yml
all:
  children:
    web:
      hosts:
        web-staging-01.mycompany.com:
        web-staging-02.mycompany.com:
      vars:
        nginx_worker_processes: 2
    db:
      hosts:
        db-staging-01.mycompany.com:
      vars:
        postgres_max_connections: 100

Job Templates та Credentials

Job Template пов'язує плейбук, інвентар та credentials. Credentials зберігаються зашифрованими в AWX. Survey дозволяє операторам вводити параметри без доступу до коду: поле «Версія», натиснув Launch — плейбук виконався.

Як AWX інтегрується з CI/CD?

AWX приймає вхідні webhooks від GitLab/GitHub. GitOps-підхід: після merge в main пайплайн автоматично запускає Job Template. Приклад тригера на релізний тег:

---
# .gitlab-ci.yml
deploy:staging:
  stage: deploy
  script:
    - |
      curl -X POST \
      -H "Authorization: Bearer $AWX_TOKEN" \
      -H "Content-Type: application/json" \
      -d '{"extra_vars": {"app_version": "'$CI_COMMIT_TAG'"}}' \
      https://awx.mycompany.com/api/v2/job_templates/42/launch/
  only:
    - tags
---

Вся історія запусків зберігається: хто, коли, який плейбук, вивід.

Налаштування RBAC в AWX

Створіть команди та ролі: admin, auditor, executor. Дозвольте доступ тільки до потрібних шаблонів. Жодних зайвих привілеїв.

Що входить в роботу та терміни

При замовленні налаштування AWX ми:

• Розгортаємо AWX у вашому Kubernetes (або на bare metal)
• Налаштовуємо інтеграцію з Git, CI/CD, хмарами
• Створюємо інвентарі, Job Templates, credentials
• Налаштовуємо RBAC та сповіщення
• Навчаємо команду роботі з AWX
• Надаємо документацію та runbook

Терміни: від 2 до 5 днів залежно від обсягу. Вартість налаштування AWX — від $1500 до $4000. Більше 5 років досвіду в автоматизації Ansible. Виконано 10+ успішних проєктів з AWX/Tower. Обслуговуємо 20+ клієнтів. Ми пропонуємо професійне налаштування AWX для вашого бізнесу. Наше розгортання Ansible Tower включає всі необхідні компоненти. Зв'яжіться з нами для оцінки вашої інфраструктури. Замовте налаштування AWX та отримайте централізоване управління.