Откат обновления

Откат обновления#

Возможность отката зависит от того, выполнены ли миграции схемы баз данных:

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

Не используйте команду kubectl delete -f с манифестами из каталога operators/ установочного пакета. Каждый такой манифест содержит не только оператор, но и общие ресурсы платформы, в том числе пространство имен astra-automation. Команда kubectl delete -f по такому манифесту удалит пространство имен вместе со всей платформой и ее данными. Удаляйте объекты только адресно, по виду и названию.

Возврат манифестов#

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

  1. Сравните текущее состояние ресурсов с манифестами, сохраненными на стадии подготовки.

  2. Примените сохраненные определения собственных ресурсов (CRD) и объекты Deployment операторов исходной версии:

    kubectl apply -f ~/preupgrade-exports/crds.yaml
kubectl apply -f ~/preupgrade-exports/operators.yaml

    Если сохранился установочный пакет версии 2.0-upd2, вместо сохраненных манифестов можно применить каталог operators/ из этого пакета.

  3. Примените исходный манифест приложения.

  4. При необходимости восстановите исходные поля ресурсов компонентов (AutomationController, PrivateAutomationHub, EDA) из файла custom-resources.yaml.

  5. Убедитесь, что объекты Deployment, StatefulSet, Service и Ingress вернулись к состоянию, сохраненному в файле workloads.yaml.

Восстановление баз данных#

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

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

  1. Остановите операторы, чтобы исключить запуск процесса Reconciliation во время восстановления:

    kubectl scale deploy aa-operator-aa-manager ac-operator-ac-manager \
  pah-operator-pah-manager eda-operator-eda-manager dashboard-operator-dashboard-manager \
  -n astra-automation --replicas=0

  2. Остановите компоненты платформы:

    kubectl scale deploy --all -n astra-automation --replicas=0
kubectl scale sts --all -n astra-automation --replicas=0

    Если СУБД PostgreSQL развернута в кластере, верните ее StatefulSet в работу – он необходим для восстановления данных:

    kubectl scale sts <название StatefulSet СУБД> -n astra-automation --replicas=1

    Здесь <название StatefulSet СУБД> – название объекта StatefulSet СУБД, которое выводит команда kubectl get sts -n astra-automation.

  3. Восстановите базы данных компонентов из дампов, созданных на стадии подготовки, штатными средствами СУБД PostgreSQL, например утилитами pg_restore или psql. Для СУБД, развернутой в кластере, выполните восстановление через под StatefulSet СУБД с помощью команды kubectl exec.

  4. Убедитесь, что секреты шифрования соответствуют сохраненным в файле encryption-secrets.yaml, так как без них компоненты не смогут расшифровать восстановленные данные.

  5. Примените сохраненные CRD и объекты Deployment операторов исходной версии, затем исходный манифест приложения, как описано в инструкции по возврату манифестов. Операторы запустятся и пересоздадут компоненты на образах исходной версии.

  6. Убедитесь, что платформа вернулась в состояние Successful, отвечает по API и все компоненты используют образы с тегом 2.0-upd2; команды приведены в инструкции по проверке работоспособности.

Удаление Automation Dashboard#

Ресурс Dashboard и оператор dashboard-operator при откате можно удалить. Удаляйте объекты адресно:

kubectl delete dashboard dashboard-demo -n astra-automation
kubectl delete deployment dashboard-operator-dashboard-manager -n astra-automation

Примечание

Том PVC собственной СУБД PostgreSQL компонента Automation Dashboard при удалении ресурса сохраняется. Если том больше не нужен, удалите его отдельно.