Проверка результата миграции

Проверка результата миграции#

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

Доступность API#

Запросите состояние компонентов через целевой шлюз:

curl -s --cacert "$CA" https://<target_host>/api/controller/v2/ping/; echo
curl -s --cacert "$CA" https://<target_host>/api/galaxy/pulp/api/v3/status/; echo
curl -s --cacert "$CA" https://<target_host>/api/eda/v1/status/; echo

Здесь:

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

  • $CA – путь к цепочке сертификатов удостоверяющего центра платформы; цепочку выбирают по модели сертификатов, как описано при перенастройке EDA.

Ожидаемый результат:

  • ответ Automation Controller содержит поле active_node с адресом целевого узла;

  • ответ Private Automation Hub содержит "connected": true в объектах database_connection и redis_connection;

  • ответ контроллера Event-Driven Automation – {"status":"good"}.

Если какой-либо компонент не отвечает, проверьте его контейнеры и ключи служб, как описано ниже.

Состояние контейнеров#

Получите список служб, у которых зафиксирован сбой, и активных контейнеров целевой платформы:

systemctl --user --failed --no-legend
podman ps --format '{{.Names}} {{.Status}}' | sort

Список служб со сбоями должен быть пустым, а все контейнеры компонентов должны быть в состоянии Up. Если служба находится в состоянии failed, просмотрите ее журнал командой journalctl --user -u <unit_name>.

Узлы служб шлюза#

Выведите узлы служб, которые шлюз зарегистрировал в своей базе:

podman exec postgresql psql -U postgres -d automationgateway -Atc \
  'SELECT name, address FROM aap_gateway_api_servicenode ORDER BY name'

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

Совпадение ключей служб#

Сравните контрольные суммы активных ключей служб в базе шлюза и в секретах компонентов:

for cluster in controller hub eda; do
  expected=$(podman exec postgresql psql -U postgres -d automationgateway -Atc "
    SELECT sk.secret FROM aap_gateway_api_servicekey sk
    JOIN aap_gateway_api_servicecluster sc ON sc.id = sk.service_cluster_id
    WHERE sk.is_active AND sc.name = '$cluster' LIMIT 1" | tr -d '\r\n' | sha256sum | cut -d ' ' -f 1)
  actual=$(podman secret inspect --showsecret --format '{{.SecretData}}' ${cluster}_resource_server | tr -d '\n' | sha256sum | cut -d ' ' -f 1)
  if [ "$expected" = "$actual" ]; then echo "$cluster: OK"; else echo "$cluster: MISMATCH"; fi
done

Ожидаемый результат:

controller: OK
hub: OK
eda: OK

Если проверка выводит MISMATCH для какого-либо ключа, повторите замену ключей служб и повторное развертывание.

Проверка данных#

Войдите в графическую консоль целевой платформы по адресу https://<target_host>/ и убедитесь в следующем:

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

  • в Automation Controller присутствуют проекты, инвентарные списки, полномочия и шаблоны заданий;

  • задание по тестовому шаблону завершается успешно;

  • в Private Automation Hub присутствуют пространства имен, коллекции и среды исполнения;

  • в Event-Driven Automation присутствуют проекты, активации сводов правил и записи аудита правил.

Объекты, перечисленные в ограничениях миграции, проверьте и при необходимости настройте отдельно.

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

Миграцию считают завершенной при следующих условиях:

  • повторное развертывание целевой платформы завершилось с failed=0;

  • API всех компонентов доступен через целевой шлюз;

  • узлы служб шлюза содержат только адрес целевого узла;

  • ключи служб в базе шлюза и в секретах компонентов совпадают;

  • данные исходной платформы доступны в графической консоли целевой платформы;

  • пользовательские настройки Automation Controller перенесены вручную и сверены с файлами из архива (см. сохранение настроек).

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