Перейти к основному содержимому

Обновление

примечание

В данном разделе описан гайд по миграции на версию 3.0.0

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

  1. Развертывание Liquibase на репозитарную БД консоли GRDL.
  2. Развертывание консоли GRDL.
  3. Развертывание UI.
  4. Развертывание воркеров.
примечание

Для корректной работы при обновлении системы с несколькими плечами и балансировщиком необходимо, чтобы балансировщик не нарушал порядок обновления.

Пример некорректной конфигурации
Балансировщик стоит между UI и двумя плечами с консолью GRDL. Тогда при обновлении UI и первого плеча с консолью GRDL автоматически нарушается порядок обновления на втором плече с консолью GRDL.

Пример корректной конфигурации
Балансировщик стоит между пользователем и двумя плечами с UI и консолью GRDL. Тогда при обновлении любого из плечей нет воздействия на другое плечо.

Сценарий обновления консоли GRDL​

Проверка готовности БД GRDL к обновлению​

подсказка

При установке компонента GRDL с нуля, воспользуйтесь Руководством по установке.

  1. Существует пользователь (роль) и схема gdl в БД модуля управления и ему выданы необходимые права
  2. Созданы tablespace grdl_ts_data и grdl_ts_idx

Шаги обновления​

  1. Запустите сценарий (playbook) DB_UPDATE перед установкой консоли, для обновления БД консоли.

  2. Удалите конфигурационные файлы k8s GraDeLy. Для этого выполните развертывание через cd пайплайн.

    Для подсистем SUBSYSTEM: GRDL_CONSOLE_FULL:

    1. Выберите версию дистрибутива DISTRIB_VERSION: <Предыдущая версия дистрибутива>.

    2. Выберите список сценариев для установки дистрибутива:

      MIGRATION_FP_CONF;
      FP_CONF_CHECK;
      KUBERNETES_PURGE_PROJECT
    подсказка

    Если сценарий KUBERNETES_PURGE_PROJECT недоступен для cd пайплайна, удалите объекты k8s, принадлежащие компоненту GraDeLy, вручную.

  3. Разверните новую версию GraDeLy через cd пайплайн.

    Для подсистем SUBSYSTEM: GRDL_CONSOLE_FULL:

    1. Выберите версию дистрибутива DISTRIB_VERSION: <Новая версия дистрибутива>.

    2. Выберите список сценариев для установки дистрибутива:

      DB_UPDATE
      MIGRATION_FP_CONF;
      FP_CONF_CHECK;
      OPENSHIFT_DEPLOY
      OPENSHIFT_INGRESS_EGRESS_DEPLOY
    подсказка

    Сценарий DB_UPDATE выполните для подсистем GRDL_CONSOLE. Для GRDL_CONSOLE установите в cd пайплайне значение ключа worker_db_flag: "NO".

Проверка обновления​

Проверьте статус приложения при помощи healthcheck (подробнее в разделе «Проверка работоспособности») по завершении обновления.

Сценарий обновления GraDely Worker в K8s середе​

Внимание!

Этот сценарий обновления для ситуаций, когда между версиями соблюдается обратная совместимость. GraDeLy гарантирует совместимость версий релизов.

Проверка готовности клиентской БД к обновлению​

Выполните шаги раздела Подготовка БД источника и БД приемника для работы с GraDeLy.

Проверка готовности Kafka к обновлению​

Выполните шаги раздела Kafka-топики в GraDeLy.

Шаги обновления​

  1. Требуется подготовить subsystems.json добавив него новые SUBSYSTEM пример:

    Для установки компонента RPLW (module)

    "<RPLW_SUBSYSTEM>": {
    "fpType": "<fpType>",
    "fpi_name": "rplw",
    "nexus_repo": "<nexus_repo>",
    "groupId": "<groupId>",
    "artifactId": "rplw-cfg",
    "versionFilter": "D-*",
    "fpi_name_ose": "rplw",
    "app_name": ["rplw-module"],
    "registryPath": "<registryPath>"
    },
  2. Сделайте back-up базы данных.

  3. Удалите предыдущую версию приложения, чтобы не было одновременно работающих серверов разных релизов (подробнее в разделе «Удаление»).

  4. Выполните шаги из раздела Установка RPLW в DropApp.

    примечание

    Особенности обновления компонента RPLW с релизов до 2.3.x:

    • Если установка RPLW будет производиться в namespace module предыдущих релизов, то перед этим потребуется очистить этот namespace от манифестов предыдущих релизов.
    • Если установка RPLW будет производиться в новый namespace то его требуется настроить в соответствии с namespace где был развернут module.
  5. Проверяйте версию дистрибутива вручную через label(version) прикладных подов или через командную строку администратором (например kubectl get pods -l version=D-2.0.0-XXX выведет все поды версии).

Проверка обновления​

Проверьте статус приложения при помощи healthcheck (подробнее в разделе «Проверка работоспособности») по завершении обновления.

Сценарий обновления GraDely Worker на VM​

Обновление с помощью Playbook​

  1. В директории Ansible, из которой выполнялось развертывание выполните запуск Playbook обновления. Для этого:

    ansible-playbook update.yml --ask-vault-pass
  2. Дождитесь результата выполнения Playbook.

Ручное обновление​

Шаги обновления​

Важно

Сценарий выполняется от суперпользователя. Перед заменой всегда создавайте back-up текущей версии.

  1. Подготовьте файлы нужной версии.

    Скачайте обновленную версию .jar и (опционально) конфигурационных файлов на целевую VM.

  2. Остановите сервис. Для этого:

    systemctl stop grdlw.service 2>/dev/null || true
  3. Создайте back-up файлов текущей версии. Для этого:

    cp -p /opt/cdc/grdlw/bin/grdlw.jar /opt/cdc/grdlw/bin/grdlw.jar.bak.$(date +%F) 2>/dev/null || true
    cp -p /opt/cdc/grdlw/conf/grdlw.properties /opt/cdc/grdlw/conf/grdlw.properties.bak.$(date +%F) 2>/dev/null || true
  4. Подмените файл /opt/cdc/grdlw/bin/grdlw.jar на файл нужной версии. Для этого:

    rm -f /opt/cdc/grdlw/bin/grdlw.jar
    mv <path/to/new/grdlw.jar> /opt/cdc/grdlw/bin/grdlw.jar

    chown grdl:grdl /opt/cdc/grdlw/bin/grdlw.jar
    chmod 640 /opt/cdc/grdlw/bin/grdlw.jar
  5. В случае если изменилась конфигурация, добавьте файл нужной версии в директорию с конфигурацией. Для этого:

    rm -f /opt/cdc/grdlw/conf/grdlw.properties
    mv <path/to/new/grdlw.properties> /opt/cdc/grdlw/conf/grdlw.properties

    chown grdl-svc:grdl-svc /opt/cdc/grdlw/conf/grdlw.properties
    chmod 640 /opt/cdc/grdlw/conf/grdlw.properties

    Для файла logback.xml шаг выполняется аналогично.

  6. Запустите сервис. Для этого:

    systemctl start grdlw.service

Изменения в параметрах настройки​

Изменения в параметрах настройки воркеров​

Если миграция осуществляется с релиза раньше 2.3.1, необходимо учесть актуальную логику работы с метками.

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