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

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

На данном этапе выполняется финальная настройка и запуск всей платформы в 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, поэтому он должен находиться в состоянии Running.

Примечание

В штатном процессе миграции выполняйте этот шаг после восстановления баз данных и до запуска операторов и компонентов платформы. Если ошибка 401 Unauthorized с сообщением service_token_auth: Invalid token появилась уже после запуска платформы, повторно выполните только этот шаг. Останавливать компоненты для повторной синхронизации ключей не требуется. Если временный под postgres-restore-temp уже удален, создайте его повторно по инструкции Создание временного пода для восстановления.

Проверка наличия секретов#

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

  • Private Automation Hub:

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

  • Automation Controller:

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

  • Event-Driven Automation:

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

Результат каждой команды должен быть больше 0. Длина значения составляет 86 символов.

Если команда вернула 0, секрет aa-demo-resource-server еще не создан или соответствующее поле в нем пустое. Вручную секрет задавать не требуется, потому что его создает оператор при развертывании платформы.

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

Без ключа подписи переходить к обновлению бессмысленно, потому что записывать в таблицу будет нечего.

Подготовка подключения к СУБД#

Команды далее обращаются к внутренней СУБД по названию сервиса aa-demo-postgres-15. Если базы данных восстановлены во внешнюю СУБД, подготовьте два значения:

  • адрес внешнего сервера PostgreSQL – он подставляется в аргумент -h вместо aa-demo-postgres-15;

  • номер порта TCP, если он отличается от стандартного, – он добавляется аргументом -p.

Все команды далее неинтерактивны, поэтому ввести пароль администратора по запросу нельзя. Пароль передается файлом .pgpass внутри временного пода: файл создается при подготовке файла с паролем и находится по пути /tmp/.pgpass. Если файл уже удален, создайте его повторно.

Важно

Файл .pgpass готовьте независимо от того, где размещены базы данных. Команды далее подключаются к СУБД по TCP, а пароль для таких подключений требуют внешний сервер и образы внутренней СУБД начиная с postgresql:2.1. Более ранние образы пароль не спрашивают, и файл им не понадобится.

Путь к файлу передается командам psql в переменной окружения PGPASSFILE. Указывайте переменную перед psql, а не после нее: иначе psql получит env в качестве аргумента.

Важно

Удалите файл с паролем из временного пода после того, как выполнен перевод ключей в зашифрованный вид – проверка на этом шаге также обращается к СУБД:

kubectl exec -n astra-automation postgres-restore-temp -- rm -f /tmp/.pgpass

Обновление ключей#

Обновите ключи в таблице Platform Gateway. Для каждого компонента выполняются два действия: значение ключа сохраняется во временный файл внутри пода, а затем psql читает его из этого файла.

Важно

Значение ключа нельзя передавать через аргумент команды. Команда kubectl exec передает каждый аргумент отдельным параметром строки запроса к API Kubernetes, поэтому значение попадает в requestURI, а оттуда – в журнал аудита API-сервера и в журналы промежуточных прокси-серверов. Ключ подписи, полученный из этих журналов, позволяет подделать служебный токен любого компонента платформы.

  • Private Automation Hub:

    Сохраните ключ во временный файл внутри пода:

    kubectl get secret aa-demo-resource-server -n astra-automation \
  -o jsonpath='{.data.galaxy_resource_server_secret}' | base64 -d | \
  kubectl exec -i -n astra-automation postgres-restore-temp -- \
    sh -c 'cat > /tmp/service.key && chmod 600 /tmp/service.key'

    Обновите ключ в таблице:

    kubectl exec -i -n astra-automation postgres-restore-temp -- \
  env PGPASSFILE=/tmp/.pgpass \
  psql -h aa-demo-postgres-15 -U postgres -d automationgateway <<'SQL'
\set val `cat /tmp/service.key`
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 get secret aa-demo-resource-server -n astra-automation \
  -o jsonpath='{.data.controller_resource_server_secret}' | base64 -d | \
  kubectl exec -i -n astra-automation postgres-restore-temp -- \
    sh -c 'cat > /tmp/service.key && chmod 600 /tmp/service.key'

    Обновите ключ в таблице:

    kubectl exec -i -n astra-automation postgres-restore-temp -- \
  env PGPASSFILE=/tmp/.pgpass \
  psql -h aa-demo-postgres-15 -U postgres -d automationgateway <<'SQL'
\set val `cat /tmp/service.key`
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 get secret aa-demo-resource-server -n astra-automation \
  -o jsonpath='{.data.eda_resource_server_secret}' | base64 -d | \
  kubectl exec -i -n astra-automation postgres-restore-temp -- \
    sh -c 'cat > /tmp/service.key && chmod 600 /tmp/service.key'

    Обновите ключ в таблице:

    kubectl exec -i -n astra-automation postgres-restore-temp -- \
  env PGPASSFILE=/tmp/.pgpass \
  psql -h aa-demo-postgres-15 -U postgres -d automationgateway <<'SQL'
\set val `cat /tmp/service.key`
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

Здесь \set – команда psql, которая присваивает переменной val содержимое файла /tmp/service.key. Обратные апострофы означают, что psql выполняет команду cat внутри пода и подставляет ее вывод.

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

UPDATE 1

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

  • UPDATE 0 – активный ключ для указанного сервисного кластера не найден. Проверьте список сервисных кластеров:

    kubectl exec -n astra-automation postgres-restore-temp -- \
  env PGPASSFILE=/tmp/.pgpass \
  psql -h aa-demo-postgres-15 -U postgres -d automationgateway -tAc \
  "SELECT name FROM aap_gateway_api_servicecluster;"

  • UPDATE 2 или больше – найдено несколько активных ключей для указанного сервисного кластера. Это допустимо, если в восстановленной базе данных для сервисного кластера действительно есть несколько активных ключей. В этом случае все они получат одно и то же значение секрета из aa-demo-resource-server.

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

