Оновлення Платформи та реєстрів до версії 1.9.6: спеціальні кроки

1. Мета інструкції

Метою цієї сторінки є відображення процесу оновлення та спеціальних кроків, необхідних для оновлення кластера Платформи та реєстрів з версії 1.9.5.19 до 1.9.6.34.

2. Підготовка кластера Платформи до оновлення

2.1. Створення повної резервної копії простору імен user-management

Оскільки цей реліз передбачає оновлення сервісу Keycloak шляхом його видалення, про всяк випадок обов’язково створіть повний бекап простору імен user-management ДО початку розгортання нової версії Платформи.

Перед створенням бекапу переконайтеся, що ви увійшли до кластера за допомогою команди oc login.
Створення повної резервної копії user-management
$ velero create backup user-management-fresh --include-namespaces user-management

2.2. Видалення застарілих ресурсів

Видаліть застарілий ресурс deploy-templates/templates/KeycloakRealmComponent.yaml та відредагуйте ресурс registry-configuration/deploy-templates/values.yaml у репозиторії registry-configuration.

Виправлення стосується лише реєстрів версії < 1.9.6.

Внесіть необхідні зміни до репозиторію registry-configuration. Для цього виконайте наступні кроки:

  1. Відрийте Openshift-консоль > Projects > control-plane та перейдіть до сервісу gerrit за відповідним роутом.

  2. Знайдіть репозиторій registry-configuration та створіть Merge Request в гілку 1.5.0-SNAPSHOT.161, який має містити видалений файл deploy-templates/templates/KeycloakRealmComponent.yaml та відредагований файл registry-configuration/deploy-templates/values.yaml, як це зображено нижче.

  3. Застосуйте зміни до відповідної гілки — виконайте git merge.

image

2.3. Встановлення актуального розміру диска Nexus для control-plane-nexus

Ця інструкція стосується кластерів, що оновлюються НЕ через пайплайн platform-deploy у Jenkins CICD2.

Якщо розмір вашого диска Nexus у проєкті control-plane-nexus відрізняється від стандартних 100GB, необхідно встановити актуальний розмір диска.

Для цього у конфігураційному файлі repositories/components/infra/control-plane-nexus.git/deploy-templates/values.gotmpl встановіть значення параметра nexus.storage.size, яке дорівнює вашому поточному розміру диска.

3. Оновлення Платформи

3.1. Запуск пайплайну platform-deploy

Запустіть пайплайн platform-deploy в Jenkins CICD2 з опціями оновлення та необхідною версією збірки, а саме 1.9.6.34.

Вкажіть необхідний режим розгортання (deploymentMode).

3.2. Оновлення cluster-mgmt

Цей крок описує стандартний процес оновлення інфраструктурних компонентів Платформи за допомогою пайплайну cluster-mgmt в адміністративній панелі Control Plane.

3.3. Внесення виправлень до скрипту

  1. Після створення Merge Request (MR) оновлення Платформи, внесіть виправлення до скрипту, що знаходиться у scripts/modify_control_plane_version.py. Додайте кодування UTF-8 до параметрів виклику метода open.

    scripts/modify_control_plane_version.py
    with open(values_file, 'r', encoding="utf-8") as file:

    Скрипт повинен мати наступний вигляд:

    image

    Зображення демонструє зміни, що були внесені вже після злиття Merge Request оновлення Платформи.
  2. Продовжіть оновлення Платформи шляхом підтвердження злиття MR.

4. Кроки після оновлення Платформи

4.1. Налаштування Cleanup Job

Після успішного оновлення Платформи, через оновлення версії Istio з версії 1.10 до 1.18, для реєстрів на версії 1.9.5 не працюватиме Cleanup Job.

Ця проблема пов’язана з помилкою в Istio версії 1.10: https://github.com/istio/istio/issues/26882.
Istio призначав неправильну групу "1337" для томів, приєднаних до поду. У версії 1.18 ця помилка була виправлена, але зазначена група залишилася. Щоб виправити це, потрібно додати init-контейнер до деплоймента компонента registry-regulation-management.

