Обновление Test IT в Kubernetes

Создайте резервную копию

Во избежание критичной потери данных перед обновлением необходимо создать резервную копию Test IT Про.

Скрипт для резервного копирования расположен в папке scripts с дистрибутивом Test IT.

Смотрите также: Резервное копирование в Kubernetes: Test IT 5.3 и более поздние версии

Соблюдайте последовательность обновления

Обновляйте систему в соответствии с порядком версий
Мы рекомендуем обновлять систему последовательно — по порядку старших (мажорных) версий продукта. Например, чтобы обновить продукт с версии 5.1 до 5.3, рекомендуется:

  1. Обновить продукт до Test IT 5.2
  2. Обновить продукт до версии 5.3

Непоследовательное обновление и игнорирование промежуточных мажорных версий может привести к ошибкам.

Контролируйте дренаж очередей
В процессе работы системы в очередях RabbitMQ могут накапливаться фоновые задачи (отправка уведомлений, асинхронная обработка данных). При резком перезапуске сервисов с новой версией сообщения, не успевшие обработаться, могут быть отклонены новым форматом данных. Рекомендуется:

  • Не останавливать сервисы немедленно и дождаться, пока потребители (consumers) обработают накопленные сообщения.

Если вы используйте версии Test IT Про до 4.6 включительно, следуйте соответствующим инструкциям на этой странице.

Миграция данных автотестов при обновлении до версии 5.4

Миграция данных автотестов может занимать до 8 часов в зависимости от их объема. Это связано с необходимостью группировки результатов тестов в прогонах с учетом конфигурации и параметров автотестов, их нумерации и последующего распределения данных по биатлонам. Во время миграции производительность системы снижается в связи с нагрузкой на базу данных. Основные рекомендации:

  1. Отслеживайте миграцию следующим образом. В начале запуска обновления запускается job webapi-migration, порождающая соответствующий pod webapi-migration-хххх. В логах этого пода периодически будет выводиться сообщение Applying migration. Минимальный уровень: Information.
    • Началом миграции служит запись вида: Applying migration '20250313093240_TMS-31090_MigrateTestResultsToTestBiathlons'.
    • При успешном окончании миграции отображается запись вида: INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion") VALUES ('20250313093240_TMS-31090_MigrateTestResultsToTestBiathlons', '9.0.5');
    • При превышении тайм-аута подключения к базе данных отобразится запись вида: Database migration timed out. Operation will be retried. Retry number: 1. После превышения тайм-аута миграция будет перезапущена автоматически. Данные, перенесенные в предыдущих попытках, затронуты не будут.
    • По окончании миграций в логах отобразится сообщение: Application started.
  2. При ошибке и прекращения работы контейнеров обновите систему повторно.
  3. При возникновении проблем, связанных с миграцией, обратитесь в техническую поддержку: support@testit.software.

Обновление

Важно

При автономном обновлении предварительно загрузите образы из архива images.tar.gz в выбранный вами локальный репозиторий. Убедитесь, что кластер имеет доступ к этому репозиторию.

  1. Создайте новую директорию, скачайте и распакуйте в ней архив с новой поставкой Helm-чарта.
  2. Сравните содержимое файлов values.yaml и values-override.yaml и перенесите пользовательские параметры в соответствующие файлы новой версии.
  3. В командной строке перейдите в директорию с новой версией и выполните следующие команды:
    # Обновите приложения.
helm upgrade --install -f testit_unichart/values-override.yaml -n <my-namespace> --create-namespace testit testit_unichart/ --wait --timeout 10h
# Дождитесь начала работы всех модулей.
watch -n 1 kubectl -n <namespace> get pods

Как обновлять Test IT до последних версий

  • Если вы используете манифесты для Kubernetes, полученные от технической поддержки, вам доступно обновление до версии 4.4 Lupus.
  • Чтобы своевременно обновлять Test IT до более поздних версий, требуется использовать helm-чарты. Для получения инструкций обратитесь в техническую поддержку: (support@testit.software).

Переход на unichart в версии 5.3.0

Для случаев, когда Kubernetes-версия продукта обновляется с 5.2.x на 5.3.0, необходимо произвести миграцию объектов Kubernetes на новый чарт:

  1. Рекомендуется: Выполните резервное копирование для сохранности данных, запустив scripts/k8s_backup.sh.
  2. Удалите чарты предыдущей версии:
    export NAMESPACE=<my-namespace>
# Убеждаемся, что в выбранном пространстве имен присутствуют
helm list -n $NAMESPACE | grep testit
# Удаляем установленные чарты testit
# NOTE: Названия чартов приведены для примера и могут отличаться в зависимости от того, какими командами они устанавливались
helm -n $NAMESPACE uninstall testit-backend
helm -n $NAMESPACE uninstall testit-frontend
# Рекомендуется удостовериться, что при удалении чартов не были удалены тома памяти
kubectl -n $NAMESPACE get pvc
# NAME                               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# auth-cache-pv-claim-auth-cache-0
# influxdb-pv-claim-influxdb-0
# minio-pv-claim-minio-0
# postgres-pv-claim-postgres-0
# rabbitmq-pv-claim-rabbitmq-0
  3. Удалите pvc RabbitMQ.
    kubectl -n $NAMESPACE delete pvc rabbitmq-pv-claim-rabbitmq-0
    В поставку 5.3.0 вошел обновленный docker образ для RabbitMQ. В связи с этим, для избегания несовместимости, pvc rabbitmq-pv-claim-rabbitmq-0 нужно удалить. В противном случае при старте возникнет ошибка Error during startup: {error,failed_to_initialize_feature_flags_registry}
  4. Если были какие-либо дополнительные настройки в (testit_backend | testit_frontend)/values-override.yaml - перенесите их в соответствующие поля в testit_unichart/values-override.yaml.
  5. Выполните установку продукта через новый Helm-чарт:
    cd <installation_folder>
