Настройка AWX/Ansible Tower для централизованного управления Ansible

Команда росла: пять инженеров, каждый запускает ansible-playbook с личного ноутбука. Версии коллекций и Python расходились, vault-пароли хранились в общем чате, а после срочного деплоя никто не мог вспомнить, кто выполнял какой плейбук. Очередной релиз упал из-за несовместимости версии Ansible. Без единой платформы каждый новый инженер тратит недели на настройку окружения. Ошибки вручную написанных инвентарей приводят к простоям. Средний MTTR (время восстановления) увеличивается втрое. Мы за 5 лет автоматизировали больше 10 проектов и знаем, как это исправить. Централизация на AWX или Ansible Tower — единственный способ вернуть контроль над инфраструктурой, обеспечить аудит каждого запуска и безопасное хранение credentials в зашифрованной базе данных (AES-256). Свяжитесь с нами — оценим ваш проект за 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 раз. Снижение операционных расходов за счёт автоматизации — до 40%. Источник: внутренняя статистика проектов

Как развернуть 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 и получите централизованное управление.