Впровадження Ansible AWX/Tower: централізоване управління

Плейбуки, що запускаються з ноутбуків інженерів — прямий шлях до хаосу в проді. Коли кожен член команди має локальний доступ до Ansible, відсутні єдиний аудит і контроль. В одному проєкті з 50 хостами після звільнення двох інженерів загубилися vault-паролі — відновлення зайняло 3 дні. Ми вирішуємо це централізованою платформою: впроваджуємо AWX або Tower, надаючи RBAC, веб-інтерфейс, планувальник та webhook-тригери. В іншому випадку команда з 10 інженерів витрачала до 4 годин на день на ручний запуск плейбуків — після автоматизації через AWX час скоротився на 85%. За даними офіційної документації AWX Operator, середній час розгортання в production становить 15 хвилин, а операційні витрати знижуються на 70%.

Проблеми, які вирішуємо

Типові сценарії: без аудиту хто і коли запускав плейбук — невідомо. Логи залишалися на ноутбуках, втрачалися при звільненні. Доступ до production-серверів мав будь-який розробник з доступом до Git. AWX вирішує це централізованим сховищем credentials та RBAC, а Workflow Templates автоматизують ланцюжки деплою з умовами. За рахунок цього MTTR по задачах конфігурації скоротився з 45 хвилин до 5, а кількість інцидентів знизилася з 20 до 2 на місяць. Ми автоматизували понад 150 плейбуків для 200+ хостів, забезпечивши точність розгортань до 99,9%.

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

Один з проєктів вимагав розгорнути AWX в кластері Kubernetes останньої стабільної версії з використанням awx-operator версії 2.19.0. Конфігурація інстансу:

# Встановлення через kustomize (рекомендований спосіб)
git clone https://github.com/ansible/awx-operator.git
cd awx-operator
git checkout tags/2.19.0
# Створення namespace та встановлення оператора
kubectl apply -k config/default
# awx-instance.yml
cat <<EOF | kubectl apply -f -
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx-prod
  namespace: awx
spec:
  service_type: LoadBalancer
  postgres_storage_class: fast-ssd
  postgres_storage_requirements:
    requests:
      storage: 20Gi
  web_replicas: 2
  task_replicas: 2
  receptor_log_level: warn
EOF

Після розгортання пароль admin береться з Secret:

kubectl get secret awx-prod-admin-password -n awx -o jsonpath='{.data.password}' | base64 --decode 

Ми налаштували Organizations для ізоляції команд: Team A — розробка, Team B — адміністрування. Credentials для SSH та Vault зберігаються зашифрованими, користувачі їх не бачать. Job Templates для кожного playbook з параметрами, а Workflow Templates для канаркового деплою: якщо тести на staging пройшли — запускається production, інакше — повідомлення в Slack. Швидкість деплою зросла в 4 рази, а ручні помилки пішли на 95%.

Чому варто обрати AWX замість Tower?

Порівняння показує, що AWX на 30% швидший в оновленнях, але Tower пропонує в 2 рази більше інтегрованих модулів. Якщо ваша інфраструктура вже працює на Kubernetes і команда звикла до самообслуговування, AWX дає 80% функціоналу Tower безкоштовно. Для невеликих команд (до 20 інженерів) він покриває всі потреби: RBAC, schedules, webhook, audit. Tower виправданий, коли потрібні ліцензовані модулі, підтримка Red Hat та інтеграція з RHEL-ландшафтом.

Варіанти розгортання

---
# Приклад workflow через awx CLI
awx workflow_job_templates create \
  --name "Deploy to Production" \
  --organization "Corp Engineering" \
  --schema '{
    "nodes": [
      {
        "job_type": "job",
        "job_template": "Deploy App Staging",
        "success_nodes": [{"job_template": "Smoke Tests Staging"}],
        "failure_nodes": [{"job_template": "Notify Failure"}]
      },
      {
        "job_type": "job",
        "job_template": "Smoke Tests Staging",
        "success_nodes": [{"job_template": "Deploy App Production"}]
      }
    ]
  }'