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

ЗМІСТ

1. Мета інструкції
2. Підготовка кластера Платформи до оновлення
3. Оновлення платформи
4. Підготовка реєстру до оновлення
- 4.1. Видалення кодової бази history-excerptor
- 4.2. Хотфікс для geo-server
5. Оновлення реєстру
6. Кроки після оновлення реєстру
- 6.1. Виконати редеплой MASTER-Build-registry-regulations-data-model
- 6.2. Оновлення реєстру з geo-server
7. Хотфікси релізу 1.9.4

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

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

Послідовність процесу оновлення:

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

Додатково:

Хотфікси релізу 1.9.4

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

Виконайте підготовчі кроки перед оновленням cluster-mgmt (за потреби). Наприклад, резервне копіювання роутів реєстру тощо.

Увійдіть до цільового OKD-кластера.

Увійдіть до інтерфейсу OpenShift (OKD) > ? > Command line tools > Copy login command > Display token > Скопіюйте токен доступу до OKD через cli та вставте у терміналі відповідну команду:
```
$ oc login --token=sha256~**** --server=https://api.master-for-update-31.mdtu
```
Встановіть утиліту oc cli. Відповідні інструкції можна знайти на тій же сторінці.

Зображення 1. Command line tools

Зображення 2. Copy login command
Видаліть застарілі ResticRepository після зміни роута компонента minio Платформи на новий.

Увійшовши на кластер, виконайте команду для формування нових резервних копій із новим посиланням до minio:
```
$ oc -n velero delete ResticRepository --all
```

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

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

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

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

3.2. Перевірка оновлення Crunchy Postgres Operator CRD-ресурсів перед оновленням Платформи

Дуже важливо переконатися, що після успішного завершення пайплайну platform-deploy відбулося успішне оновлення Custom Resource Definition (CRD) для postgres-operator.

Що таке Custom Resource Definition (CRD)?

CRD (Custom Resource Definition) в OpenShift — це механізм, який дозволяє розширити API OpenShift для створення нових ресурсів, що не є вбудованими в сам OpenShift.

За допомогою CRD можна визначити власні ресурси та їх схеми, які описуються у форматі YAML. Такі ресурси можуть бути використані для моделювання та управління спеціалізованими ресурсами, які відображають особливості конкретної додаткової функціональності або додаткових об’єктів, що потребують управління в OpenShift-кластері.

CRD визначається у вигляді спеціального ресурсу OpenShift, який називається CustomResourceDefinition. Він описує структуру власного ресурсу, його атрибути, правила валідації, версію API та інші характеристики. Після визначення CRD можна створювати екземпляри власних ресурсів, які додатково управляються OpenShift.

CRD дозволяє розширити функціональність OpenShift, додати нові типи ресурсів та використовувати їх для розробки спеціалізованих рішень на базі OpenShift.

Увійдіть до цільового кластера OpenShift, як показано у розділі Підготовка кластера Платформи до оновлення, якщо ви досі цього не зробили.

Перевірте, що в CRD-ресурсах оновилися лейбли (labels) та анотації (annotations). Виконайте по черзі наступні команди та отримайте відповідні валідні значення:

Команди і валідні значення лейблів та анотацій

$ oc get crd postgresclusters.postgres-operator.crunchydata.com -o jsonpath='{.metadata.annotations.helm\.sh/resource-policy}'
keep

$ oc get crd pgupgrades.postgres-operator.crunchydata.com -o jsonpath='{.metadata.annotations.helm\.sh/resource-policy}'
keep

$ oc get crd postgresclusters.postgres-operator.crunchydata.com -o jsonpath='{.metadata.labels.app\.kubernetes\.io/version}'
5.3.0

$ oc get crd pgupgrades.postgres-operator.crunchydata.com -o jsonpath='{.metadata.labels.app\.kubernetes\.io/version}'
5.3.0

Наведені нижче кроки 3.2.1-3.2.3 обов’язкові лише тоді, коли результат виконання команд oc get crd відрізняється від наведеного вище (не існує анотації resource-policy або версія відрізняється від 5.3.0):

Застосування команд label та annotate для CRD
Клонування репозиторію control-plane-installer та перемикання на останній тег версії 1.9.4
Застосування нових CRD для postgres-operator

Якщо в CRD відсутня анотація *_helm.sh/resource-policy:keep *_або значення лейбли app.kubernetes.io/version відмінне від 5.3.0, потрібно виконати кроки 3.2.1-3.2.3, наведені нижче, інакше запуск cluster-mgmt пайплайна видалить існуючі postgres-operator CRDs і відповідно всі існуючі кластери Postgres та всі БД у реєстрах)!!!

