Настройка и запуск

Настройка и запуск#

На данном этапе выполняется финальная настройка и запуск всей платформы в Kubernetes.

Очистка данных шлюза#

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

Очистка выполняется внутри ранее созданного временного пода postgres-restore-temp.

  1. Подключитесь к PostgreSQL:

    psql -h aa-demo-postgres-15 -U postgres -d automationgateway

  2. Выполните последовательно следующие SQL-запросы:

    Удаление дополнительных маршрутов:#
    DELETE FROM public.aap_gateway_api_additionalroute;
DELETE FROM public.aap_gateway_api_servicenode;
    Удаление маршрутов API-сервисов:#
    DELETE FROM public.aap_gateway_api_serviceapiroute;
    Удаление всех маршрутов:#
    DELETE FROM public.aap_gateway_api_route;
    Удаление HTTP-портов API:#
    DELETE FROM public.aap_gateway_api_httpport
WHERE is_api_port = true;

  3. Убедитесь, что таблицы очищены:

    SELECT COUNT(*) FROM public.aap_gateway_api_additionalroute;
SELECT COUNT(*) FROM public.aap_gateway_api_serviceapiroute;
SELECT COUNT(*) FROM public.aap_gateway_api_route;
SELECT COUNT(*) FROM public.aap_gateway_api_httpport
WHERE is_api_port = true;

    Каждый запрос должен вернуть значение 0.

  4. Выйдите из консоли PostgreSQL, выполнив следующую команду SQL:

    \q

  5. Выйдите из временного пода:

    exit

Синхронизация подписных ключей сервисов с секретами Kubernetes#

При восстановлении базы данных Platform Gateway из окружения ВМ в таблицу aap_gateway_api_servicekey из исходной платформы попадают ключи для подписи. Сервисы Private Automation Hub, Automation Controller и Event-Driven Automation в Kubernetes подписывают служебные токены ключами из секрета aa-demo-resource-server. Если значения в таблице aap_gateway_api_servicekey не совпадают со значениями из секрета aa-demo-resource-server, Platform Gateway отклоняет запросы сервисов с ошибкой 401 Unauthorized. В журнале Platform Gateway при этом появляется сообщение service_token_auth: Invalid token для запроса /api/gateway/v1/service-index/metadata/.

Выполните команды на узле, где доступен kubectl. Временный под postgres-restore-temp должен быть запущен, а операторы и компоненты платформы должны быть остановлены.

Примечание

В командах используется название сервиса внутренней PostgreSQL aa-demo-postgres-15. Если базы данных восстанавливаются во внешнюю PostgreSQL, замените значение аргумента -h на адрес внешнего сервера и при необходимости добавьте аргумент -p с номером порта.

  • Private Automation Hub:

    kubectl exec -i -n astra-automation postgres-restore-temp -- \
  psql -h aa-demo-postgres-15 -U postgres -d automationgateway \
  -v val="$(kubectl get secret aa-demo-resource-server -n astra-automation -o jsonpath='{.data.galaxy_resource_server_secret}' | base64 -d)" <<'SQL'
UPDATE aap_gateway_api_servicekey sk SET secret = :'val'
FROM aap_gateway_api_servicecluster sc
WHERE sc.id = sk.service_cluster_id AND sc.name = 'hub' AND sk.is_active;
SQL

  • Automation Controller:

    kubectl exec -i -n astra-automation postgres-restore-temp -- \
  psql -h aa-demo-postgres-15 -U postgres -d automationgateway \
  -v val="$(kubectl get secret aa-demo-resource-server -n astra-automation -o jsonpath='{.data.controller_resource_server_secret}' | base64 -d)" <<'SQL'
UPDATE aap_gateway_api_servicekey sk SET secret = :'val'
FROM aap_gateway_api_servicecluster sc
WHERE sc.id = sk.service_cluster_id AND sc.name = 'controller' AND sk.is_active;
SQL

  • Event-Driven Automation:

    kubectl exec -i -n astra-automation postgres-restore-temp -- \
  psql -h aa-demo-postgres-15 -U postgres -d automationgateway \
  -v val="$(kubectl get secret aa-demo-resource-server -n astra-automation -o jsonpath='{.data.eda_resource_server_secret}' | base64 -d)" <<'SQL'
UPDATE aap_gateway_api_servicekey sk SET secret = :'val'
FROM aap_gateway_api_servicecluster sc
WHERE sc.id = sk.service_cluster_id AND sc.name = 'eda' AND sk.is_active;
SQL

После выполнения каждой команды должен быть получен следующий результат:

UPDATE 1

Проверьте, что хеши подписных ключей в таблице Platform Gateway соответствуют значениям из секрета aa-demo-resource-server:

  1. Получите хеши активных ключей, сохраненных в базе данных Platform Gateway:

    kubectl exec -n astra-automation postgres-restore-temp -- \
  psql -h aa-demo-postgres-15 -U postgres -d automationgateway -tAc \
  "SELECT sc.name, md5(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 ORDER BY sc.name;"

  2. Получите хеш значения из секрета для Private Automation Hub:

    kubectl get secret aa-demo-resource-server -n astra-automation \
  -o jsonpath='{.data.galaxy_resource_server_secret}' | base64 -d | md5sum

    Вывод должен иметь следующий формат:

    controller|c4749668a13e6c024cfa4aa545f7aec4
eda|1d5290bc647eae94f4118fba0065b2f8
hub|09e1f2d180ed579108ed2135be8b2581

09e1f2d180ed579108ed2135be8b2581  -

Хеш в строке hub должен совпадать с хешем, полученным из секрета galaxy_resource_server_secret. Для проверки Automation Controller и Event-Driven Automation аналогично сравните строки controller и eda со значениями из полей controller_resource_server_secret и eda_resource_server_secret.

Секрет RESOURCE_SERVER для Private Automation Hub#

Править секрет pah-demo-server вручную не требуется и недопустимо. Оператор формирует значение RESOURCE_SERVER["SECRET_KEY"] из секрета aa-demo-resource-server при каждом согласовании состояния. Если изменить pah-demo-server напрямую, оператор перезапишет ручные изменения.

Согласованность Private Automation Hub и Platform Gateway обеспечивает шаг Синхронизация подписных ключей сервисов с секретами Kubernetes.

Удаление секрета, содержащего токен OAuth2#

Секрет aa-demo-gateway-oauth2-token-secret содержит токен OAuth2, используемый шлюзом для взаимодействия с другими компонентами. После миграции данный токен неактуален и его необходимо удалить с помощью следующей команды:

kubectl delete secret aa-demo-gateway-oauth2-token-secret -n astra-automation

Оператор aa-operator автоматически пересоздаст данный секрет при запуске с корректными значениями для окружения Kubernetes.

Запуск операторов#

Запустите операторы в следующей последовательности:

  1. Запустите aa-operator:

    kubectl scale deployment -n astra-automation \
  aa-operator-aa-manager --replicas=1

  2. Дождитесь, пока aa-operator станет доступен:

    kubectl wait --for=condition=available --timeout=60s \
  deployment/aa-operator-aa-manager -n astra-automation

  3. Запустите остальные операторы:

    kubectl scale deployment -n astra-automation \
  ac-operator-ac-manager \
  eda-operator-eda-manager \
  pah-operator-pah-manager \
  --replicas=1

  4. Проверьте статус операторов:

    kubectl get pods -n astra-automation | grep operator

Автоматический запуск компонентов операторами#

Примечание

После запуска операторов все компоненты платформы будут созданы и запущены автоматически в соответствии с ранее подготовленным манифестом, например k8s-base-aa-demo.yaml.

Ручное масштабирование Deployment не требуется.

Операторы автоматически выполняют следующие действия:

  • создают компоненты Deployment;

  • устанавливают корректное количество реплик;

  • создают заново токен OAuth2 для шлюза;

  • настраивают все внутренние связи между сервисами.

Для отслеживания процесса используйте следующую команду:

kubectl get pods -n astra-automation --watch

Ожидаемый процесс:

  • операторы создают Deployment;

  • поды проходят стадии ContainerCreating и Running;

  • через несколько минут все компоненты должны быть в состоянии Running или Completed.

Примечание

Для топологии уровня предприятия количество реплик определяется спецификацией в манифесте AstraAutomation. Для изменения конфигурации необходимо отредактировать манифест и применить его повторно.

Удаление исходных узлов#

После завершения миграции необходимо удалить из Astra Automation сведения об узлах, использовавшихся в исходном окружении на виртуальных машинах.

  1. Получите название пода ac-demo-task:

    kubectl get pods -n astra-automation -o name | grep ac-demo-task

    Примечание

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

  2. Подключитесь к выбранному поду:

    kubectl exec -it -n astra-automation <pod-name> -- bash

    Здесь <pod-name> – название выбранного пода.

    Например:

    kubectl exec -it -n astra-automation ac-demo-task-86f48fc4dc-4rx68 -- bash

  3. Удалите сведения об узле исходной инсталляции:

    awx-manage deprovision_instance --hostname <hostname>

    Здесь <hostname> – адрес узла из исходной инсталляции на виртуальных машинах.

    Список таких узлов можно посмотреть в графической консоли в разделе Автоматизация процессов ‣ Инфраструктура ‣ Представление топологии (Automation Execution ‣ Infrastructure ‣ Topology View).

    Например:

    awx-manage deprovision_instance --hostname 10.177.87.18

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

    Instance Removed
Successfully deprovisioned 10.177.87.18
(changed: True)

    Важно

    Команду awx-manage deprovision_instance необходимо выполнить отдельно для каждого узла исходной инсталляции.

  4. Выйдите из пода:

    exit

Проверка журналов#

После запуска платформы проверьте журналы ключевых компонентов:

  • Platform Gateway:

    kubectl logs -n astra-automation deployment/aa-demo-gateway --tail=50 --timestamps

  • Automation Controller:

    kubectl logs -n astra-automation deployment/ac-demo-web --tail=50 --timestamps

  • Private Automation Hub:

    kubectl logs -n astra-automation deployment/pah-demo-api --tail=50 --timestamps

  • Event-Driven Automation:

    kubectl logs -n astra-automation deployment/eda-demo-api --tail=50 --timestamps

Примечание

Флаг --timestamps не является обязательным, но рекомендуется для определения времени фиксации событий при проверке системы.

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

  • отсутствие ошибок подключения к БД;

  • отсутствие ошибок аутентификации;

  • корректная инициализация компонентов.

Удаление временного пода#

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

kubectl delete pod postgres-restore-temp -n astra-automation