Действия после миграции

Действия после миграции#

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

Ввод секретных значений полномочий#

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

  • через графическую консоль: Автоматизация процессов ‣ Инфраструктура ‣ Полномочия (Automation Execution ‣ Infrastructure ‣ Credentials), кнопка Редактировать (Edit) у каждого полномочия;

  • через API:

    curl -k -H "Authorization: Bearer <gateway-token>" \
   -X PATCH 'https://<aa-gateway>/api/controller/v2/credentials/<id>/' \
   -H 'Content-Type: application/json' \
   -d '{"inputs": {"username": "ansible", "ssh_key_data": "<key>"}}'

    Здесь:

    • <aa-gateway> – адрес шлюза Astra Automation;

    • <gateway-token> – токен доступа шлюза, созданный на этапе подготовки;

    • <id> – идентификатор полномочия;

    • <key> – секретное значение, например закрытый ключ SSH.

    Примечание

    Поле inputs перезаписывается целиком: передавайте в запросе все поля полномочия, включая несекретные. Запрос обновляет одно полномочие – выполните его для каждого полномочия из списка.

После ввода секретов повторите синхронизацию проектов, использующих полномочия доступа к репозиториям.

Смена паролей пользователей#

Каждая перенесенная учетная запись имеет пароль INITIAL, если пароли не были заменены на этапе правки. Смените пароли через API шлюза:

curl -k -H "Authorization: Bearer <gateway-token>" \
   -X PATCH 'https://<aa-gateway>/api/gateway/v1/users/<id>/' \
   -H 'Content-Type: application/json' \
   -d '{"password": "<new-password>"}'

Здесь:

  • <id> – идентификатор пользователя в шлюзе;

  • <new-password> – новый пароль.

Долгосрочное решение – настроить внешнюю аутентификацию через шлюз платформы (см. управление доступом).

Членство в организациях и командах#

Роли уровня организации (member, admin, auditor) и состав команд не переносятся. Назначьте их через API шлюза.

  1. Получите список определений ролей платформы:

    curl -k -H "Authorization: Bearer <gateway-token>" \
   'https://<aa-gateway>/api/gateway/v1/role_definitions/'

    Доступные определения: «Platform Auditor», «Organization Member», «Organization Admin», «Team Member», «Team Admin».

  2. Назначьте роль пользователю:

    curl -k -H "Authorization: Bearer <gateway-token>" \
   -X POST 'https://<aa-gateway>/api/gateway/v1/role_user_assignments/' \
   -H 'Content-Type: application/json' \
   -d '{"role_definition": <definition-id>, "user": <user-id>, "object_id": <org-or-team-id>}'

    Здесь:

    • <definition-id> – идентификатор определения роли;

    • <user-id> – идентификатор пользователя в шлюзе;

    • <org-or-team-id> – идентификатор организации или команды, к которой относится роль.

Назначения также доступны в графической консоли (см. назначение индивидуальных ролей).

Узлы согласования потоков заданий#

Создайте заново узлы согласования, удаленные на этапе правки:

  1. Перейдите в визуализатор потока заданий: выберите на панели навигации Автоматизация процессов ‣ Шаблоны (Automation Execution ‣ Templates), затем выберите поток заданий.

  2. Добавьте узел типа «Согласование» (Approval) на прежнее место топологии и восстановите связи с соседними узлами.

  3. Укажите название, описание и время ожидания согласования.

Группы исполняющих узлов#

Создайте группы исполняющих узлов по списку, подготовленному на этапе планирования, и назначьте их организациям, инвентарным спискам и шаблонам заданий. Управление группами описано в разделе Группы исполняющих узлов.

Завершение миграции#

  1. Настройте внешнюю аутентификацию (SSO, LDAP) через шлюз платформы, если она использовалась в AWX (см. управление доступом).

  2. Проверьте адреса веб-перехватчиков во внешних системах (репозитории, мессенджеры): они должны указывать на шлюз Astra Automation вместо AWX.

  3. Выполните финальные пробные запуски с введенными секретами.

  4. Переключите точку входа пользователей (DNS или балансировщик нагрузки) на шлюз Astra Automation.

  5. Удалите токен доступа шлюза, созданный для миграции (см. удаление токена).

  6. Удалите файлы экспорта с управляющего узла:

    rm -rf /var/tmp/awx-export /var/tmp/awx-export.orig

    Файлы экспорта содержат структуру инфраструктуры автоматизации и введенные вручную значения – не храните их дольше необходимого.

  7. Оставьте AWX в резерве на период наблюдения (1–2 недели), затем выведите из эксплуатации.