helm upgrade --install -f testit_unichart/values-override.yaml -n <my-namespace> --create-namespace testit testit_unichart/ --wait --timeout 10m
# Дождитесь начала работы всех компонентов продукта.
watch -n 1 kubectl -n <my-namespace> get pods
  6. Опционально: Выполните восстановление данных (из п.1) с помощью scripts/k8s_restore.sh, если тома памяти не сохранились во время миграции, или замечена потеря данных.

Переход на Alpine в версии 4.6


Развернуть/свернуть инструкцию

Важно

Начиная с версии 4.6.0 в базовых образах сервисов Test IT, а также образах PostgreSQL, InfluxDB, Redis используется версия Alpine. Данное изменение уменьшает фактический размер образов и существенно снижает количество потенциальных уязвимостей контейнеров.

Пользователям PostgreSQL

Если вы используете сервер PostgreSQL из состава поставки Test IT, в процессе обновления для корректной работы сервисов необходимо переиндексировать базы данных в связи с переходом сервера на Alpine и запустить процесс обновления прав доступа (инструкцию читайте ниже).

Обновление прав доступа

  1. Произведите обновление релиза с включением параметра postgres.initPermissions:
    helm upgrade --install testit-backend testit_backend/ -n <namespace> --set postgres.initPermissions=true
    Параметр postgres.initPermissions достаточно использовать один раз при обновлении, позже это действие не потребуется.
  2. После окончания процесса обновления Test IT до 4.6.0 можно исключить init-контейнер из релиза, выполнив повторный запуск обновления:
    helm upgrade --install testit-backend testit_backend/ -n <namespace> --set postgres.initPermissions=false

Действия, описанные ниже, необходимо выполнить после запуска новой версии Test IT, т.е. после выполнения команд helm upgrade в обновлении.

  1. Перейдите в директорию с установочными файлами версии 4.6.0 Kubernetes.
  2. Определите пространство имен (namespace), в котором запущено приложение Test IT:
    kubectl get ns
# Здесь будут отображены доступные пространства имен
  3. Установите право на выполнение скрипта:
    chmod +x scripts/k8s_postgres_reindex_alpine.sh
  4. Запустите скрипт, заменив namespace на свое пространство имен:
    ./scripts/k8s_postgres_reindex_alpine.sh <namespace>
# Пример: ./scripts/k8s_postgres_reindex_alpine.sh my-testit-namespace
  5. Убедитесь, что реиндексация баз данных прошла успешно. По окончании работы скрипта отобразится строка:
    Reindex completed successfully!

В случае ошибки устраните проблему самостоятельно или свяжитесь с технической поддержкой (support@testit.software).

Подготовка к обновлению до версии 4.5


Развернуть/свернуть инструкцию

Пользователям внешних СУБД

Если вы используете внешнюю СУБД (не входящую в поставку), то вместо исполнения скрипта необходимо применить команду очистки базы данных backgrounddb вручную.

Очистка backgrounddb через СУБД из состава поставки посредством скрипта

  1. Перед выполнением скрипта очистки background_db перейдите в директорию, в которой находится папка scripts/:
    cd my-testit-directory
ls
# Здесь должна присутствовать папка scripts/
  2. Определите пространство имен (namespace), в котором запущено приложение Test IT:
    kubectl get ns
# Здесь будут отображены доступные пространства имен
  3. Установите право на выполнение скрипта clean_backgrounddb.sh:
    chmod +x scripts/clean_backgrounddb.sh
  4. Запустите скрипт, заменив <namespace> на свое пространство имен:
    scripts/clean_backgrounddb.sh <namespace> 
# Пример: ./scripts/clean_backgrounddb.sh my-testit-namespace
    Убедитесь, что очистка прошла успешно. По окончании работы скрипта отобразится строка:
     Done! Please proceed to the next update step
    В случае ошибки устраните проблему самостоятельно или свяжитесь с технической поддержкой (support@testit.software).

Очистка backgrounddb во внешней СУБД (не входит в поставку)

При использовании внешней СУБД необходимо подключиться к ней, выбрать базу данных backgrounddb и произвести удаление следующих таблиц:

  • public."SearchItems"
  • public."Resources"
  • public."Projects"
  • public."__EFMigrationsHistory

Чтобы удалить background_db, примените команду:

  DROP TABLE IF EXISTS public."SearchItems", public."Resources", public."Projects", public."__EFMigrationsHistory";
Обновлено: