Ansible AWX на K3s: развёртывание и OpenStack

Что такое Ansible AWX?

Ansible AWX — это открытая (open-source) версия Red Hat Ansible Automation Platform, предоставляющая веб-интерфейс для интерактивного управления ресурсами Ansible. С помощью AWX команды могут запускать плейбуки (playbooks), управлять инвентаризациями (inventories), планировать задания и хранить учётные данные — всё через браузер, без необходимости входить в терминал по SSH.

Начиная с версии 18.0 рекомендуется разворачивать AWX с помощью оператора (Operator) поверх платформы Kubernetes.

Этап 1: развёртывание AWX на K3s

Почему K3s?

K3s — это облегчённый дистрибутив Kubernetes от компании Rancher. Он сохраняет полную функциональность Kubernetes, но потребляет значительно меньше ресурсов по сравнению с «ванильным» Kubernetes. K3s хорошо подходит для лабораторных сред с ограниченными характеристиками (минимум 4 ядра / 8 ГБ ОЗУ для однонодовой установки AWX).

Шаги развёртывания

Установить K3s:

curl -sfL https://get.k3s.io | sh -

Установить AWX Operator:

git clone https://github.com/ansible/awx-operator.git
cd awx-operator
git checkout 2.19.1
make deploy

Создать экземпляр AWX:

apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx-instance
  namespace: awx
spec:
  service_type: NodePort

После этого AWX будет доступен через NodePort, а пароль администратора можно получить командой:

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

Этап 2: динамический инвентарь из OpenStack

Проблема: ошибка разрешения DNS-имён

При попытке синхронизировать динамический инвентарь из OpenStack AWX может завершаться с ошибкой, поскольку поды внутри Kubernetes не могут разрешить внутренние доменные имена. Решение — обновить ConfigMap CoreDNS:

kubectl edit configmaps coredns -n kube-system

Добавьте нужные записи хостов в блок NodeHosts. После перезапуска CoreDNS команда nslookup из пода начнёт работать, а синхронизация инвентаря завершится успешно.

Настройка динамического инвентаря OpenStack

Создайте пользовательский тип учётных данных (Credential Type) для OpenStack с полями ввода: username, password, project_name, auth_url и region_name. Конфигурация инжектора (Injector Configuration) сопоставляет эти поля с переменными окружения вида OS_*.

Для поддержки нескольких проектов добавьте в переменные источника инвентаря (inventory Source Variables) следующее:

plugin: openstack.cloud.openstack
cloud: myopenstack
expand_hostvars: true
fail_on_errors: true
all_projects: true

Этап 3: работа с динамическими SSH-пользователями

Одной из главных сложностей было то, что у каждого экземпляра OpenStack мог быть свой системный SSH-пользователь по умолчанию (ubuntu, centos, cloud-user) и отдельный SSH-ключ. Наша команда разработала несколько подходов к решению этой задачи.

Подход 1: Bash-скрипт для обновления ansible_user

Скрипт update_host.sh читает файл ip_user_map.json и отправляет PATCH-запросы к AWX API, обновляя переменные каждого хоста в соответствии с картой.

Подход 2: Автоматическое определение через Ansible Facts

Создаются два шаблона заданий (Job Templates): первый — для этапа setup (сбор и сохранение ansible facts в хранилище фактов), второй — для выполнения основных задач с использованием уже известного пользователя из сохранённых фактов.

- name: Set ansible_user dynamically
  set_fact:
    ansible_user: >-
      {{
        ansible_env.SUDO_USER |
        default(ansible_user_id, true) |
        default('ubuntu')
      }}

Подход 3: Определение по имени образа OpenStack

Метаданные image_name тома OpenStack используются для автоматического определения корректного SSH-пользователя с помощью regex_replace.

Этап 4: узлы выполнения AWX (мультипроектная среда)

Сетевая изоляция между проектами

Каждый проект OpenStack имеет собственную изолированную сеть. Управляющий узел (control plane) AWX не всегда может достучаться до экземпляров во всех проектах. Решение — разворачивать узел выполнения на базе Receptor (Receptor-based Execution Node) в каждом проекте как агент выполнения.

Принцип работы

Управляющий узел AWX → передаёт инструкции через Receptor → узел выполнения внутри целевого проекта запускает плейбук → результаты возвращаются в AWX.

Требования к ОС для узлов выполнения

Необходима Ubuntu 22.04 (Jammy) или RHEL 9, поскольку:

