Оновлення Платформи та реєстрів до версії 1.9.6: спеціальні кроки
1. Мета інструкції
Метою цієї сторінки є відображення процесу оновлення та спеціальних кроків, необхідних для оновлення кластера Платформи та реєстрів з версії 1.9.5.19
до 1.9.6.34
.
2. Підготовка кластера Платформи до оновлення
2.1. Створення повної резервної копії простору імен user-management
Оскільки цей реліз передбачає оновлення сервісу Keycloak шляхом його видалення, про всяк випадок обов’язково створіть повний бекап простору імен user-management
ДО початку розгортання нової версії Платформи.
Перед створенням бекапу переконайтеся, що ви увійшли до кластера за допомогою команди oc login .
|
$ 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. Для цього виконайте наступні кроки:
-
Відрийте Openshift-консоль > Projects >
control-plane
та перейдіть до сервісуgerrit
за відповідним роутом. -
Знайдіть репозиторій registry-configuration та створіть Merge Request в гілку
1.5.0-SNAPSHOT.161
, який має містити видалений файл deploy-templates/templates/KeycloakRealmComponent.yaml та відредагований файл registry-configuration/deploy-templates/values.yaml, як це зображено нижче. -
Застосуйте зміни до відповідної гілки — виконайте
git merge
.
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. Внесення виправлень до скрипту
-
Після створення Merge Request (MR) оновлення Платформи, внесіть виправлення до скрипту, що знаходиться у scripts/modify_control_plane_version.py. Додайте кодування
UTF-8
до параметрів виклику методаopen
.scripts/modify_control_plane_version.pywith open(values_file, 'r', encoding="utf-8") as file:
Скрипт повинен мати наступний вигляд:
Зображення демонструє зміни, що були внесені вже після злиття Merge Request оновлення Платформи. -
Продовжіть оновлення Платформи шляхом підтвердження злиття 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
виконайте наступні кроки:
-
Перейдіть до gerrit у проєкті
control-plane
. -
Оберіть репозиторій registry-regulation-management та внесіть зміни до гілки, яка відповідає версії Платформи
1.9.5
.Приклад:
-
У маніфест deploy-templates/templates/deployment.yaml за шляхом .spec.template.spec додайте наступний код для створення init-контейнера, що змінить групу на актуальну:
Deployment configinitContainers: - 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
-
Після додавання блоку коду, маніфест deployment.yaml повинен виглядати наступним чином:
-
-
Після додавання блоку коду до маніфесту, перезапустіть кожен MASTER-Build-
<registry-name>
пайплайн для реєстру, який відповідає версії1.9.5
.<registry-name>
— назва реєстру.
Після успішного запуску Build-пайплайну, CleanUp Job відновить свою працездатність.
Якщо на кластері існує багато реєстрів версії Зверніть увагу, що цей скрипт вносить патчі до deployment-конфігурації усіх реєстрів. Якщо виключити деякі реєстри із процесу, їх можна додати у поле ![]() Зображення 1. Приклад виключення реєстру abc-01 із процесу внесення патчу:
Скрипт patching-deployment.sh внесення патчів до deployment-конфігурації компонента
registry-regulation-management
![]() Зображення 2. Приклад запуску скрипту із попереднім входом через
oc cli |
4.2. Оновлення анотації для reloader env.js у компоненті common-web-app
Після оновлення Платформи та перед оновленням реєстру виконайте наступні кроки:
-
Перейдіть у центральний Gerrit.
-
Відкрийте Browse > Repositories > common-web-app.
-
Перейдіть у розділ Commands та натисніть
Create change
. -
Оберіть версію
1.9.4.96
common-web-app, з котрою відбувалося оновлення, впишіть опис змін та натисніть на створення нового CRD. -
У новому вікні натисніть
Edit
>ADD/OPEN/UPLOAD
. -
Оберіть файл deploy-templates/templates/deployment.yaml.
-
Додайте замість наявної анотації
configmap.reloader.stakater.com/reload: "environment-js"
нову (як показано нижче) та збережіть зміни.configmap.reloader.stakater.com/reload: "environment-js-{{ $portal.name }}"
-
Натисніть
START REVIEW
>Code-Review +2
>Verified +1
>SEND AND START REVIEW
>Submit
.
4.3. Застосування hotfix для реєстрів версії 1.9.5
-
Перейдіть до Gerrit у проєкті
control-plane
. -
Відкрийте репозиторій edp-library-stages-fork та внесіть зміни в гілку
build/0.2.1-SNAPSHOT.395
(Commands >Create change
). -
Натисніть у новому вікні
Edit
>ADD/OPEN/UPLOAD
. -
Оберіть файл src/com/epam/edp/customStages/impl/cd/DeployViaHelmfile.groovy та внести зміну у рядок
326
, зокрема додайте знак символ?
(знак питання) та натиснітьSave
. -
Оберіть файл src/com/epam/edp/customStages/helper/DeployHelper.groovy та внести зміну у рядок
605
, а саме видаліть символ!
(знак оклику), та натиснітьSave and Publish
. -
Проставте оцінки
+2 Code Review
та+1 Verified
та виконайтеgit merge
змін.
4.4. Застосувати фікс для реєстрів 1.9.6
-
Перейдіть до Gerrit у проєкті
control-plane
. -
Оберіть репозиторій edp-library-stages-fork та внесіть зміни в гілку
build/0.2.1-SNAPSHOT.418
(Commands >Create change
). -
Натисніть у новому вікні
Edit
> обратиADD/OPEN/UPLOAD
. -
Обрати файл src/com/epam/edp/customStages/helper/DeployHelper.groovy та внесіть зміну у рядок
607
, зокрема видаліть символ!
(знак оклику), та натиснітьSave and Publish
. -
Проставте оцінки
+2 Code Review
,+1 Verified
та виконайте git merge змін.
5. Оновлення реєстру
-
Оновіть реєстр до нової версії відповідно до інструкції Оновлення компонентів реєстру
-
Перейдіть до застосування хотфіксів, описаних нижче.
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
хотфікс-образів:
-
Виконайте
pull
.docker pull <your-repo-name>/<image-name>:tag
Наприклад:
docker pull uss2jelastic/kafka-api-core-base-image-1-9-6-hotfix
У Dockerhub кожний репозиторій надає приклад, як робити pull
. -
Після
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
-
Після встановлення тегу виконайте
push
.-
Виконайте вхід до Платформи за допомогою
oc cli
. Токен можна отримати через Openshift-консоль, у секції Copy login command. -
Якщо ви користуєтеся Windows, то внесіть наступний запис до файлу C:\Windows\System32\drivers\etc\hosts, якщо linux — то запис потрібно зробити в /etc/hosts.
127.0.0.1 localregistry
-
Відкрийте декілька терміналів, в одному переадресуйте порти на под
nexus
, який можна знайти у проєктіcontrol-plane-nexus
в Openshift > Workloads > Pods.oc port-forward <nexus-pod-name> 5000:5000 -n control-plane-nexus
-
Виконайте вхід в
nexus
.Пароль можна знайти у секреті nexus-admin-password проєкту control-plane-nexus
.docker login -u admin -p <secret-password> localregistry:5000
-
Переконайтеся, що вхід успішний. Після цього можна виконати
push
. Це може зайняти певний час.Пам’ятайте, що в іншому терміналі повинна бути активною переадресація портів. docker push localregistry:5000/control-plane/image_name:tag
-
Після цього ваш образ з’явиться в
nexus
. Туди можна перейти через Openshift > Networking > Routes >nexus
у проєктіcontrol-plane-nexus
. Всі образи знаходяться у Browse > docker-registry.
-
-
Застосуйте необхідні
nexus
-образи до реєстру.У
control-plane-gerrit
знайдіть репозиторій реєстру і в його гілціmaster
внесіть зміни до файлу deploy-templates/helmfile.yaml. При зміні образа вкажіть версію і шлях до папки з образом, як вnexus
:- bpms:
-
- common-web-app:
-
- dataplatform-jenkins-agent:
-
Приклад 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.
- Тимчасове рішення:
-
Необхідно перейти до редагування реєстру > вкладка авторизації надавачів послуг > ввімкнути та вимкнути перемикач на інтерфейсі та підтвердити зміни.