Розгортання AWX (

Що ми налаштовуємо і навіщо

У сучасному світі 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 "Запуск резервного копіювання AWX о ${DATE}..."

# Запуск скрипта резервного копіювання AWX
# AWX installer playbook має вбудовану ціль для резервного копіювання
cd "${AWX_INSTALL_DIR}" || { echo "Помилка: Директорія установки AWX не знайдена."; 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_FILE}"
    # Очищення старих резервних копій (залишити останні 7 днів)
    find "${BACKUP_DIR}" -type f -name "awx_backup_*.tar.gz" -mtime +7 -delete
    echo "Старі резервні копії очищено."
else
    echo "Помилка: Файл резервної копії AWX не знайдено після запуску плейбука."
    exit 1
fi

echo "Резервне копіювання AWX завершено."

Зробіть скрипт виконуваним:

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, оскільки це не кластерне рішення. Плануйте невелике вікно недоступності.

Регулярне обслуговування та своєчасні оновлення важливі для безпеки та стабільності вашої платформи автоматизації.

Вирішення проблем + 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, для підвищення безпеки.