Обновление системы

Обновление системы#

Стандартное обновление - это обновление комплекта приложения (appkit) с применением изменений так, что сервер приложений перезапускается, а пользователи отключаются на время перезапуска.

Как правило, применяется когда меняется хотя бы один из компонентов:

  • globalserver.zip (сервер приложений)

  • profile.zip (профиль конфигурации)

  • applib.zip (прикладное решение)

  • а также когда требуется обновление схемы БД.

Горячее обновление - режим, при котором можно обновить только прикладное решение без отключения пользователей и без перезапуска серверов, но при строгих условиях:

  • включён флаг hot_reload: true в группе ресурсов (resgroup);

  • меняется только applib.zip (и опционально appsrc), а globalserver.zip и profile.zip остаются без изменений;

  • если в рамках обновления требуется миграция/обновление схемы БД, поведение зависит от настройки «осушения» кластера перед обновлением БД (drain_cluster_before_db_upgrade).

Внимание

Если вы запускаете обновление схемы БД при включённом drain_cluster_before_db_upgrade: true, пользователи будут отключены на время обновления БД, даже если горячее обновление включено.

Стандартное обновление#

Вариант A. С использованием nscli#

  1. Для обновления комплекта приложения (appkit: сервера приложений, прикладного решения) подготовьте его и загрузите на NFS-хранилище:

    ./appkit.sh push --namespace gs-ctk --source workspace/appkit --destination appkit/v2

    • --namespace gs-ctk - пространство имен, в котором развертан gs-ctk.

    • --source workspace/appkit - путь к папке с комплектом на локальной ФС относительно текущей папки.

    • --destination appkit/v2 - путь к папке, в которую следует поместить комплект, относительно точки монтирования системного хранилища.

  2. Обновите хеши и пути к комплекту приложения (appkit) в конфигурации при помощи команды:

    # не требует подключения к кластеру, хеши будут посчитаны с комплекта приложений на локальном диске
./appkit.sh switch_local --config-path ./config.yaml --resgroup gs-cluster-1 --local-appkit workspace/appkit --remote-appkit appkit/v2

    • --config-path ./config.yaml - путь к конфигурационному ресурсу.

    • --resgroup gs-cluster-1 - название группы ресурсов.

    • --local-appkit workspace/appkit - путь к папке с комплектом на локальной ФС относительно текущей папки (--source из предыдущего пункта).

    • --remote-appkit appkit/v2 - путь к папке на системном хранилище, в котором находится комплект (--destination из предыдущего пункта).

    ИЛИ

    # хеши читаются с комплекта приложений на хранилище в кластере, следовательно требует подключения к кластеру
./appkit.sh switch_remote --config-path ./config.yaml --resgroup gs-cluster-1 --namespace gs-ctk --remote-appkit appkit/v2

    • --config-path ./config.yaml - путь к конфигурационному ресурсу.

    • --resgroup gs-cluster-1 - название группы ресурсов.

    • --namespace gs-ctk - пространство имен, в котором развертан gs-ctk.

    • --remote-appkit appkit/v2 - путь к папке на системном хранилище, в котором находится комплект (--destination из предыдущего пункта).

  3. Переключите показатель версии базы данных database_schema_version, чтобы запустить обновление базы данных при следующем применении ресурса:

    ./appkit.sh upgrade --config-path ./config.yaml --resgroup gs-cluster-1

  4. Повторно примените ресурс:

    kubectl apply -f ./config.yaml

Совет

Для отслеживания статуса обновления и чтения логов, используйте команду:

./appkit.sh wait_upgrade --namespace gs-ctk --resgroup gs-cluster-1

Вариант B. Без nscli (вручную)#

Этот вариант делает то же самое по сути, но без использования утилиты.

  1. Сформируйте комплект приложения

    Необходимо подготовить три zip-архива:

    • globalserver.zip

    • applib.zip

    • profile.zip

    Внимание

    Архивы должны содержать содержимое соответствующих папок, а не саму папку верхнего уровня (то есть внутри applib.zip лежат модули, а не директория applib/ целиком).

  2. Сгенерируйте sha1-файлы рядом с архивами

    Рядом с каждым архивом должен лежать файл *.sha1 с sha1-суммой (строка без лишних символов).

    Пример скрипта:

    for archive in appkit/*.zip
do
  sha1sum < "$archive" | tr -d ' -' | tr -d '\n' > "$archive.sha1"
done

  3. Загрузите архивы и .sha1 на системное NFS-хранилище

    Загрузите в новый каталог вида appkit/v2 (необходимо сделать инкремент текущей версии appkit).

  4. Обновите конфигурацию

    В конфигурационном ресурсе обновите:

    • путь к комплекту (path)

    • хеши: applib_sha1, appsrc_sha1 (если используется), globalserver_sha1, profile_sha1

    • счётчики: globalserver_instance и database_schema_version

  5. Примените ресурс:

    kubectl apply -f config.yaml

Горячее обновление#

Горячее обновление имеет смысл, когда меняется только applib.zip (и/или appsrc), а globalserver.zip и profile.zip остаются прежними. Иначе необходимо использовать стандартное обновдение.

Функция управляется параметрами в GlobalConfiguration:

apiVersion: global-system.ru/v1
kind: GlobalConfiguration
metadata:
  name: config
spec:
  resgroups:
    - hot_reload: true
      drain_cluster_before_db_upgrade: false

Ключевые параметры:

  • hot_reload

    • true - разрешает горячее обновление, если изменяется только applib.zip, а сервер приложений (globalserver.zip) и профиль (profile.zip) остаются без изменений. Обновления применяется без перезапуска серверов.

    • false - любое обновление приводит к перезапуску и отключению пользователей

  • drain_cluster_before_db_upgrade

    • true (рекомендуется, по умолчанию) - перед обновлением БД кластер «осушается» (новые соединения не принимаются, текущие завершаются). Это гарантирует согласованность данных и отсутствие конфликтов.

    • false - Обновление БД выполняется в фоне, пока пользователи продолжают работу.

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

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

Примечание

Если вы инициируйте обновление БД при помощи ./appkit.sh upgrade при включенном осушении кластера (drain_cluster_before_db_upgrade = true), то пользователи будут отключены на время обновления БД независимо от того, включено горячее обновление (hot_reload) или нет.

Вариант A. Горячее обновление с использованием nscli#

  1. Включите hot reload и настройте «осушение»:

    Используйте интерактивный мастер для настройки параметров группы ресурсов:

    ./configmgr.sh configure_resgroup --config-path config.yaml --resgroup gs-cluster-1

    Настройка группы ресурсов: gs-cluster-1
=======================================

...
Включить горячие обновления?[да,нет]:да
Осушать кластер перед запуском обновления?[да,нет]:нет
...

    Или точечно командами:

    # Включение/выключение горячего обновления
./appkit.sh allow_hot_reload --config-path config.yaml --resgroup gs-cluster-1
./appkit.sh disallow_hot_reload --config-path config.yaml --resgroup gs-cluster-1

# Управление осушением кластера перед обновлением БД
./appkit.sh drain_before_upgrade --config-path config.yaml --resgroup gs-cluster-1
./appkit.sh do_not_drain_before_upgrade --config-path config.yaml --resgroup gs-cluster-1

  2. Загрузите на хранилище обновленные компоненты:

    Для того, чтобы скопировать на сетевое хранилище только нужные компоненты (например, только прикладное решение), используйте аргумент --items команды ./appkit.sh push:

    ./appkit.sh push --namespace gs-ctk --source workspace/appkit --destination appkit/v2 --items applib,appsrc

  3. Обновите хеши компонентов в конфигурационном файле:

    ./appkit.sh switch_remote --config-path ./config.yaml --resgroup gs-cluster-1 --namespace gs-ctk --remote-appkit appkit/v2

  4. Обновите целевую версию схемы:

    ./appkit.sh upgrade --config-path ./config.yaml --resgroup gs-cluster-1

  5. Примените ресурс:

    kubectl apply -f config.yaml

После этого начнётся обновление прикладного решения (и при необходимости БД) в соответствии с выбранными флагами.

Вариант B. Горячее обновление без nscli (вручную)#

  1. Включите hot reload и настройте «осушение» в GlobalConfiguration.

  2. Сформируйте архив applib.zip (и при необходимости appsrc).

  3. Сгенерируйте applib.zip.sha1 рядом с архивом (пример скрипта тот же, что и в обычном обновлении).

  4. Загрузите архив и applib.zip.sha1 на системное NFS-хранилище.

  5. В конфигурационном ресурсе обновите:

    • путь к комплекту (path);

    • applib_sha1 (и appsrc_sha1, если используется appsrc);

    • счётчики: globalserver_instance и database_schema_version

  6. Примените ресурс:

    kubectl apply -f config.yaml

Режимы обновления базы данных#

Есть два режима обновления базы данных:

  • Через запуск мигратора на поде global_server_excl по команде nsctl.

  • Через ресурс Kubernetes типа Job с запуском отдельного пода.

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

  1. Процесс обновления запускается через nsctl, но не зависит от него.

  2. Запуск временного сервера приложения позволяет изолировать ошибки, связанные с нагоном релиза.

В будущем, запуск через Job заменит собой запуск мигратора на поде global_server_excl.

Чтобы выбрать режим, используйте интерактивный мастер для настройки параметров группы ресурсов:

./configmgr.sh configure_resgroup --config-path config.yaml --resgroup gs-cluster-1

Настройка группы ресурсов: gs-cluster-1
=======================================

...
Включить обновление при помощи ресурса Kubernetes типа Job?[да,нет]:да
Укажите размер кучи Java (Xmx) для Job обновления:3500M
Введите запрос CPU для globalserver:2
Введите запрос MEMORY для globalserver:4G
Введите лимиты CPU для globalserver:2
Введите лимиты MEMORY для globalserver:4G
Введите запрос CPU для systemagent:1
Введите запрос MEMORY для systemagent:250M
Введите лимиты CPU для systemagent:1
Введите лимиты MEMORY для systemagent:500M
...

Режим также можно изменить, установив значение параметра группы ресурсов upgrade_job.enabled в true или false.

При включенном обновлении через Job после выполнения ./appkit.sh upgrade (или изменения параметра группы ресурсов database_schema_version другим способом) и применения конфигурационного ресурса, nsctl должен удалить старый Job вместе с созданным им подом, и создать новый.

Job и под обновления можно определить по метке (label) global-system.ru/is-upgrade-job-pod-for, значение которого соответствует названию группы ресурсов. Название Job состоит из префикса upgrade-job- и названия группы ресурсов, например, upgrade-job-gs-cluster-1.

Обновление кластерных утилит#

  1. Загрузите и распакуйте новую версию nscli и Helm-чарт

  2. Обновите, используя созданный ранее values.yaml:

    helm upgrade gs-ctk ~/nscli/helm_chart -f values.yaml
Содержание