Podman официально доступен начиная с Focal 20.10+
Python >= 3.9 уже входит в базовую поставку
Последние версии Ansible поддерживают синтаксис FQCN

Установка Receptor

Добавить новый экземпляр в интерфейсе AWX и скачать комплект установщика (bundle installer).
Установить Ansible на узел выполнения.
Отредактировать inventory.yml внутри комплекта — указать актуальные значения ansible_host и ansible_user.
Запустить плейбук установщика.
Добавить DNS-запись для имени хоста узла выполнения в CoreDNS.
Выполнить проверку работоспособности (health check) из панели управления AWX.
Создать группу экземпляров (Instance Group) и назначить в неё узел выполнения.

Этап 5: ручные плейбуки и монтирование томов

Чтобы запускать плейбуки, хранящиеся вручную (а не из SCM/Git), AWX необходимо настроить так, чтобы его поды монтировали нужный каталог с хоста.

spec:
  web_extra_volume_mounts: |
    - name: playbook-volume
      mountPath: /var/lib/awx/projects
  task_extra_volume_mounts: |
    - name: playbook-volume
      mountPath: /var/lib/awx/projects
  extra_volumes: |
    - name: playbook-volume
      hostPath:
        path: /data/projects
        type: Directory

После этого все плейбуки можно просто размещать в каталоге /data/projects на виртуальной машине AWX.

Этап 6: пользовательское окружение выполнения (Execution Environment)

Если плейбук требует коллекцию, отсутствующую в стандартном образе EE (например, openstack.cloud), необходимо собрать собственный образ EE с помощью ansible-builder.

pip3 install ansible-builder
ansible-builder build -t ee-openstack:latest

Готовый образ публикуется в реестре (registry) и регистрируется в AWX как новое окружение выполнения (Execution Environment).

Этап 7: установка в изолированной среде (Air-Gap / офлайн)

В производственных средах без доступа к интернету установка выполняется полностью в офлайн-режиме с использованием:

Зеркала реестра (Docker Registry v2) для кэширования образов с docker.io и quay.io.
Офлайн-установки K3s с использованием заранее скачанного файла k3s-airgap-images-amd64.tar.zst.
Конфигурации registries.yaml, чтобы K3s забирал образы из локального зеркала.

В результате получается полностью работоспособная установка AWX, функционирующая без какого-либо подключения к интернету — в качестве источника образов используется локальное зеркало реестра.

Расчёт ёмкости и количества fork-процессов

AWX рассчитывает ёмкость узла выполнения на основе:

CPU: количество_ядер × 4 fork-процесса
ОЗУ: объём_ОЗУ_МБ / 100 fork-процессов

Используется меньшее из двух значений. Для экземпляра с 4 vCPU / 16 ГБ ОЗУ AWX способен обрабатывать до 1100 событий в секунду и одновременно выполнять до 137 fork-процессов — вполне достаточно для управления тысячами хостов.

Выводы

Ключевые уроки, вынесенные в ходе исследования:

DNS — это основа всего. Наиболее частая проблема при развёртывании AWX на Kubernetes неизменно сводится к настройке CoreDNS.
SSH-пользователи должны определяться динамически. В мультиоперационной среде OpenStack подход «одни учётные данные для всех» попросту не работает.
Один узел выполнения на проект — оптимальное решение для сетевой изоляции между проектами OpenStack.
Офлайн-установка требует тщательной подготовки — все зависимости должны быть доступны в локальном реестре до начала установки.
Хранилище фактов AWX (Fact Storage) чрезвычайно полезно для кэширования информации о хостах, чтобы плейбуки не собирали факты заново при каждом запуске.

Заключение

Ansible AWX зарекомендовал себя как мощная платформа для управления инфраструктурной автоматизацией в масштабе. Благодаря подходу на основе оператора поверх Kubernetes AWX обеспечивает высокую гибкость — от однонодовых развёртываний до кластеризации с несколькими узлами выполнения в полностью изолированных корпоративных средах.

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

Нужна помощь с платформой автоматизации?

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

Компания Boer Technology специализируется на проектировании, внедрении и сопровождении систем автоматизации, в том числе на базе AWX. Наша команда имеет опыт управления производственными средами с сотнями узлов, что позволяет централизованно и эффективно управлять вашей инфраструктурой.

Связаться с нами

Готовы перейти к автоматизированному управлению платформой? Обсудим, чем мы можем помочь:

Сайт: www.btech.id
Email: support@btech.id

Ссылки:

Авторы: команда Managed Services — PT. Boer Technology