Для усунення цієї проблеми, в наявних реєстрах ЛИШЕ версії 1.9.5 виконайте наступні кроки:

  1. Перейдіть до gerrit у проєкті control-plane.

  2. Оберіть репозиторій registry-regulation-management та внесіть зміни до гілки, яка відповідає версії Платформи 1.9.5.

    Приклад:

    image

    1. У маніфест deploy-templates/templates/deployment.yaml за шляхом .spec.template.spec додайте наступний код для створення init-контейнера, що змінить групу на актуальну:

      Deployment config
      initContainers:
        - name: setup-permissions
          image: "{{ .Values.image.name }}:{{ .Values.image.version }}"
          command: ["sh", "-c", "chown -R 1001:1001 {{ .Values.gerrit.repositoryDirectory }}"]
          volumeMounts:
            - name: repositories-data
              mountPath: {{ .Values.gerrit.repositoryDirectory }}
          securityContext:
            runAsUser: 0
    2. Після додавання блоку коду, маніфест deployment.yaml повинен виглядати наступним чином:

      image

  3. Після додавання блоку коду до маніфесту, перезапустіть кожен MASTER-Build-<registry-name> пайплайн для реєстру, який відповідає версії 1.9.5.

    <registry-name> — назва реєстру.

Після успішного запуску Build-пайплайну, CleanUp Job відновить свою працездатність.

Якщо на кластері існує багато реєстрів версії 1.9.5, і перезапуск кожної збірки Jenkins-пайплайну займає багато часу, можна використати наступний bash-скрипт для оновлення deployment-конфігурації сервісу registry-regulation-management без оновлення реєстру через Jenkins-пайплайн.

Зверніть увагу, що цей скрипт вносить патчі до deployment-конфігурації усіх реєстрів. Якщо виключити деякі реєстри із процесу, їх можна додати у поле --field-selector .

image
Зображення 1. Приклад виключення реєстру abc-01 із процесу внесення патчу:
Скрипт patching-deployment.sh внесення патчів до deployment-конфігурації компонента registry-regulation-management
#!/bin/bash
for registry in $(oc get codebases -n control-plane --no-headers -o custom-columns=":metadata.name" --field-selector=metadata.name!=cluster-mgmt); do
  echo "Patching ${registry}"
  oc patch deployment registry-regulation-management-deployment -n ${registry} -p '{"spec":{"template":{"spec":{"initContainers": [{"name": "setup-permissions", "image": "docker-registry.control-plane-nexus.svc:5004/control-plane/registry-regulation-management-master:1.9.5.8", "command": ["sh", "-c", "chown -R 1001:1001 /var/lib/repos-data"], "volumeMounts": [{"name": "repositories-data", "mountPath": "/var/lib/repos-data"}], "securityContext": {"runAsUser": 0}}]}}}}'
done
image
Зображення 2. Приклад запуску скрипту із попереднім входом через oc cli

4.2. Оновлення анотації для reloader env.js у компоненті common-web-app

Після оновлення Платформи та перед оновленням реєстру виконайте наступні кроки:

  1. Перейдіть у центральний Gerrit.

  2. Відкрийте Browse > Repositories > common-web-app.

  3. Перейдіть у розділ Commands та натисніть Create change.

  4. Оберіть версію 1.9.4.96 common-web-app, з котрою відбувалося оновлення, впишіть опис змін та натисніть на створення нового CRD.

  5. У новому вікні натисніть Edit > ADD/OPEN/UPLOAD.

  6. Оберіть файл deploy-templates/templates/deployment.yaml.

  7. Додайте замість наявної анотації configmap.reloader.stakater.com/reload: "environment-js" нову (як показано нижче) та збережіть зміни.

    configmap.reloader.stakater.com/reload: "environment-js-{{ $portal.name }}"

    image

  8. Натисніть START REVIEW > Code-Review +2 > Verified +1 > SEND AND START REVIEW > Submit.

4.3. Застосування hotfix для реєстрів версії 1.9.5

  1. Перейдіть до Gerrit у проєкті control-plane.

  2. Відкрийте репозиторій edp-library-stages-fork та внесіть зміни в гілку build/0.2.1-SNAPSHOT.395 (Commands > Create change).

    image

  3. Натисніть у новому вікні Edit > ADD/OPEN/UPLOAD.

  4. Оберіть файл src/com/epam/edp/customStages/impl/cd/DeployViaHelmfile.groovy та внести зміну у рядок 326, зокрема додайте знак символ ? (знак питання) та натисніть Save.

    image

  5. Оберіть файл src/com/epam/edp/customStages/helper/DeployHelper.groovy та внести зміну у рядок 605, а саме видаліть символ ! (знак оклику), та натисніть Save and Publish.

    image

  6. Проставте оцінки +2 Code Review та +1 Verified та виконайте git merge змін.