kubectl exec -n astra-automation postgres-restore-temp -- rm -f /tmp/service.key

Проверка записанных значений#

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

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

    kubectl exec -n astra-automation postgres-restore-temp -- \
  env PGPASSFILE=/tmp/.pgpass \
  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;"

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

    controller|<controller_secret_md5>
eda|<eda_secret_md5>
hub|<hub_secret_md5>

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

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

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

    <hub_secret_md5>  -

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

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

Перевод ключей в зашифрованный вид#

Важно

Этот шаг выполняется после запуска компонентов платформы: он обращается к поду Platform Gateway.

Platform Gateway хранит ключи подписи служебных токенов в базе данных зашифрованными – значение в колонке secret имеет вид $encrypted$UTF8$AESCBC$.... Запрос UPDATE записывает значение из секрета как есть, поэтому после синхронизации ключ хранится незашифрованным. Platform Gateway принимает такое значение и работает с ним: при чтении незашифрованное значение возвращается без изменений. Однако само оно зашифрованным не станет – ни перезапуск компонентов, ни повторная аутентификация компонентов колонку не перезаписывают.

Чтобы вернуть ключи к принятому в платформе виду, сохраните их средствами Platform Gateway:

for pair in "galaxy_resource_server_secret:hub" \
            "controller_resource_server_secret:controller" \
            "eda_resource_server_secret:eda"; do
  field=${pair%%:*}
  cluster=${pair##*:}

  kubectl get secret aa-demo-resource-server -n astra-automation \
    -o jsonpath="{.data.$field}" | base64 -d | \
    kubectl exec -i -n astra-automation deployment/aa-demo-gateway -c api -- \
      /opt/aap_gateway/venv/bin/python3 -c "
import os, sys, django
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'aap_gateway.settings')
django.setup()
from aap_gateway_api.models import ServiceKey
value = sys.stdin.read()
for key in ServiceKey.objects.filter(is_active=True, service_cluster__name=sys.argv[1]):
    key.secret = value
    key.save()
" "$cluster"
done

Команда обрабатывает ключи всех трех компонентов: Private Automation Hub, Automation Controller и Event-Driven Automation. У Platform Gateway собственного ключа нет – он проверяет служебные токены компонентов, а сам их не подписывает.

Цикл передает ключи по одному на стандартный поток ввода (stdin) программы Python, а не аргументом команды: значения аргументов попадают в журнал аудита API-сервера. Название сервисного кластера не секретное, поэтому его можно передать аргументом.

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

Проверьте результат:

kubectl exec -n astra-automation postgres-restore-temp -- \
  env PGPASSFILE=/tmp/.pgpass \
  psql -h aa-demo-postgres-15 -U postgres -d automationgateway -tAc \
  "SELECT sc.name, left(sk.secret, 24) 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;"

Значение каждой строки должно начинаться с $encrypted$UTF8$AESCBC$.

Проверка выполняется из временного пода postgres-restore-temp и использует файл /tmp/.pgpass. Если под или файл уже удалены, создайте их повторно по инструкциям Создание временного пода для восстановления и Подготовка файла с паролем.

Примечание

Для перевода ключа в зашифрованный вид не используйте команду generate_service_secret. Она создает новый ключ, который не будет совпадать со значением в секрете aa-demo-resource-server, и аутентификация компонентов снова нарушится.

Секрет 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

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

    deployment.apps/aa-operator-aa-manager condition met

  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. Для изменения конфигурации необходимо отредактировать манифест и применить его повторно.

Важно

После перехода компонентов в состояние Running вернитесь к шагу перевода ключей в зашифрованный вид. Он отложен до этого момента, так как обращается к поду Platform Gateway, и без него ключи подписи остаются в базе данных в открытом виде.

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

После завершения миграции необходимо удалить из 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

Удаление миграционного артефакта#

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

Все приведенные далее команды выполняйте на ВМ, где выполнялся сбор данных. Удаление на остальных узлах выполняется одной командой ssh без открытия интерактивного сеанса, поэтому переключаться между узлами не требуется.

  1. Удалите артефакт и распакованный каталог на узле кластера Kubernetes, где был запущен временный под:

    ssh -t [-i <ssh_key>] <ssh_user>@<cluster_node_ip> \
  sudo rm -rf /tmp/migration-export /tmp/artifact.tar.gz /tmp/artifact.tar.gz.sha256

    Здесь <cluster_node_ip> – IP-адрес узла кластера Kubernetes, на который был скопирован артефакт.

    Аргумент -t необходим для того, чтобы sudo мог запросить пароль.

  2. Удалите копию артефакта на установочном узле (см. шаг копирования артефакта):

    ssh [-i <ssh_key>] <ssh_user>@<installation_node_ip> \
  rm -f /tmp/artifact.tar.gz /tmp/artifact.tar.gz.sha256

    Здесь <installation_node_ip> – IP-адрес установочного узла.

  3. Удалите артефакт и исходные файлы экспорта на самой ВМ, где выполнялся сбор данных:

    rm -rf migration-export artifact.tar.gz artifact.tar.gz.sha256 database-info.txt

    Если файл database-info.txt хранится в другом каталоге, удалите его вручную.

Предупреждение

Не оставляйте secrets.yml, database-info.txt, дампы баз данных и архив artifact.tar.gz в каталогах временного хранения. Эти файлы содержат чувствительные данные платформы.