Миграция в контейнерную модель#
Миграция переносит платформу, развернутую на ВМ, в контейнерную модель развертывания без изменения версии платформы.
Важно
Инструкция описывает миграцию платформы, развернутой в базовой топологии модели развертывания из deb-пакетов, в которой компоненты находятся на нескольких узлах. Целевую платформу необходимо развернуть в базовой топологии контейнерной модели, в которой все компоненты, включая СУБД, находятся на одном узле. Этот узел одновременно служит установочным.
Исходная и целевая платформы должны иметь одну и ту же версию Astra Automation. Если исходная платформа использует более раннюю версию, сначала обновите ее до версии целевой платформы. Обновление версии и смену модели развертывания в одной процедуре не совмещайте.
Миграция переносит базы данных компонентов и постоянные секреты, которыми компоненты шифруют данные в этих базах. Остальное целевая платформа получает при штатном развертывании в контейнерах. Поэтому прежде чем начать миграцию, ознакомьтесь с подготовкой и развертыванием платформы в контейнерах.
Инструкция рассчитана на следующие условия:
исходная платформа развернута из пакетов deb и использует СУБД, развернутую средствами платформы;
базы данных целевой платформы называются так же, как базы исходной платформы, и принадлежат пользователям с теми же названиями.
Последнее условие выполняется, если описание инвентаря целевой платформы не переопределяет значения по умолчанию, перечисленные в таблице.
Компонент |
База данных |
Владелец базы |
|---|---|---|
Platform Gateway |
|
|
Automation Controller |
|
|
Private Automation Hub |
|
|
Контроллер Event-Driven Automation |
|
|
Если исходная платформа использует внешнюю СУБД или названия баз отличаются, скорректируйте команды экспорта и восстановления под свои названия.
Ограничения миграции#
Миграция считается завершенной, когда восстановлены базы данных, шлюз платформы зарегистрировал службы целевого узла и программный интерфейс (API) всех компонентов доступен. Процедура не переносит или переносит без проверки работоспособности следующие объекты, которые надо проверить и при необходимости настроить заново вручную:
Объект |
Что сделать после миграции |
|---|---|
Проекты, своды правил, активации и потоки событий Event-Driven Automation |
Замените ссылки на адреса и образы исходной платформы по инструкции по перенастройке EDA. Процедура восстановления переносит базу данных Event-Driven Automation целиком вместе с этими ссылками, поэтому объекты сохраняются, но продолжают указывать на исходную платформу. |
Группы исполняющих узлов и схема взаимодействия узлов |
Проверьте состав групп исполняющих узлов и при необходимости добавьте в них узел целевой платформы. При повторном развертывании утилита заменяет в Automation Controller узлы исходной платформы узлом целевой платформы, поэтому группы, в которые входили исполняющие и переходные узлы исходной платформы, остаются без них. Процедура проверяет Automation Controller. |
Содержимое Private Automation Hub |
Загрузите заново или синхронизируйте коллекции и образы, так как восстановленная база Private Automation Hub содержит сведения о них, но не сами файлы. Проверьте внешние репозитории и состояние их синхронизации. |
Собственный центр сертификации для Receptor |
Настройте собственный центр сертификации на целевой платформе, если исходная платформа его использовала. |
Изолированная среда |
Проверьте офлайн-пакеты, зеркала реестров и цепочки доверия. |
Собственные среды исполнения и среды принятия решений |
Перенесите образы, собранные вне поставки платформы, в целевой Private Automation Hub и обновите ссылки на них в Automation Controller и Event-Driven Automation. |
Внешние источники аутентификации и интеграции |
Проверьте настройки SSO, LDAP и OIDC, полномочия для систем управления исходным кодом и реестров, веб-перехватчики и адреса внешних систем. |
После восстановления часть сред исполнения и сред принятия решений указывает на реестр исходной платформы.
Например, так ведут себя среда исполнения Automation Hub Default execution environment и среда принятия решений Automation Hub Default Decision Environment, которые утилита создала при развертывании исходной платформы.
Замените адреса образов в свойствах таких сред на адреса целевой платформы или перенесите образы в целевой Private Automation Hub.
Почему Event-Driven Automation требует ручной настройки#
Объекты Event-Driven Automation переносятся восстановлением базы данных.
Проекты, своды правил, активации, потоки событий и полномочия остаются на целевой платформе, а полномочия расшифровываются, так как целевая платформа использует секрет eda_secret_key исходной.
Однако активации после миграции сами не запускаются, и причин тому две.
Утилита развертывания перезаписывает среду принятия решений по умолчанию.
Повторное развертывание целевой платформы после восстановления баз данных заменяет образ среды Default Decision Environment на образ из своей поставки.
Этот образ не содержит коллекцию ansible.eda, поэтому активация с источником из этой коллекции завершается ошибкой SourcePluginNotFoundException.
Среде необходимо вернуть полный образ среды принятия решений, доступный в реестре целевой платформы.
Объекты хранят адреса исходной платформы. Полномочия для доступа к Automation Controller и к реестру, а также среды принятия решений содержат адреса узлов исходной платформы. После переноса эти адреса указывают в прежнюю инфраструктуру, поэтому активация обращается к исходному контроллеру, а образ тянется из исходного реестра.
Обе причины устраняются запросами к API Event-Driven Automation и не требуют создания объектов заново (порядок действий приведен в инструкции по перенастройке EDA). Проверка на стенде подтвердила, что ручная настройка необходима из-за поведения утилиты развертывания и адресов в объектах, а не из-за переноса базы данных.
Последовательность действий#
Миграция в контейнерную модель предусматривает следующие шаги:
Перенастройка EDA после миграции, если исходная платформа использовала Event-Driven Automation.