Развёртывание AWX (Ansible Tower) на VPS для централизованной автоматизации

Что мы настраиваем и зачем

В современном мире IT-инфраструктуры, где количество серверов, сервисов и конфигураций постоянно растет, ручное управление становится неэффективным и чреватым ошибками. Ansible — это мощный инструмент автоматизации, позволяющий описывать инфраструктуру как код и управлять ею декларативно. Однако работа с Ansible из командной строки может быть сложной для больших команд или требовать дополнительных инструментов для планирования, аудита и централизованного управления учетными данными.

Именно здесь на сцену выходит AWX. AWX — это открытая версия Red Hat Ansible Tower, предоставляющая веб-интерфейс для Ansible. Он превращает Ansible из инструмента командной строки в полноценную платформу автоматизации, доступную через браузер. С помощью AWX вы сможете централизованно управлять следующими аспектами:

• Инвентарь: Динамическое и статическое управление списком серверов и устройств.
• Учетные данные: Безопасное хранение SSH-ключей, паролей, токенов API и других секретов.
• Проекты: Синхронизация ваших Ansible-плейбуков из Git-репозиториев (GitHub, GitLab, Bitbucket и т.д.).
• Шаблоны задач (Job Templates): Создание готовых к запуску задач с предопределенными параметрами, которые могут запускать даже нетехнические пользователи.
• Планирование: Настройка регулярных запусков автоматизации по расписанию.
• Мониторинг и аудит: Просмотр результатов всех запусков, логов, истории изменений и кто что запускал.
• Контроль доступа: Делегирование прав и ролей членам команды.

Что получит читатель в итоге? Вы получите полностью функционирующую платформу AWX на вашем VPS, готовую к автоматизации вашей инфраструктуры. Это позволит вам и вашей команде эффективно управлять серверами, развертывать приложения, обновлять ПО и выполнять другие рутинные задачи с помощью Ansible, используя удобный веб-интерфейс.

Альтернативы: Cloud-managed vs. Self-hosted

Существуют два основных подхода к использованию платформ автоматизации: облачные управляемые сервисы и самостоятельное развертывание (self-hosted). Red Hat предлагает коммерческий Ansible Automation Platform (ранее Ansible Tower) как управляемое решение, а также облачные сервисы, которые предоставляют схожие возможности без необходимости управлять инфраструктурой под ними. Однако у self-hosted подхода на VPS есть свои преимущества:

• Полный контроль: Вы полностью контролируете данные, безопасность и конфигурацию системы.
• Экономия: Зачастую self-hosted решение на VPS обходится дешевле, особенно для небольших и средних команд, по сравнению с ежемесячной подпиской на облачные аналоги.
• Гибкость: Возможность тонкой настройки под специфические требования вашей инфраструктуры или политики безопасности.
• Обучение и развитие: Отличная возможность углубить свои знания в области развертывания и управления контейнеризированными приложениями.

Развертывание на VPS идеально подходит для тех, кто ищет баланс между контролем, стоимостью и удобством. Это позволяет получить мощный инструмент автоматизации без необходимости инвестировать в дорогую аппаратную инфраструктуру или полностью доверять свои данные сторонним облачным провайдерам.

Какой VPS-конфиг нужен под эту задачу

AWX, как и любое сложное веб-приложение, имеет определенные требования к ресурсам. Поскольку AWX работает внутри контейнеров Docker и включает в себя несколько компонентов (PostgreSQL, Redis, RabbitMQ, веб-интерфейс, исполнители), ему требуется достаточно ресурсов для стабильной работы. Представленные ниже требования актуальны для 2026 года и рассчитаны на типичное использование AWX для управления 10-50 узлами с несколькими одновременными задачами.

Минимальные требования:

• CPU: 2 ядра. AWX активно использует CPU во время синхронизации проектов, запуска задач и обработки веб-запросов.
• RAM: 4 ГБ. Это критический ресурс. AWX, PostgreSQL и другие контейнеры могут потреблять значительный объем памяти. Меньше 4 ГБ приведет к постоянному своппингу и низкой производительности.
• Диск: 40 ГБ SSD. Для операционной системы, Docker-образов, базы данных PostgreSQL и логов. SSD настоятельно рекомендуется для производительности базы данных.
• Сеть: 100 Мбит/с. Для доступа к веб-интерфейсу, синхронизации Git-репозиториев и выполнения задач на удаленных узлах.
• Операционная система: Ubuntu 24.04 LTS (или более новая LTS-версия), CentOS Stream 9 (или RHEL 9).

