Планирование миграции с AWX

Планирование миграции с AWX#

На этом этапе происходит подготовка к переносу конфигурации автоматизации из AWX в Astra Automation.

Миграция выполняется через REST API обеих систем с помощью коллекций Ansible: объекты выгружаются из AWX в файлы YAML, затем загружаются в Astra Automation. Процесс не зависит от способа развертывания исходной и целевой систем: AWX может работать в Kubernetes или в контейнерах на ВМ, а Astra Automation – на ВМ или в кластере Kubernetes.

Инструкция проверена на миграции AWX 24.6.1 в Astra Automation 2.0-upd2. Для других версий AWX с API v2 процесс аналогичен, однако перед миграцией рабочей среды необходимо проверить его на тестовом стенде.

Примечание

Миграция переносит конфигурацию автоматизации: организации, полномочия, проекты, инвентарные списки, шаблоны заданий и потоков заданий. История запусков и секретные значения через API не переносятся (см. состав переносимых ресурсов).

Архитектурные различия#

Astra Automation отличается от AWX архитектурой: единой точкой входа является шлюз платформы (Platform Gateway), который централизованно управляет пользователями, организациями и аутентификацией для всех компонентов. Эти различия определяют порядок миграции:

Подсистема

AWX

Astra Automation

Точка входа пользователя

Напрямую в AWX

Шлюз платформы

Организации, пользователи, команды пользователей

Объекты AWX

Общие ресурсы платформы; создаются только через API шлюза

Аутентификация (SSO, LDAP)

Настройки AWX

Аутентификаторы шлюза платформы

Токены доступа OAuth 2.0

Выдает AWX

Выдает шлюз платформы

RBAC

Один уровень

Два уровня: роли платформы (шлюз) и объектные роли (Automation Controller)

Контент автоматизации

Внешние источники

Private Automation Hub

Событийная автоматизация

Отсутствует

Event-Driven Automation

Ресурсы Automation Controller (полномочия, проекты, инвентарные списки, шаблоны) переносятся через API контроллера. Попытка создать организацию, пользователя или команду через API контроллера завершается ошибкой HTTP 403 с сообщением Creation of this resource is not allowed. Create this resource via the platform ingress – такие ресурсы необходимо создавать через API шлюза.

Состав переносимых ресурсов#

В таблице перечислены типы ресурсов AWX и особенности их переноса в Astra Automation:

Ресурс

Переносится

Примечание

Организации

Да

Через API шлюза

Пользователи

Частично

Пароли не переносятся: каждой перенесенной учетной записи назначается пароль INITIAL, который необходимо немедленно сменить (см. критические моменты)

Команды пользователей

Частично

Переносятся название, описание и организация; членов команд необходимо назначить заново

Типы полномочий (пользовательские)

Да

Включая определения полей и внедряемые переменные (injectors)

Полномочия

Частично

Переносится структура; секретные значения (пароли, ключи SSH, токены) необходимо ввести заново

Проекты

Да

После импорта выполняется синхронизация; репозитории должны быть доступны из Astra Automation

Инвентарные списки, узлы, группы

Да

Включая членство узлов в группах и переменные

Источники динамической инвентаризации

Да

Источник данных должен быть доступен из Astra Automation

Шаблоны заданий

Да

Включая опросы (survey), метки и привязки шаблонов уведомлений

Шаблоны потоков заданий

Частично

Топология узлов и связей (success/failure/always) переносится; узлы согласования (approval) необходимо исключить из импорта и создать заново

Расписания

Да

Кроме системных расписаний очистки AWX – их необходимо исключить из импорта

Шаблоны уведомлений

Частично

Секретные поля конфигурации (например, токены) необходимо указать вручную до импорта

Среды исполнения (записи EE)

Частично

Переносятся записи; образы контейнеров необходимо доставить в реестр, доступный из Astra Automation, и исправить ссылки

Метки

Да

Включая привязки к шаблонам заданий

Объектные роли RBAC (шаблоны, проекты, инвентарные списки, полномочия)

Да

Назначения ролей пользователям и командам на объекты Automation Controller

Роли уровня организации и платформы (member, admin, auditor)

Нет

Назначаются заново через API или графическую консоль шлюза (см. назначение ролей)

Интеграции с внешними хранилищами секретов

Нет

Подключения полномочий к внешним источникам (HashiCorp Vault и подобные) настраиваются заново

Группы исполняющих узлов (instance groups)

Нет

Топология исполнения различается; создаются заново

История запусков

Нет

Не предоставляется API AWX

Токены OAuth 2.0

Нет

В Astra Automation токены доступа выдает шлюз платформы

Настройки AWX (Settings), SSO, LDAP

Нет

Аутентификация настраивается в шлюзе платформы (см. управление доступом)

Требования#

Для выполнения миграции требуется управляющий узел (control node) – машина, с которой запускаются сценарии миграции. Можно использовать установочный узел Astra Automation.

Компонент

Требование

Управляющий узел

ansible-core версии не ниже 2.16; пакет доступен в репозитории Astra Automation (см. справочник aa-setup)

Коллекции Ansible

infra.controller_configuration, awx.awx (см. получение коллекций)

Сетевая связность

Доступ с управляющего узла к AWX API и к Astra Automation Gateway API (HTTPS)

Учетные записи

Административный доступ к AWX и Astra Automation

AWX

Версия с API v2 (инструкция проверена на 24.6.1); API доступен по сети

Astra Automation

Платформа развернута, лицензия активирована – без активной подписки создание узлов при импорте завершается ошибкой HTTP 403

Целевая установка

Рекомендуется чистая установка Astra Automation: одноименные объекты перезаписываются при импорте

Примечание

Дисковое пространство для файлов экспорта обычно не превышает 100 МБ даже для масштабных управляемых сред.

Получение коллекций Ansible#

Для миграции используются три коллекции:

  • infra.controller_configuration – экспорт объектов AWX и импорт объектов Automation Controller (инструкция проверена с версией 3.4.1);

  • awx.awx – зависимость предыдущей коллекции с модулями для работы с API (проверена версия 24.6.1);

  • ansible.gateway_configuration – импорт организаций, пользователей и команд через шлюз платформы.

Коллекция ansible.gateway_configuration поставляется в составе пакета для развертывания Astra Automation и после установки Astra Automation доступна в каталоге collections/ утилиты aa-setup.

Коллекции infra.controller_configuration и awx.awx опубликованы в каталоге Ansible Galaxy. При наличии доступа в интернет с управляющего узла установите их командой:

ansible-galaxy collection install infra.controller_configuration awx.awx

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

ansible-galaxy collection download infra.controller_configuration awx.awx -p ./collections-offline

Команда сохраняет в каталог архивы коллекций и файл requirements.yml. Перенесите каталог на управляющий узел и установите коллекции:

ansible-galaxy collection install -r collections-offline/requirements.yml

Критические моменты#

До начала работ необходимо принять следующие решения и подготовить данные:

  • Объем переносимых данных. Оцените количество объектов каждого типа в AWX – эти числа пригодятся при проверке результатов. Счетчик возвращается в поле count ответа на запрос списка:

    curl -k -u admin:<password> 'https://<awx>/api/v2/job_templates/?page_size=1'

    Здесь:

    • <awx> – адрес контроллера AWX;

    • <password> – пароль администратора AWX.

  • Секретные значения полномочий. AWX API не позволяет получить секретные данные: пароли, ключи SSH и токены полномочий предстоит ввести в Astra Automation заново. Соберите список полномочий и их секретных значений из исходных источников (хранилище секретов, парольный менеджер) до начала миграции – это самый трудоемкий ручной этап.

  • Пароли пользователей. Пароли не переносятся: для каждой перенесенной учетной записи система создает пароль INITIAL, с которым пользователи могут войти в систему. Сразу после импорта необходимо сменить пароли всех перенесенных учетных записей или настроить внешнюю аутентификацию (см. решения по управлению доступом). Согласуйте с пользователями процедуру получения новых паролей.

  • Внешняя аутентификация. Настройки SSO и LDAP из AWX не переносятся. Аутентификацию необходимо настраивать в шлюзе платформы заново.

  • Образы сред исполнения. Записи EE в AWX обычно ссылаются на внешние реестры (например, quay.io). Определите, какие образы используются, доставьте их в реестр, доступный из Astra Automation (например, Private Automation Hub), и подготовьте новые ссылки.

  • Группы исполняющих узлов. Составьте список групп исполняющих узлов AWX и их привязок к шаблонам и инвентарным спискам: в Astra Automation соответствующие группы создаются заново.

  • Резервная копия AWX. Создайте резервную копию AWX (например, pg_dump базы данных) на случай непредвиденных ситуаций. Миграция не изменяет данные AWX (экспорт выполняет только чтение), однако резервная копия обязательна для рабочих сред.

Порядок работ и доступность#

Остановка AWX не требуется: экспорт читает данные через API, исходная система продолжает работать. Единственный период недоступности для пользователей – время, необходимое для переключения точки входа (DNS или балансировщик нагрузки) на шлюз Astra Automation.

Этап

Доступность AWX

Доступность Astra Automation

Подготовка и экспорт

Работает

–

Правка файлов экспорта

Работает

–

Импорт

Работает

Наполняется

Проверка и действия после миграции

Работает

Работает

Переключение пользователей (DNS или балансировщик)

Недоступен

Работает

Период наблюдения

Резерв

Работает

Важно

Не вносите изменения в объекты AWX между экспортом и переключением пользователей: изменения, сделанные после экспорта, в Astra Automation не попадут. Если изменения все же произошли, повторите экспорт и импорт – процесс идемпотентен.

План отката#

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

  1. Верните DNS-запись или настройку балансировщика на AWX.

  2. Зафиксируйте причину отката и устраните ее на стенде Astra Automation.

  3. Повторите импорт: операции идемпотентны, существующие объекты обновляются без дублирования.

Рекомендуется выводить AWX из эксплуатации только после периода наблюдения (1–2 недели штатной работы Astra Automation).

День выполнения миграции описан в разделе Миграция с AWX.