3.2.1. Застосування команд label та annotate для CRD

Виконайте наведені нижче команди label та annotate ДО ЗАПУСКУ cluster-mgmt пайплайна:

Застосування команд label та annotate для CRD

oc label crd pgupgrades.postgres-operator.crunchydata.com app.kubernetes.io/managed-by-

oc annotate crd pgupgrades.postgres-operator.crunchydata.com helm.sh/resource-policy=keep

oc annotate crd pgupgrades.postgres-operator.crunchydata.com meta.helm.sh/release-name-

oc annotate crd pgupgrades.postgres-operator.crunchydata.com meta.helm.sh/release-namespace-


oc label crd postgresclusters.postgres-operator.crunchydata.com app.kubernetes.io/managed-by-

oc annotate crd postgresclusters.postgres-operator.crunchydata.com helm.sh/resource-policy=keep

oc annotate crd postgresclusters.postgres-operator.crunchydata.com meta.helm.sh/release-name-

oc annotate crd postgresclusters.postgres-operator.crunchydata.com meta.helm.sh/release-namespace-

3.2.2. Клонування репозиторію control-plane-installer та перемикання на останній тег версії 1.9.4

Клонуйте репозиторій control-plane-installer і перемкніться на останній тег версії 1.9.4. Для цього по черзі виконайте наступні команди:

$ git clone "ssh://name_surname@epam.com@gerrit-mdtu-ddm-edp-cicd.apps.cicd2.mdtu-ddm.projects.epam.com:32114/mdtu-ddm/infrastructure/control-plane-installer" && scp -p -P 32114 name_surname@epam.com@gerrit-mdtu-ddm-edp-cicd.apps.cicd2.mdtu-ddm.projects.epam.com:hooks/commit-msg "control-plane-installer/.git/hooks/"

$ cd control-plane-installer

$ git checkout master # set 1.9.4 version or left master for now (TODO: paste latest installer version)

3.2.3. Застосування нових CRD для postgres-operator

Застосуйте нові CRD для postgres-operator:

$ oc apply --server-side --force-conflicts -f deploy-templates/customresourcedefinitions/crds/crunchy-postgres-operator/

За відсутності доступу до CICD2-кластера, ці конфігураційні файли CRD можна взяти з екземпляра, на якому розпаковувався installer, за наступним шляхом:

$ cd repositories/components/control-plane/control-plane-installer.git/

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

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

Див. детальніше на сторінці Оновлення інфраструктурних компонентів Платформи.

4. Підготовка реєстру до оновлення

4.1. Видалення кодової бази history-excerptor

Відкрийте OpenShift-консоль > Project: <Ваш реєстр> > натисніть випадний список Resources > виконайте пошук по значенню Codebase.
У рядку Codebase з ім’ям history-excerptor натисніть позначку, яка має вигляд трьох вертикальних крапок > далі — кнопку Delete Codebase.
Дочекатися видалення history-excerptor та перевірте, що у реєстровому Jenkins зникла папка history-excerptor.
Запустіть пайплайн MASTER-Build-<назва-реєстру>:
- Увійдіть до Control Plane як адміністратор реєстру.
- Перейдіть до розділу Реєстри > оберіть ваш реєстр > Швидкі посилання > Адміністративна зона Платформи.

4.2. Хотфікс для geo-server

Додайте хотфікс для geo-server.

Щоб уникнути проблем з оновленням налаштувань geo-server, які можуть виникнути через проблеми з монтуванням другого пода до наявного тому (volume), вам потрібно змінити стратегію розгортання geo-server. Альтернативно ви також можете виконати кроки, описані у розділі Оновлення реєстру з geo-server, щоб оновити налаштування geo-server вручну.

Якщо ви хочете внести зміни в код чарта geo-server, вам потрібно створити запит на злиття (Merge Request) до відповідної гілки релізу в репозиторії geo-server.

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

Цей крок описує стандартний процес оновлення компонентів реєстру в адміністративній панелі Control Plane.

Див. детальніше на сторінці Оновлення компонентів реєстру.

6. Кроки після оновлення реєстру

6.1. Виконати редеплой MASTER-Build-registry-regulations-data-model

Внесено зміни до шаблонів registry-rest-api, зокрема видалено бакет lowcode-form-data-storage та всі його залежності.

