Внедрение 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"}]
      }
    ]
  }'