Перейти к основному содержанию
`Ctrl`+`K`

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

Стандартное обновление - это обновление комплекта приложения (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