Тому ми рекомендуємо запустити пайплайн MASTER-Build-registry-regulations > data-model для оновлення регламенту, зокрема моделі даних. Це допоможе уникнути можливих проблем із доступом до registry-rest-api у разі створення нового поду, який шукатиме config map із даними про вже видалений бакет lowcode-form-data-storage. Подальший запуск вказаного пайплайну оновить шаблон розгортання, видаливши ці залежності.

Отже, виконайте наступні кроки для повторного розгортання регламенту реєстру:

Відкрийте Jenkins вашого реєстру.

Запустіть пайплайн MASTER-Build-registry-regulations > data-model для оновлення конфігурації registry-rest-api.

6.2. Оновлення реєстру з geo-server

У випадку оновлення реєстру, який містить компонент geo-server, може виникнути ситуація, коли стратегія RollingUpdate не працює належним чином, і в результаті не може створитися додатковий под. Якщо до коду не було внесено hotfix, описаний у розділі Хотфікс для geo-server, то при виникненні проблеми (тобто, якщо пайплайн оновлень не проходить через компонент geo-server), вам потрібно вручну перестворити под geo-server.

Для цього перейдіть в Openshift-консоль за таким шляхом для вашого реєстру та виконайте наступні кроки:

Відкрийте Openshift-консоль > Search > оберіть проєкт із вашим реєстром > Workloads → Deployments > geo-server.

Видаліть под.

Створіть новий под.

Виконайте повторне розгортання пайплайну MASTER-Build-<назва-реєстр>:

Увійдіть до Control Plane як адміністратор реєстру.

Перейдіть до розділу Реєстри > оберіть ваш реєстр > Швидкі посилання > Адміністративна зона Платформи.

Перейдіть до сервісу Jenkins Платформи.

Запустіть пайплайн MASTER-Build-<назва-реєстру>.

7. Хотфікси релізу 1.9.4

7.1. Застосування нового образу із документацією: 1.9.4.367

Застосуйте новий образ документації: 1.9.4.367. Щоб завантажити Docker образ на кластер, потрібно мати:

приватний Docker registry;

Docker локально;

oc cli локально.

Якщо у вас є образ на локальній машині (перед цим ви зробили pull із приватного registry), і ви хочете його завантажити до nexus на вашому кластері, то виконайте наступні дії:

Перш за все, виконайте вхід до OpenShift-консолі Платформи на кластері envone за допомогою oc cli. Отримайте токен доступу для входу в інтерфейсі Openshift-консолі > Copy login command.

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

127.0.0.1 localregistry

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

oc port-forward <nexus_pod_name> 5000:5000 -n control-plane-nexus

В іншому терміналі правильно призначте тег вашого образа, щоб він був завантажений до nexus.

docker image tag <your_image>:<version> localregistry:5000/<your_image>:<version> example: docker image tag docker.registry.io/docs/ddm-architecture-master:1.9.4.367 localregistry:5000/control-plane/ddm-architecture-master:1.9.4.367

Після призначення тегу виконайте вхід до nexus. Пароль можна знайти в секреті nexus-admin-password проєкту control-plane-nexus.

docker login -u admin -p <secret_password> localregistry:5000

Переконайтеся, що логін успішний. Після цього можна виконувати push.

docker push localregistry:5000/control-plane/ddm-architecture-master:1.9.4.367

Пам’ятайте, що в іншому терміналі повинен бути налаштована активна переадресація портів).

Виконання команди може зайняти деякий час.

Після публікації образу в nexus, можна знайти необхідний артефакт. Для цього перейдіть до Openshift > Networking > Routes > проєкт control-plane-nexus > сервіс nexus.

Ви можете побачити усі доступні образи у розділі Browse > docker-registry.

Відкрийте налаштування (deployment) сервісу ddm-architecture у проєкті documentation, далі перейдіть до YAML, змініть версію документації та збережіть.
В результаті под із новою версією документації перествориться автоматично.

7.2. Виправлення для логування: logging 5.7.0

Внесіть виправлення перед запуском пайплайну cluster-mgmt, або запустіть його повторно вручну.

Виконуйте зміни у центральному gerrit Платформи (проєкт control-plane), у репозиторії components/infra/logging із версією 1.5.0-SNAPSHOT.82.

Файл deploy-templates/logging-instance/templates/050-clo-instance.yaml виглядатиме так:

Код зміни виглядатиме так:

collection: resources: limits: cpu: '1' memory: 1024Mi requests: cpu: 200m memory: 1024Mi tolerations: - operator: Exists type: fluentd

Файл deploy-templates/logging-instance/templates/clusterlogforwarder.yaml виглядатиме так:

Код зміни виглядатиме так:

pipelines: - name: application-logs inputRefs: - application outputRefs: - default parse: json - name: infra-audit-logs inputRefs: - infrastructure - audit outputRefs: - default

7.3. Виправлення postgres

Внесіть виправлення перед оновленням реєстрів, або запустіть пайплайн оновлення повторно вручну.

Виконуйте зміни у центральному gerrit Платформи (проєкт control-plane), у репозиторії components/registry/registry-postgres із версією 1.9.4-SNAPSHOT.10.

Файл deploy-templates/templates/operational-pool-configmap.yaml виглядатиме так:

Код змін виглядатиме так:

enable_shared_relcache = off

7.4. Перевірка логіна в Keycloak

Внесіть виправлення перед оновленням реєстрів, або запустіть пайплайн оновлення повторно вручну.

У разі виникнення наступної помилки, необхідно виконати декілька кроків для розблокування користувачів:

Перейдіть у проєкт user-management > secrets та знайдіть секрет keycloak.

Скопіюйте значення password до буфера обміну.

Перейдіть до keycloak та авторизуйтесь як admin з отриманим вище паролем.

Перейдіть до реалму master > Identity Providers > openshift-sso.

Перейдіть до розділу Open ID Config та впевнитися, що у полі client вказано openshift.

Перейдіть до реалму openshift > Clients > Credentials та скопіюйте значення поля secret.

Поверніться до налаштувань, які були вказані у пункті 5.

Встановіть значення, скопійоване у пункті 6, у поле Client Secret.

Збережіть налаштування.

Відкрийте OpenShift-консоль > Identity providers та знайдіть openshift-master.

Перейдіть до YAML-перегляду.

Знайдіть поле clientSecret та замініть його на секрет, скопійований у пункті 6.

Збережіть зміни.

Відкрийте проєкт user-management та перезавантажте под keycloak operator.

7.5. Видалення cleanup пайплайну

Внесіть виправлення перед оновленням реєстрів, або запустіть пайплайн оновлення повторно вручну.

Лише для промислового (prod) оточення.

Виконуйте зміни у центральному gerrit Платформи (проєкт control-plane), у репозиторії components/registry/jenkins-operator із версією 1.5.0-SNAPSHOT.227.

Файл deploy-templates/JobProvisioner.groovy виглядатиме так:

Код зміни виглядатиме так:

/*createCleanUpPipeline("cleanup-job", codebaseName, cleanupStages, repositoryPath, codebaseHistoryName, deploymentMode)*/

7.6. Відключення error логування kong

Внесіть виправлення перед оновленням реєстрів, або запустіть пайплайн оновлення повторно вручну.

Лише для оточення vSphere.

Виконуйте зміни у центральному gerrit Платформи (проєкт control-plane), у репозиторії components/registry/kong із версією 1.5.0-SNAPSHOT.59.

Файл deploy-templates/values.yaml виглядатиме так:

Код змін виглядатиме так:

proxy_error_log: /dev/null admin_error_log: /dev/null

7.7. Виправлення у сервісах по роботі з даними (data-сервіси)

Внесіть виправлення перед оновленням реєстрів, або запустіть пайплайн оновлення повторно вручну.

Виконуйте зміни у центральному gerrit Платформи (проєкт control-plane), у репозиторії components/registry/jenkins-operator із версією 1.5.0-SNAPSHOT.227.

Файл deploy-templates/JobProvisioner.groovy виглядатиме так:

Код змін виглядатиме так:

'[{"name": "create-projects"}]]},' + '{"stages": [{"name": "delete-data-services"},' + '{"name": "clone-projects"},' + '{"name": "generate-projects"},' +

7.8. Виправлення Redash

Внесіть виправлення перед оновленням реєстрів, або запустіть пайплайн оновлення повторно вручну.

Лише для e-shelter-prod.

Виконуйте зміни у центральному gerrit Платформи (проєкт control-plane), у репозиторії components/registry/redash-chart із версією 1.5.0-SNAPSHOT.103.

Для 1.5.0-SNAPSHOT.103 потрібно створити нову гілку, бо зміни повинні застосовуватися до одного реєстру, а не глобально до всіх.

Файл deploy-templates/templates/HorizontalPodAutoscaler.yaml виглядатиме так:

Файл deploy-templates/values.yaml виглядатиме так: