Обновление старых версий Test IT в Kubernetes

Внимание

  • Эта инструкция актуальна, если вы разворачивали Test IT в Kubernetes с помощью манифестов.
  • В случае возникновения вопросов, рекомендуем обращаться в техническую поддержку (support@yoonion.ru).

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

Важно

Обновление до версии 4.2 осуществляется с версии 4.1.0 и выше.

Перед обновлением системы выполните следующие действия:

  • Создайте резервную копию системы (рекомендуется).
  • Убедитесь, что в кластере Kubernetes, в котором запущен Test IT, достаточно места для создания файлов дампа Postgres и новых бакетов MiniO.
  • Если вы используете внешнее объектное хранилище MinIO и/или внешнюю СУБД Postgres, а не сервисы из поставки Test IT, пропустите соответствующие разделы этой инструкции.

Миграция бакетов MinIO Kubernetes

Начиная с версии 4.2 MinIO Gateway не поддерживается. Поэтому перед обновлением необходимо выполнить миграцию бакетов MinIO и их метаданных.

  1. Перейдите в директорию с установочными файлами или скопируйте файл scripts/k8s_minio_migrate.sh и папку jobs/minio/migrate в удобную для вас директорию, где будет проходить миграция. Убедитесь, что на диске достаточно места для временного хранения содержимого minio и avatars-minio.

    Внимание

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

    scripts/
        k8s_minio_migrate.sh
    jobs/
        minio/
            migrate/
                job.yaml
                configmap.yaml
                pvc.yaml
    
  2. Добавьте разрешение на использование скрипта:

    chmod +x ./scripts/k8s_minio_migrate.sh
    
  3. Определите пространство имен, в котором у вас запущен Test IT:

    kubectl get ns
    # Здесь будут отображены доступные пространства имен
    
  4. Запустите скрипт, передав ему соответствующее пространство имен:

    ./scripts/k8s_minio_migrate.sh <namespace>
    # Пример: ./scripts/k8s_minio_migrate.sh my-testit-namespace
    # Для более развернутых логов и очистки временных файлов, создаваемых при выполнении скрипта, его можно запустить с флагами -d и -c соответственно.
    # ./scripts/k8s_minio_migrate.sh -d my-testit-namespace
    # или ./scripts/k8s_minio_migrate.sh -c my-testit-namespace
    # или ./scripts/k8s_minio_migrate.sh -dc my-testit-namespace
    

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

    Migration successful!
    

    В случае ошибки миграции логи сохранятся в текущую директорию:

    Job 'job_name' failed. Logs: '/path/to/job_name-dd-mm-yyyy-fail.log'.
    

    В случае ошибки миграции устраните проблему самостоятельно или свяжитесь с технической поддержкой (support@yoonion.ru). По окончании миграции вы можете перейти к процессу миграции баз СУБД Postgres.

Миграция СУБД Postgres

Начиная с версии 4.2 в качестве основной системы управления базами данных (СУБД) используется Postgres 14. В процессе обновления необходимо выполнить дамп ваших баз данных (БД) с предыдущей версии Test IT и их восстановление в новой версии. Во время дампа и восстановления баз данных продукт будет недоступен.

  1. Перейдите в директорию с установочными файлами или скопируйте в другую директорию файлы scripts/k8s_postgres_migrate.sh, scripts/k8s_postgres_migrate.env и папку jobs/postgres, сохраняя следующую структуру:
    scripts/
        k8s_postgres_migrate.sh
    jobs/
        postgres/
            import/
                job.yaml
                configmap.yaml
                pvc.yaml
            export/
                job.yaml
                configmap.yaml
    
  2. Задайте значение переменной, определяющей размер хранилища для .dump файлов баз testitdb, avatarsdb, authdb:
    export DUMP_VOLUME_SIZE_GB=50
    # ПРИМЕЧАНИЕ: данное значение в 50 Gb указано для примера, актуальное значение лучше выбрать в соответствии с действующим размером баз.
    
  3. Добавьте разрешение на использование скрипта:
    chmod +x ./scripts/k8s_postgres_migrate.sh
    
  4. Определите пространство имен, в котором у вас запущен Test IT:
    kubectl get ns
    # Здесь будут отображены доступные пространства имен
    
  5. Запустите скрипт, передав ему соответствующее пространство имен:
    ./scripts/k8s_postgres_migrate.sh <namespace>
    # Пример: ./scripts/k8s_postgres_migrate.sh my-testit-namespace
    # Для более развернутых логов и очистки временных файлов, создаваемых при выполнении скрипта, его можно запустить с флагами -d и -c соответственно.
    # ./scripts/k8s_postgres_migrate.sh -d my-testit-namespace
    # или ./scripts/k8s_postgres_migrate.sh -c my-testit-namespace
    # или ./scripts/k8s_postgres_migrate.sh -dc my-testit-namespace
    
    Убедитесь, что миграция прошла успешно. При успешной миграции по окончании работы скрипта отобразится строка:
    Migration successful! Restarting Test IT...
    
    В случае ошибки миграции отобразится строка:
    Job 'job_name' failed. Logs: '/path/to/job_name-dd-mm-yyyy-fail.log'.
    
    Устраните проблему самостоятельно или свяжитесь с технической поддержкой (support@yoonion.ru).

Обновление

Важно

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

  1. В зависимости от вашей текущей версии Test IT, ознакомьтесь с <old>-<new>_upgrade_plan.yaml (<old> - версия продукта, с которой производится обновление).
  2. Скопируйте старые конфигурационные файлы Kubernetes в папку для новой версии, например:
    mkdir ./TestIT_4.2.4_k8s
    cp ./TestIT_4.1.0_k8s/*.yaml ./TestIT_4.2.4_k8s/
    
  3. В соответствии с upgrage_plan, примените соответствующие изменения к конфигурационным файлам .yaml. Например:
    transfer-service: # <--- Название деплойментa (deployments.yaml)
      image: ...:4.2.4 # <--- новая версия образа
      environment: # Edit configmap # <--- соответствующий деплойментy конфигмап (configmap.yaml)
        + RABBITMQ_SSL_ENABLED: "false" # <--- переменная, которую необходимо добавить/изменить/удалить
    
  4. После успешного выполнения необходимых скриптов/миграций, описанных выше, примените изменения. Например:
    kubectl apply -f ./TestIT_4.2.4_k8s/ --dry-run=client # валидация конфигурации, без каких-либо фактических изменений в кластере
    #                                   ^^ Опционально: можно добавить флаг -oyaml для вывода в терминал будущих объектов k8s
    kubectl apply -f ./TestIT_4.2.4_k8s/ # применение обновления
    
Обновлено: