Миграция на версию 2.0#
Подготовка и миграция Astra Automation на версию 2.0 состоит из нескольких стадий:
Предупреждение
Перед началом работ ознакомьтесь со списком известных проблем миграции Astra Automation на версию 2.0.
Для перехода сразу на некоторую стадию выберите соответствующий блок диаграммы.
Миграция платформы на виртуальных машинах в облачном пространстве или в собственном центре обработки данных является традиционным способом. Если вам больше подходит использование физических серверов вместо ВМ, то приведенные далее инструкции не меняются по сути.
Цель миграции#
Цель миграции – безопасно обновить Astra Automation до версии 2.0, сохранив данные, проекты, коллекции, среды выполнения, расписания и историю заданий.
Обновление выполняется путем создания экземпляра платформы на новых узлах с обновлением ее внутренних ресурсов из резервной копии. Такой подход исключает риски простоя и обеспечивает полный контроль за изменениями в новой архитектуре и модели доступа. Рабочее окружение может быть на серверах в вашем центре обработки данных или в окружении облачного провайдера.
В процессе обновления используется утилита aa-setup.
Что переносится автоматически#
При обновлении Astra Automation до версии 2.0 выполняется автоматическая миграция следующих элементов:
База данных Automation Controller и Private Automation Hub.
Проекты, инвентари и шаблоны заданий.
Коллекции в Private Automation Hub и EE.
Пользователи, команды пользователей и организации:
При наличии дублированных учетных записей приоритет отдается записям из Automation Controller.
Роли сохраняются на уровне компонентов до завершения связывания с ними учетных записей.
После завершения связывания учетных записей все роли автоматически переносятся в шлюз.
История выполнения заданий.
Что не переносится автоматически#
Следующие элементы не переносятся автоматически и требуют дополнительной ручной настройки:
привязка ролей к пользователям (новая модель RBAC на уровне шлюза);
настройка SSO и LDAP – требуется полное изменение через настройку шлюза;
своды правил, их активации и источники событий Event-Driven Automation;
база данных Event-Driven Automation;
OAuth-приложения Automation Controller;
конфигурации групп узлов контроллера;
пользовательские настройки с прямыми URL внутренних узлов.
Изменения в управлении пользователями#
В версии 2.0 реализована новая архитектура управления пользователями:
В версии 1.2 пользователи управлялись напрямую через API контроллера –
/api/v2/users/.В версии 2.0 все пользователи управляются через шлюз –
/api/gateway/v1/users/.
Основные принципы новой модели:
RBAC реализован централизованно на уровне шлюза.
Аутентификация и авторизация отделены от исполнения заданий.
Роли из 1.2 не совпадают напрямую с реализацией 2.0.
Automation Controller, Private Automation Hub и Event-Driven Automation используют единое пространство для аутентификации пользователей.
Что перестанет и что продолжит работать#
Для поддержания обратной совместимости в версии 2.0 допускается прямой доступ к компонентам платформы (например, к узлам контроллера). Однако это не обеспечивает полной обратной совместимости.
Сценарий |
Статус |
Примечание |
|---|---|---|
Сценарии, использующие точки доступа API |
Не поддерживаются |
|
Интеграции с HR-системами, создающие пользователей через API контроллера |
Не поддерживаются |
|
Рабочие процессы CI/CD, управляющие пользователями через контроллер |
Не поддерживаются |
Миграция на шлюз |
Запуск шаблонов заданий через API контроллера |
Работает |
Точка доступа API |
Работа с проектами, инвентарями и полномочиями |
Работает |
API контроллера временно сохраняет совместимость |
Получение истории выполнения заданий через API |
Работает |
API контроллера временно сохраняет совместимость |
Работа с коллекциям Private Automation Hub через его API |
Работает |
API Private Automation Hub временно сохраняет совместимость |
SSO и LDAP |
Требуется повторная настройка |
Настройки провайдеров аутентификации не переносятся на шлюз автоматически |
API, требующие миграции на шлюз#
В Astra Automation 2.0 изменены точки доступа API для управления пользователями и ролями. Все вызовы, ранее выполнявшиеся к API контроллера, должны быть переведены на API шлюза.
Старый путь (1.2) |
Новый путь (2.0) |
|---|---|
|
|
|
|
|
|
|
|
|
|