4.4. Застосувати фікс для реєстрів 1.9.6

  1. Перейдіть до Gerrit у проєкті control-plane.

  2. Оберіть репозиторій edp-library-stages-fork та внесіть зміни в гілку build/0.2.1-SNAPSHOT.418 (Commands > Create change).

    image

  3. Натисніть у новому вікні Edit > обрати ADD/OPEN/UPLOAD.

  4. Обрати файл src/com/epam/edp/customStages/helper/DeployHelper.groovy та внесіть зміну у рядок 607, зокрема видаліть символ ! (знак оклику), та натисніть Save and Publish.

    image

  5. Проставте оцінки +2 Code Review, +1 Verified та виконайте git merge змін.

5. Оновлення реєстру

  1. Оновіть реєстр до нової версії відповідно до інструкції Оновлення компонентів реєстру

  2. Перейдіть до застосування хотфіксів, описаних нижче.

5.1. Push бібліотеки сервісів даних до центрального сховища артефактів Nexus

Виконайте push бібліотеки сервісів по роботі з даними до центрального сховища артефактів control-plane-nexus.

У helmfile.yaml прописувати їх не потрібно.
Список образів
model-core-base-image-1-9-6-hotfix:1.9.4-1.9.6-HOTFIX-SNAPSHOT.1
kafka-api-core-base-image-1-9-6-hotfix:1.9.4-1.9.6-HOTFIX-SNAPSHOT.1
rest-api-core-base-image-1-9-6-hotfix:1.9.6-1.9.6-HOTFIX-SNAPSHOT.1
soap-api-core-base-image-1-9-6-hotfix:1.9.4-1.9.6-HOTFIX-SNAPSHOT.1

5.2. Застосування hotfix-образів для компонентів реєстру

Застосуйте наступні hotfix-образи для відповідних компонентів реєстру у helmfile.yaml реєстру.

bpms:
1.9.7-1.9.6-HOTFIX-SNAPSHOT.1
dataplatform-jenkins-agent:
1.9.6-1.9.6-HOTFIX-SNAPSHOT.5
common-web-app:
1.9.6-MDTUDDM-27852-HOT-FIX-SNAPSHOT.3

5.3. Послідовність роботи з pull і push хотфікс-образів

Завантажити образи можна за посиланням: https://hub.docker.com/u/uss2jelastic. Для цього потрібно мати встановлений Docker https://docs.docker.com/engine/install/.

Послідовність роботи з pull і push хотфікс-образів:

  1. Виконайте pull.

    docker pull <your-repo-name>/<image-name>:tag

    Наприклад:

    docker pull uss2jelastic/kafka-api-core-base-image-1-9-6-hotfix
    У Dockerhub кожний репозиторій надає приклад, як робити pull.

    special steps 1 9 6 13

  2. Після pull на локальну машину, змініть тег образа.

    docker image tag <your-repo-name>/<image-name>:tag localregistry:5000/control-plane/<image-name>:tag
    Список тегів для хотфіксів даного релізу
    docker image tag uss2jelastic/model-core-base-image-1-9-6-hotfix:1.9.4-1.9.6-HOTFIX-SNAPSHOT.1 localregistry:5000/control-plane/model-core-base-image-1-9-6-hotfix:1.9.4-1.9.6-HOTFIX-SNAPSHOT.1
    docker image tag uss2jelastic/kafka-api-core-base-image-1-9-6-hotfix:1.9.4-1.9.6-HOTFIX-SNAPSHOT.1 localregistry:5000/control-plane/kafka-api-core-base-image-1-9-6-hotfix:1.9.4-1.9.6-HOTFIX-SNAPSHOT.1
    docker image tag uss2jelastic/rest-api-core-base-image-1-9-6-hotfix:1.9.6-1.9.6-HOTFIX-SNAPSHOT.1 localregistry:5000/control-plane/rest-api-core-base-image-1-9-6-hotfix:1.9.6-1.9.6-HOTFIX-SNAPSHOT.1
    docker image tag uss2jelastic/soap-api-core-base-image-1-9-6-hotfix:1.9.4-1.9.6-HOTFIX-SNAPSHOT.1 localregistry:5000/control-plane/soap-api-core-base-image-1-9-6-hotfix:1.9.4-1.9.6-HOTFIX-SNAPSHOT.1
    docker image tag uss2jelastic/bpms-1-9-6-hotfix:1.9.7-1.9.6-HOTFIX-SNAPSHOT.1 localregistry:5000/control-plane/bpms-1-9-6-hotfix:1.9.7-1.9.6-HOTFIX-SNAPSHOT.1
    docker image tag uss2jelastic/dataplatform-jenkins-agent-1-9-6-hotfix:1.9.6-1.9.6-HOTFIX-SNAPSHOT.5 localregistry:5000/control-plane/dataplatform-jenkins-agent-1-9-6-hotfix:1.9.6-1.9.6-HOTFIX-SNAPSHOT.5
    docker image tag uss2jelastic/common-web-app-master:1.9.6-MDTUDDM-27852-HOT-FIX-SNAPSHOT.3 localregistry:5000/control-plane/common-web-app-master:1.9.6-MDTUDDM-27852-HOT-FIX-SNAPSHOT.3
  3. Після встановлення тегу виконайте push.

    1. Виконайте вхід до Платформи за допомогою oc cli. Токен можна отримати через Openshift-консоль, у секції Copy login command.

      special steps 1 9 6 14

    2. Якщо ви користуєтеся Windows, то внесіть наступний запис до файлу C:\Windows\System32\drivers\etc\hosts, якщо linux — то запис потрібно зробити в /etc/hosts.

      127.0.0.1 localregistry
    3. Відкрийте декілька терміналів, в одному переадресуйте порти на под nexus, який можна знайти у проєкті control-plane-nexus в Openshift > Workloads > Pods.

      oc port-forward <nexus-pod-name> 5000:5000 -n control-plane-nexus
    4. Виконайте вхід в nexus.

      Пароль можна знайти у секреті nexus-admin-password проєкту control-plane-nexus.
      docker login -u admin -p <secret-password> localregistry:5000
    5. Переконайтеся, що вхід успішний. Після цього можна виконати push. Це може зайняти певний час.

      Пам’ятайте, що в іншому терміналі повинна бути активною переадресація портів.
      docker push localregistry:5000/control-plane/image_name:tag
    6. Після цього ваш образ з’явиться в nexus. Туди можна перейти через Openshift > Networking > Routes > nexus у проєкті control-plane-nexus. Всі образи знаходяться у Browse > docker-registry.

      special steps 1 9 6 15

  4. Застосуйте необхідні nexus-образи до реєстру.

    У control-plane-gerrit знайдіть репозиторій реєстру і в його гілці master внесіть зміни до файлу deploy-templates/helmfile.yaml. При зміні образа вкажіть версію і шлях до папки з образом, як в nexus:

    bpms:

    special steps 1 9 6 16

    common-web-app:

    special steps 1 9 6 17

    dataplatform-jenkins-agent:

    special steps 1 9 6 18

    Приклад deploy-templates/helmfile.yaml для компонента dataplatform-jenkins-agent
    - name: dataplatform-jenkins-agent
      namespace: '{{ env "NAMESPACE" }}'
      labels:
        type: remote
        update_scc: false
        repoURL: ssh://jenkins@gerrit.mdtu-ddm-edp-cicd:32114/mdtu-ddm/data-architecture/devops-application/dataplatform-jenkins-agent.git
        path: components/registry/
        branch: 1.9.6.24
      chart: /opt/repositories/dataplatform-jenkins-agent/deploy-templates
      version: 1.9.6-1.9.6-HOTFIX-SNAPSHOT.2
      values:
      - values.yaml
      - values.gotmpl
      - image:
          name: '{{ env "edpComponentDockerRegistryUrl" }}/{{ env "globalEDPProject" }}/dataplatform-jenkins-agent-1-9-6-hotfix'
          version: 1.9.6-1.9.6-HOTFIX-SNAPSHOT.2
      missingFileHandler: Warn
      needs:
      - '{{ env "NAMESPACE" }}/istio-configuration'
      - '{{ env "NAMESPACE" }}/network-management'
      - '{{ env "NAMESPACE" }}/keycloak-operator'
      - '{{ env "NAMESPACE" }}/gerrit-operator'
      - '{{ env "NAMESPACE" }}/jenkins-operator'
      - '{{ env "NAMESPACE" }}/registry-configuration'
У цьому релізі при зміні образу гілки міняти НЕ ПОТРІБНО.
Після встановлення хотфіксів потрібно перезібрати модель даних реєстру.

6. Відомі проблеми

Проблема:

Залишається вимкненим перемикач "Самостійна реєстрація користувачів" у Control Plane після вмикання та підтвердження Merge Request.

Тимчасове рішення:

Необхідно перейти до редагування реєстру > вкладка авторизації надавачів послуг > ввімкнути та вимкнути перемикач на інтерфейсі та підтвердити зміни.