Рекомендуемый VPS-план под задачу:

Для комфортной работы и возможности масштабирования в будущем рекомендуется следующий конфигурация:

• CPU: 4 ядра.
• RAM: 8 ГБ.
• Диск: 80-100 ГБ SSD (NVMe предпочтительнее).
• Сеть: 1 Гбит/с.

С такими характеристиками можно взять VPS с указанными характеристиками, чтобы обеспечить стабильную работу AWX и иметь запас ресурсов для роста. Если вы планируете управлять сотнями или тысячами узлов, запускать десятки одновременных задач или хранить огромные объемы логов, то следует рассмотреть более мощные конфигурации.

Когда нужен dedicated, а не VPS

Dedicated-сервер становится необходимым, когда ваш проект выходит за рамки возможностей VPS, даже самых мощных. Это обычно происходит в следующих случаях:

• Масштаб: Управление тысячами узлов, сотнями одновременно выполняемых задач, или когда AWX является критически важной частью CI/CD-пайплайна крупной компании.
• Производительность: Требования к максимальной производительности дисковой подсистемы (IOPS), CPU или RAM, которые не может обеспечить виртуализация.
• Изоляция: Полная изоляция от "соседей" по гипервизору, гарантирующая стабильность производительности и отсутствие внешних факторов влияния.
• Собственные политики безопасности: Необходимость установки специфического аппаратного обеспечения или очень строгих требований к безопасности, которые легче реализовать на полностью контролируемом оборудовании.

Для большинства сценариев, описанных в этом руководстве (до 100-200 узлов), мощного VPS будет вполне достаточно. Если же вы масштабируетесь до корпоративного уровня, рассмотрите аренду подходящего dedicated-сервера.

Локация: на что влияет

Выбор локации VPS-сервера влияет на несколько ключевых аспектов:

• Задержка (Latency): Чем ближе сервер к вашим основным пользователям (команде, которая будет работать с AWX) и к управляемым узлам, тем меньше будет задержка. Низкая задержка важна для быстрого отклика веб-интерфейса AWX и для оперативного выполнения команд Ansible.
• Соответствие законодательству: В некоторых случаях требуется хранить данные в определенной юрисдикции из-за регуляторных требований (например, GDPR в Европе).
• Скорость синхронизации: Если ваши Git-репозитории или управляемые узлы находятся далеко от AWX-сервера, синхронизация проектов и выполнение задач может занимать больше времени.

Рекомендуется выбирать локацию, максимально близкую к вашей команде и к основной инфраструктуре, которой будет управлять AWX.

Подготовка сервера

Перед установкой AWX необходимо выполнить базовую настройку безопасности и установить необходимые утилиты. Предполагается, что вы используете свежую установку Ubuntu 24.04 LTS и имеете доступ по SSH под учетной записью root или пользователем с sudo-правами.

1. Обновление системы

Всегда начинайте с обновления пакетного менеджера и установленных пакетов, чтобы получить последние версии ПО и исправления безопасности.

sudo apt update && sudo apt upgrade -y
# Обновление списка пакетов и всех установленных пакетов

sudo apt autoremove -y && sudo apt clean
# Удаление ненужных пакетов и очистка кэша

2. Создание нового пользователя с sudo-правами

Работать под root напрямую не рекомендуется. Создайте нового пользователя и предоставьте ему sudo-права.

sudo adduser awxadmin
# Создание нового пользователя с именем awxadmin

Следуйте инструкциям по созданию пароля и заполнению информации о пользователе. Затем добавьте пользователя в группу sudo:

sudo usermod -aG sudo awxadmin
# Добавление пользователя awxadmin в группу sudo

Теперь выйдите из сессии root и войдите под новым пользователем awxadmin.

3. Настройка SSH-ключей (рекомендуется)

Использование SSH-ключей вместо паролей значительно повышает безопасность. Если у вас еще нет SSH-ключа, сгенерируйте его на вашей локальной машине:

ssh-keygen -t rsa -b 4096 -C "[email protected]"
# Генерация нового SSH-ключа (на локальной машине)

Затем скопируйте публичный ключ на ваш сервер. Замените your_user и your_server_ip на свои данные.

ssh-copy-id awxadmin@your_server_ip
# Копирование публичного ключа на сервер

После этого вы можете отключить аутентификацию по паролю для SSH в файле /etc/ssh/sshd_config, изменив PasswordAuthentication yes на no и перезапустив службу SSH. Это значительно повысит безопасность, но убедитесь, что ваш SSH-ключ работает, прежде чем отключать пароли.

sudo nano /etc/ssh/sshd_config
# Откройте файл конфигурации SSH

Найдите строку #PasswordAuthentication yes, раскомментируйте ее и измените на:

PasswordAuthentication no

Также рекомендуется изменить порт SSH с 22 на другой (например, 2222), если вы не используете Fail2ban или другие средства защиты от брутфорса:

Port 2222

Сохраните файл и перезапустите службу SSH:

sudo systemctl restart sshd
# Перезапуск службы SSH

Теперь вы сможете подключаться к серверу только по SSH-ключу и, если меняли, по новому порту: ssh -p 2222 awxadmin@your_server_ip.

4. Настройка файрвола (UFW)

UFW (Uncomplicated Firewall) — это простой в использовании интерфейс для iptables. Настроим его, чтобы разрешить только необходимые порты.

sudo apt install ufw -y
# Установка UFW

sudo ufw allow OpenSSH
# Разрешить SSH (если вы изменили порт SSH, замените на 'sudo ufw allow 2222/tcp')
sudo ufw allow http
# Разрешить HTTP (порт 80)
sudo ufw allow https
# Разрешить HTTPS (порт 443)
sudo ufw enable
# Включить файрвол. Подтвердите 'y'.
sudo ufw status verbose
# Проверить статус файрвола

5. Установка Fail2ban

Fail2ban защищает сервер от атак методом подбора паролей, блокируя IP-адреса, с которых поступает слишком много неудачных попыток входа.

sudo apt install fail2ban -y
# Установка Fail2ban

Создайте файл локальной конфигурации, чтобы ваши изменения не были перезаписаны при обновлении пакета:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# Копирование основного конфига в локальный

Откройте /etc/fail2ban/jail.local и настройте его по своему усмотрению. Убедитесь, что для [sshd] секции enabled = true. Если вы изменили порт SSH, укажите его в port:

sudo nano /etc/fail2ban/jail.local

Пример изменений в jail.local (найдите секцию [DEFAULT] и [sshd]):

[DEFAULT]
bantime = 10m
findtime = 10m
maxretry = 5
banaction = ufw

[sshd]
enabled = true
port = ssh,2222 # Если вы изменили порт SSH, добавьте его сюда
mode = aggressive

Сохраните файл и перезапустите Fail2ban:

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban
# Перезапуск и включение автозапуска Fail2ban
sudo fail2ban-client status sshd
# Проверить статус jail sshd

Теперь ваш сервер готов к установке AWX с базовым уровнем безопасности.

Установка ПО — пошагово

AWX развертывается с использованием Docker и Docker Compose. Мы будем использовать актуальные версии этих инструментов и самого AWX (на 2026 год, предполагаем Docker 25.x+, Docker Compose 2.x+, AWX 24.x+).

1. Установка Docker и Docker Compose

Сначала установим необходимые пакеты для Docker.

sudo apt install ca-certificates curl gnupg lsb-release -y
# Установка необходимых утилит для работы с репозиториями

Добавим официальный GPG-ключ Docker:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
# Добавление GPG-ключа Docker

Добавим репозиторий Docker в APT:

echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# Добавление репозитория Docker

Обновим список пакетов и установим Docker Engine, Docker CLI и containerd:

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io -y
# Установка Docker Engine, CLI и containerd

Добавим текущего пользователя в группу docker, чтобы не использовать sudo для каждой команды Docker:

sudo usermod -aG docker awxadmin
# Добавление пользователя awxadmin в группу docker

Примените изменения группы. Для этого либо выйдите и снова войдите в систему, либо выполните:

newgrp docker
# Применение изменений группы без выхода из системы

Проверим установку Docker:

docker run hello-world
# Запуск тестового контейнера Docker

Теперь установим Docker Compose. Он обычно поставляется как плагин Docker CLI.

sudo apt install docker-compose-plugin -y
# Установка Docker Compose как плагина

Проверим версию Docker Compose:

docker compose version
# Проверка версии Docker Compose

2. Установка Git и Ansible

AWX потребуется Git для синхронизации проектов и Ansible для выполнения задач. Хотя AWX поставляется с Ansible внутри контейнера, иметь его на хосте полезно для отладки и ручного управления.

sudo apt install git ansible -y
# Установка Git и Ansible

3. Загрузка AWX-оператора и инсталлятора

AWX обычно развертывается с помощью оператора Kubernetes или через скрипт инсталлятора, который использует Docker Compose для локальной установки. Мы используем инсталлятор на основе Docker Compose.

mkdir ~/awx_install && cd ~/awx_install
# Создание директории для установки AWX

Загрузим последнюю стабильную версию AWX. На 2026 год, предположим, что актуальная версия AWX — 24.x.x. Вы всегда можете найти последнюю версию на GitHub-странице AWX.

git clone https://github.com/ansible/awx.git
# Клонирование репозитория AWX

cd awx/installer
# Переход в директорию инсталлятора

4. Настройка инсталлятора AWX

Инсталлятор AWX использует файл inventory для конфигурации. Откройте его для редактирования.

nano inventory
# Редактирование файла инвентаря AWX

В файле inventory найдите следующие строки и настройте их:

• admin_password: Установите надежный пароль для администратора AWX.
• secret_key_path: Убедитесь, что этот путь существует или будет создан.
• docker_compose_dir: Путь, где будут храниться файлы Docker Compose.
• pg_password, rabbitmq_password: Можно оставить значения по умолчанию, если это тестовая установка, но для продакшена лучше сгенерировать уникальные пароли.

Пример изменений (найдите и измените):

[all:vars]
admin_password='YourStrongAdminPassword123!' # Установите свой пароль
secret_key_path=/var/lib/awx/awxsecret.key # Путь к файлу с секретным ключом
docker_compose_dir=~/awx_install/awx-compose # Директория для Docker Compose файлов

# ... (остальные параметры можно оставить по умолчанию для первой установки)

Сохраните изменения (Ctrl+O, Enter, Ctrl+X).

5. Запуск инсталлятора AWX

Теперь запустим скрипт инсталлятора. Он использует Ansible для развертывания всех компонентов AWX с помощью Docker Compose.

ansible-playbook -i inventory install.yml
# Запуск плейбука для установки AWX

Этот процесс займет некоторое время, так как Docker будет загружать все необходимые образы и настраивать контейнеры. После завершения вы увидите сообщение об успешной установке.

6. Проверка работы контейнеров

После завершения установки убедитесь, что все контейнеры AWX запущены и работают корректно.

docker compose -f ~/awx_install/awx-compose/docker-compose.yml ps
# Проверка статуса контейнеров AWX

Вы должны увидеть список контейнеров (awx_web, awx_task, awx_postgres, awx_redis) со статусом Up. Если какой-либо контейнер не запущен, проверьте логи командой docker compose logs <container_name>.

AWX по умолчанию будет доступен на порту 80 (HTTP). В следующем разделе мы настроим HTTPS.

Конфигурация

После успешной установки AWX необходимо выполнить первоначальную настройку, обеспечить безопасный доступ через HTTPS и проверить работоспособность системы.

1. Доступ к веб-интерфейсу AWX

AWX по умолчанию доступен по HTTP на порту 80. Откройте ваш веб-браузер и перейдите по IP-адресу вашего VPS или доменному имени (если вы уже настроили DNS): http://your_server_ip_or_domain.

Вы увидите страницу входа в AWX. Используйте следующие учетные данные:

• Username: admin
• Password: Пароль, который вы задали в файле inventory (admin_password).

После входа вы попадете на панель управления AWX.

2. Настройка TLS/HTTPS с помощью Caddy

Использование HTTP для доступа к AWX небезопасно, так как все данные, включая учетные данные, передаются в открытом виде. Мы настроим HTTPS с помощью Caddy — современного веб-сервера с автоматическим управлением сертификатами Let's Encrypt. Caddy прост в настройке и автоматически продлевает сертификаты.

2.1. Установка Caddy

Сначала остановите AWX, чтобы Caddy мог использовать порт 80/443:

cd ~/awx_install/awx/installer
ansible-playbook -i inventory -e "awx_component_state=absent" install.yml
# Остановка и удаление AWX контейнеров, чтобы освободить порты 80/443
# (AWX будет переустановлен с настройкой порта 8052 для внутреннего доступа)

Установите Caddy:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy -y
# Установка Caddy из официального репозитория

2.2. Конфигурация Caddyfile

Создайте файл конфигурации Caddy для AWX. Предположим, ваш домен для AWX — awx.yourdomain.com.

sudo nano /etc/caddy/Caddyfile
# Открытие файла конфигурации Caddy

Удалите все существующее содержимое и вставьте следующее. Замените awx.yourdomain.com на ваш реальный домен.

awx.yourdomain.com {
    reverse_proxy localhost:8052 # AWX по умолчанию слушает на 8052 после установки с Caddy
    # Optional: Enable Caddy's automatic HTTPS
    tls {
        # email [email protected] # Optional: Specify email for Let's Encrypt notifications
    }
    # Optional: Log requests
    log {
        output file /var/log/caddy/awx_access.log
        format json
    }
}

Сохраните файл (Ctrl+O, Enter, Ctrl+X).

2.3. Переконфигурация AWX для работы с Caddy

Теперь нам нужно изменить файл inventory AWX, чтобы он не пытался использовать порты 80/443, а слушал на внутреннем порту, например 8052.

cd ~/awx_install/awx/installer
nano inventory
# Открытие файла инвентаря AWX

Найдите секцию [all:vars] и добавьте или измените следующие строки:

# ...
awx_web_port=8052
awx_nginx_port=8052
# ...

Сохраните файл и снова запустите инсталлятор AWX. Теперь AWX будет настроен для прослушивания на порту 8052, и Caddy будет проксировать запросы к нему.

ansible-playbook -i inventory install.yml
# Повторный запуск инсталлятора AWX с новыми настройками порта

2.4. Запуск Caddy

После успешной переустановки AWX, запустите и включите Caddy:

sudo systemctl enable caddy
sudo systemctl restart caddy
# Включение и запуск службы Caddy
sudo systemctl status caddy
# Проверка статуса Caddy

Убедитесь, что Caddy работает без ошибок. Теперь вы можете получить доступ к AWX по https://awx.yourdomain.com. Caddy автоматически получит и настроит сертификат Let's Encrypt.

3. Проверка работоспособности

После настройки HTTPS, проверьте доступ к AWX и его основные функции.

• Доступ по HTTPS: Откройте https://awx.yourdomain.com в браузере. Убедитесь, что соединение защищено (зеленый замочек в адресной строке).
• Вход в систему: Войдите под учетными данными admin.
• Создание первого проекта:
  • Перейдите в раздел Projects.
  • Нажмите Add.
  • Укажите Name (например, "My First Project").
  • Выберите SCM Type: Git.
  • Укажите SCM URL (например, https://github.com/ansible/ansible-examples.git).
  • Нажмите Save.
  • Затем нажмите на значок синхронизации рядом с проектом, чтобы AWX загрузил плейбуки из репозитория.
• Создание инвентаря:
  • Перейдите в раздел Inventories.
  • Нажмите Add и выберите Inventory.
  • Укажите Name (например, "My Localhost Inventory").
  • Нажмите Save.
  • Внутри инвентаря перейдите на вкладку Hosts, нажмите Add и добавьте хост localhost.
• Создание шаблона задачи (Job Template):
  • Перейдите в раздел Templates.
  • Нажмите Add и выберите Job Template.
  • Укажите Name (например, "Ping Localhost").
  • Выберите Inventory: My Localhost Inventory.
  • Выберите Project: My First Project.
  • Укажите Playbook: ping.yml (этот плейбук есть в ansible-examples).
  • Выберите Credential (если нужно, но для ping localhost не обязательно).
  • Нажмите Save.
  • Запустите шаблон, нажав на значок "ракеты" рядом с ним. Убедитесь, что задача завершилась успешно.

Эти шаги подтвердят базовую работоспособность AWX и готовность к дальнейшему использованию.

Бэкапы и обслуживание

Резервное копирование — это критически важный аспект любой системы, особенно такой, как AWX, которая управляет вашей инфраструктурой. Потеря данных AWX может означать потерю всей истории автоматизации, инвентаря и учетных данных.

1. Что бэкапить

Для AWX необходимо бэкапить следующие компоненты:

• База данных PostgreSQL: Содержит все метаданные AWX: инвентарь, проекты, учетные данные, шаблоны задач, историю запусков, пользователей и их роли. Это самый важный компонент.
• Конфигурационные файлы AWX: В основном это файл inventory, который вы использовали для установки, и, возможно, другие файлы, если вы их модифицировали.
• Секретный ключ AWX (secret_key_path): Этот ключ используется для шифрования конфиденциальных данных в базе данных. Без него восстановление базы данных невозможно. Убедитесь, что он также бэкапится.
• Данные проектов: Если вы храните проекты локально (хотя обычно они синхронизируются из Git), убедитесь, что они также включены в бэкап.

2. Простой скрипт автобэкапа

AWX предоставляет встроенную утилиту для резервного копирования. Мы воспользуемся ею, чтобы создать простой скрипт, запускаемый по расписанию.

Создайте файл awx_backup.sh в директории, например, /usr/local/bin/:

sudo nano /usr/local/bin/awx_backup.sh

Вставьте следующее содержимое, заменив YOUR_AWX_INSTALL_DIR на путь к вашей директории установки AWX (например, ~/awx_install/awx/installer) и /path/to/backup/destination на ваш целевой путь для резервных копий.

#!/bin/bash

# Путь к директории инсталлятора AWX
AWX_INSTALL_DIR="/home/awxadmin/awx_install/awx/installer"

# Директория для хранения резервных копий
BACKUP_DIR="/var/backups/awx"

# Текущая дата для имени файла бэкапа
DATE=$(date +%Y%m%d%H%M%S)

# Имя файла резервной копии
BACKUP_FILE="${BACKUP_DIR}/awx_backup_${DATE}.tar.gz"

# Создаем директорию для бэкапов, если ее нет
mkdir -p "${BACKUP_DIR}"

echo "Starting AWX backup at ${DATE}..."

# Запуск скрипта бэкапа AWX
# AWX installer playbook имеет встроенную цель для бэкапа
cd "${AWX_INSTALL_DIR}" || { echo "Error: AWX install directory not found."; exit 1; }
ansible-playbook -i inventory install.yml -e "mode=backup"

# AWX backup создает tar.gz в директории, где находится docker-compose.yml
# Перемещаем его в нашу директорию для бэкапов
# Имя файла будет awx-backup-YYYY-MM-DD-HHMMSS.tar.gz
LATEST_BACKUP=$(ls -t ~/awx_install/awx-compose/awx-backup-.tar.gz | head -1)

if [ -f "$LATEST_BACKUP" ]; then
    mv "$LATEST_BACKUP" "${BACKUP_FILE}"
    echo "AWX backup created successfully: ${BACKUP_FILE}"
    # Очистка старых бэкапов (оставить последние 7 дней)
    find "${BACKUP_DIR}" -type f -name "awx_backup_.tar.gz" -mtime +7 -delete
    echo "Old backups cleaned up."
else
    echo "Error: AWX backup file not found after running playbook."
    exit 1
fi

echo "AWX backup finished."

Сделайте скрипт исполняемым:

sudo chmod +x /usr/local/bin/awx_backup.sh

Настройте запуск скрипта с помощью Cron. Например, для ежедневного бэкапа в 03:00 ночи:

sudo crontab -e
# Открыть crontab для root-пользователя

Добавьте следующую строку в конец файла:

0 3   * /usr/local/bin/awx_backup.sh >> /var/log/awx_backup.log 2>&1
# Ежедневный запуск бэкапа в 03:00 ночи

3. Куда складывать бэкапы

Хранить бэкапы на том же сервере, что и AWX, крайне не рекомендуется. В случае выхода из строя сервера вы потеряете и систему, и ее бэкапы. Рекомендуемые варианты:

• Внешнее S3-совместимое хранилище: Такие сервисы, как AWS S3, Backblaze B2, DigitalOcean Spaces или MinIO на другом сервере, являются отличным выбором для долговременного и надежного хранения. Используйте утилиты типа s3cmd, rclone или aws cli для отправки файлов.
• Отдельный VPS: Вы можете настроить другой, менее мощный VPS исключительно для хранения бэкапов. Используйте rsync или scp для передачи файлов.
• NFS/SMB-шара: Если у вас есть централизованное сетевое хранилище.

Расширьте скрипт awx_backup.sh, чтобы он отправлял созданный .tar.gz файл в удаленное хранилище после его создания.

4. Обновления: Rolling vs. Maintenance Window

Обновление AWX и его зависимостей (Docker, ОС) требует внимательного подхода.

• Обновление ОС и Docker: Рекомендуется выполнять в "окно обслуживания" (maintenance window), когда нагрузка на сервер минимальна. Эти обновления могут потребовать перезагрузки сервера или перезапуска Docker-демона, что приведет к временной недоступности AWX.
• Обновление AWX: Обновление самой платформы AWX обычно выполняется путем загрузки новой версии инсталлятора и повторного запуска ansible-playbook -i inventory install.yml. Инсталлятор позаботится об обновлении контейнеров и миграции базы данных. Всегда читайте релизные заметки (release notes) перед обновлением AWX, чтобы быть в курсе возможных изменений и требований.
• Стратегия:
  • Всегда делайте полный бэкап перед любым крупным обновлением.
  • Тестируйте обновления на стейджинг-сервере, если это возможно.
  • Избегайте "rolling updates" для AWX на одном VPS, так как это не кластерное решение. Планируйте небольшое окно недоступности.

Регулярное обслуживание и своевременные обновления важны для безопасности и стабильности вашей платформы автоматизации.

Troubleshooting + FAQ

В этом разделе собраны ответы на часто задаваемые вопросы и решения типичных проблем, которые могут возникнуть при развертывании и эксплуатации AWX.

AWX не запускается или контейнеры находятся в состоянии "Exited"

Что проверить:

1. Логи контейнеров: Самый первый шаг — проверить логи проблемного контейнера. Используйте команду docker compose -f ~/awx_install/awx-compose/docker-compose.yml logs <имя_контейнера> (например, awx_web, awx_task, awx_postgres).
2. Доступность портов: Убедитесь, что необходимые порты (80, 443, 8052) не заняты другими процессами. Используйте sudo lsof -i :80 или sudo netstat -tulnp | grep :80.
3. Свободные ресурсы: Проверьте использование RAM и диска. AWX требует значительных ресурсов. Команды free -h и df -h помогут. Нехватка памяти часто приводит к остановке контейнеров.
4. Файл инвентаря: Убедитесь, что в ~/awx_install/awx/installer/inventory нет опечаток, особенно в паролях.

Как фиксить: Исправьте ошибки, найденные в логах. Если проблема в портах, остановите конфликтующий сервис или измените порт AWX/Caddy. Если не хватает RAM, рассмотрите обновление VPS.

Не удается получить доступ к AWX через веб-интерфейс

Что проверить:

1. Firewall (UFW): Убедитесь, что порты 80 (HTTP) и 443 (HTTPS) разрешены в UFW: sudo ufw status verbose.
2. Caddy/Nginx: Если вы используете реверс-прокси (Caddy или Nginx), проверьте, запущен ли он и правильно ли настроен. sudo systemctl status caddy.
3. DNS-запись: Если вы используете доменное имя, убедитесь, что DNS-запись (A-запись) для вашего домена (например, awx.yourdomain.com) указывает на IP-адрес вашего VPS.
4. Внутренний порт AWX: Проверьте, на каком порту AWX слушает внутри контейнера (по умолчанию 8052 после настройки с Caddy). Caddy должен проксировать на этот порт.

Как фиксить: Откройте порты в UFW, перезапустите Caddy, обновите DNS-запись.

Проекты не синхронизируются из Git-репозитория

Что проверить:

1. URL репозитория: Убедитесь, что URL Git-репозитория указан корректно (например, https://github.com/user/repo.git).
2. Учетные данные SCM: Если репозиторий приватный, убедитесь, что в AWX созданы и прикреплены правильные учетные данные для SCM (Git-логин/пароль или SSH-ключ).
3. Доступность Git-хоста: Убедитесь, что AWX-сервер может подключиться к Git-хосту (например, ping github.com).
4. Логи проекта: В AWX перейдите в Projects, выберите ваш проект и посмотрите логи последней синхронизации. Там будет указана причина ошибки.

Как фиксить: Исправьте URL, обновите учетные данные, проверьте сетевую доступность. Для SSH-ключей убедитесь, что ключ добавлен в AWX и у него нет парольной фразы, если это не предусмотрено.

Задачи Ansible завершаются ошибкой "Host Key Verification Failed"

Что проверить:

1. Известные хосты: AWX, как и обычный Ansible, добавляет ключи хостов в known_hosts. Если IP-адрес удаленного сервера изменился или ключ был скомпрометирован, может возникнуть эта ошибка.
2. Учетные данные SSH: Убедитесь, что учетные данные SSH, используемые в шаблоне задачи, корректны и имеют необходимые права на удаленном хосте.

Как фиксить: В AWX есть опция "Enable Host Key Checking" в шаблоне задачи. Для начала отладки можно временно отключить ее (не рекомендуется для продакшена). Лучше добавить ключ хоста вручную: подключитесь к удаленному хосту с AWX-сервера командой ssh root@remote_host_ip (или другим пользователем), чтобы ключ добавился в ~/.ssh/known_hosts внутри контейнера AWX-task. Или настройте для AWX автоматическое управление ключами хостов.

Какой VPS-конфиг минимально подойдёт?

Для минимальной установки AWX, способной обслуживать небольшое количество узлов (до 10-15) и запускать несколько задач в день, потребуется VPS с 2 ядрами CPU, 4 ГБ оперативной памяти и 40 ГБ SSD-диска. Однако, для более комфортной работы и масштабирования, особенно если вы планируете управлять 20+ узлами или запускать параллельные задачи, настоятельно рекомендуется конфигурация с 4 ядрами CPU, 8 ГБ RAM и 80-100 ГБ SSD (NVMe).

Что выбрать — VPS или dedicated для этой задачи?

Выбор между VPS и dedicated-сервером зависит от масштаба вашей автоматизации и требований к производительности/изоляции. Для большинства индивидуальных разработчиков, небольших команд или соло-фаундеров, управляющих до 100-200 узлами, мощного VPS будет вполне достаточно. Он предлагает отличный баланс стоимости, гибкости и производительности. Dedicated-сервер становится оправданным, если вы управляете сотнями или тысячами узлов, имеете очень высокие требования к производительности дисковой подсистемы, нуждаетесь в полной аппаратной изоляции или имеете строгие корпоративные требования к безопасности, которые не могут быть удовлетворены на виртуализированном оборудовании.

Выводы и следующие шаги

Поздравляем! Вы успешно развернули AWX на своём VPS, создав централизованную платформу для управления автоматизацией на базе Ansible. Теперь у вас есть мощный инструмент, который поможет вашей команде эффективно управлять инфраструктурой, стандартизировать процессы развертывания и сократить количество ручных ошибок.

Куда двигаться дальше?

1. Интеграция с CI/CD: Включите AWX в ваш пайплайн непрерывной интеграции/непрерывной доставки. Запускайте AWX-задачи автоматически после успешной сборки кода или слияния веток.
2. Расширение инвентаря: Настройте динамический инвентарь из облачных провайдеров (AWS, Azure, GCP) или систем мониторинга, чтобы AWX всегда знал о вашей актуальной инфраструктуре.
3. Мониторинг и логирование: Интегрируйте логи AWX с централизованными системами мониторинга (Prometheus, Grafana) и агрегации логов (ELK Stack, Loki) для лучшего обзора состояния вашей автоматизации.
4. Управление секретами: Используйте возможности AWX для безопасного хранения и управления учетными данными, а также рассмотрите интеграцию с внешними хранилищами секретов, такими как HashiCorp Vault, для повышения безопасности.