Перенастройка EDA после миграции

Перенастройка EDA после миграции#

Процедура восстановления переносит базу данных Event-Driven Automation целиком вместе с проектами, сводами правил, активациями, потоками событий и полномочиями. Целевая платформа использует секрет eda_secret_key исходной платформы, поэтому она расшифровывает перенесенные полномочия и пересоздавать их не требуется. Однако часть объектов продолжает ссылаться на адреса исходной платформы или на образы в ее реестре. Эти ссылки необходимо заменить через API контроллера Event-Driven Automation.

Выполняйте команды на узле целевой платформы.

Объекты для проверки#

Проверьте следующие объекты Event-Driven Automation:

  • среда принятия решений Default Decision Environment, образ которой утилита развертывания заменила на образ из поставки целевой платформы;

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

  • полномочия реестра и полномочия для доступа к Automation Controller, содержащие адреса исходной платформы;

  • проекты, для которых необходимо повторить синхронизацию;

  • активации, которые используют перечисленные среды и полномочия;

  • потоки событий и их сопоставление с активациями (source_mappings).

Проверка сертификата платформы#

Команды этой инструкции передают пароль администратора и токен доступа, поэтому проверку сертификата платформы отключать нельзя. Аргумент -k (--insecure) в них не используется: при подмене узла он отдает пароль и токен тому, кто ответил вместо платформы.

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

  • Сертификат публичного удостоверяющего центра. Узел доверяет платформе сам, поэтому цепочка не требуется: удалите из команд аргумент --cacert "$CA".

  • Сертификат корпоративного удостоверяющего центра. Цепочка находится в файле, который задан переменной custom_ca_cert описания инвентаря целевой платформы.

  • Удостоверяющий центр, созданный утилитой развертывания. Утилита создает его при развертывании, если переменная custom_ca_cert не задана, и сохраняет сертификат на узле платформы в файле ~/astra-automation/tls/ca.cert в домашнем каталоге учетной записи из переменной ansible_user. Узел этому центру не доверяет: утилита подключает сертификат только внутрь контейнеров, поэтому аргумент --cacert для команд обязателен.

Задайте путь к цепочке:

CA=</path/to/ca_chain>

Здесь </path/to/ca_chain> – файл цепочки сертификатов, выбранный по модели сертификатов целевой платформы. Для удостоверяющего центра, созданного утилитой развертывания, это ~/astra-automation/tls/ca.cert.

Проверьте, что платформа отвечает с этой цепочкой:

curl -s --cacert "$CA" -o /dev/null -w '%{http_code}\n' https://<target_host>/api/controller/v2/ping/

Ожидаемый результат – код 200. Если команда сообщает об ошибке проверки сертификата, миграцию продолжать нельзя, пока сертификат не станет доверенным: иначе следующие команды отдадут пароль администратора неизвестному узлу.

Получение токена доступа#

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

TOKEN=$(curl -s --cacert "$CA" -X POST -u <admin_username>:<admin_password> \
  https://<target_host>/api/gateway/v1/tokens/ \
  | python3 -c 'import json, sys; print(json.load(sys.stdin)["token"])')

Здесь:

  • <admin_username> и <admin_password> – учетные данные администратора платформы;

  • <target_host> – доменное имя узла с развернутой целевой платформой, на которое выпущен сертификат платформы. По IP-адресу проверка сертификата завершается ошибкой, так как сертификаты платформы выпускаются на доменное имя узла.

Подробнее о токенах доступа см. методы аутентификации.

Перенос образов среды принятия решений#

Для замены образов среды принятия решений выполните следующие действия:

  1. Получите таблицу, представляющую среды принятия решений и адреса их образов:

    URL="https://<target_host>/api/eda/v1/decision-environments/?page_size=100"
while [ -n "$URL" ]; do
  RESP=$(curl -s --cacert "$CA" -H "Authorization: Bearer $TOKEN" "$URL")
  printf '%s' "$RESP" | python3 -c 'import json, sys; [print(i["id"], i["name"], i["image_url"]) for i in json.load(sys.stdin)["results"]]'
  URL=$(printf '%s' "$RESP" | python3 -c 'import json, sys; n = json.load(sys.stdin).get("next") or ""; print(n if not n or n.startswith("http") else "https://<target_host>" + n)')
done

    Цикл читает страницы, пока ответ содержит ссылку next, и останавливается, когда она пуста. Без обхода страниц команда вернула бы только первые 100 объектов, а остальные молча сохранили бы ссылки на исходную платформу.

  2. Если образ находится в реестре исходной платформы, скопируйте его в реестр целевого Private Automation Hub.

    Команду выполняют на узле, где установлена утилита skopeo. На узлах платформы, развернутой из deb-пакетов, она установлена вместе с платформой, а на узле контейнерной платформы ее устанавливают отдельно:

    sudo apt install skopeo

    В ссылках на образы реестры называют тем доменным именем, на которое выпущен их сертификат. По IP-адресу проверка сертификата завершается ошибкой x509: cannot validate certificate ... because it doesn't contain any IP SANs, так как сертификаты платформы выпускаются на доменное имя узла. Проверено на стенде: копирование по доменному имени проходит, по IP-адресу того же узла – нет.

    skopeo copy --format v2s2 \
  --src-creds <source_registry_user>:<source_registry_password> \
  --dest-creds <target_registry_user>:<target_registry_password> \
  docker://<source_gateway_host>/<de_repository>:<de_tag> \
  docker://<target_host>/<de_repository>:<de_tag>

    Здесь:

    • <source_gateway_host> – доменное имя узла Platform Gateway исходной платформы, на которое выпущен сертификат реестра;

    • <source_registry_user> и <source_registry_password> – реквизиты учетной записи для доступа к реестру исходной платформы;

    • <target_registry_user> и <target_registry_password> – реквизиты учетной записи для доступа к реестру целевой платформы;

    • <de_repository> и <de_tag> – репозиторий и тег образа среды принятия решений.

    Команда передает реквизиты доступа к обоим реестрам, поэтому проверку сертификата отключать нельзя: аргументы --src-tls-verify=false и --dest-tls-verify=false в ней не используются.

    Если реестр использует сертификат собственного удостоверяющего центра, настройте доверие ему до копирования одним из двух способов:

    Здесь <registry_host> – адрес реестра в ссылке на образ, включая порт, если он нестандартный. Для реестра целевой платформы это та же цепочка, которую задает переменная CA.

  3. Замените адрес образа в среде принятия решений:

    curl -s --cacert "$CA" -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"image_url": "<target_host>/<de_repository>:<de_tag>"}' \
  https://<target_host>/api/eda/v1/decision-environments/<de_id>/

    Здесь <de_id> – идентификатор среды принятия решений из вывода первой команды.

Если после копирования реестр целевой платформы возвращает ошибку MANIFEST_UNKNOWN при загрузке образа, проверьте, что репозиторий образа опубликован в Private Automation Hub целевой платформы.

Возврат полного образа среде по умолчанию#

Повторное развертывание целевой платформы заменяет образ среды Default Decision Environment на образ из своей поставки. Этот образ не содержит коллекцию ansible.eda, поэтому активация с источником из этой коллекции завершается ошибкой SourcePluginNotFoundException. Адрес такого образа указывает на реестр целевой платформы, поэтому под проверку при переносе образов он не попадает.

Верните среде полный образ среды принятия решений – aa-full-de из реестра целевой платформы:

curl -s --cacert "$CA" -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"image_url": "<target_host>/aa-<version>/aa-full-de:latest"}' \
  https://<target_host>/api/eda/v1/decision-environments/<de_id>/

Здесь:

  • <version> – версия платформы в пути реестра, например 2.1;

  • <de_id> – идентификатор среды Default Decision Environment из таблицы сред принятия решений.

Если образа aa-full-de в реестре целевой платформы нет, скопируйте его туда из реестра исходной платформы так же, как остальные образы сред принятия решений.

После замены адреса перезапустите активации, которые используют эту среду (см. перезапуск активаций).

Замена адресов в полномочиях#

Выведите полномочия Event-Driven Automation и их типы:

URL="https://<target_host>/api/eda/v1/eda-credentials/?page_size=100"
while [ -n "$URL" ]; do
  RESP=$(curl -s --cacert "$CA" -H "Authorization: Bearer $TOKEN" "$URL")
  printf '%s' "$RESP" | python3 -c 'import json, sys; [print(i["id"], i["name"], i["credential_type"]["name"]) for i in json.load(sys.stdin)["results"]]'
  URL=$(printf '%s' "$RESP" | python3 -c 'import json, sys; n = json.load(sys.stdin).get("next") or ""; print(n if not n or n.startswith("http") else "https://<target_host>" + n)')
done

Цикл читает страницы до конца так же, как при выводе сред принятия решений.

Замените адрес в полномочии реестра:

curl -s --cacert "$CA" -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"inputs": {"host": "<target_host>"}}' \
  https://<target_host>/api/eda/v1/eda-credentials/<credential_id>/

Для полномочия доступа к Automation Controller укажите в поле host значение https://<target_host>/api/controller.

Здесь <credential_id> – идентификатор полномочия из вывода предыдущей команды.

API возвращает секретные поля полномочий в виде $encrypted$. Запрос PATCH меняет только переданные поля и не затрагивает секретные значения.

Синхронизация проектов#

Запустите синхронизацию каждого проекта Event-Driven Automation:

curl -s --cacert "$CA" -X POST \
  -H "Authorization: Bearer $TOKEN" \
  https://<target_host>/api/eda/v1/projects/<project_id>/sync/

Здесь <project_id> – идентификатор проекта.

Если после синхронизации изменилось содержимое свода правил, решение о запуске активации с новой версией принимает владелец проекта.

Перезапуск активаций#

Если адрес образа исправлен в самой среде принятия решений, активацию достаточно перезапустить:

curl -s --cacert "$CA" -X POST \
  -H "Authorization: Bearer $TOKEN" \
  https://<target_host>/api/eda/v1/activations/<activation_id>/restart/

Здесь <activation_id> – идентификатор активации. После перезапуска активация создает новый экземпляр, который загружает образ по исправленному адресу.

Контроллер Event-Driven Automation не позволяет сменить среду принятия решений у включенной активации. Поэтому если активации необходимо назначить другую среду, выполните следующие действия:

  1. Выключите активацию:

    curl -s --cacert "$CA" -X POST \
  -H "Authorization: Bearer $TOKEN" \
  https://<target_host>/api/eda/v1/activations/<activation_id>/disable/

    Здесь <activation_id> – идентификатор активации.

  2. При необходимости укажите новую среду принятия решений:

    curl -s --cacert "$CA" -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"decision_environment_id": <de_id>}' \
  https://<target_host>/api/eda/v1/activations/<activation_id>/

  3. Включите активацию и проверьте ее состояние:

    curl -s --cacert "$CA" -X POST \
  -H "Authorization: Bearer $TOKEN" \
  https://<target_host>/api/eda/v1/activations/<activation_id>/enable/

curl -s --cacert "$CA" -H "Authorization: Bearer $TOKEN" \
  https://<target_host>/api/eda/v1/activations/<activation_id>/ \
  | python3 -c 'import json, sys; print(json.load(sys.stdin)["status"])'

    Ожидаемый результат через несколько минут – running.

Если активация не переходит в состояние running, просмотрите журнал ее последнего запуска в графической консоли Event-Driven Automation на вкладке История (History) активации.