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

Содержание

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

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

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

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

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

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

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

Выполните последовательно следующие 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;
```

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

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.

Выйдите из консоли PostgreSQL, выполнил следующую команду SQL:
```
\q
```
Выйдите из временного пода:
```
exit
```

Обновление секрета RESOURCE_SERVER#

Private Automation Hub использует секрет RESOURCE_SERVER для аутентификации и взаимодействия внутренних компонентов. В рамках миграции данный секрет обязан содержать SECRET_KEY, используемом в исходном Private Automation Hub в окружении ВМ.

Получите текущее значение секрета:

kubectl get secret pah-demo-server -n astra-automation \
  -o jsonpath='{.data.settings\.py}' | base64 -d > settings.py

В полученном файле settings.py в секции RESOURCE_SERVER измените значение SECRET_KEY на значение hub_secret_key из файла secrets.yml:
```
{
  "SECRET_KEY": "<hub_secret_key_from_secrets.yml>"
}
```
Закодируйте файл settings.py в формат base64:
```
cat settings.py | base64 -w 0 > settings_encoded.txt
```

Обновите секрет в кластере Kubernetes:

kubectl patch secret pah-demo-server -n astra-automation --type='json' \
  -p="[{\"op\": \"replace\", \"path\": \"/data/settings.py\", \"value\": \"$(cat settings_encoded.txt)\"}]"

Проверьте, что секрет успешно обновлен:

kubectl get secret pah-demo-server -n astra-automation \
  -o jsonpath='{.data.settings\.py}' | base64 -d

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

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

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

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

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

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

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

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

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

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

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

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

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

kubectl get pods -n astra-automation | grep operator

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

Внимание

После запуска операторов все компоненты платформы будут созданы и запущены автоматически в соответствии с манифестом minikube-minimal-aa-demo.yaml. Ручное масштабирование Deployment не требуется.

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

создают компоненты Deployment;
устанавливают корректное количество реплик;
создают заново токен OAuth2 для шлюза;
настраивают все внутренние связи между сервисами.

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

kubectl get pods -n astra-automation --watch

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

операторы создают Deployment;
поды проходят стадии ContainerCreating и Running;
через несколько минут все компоненты должны быть в состоянии Running или Completed.

Примечание

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

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

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

Platform Gateway:

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

Automation Controller:

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

Private Automation Hub:

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

Event-Driven Automation:

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

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

отсутствие ошибок подключения к БД;
отсутствие ошибок аутентификации;
корректная инициализация компонентов.

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

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

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