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

ЗМІСТ

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

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

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

Додатково зверніть увагу на:

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

2.1. Підготовка кластерів, розгорнутих на vSphere

  1. Зробіть резервні копії платформних компонентів Vault та Minio разом із томами (volumes) за допомогою vSphere.

    Приклади знімків (snapshots)

    special steps 1.9.5 001

    special steps 1.9.5 002

  2. В інтерфейсі vSphere створіть нову папку для перенесення томів Minio поряд зі старою папкою.

  3. В інтерфейсі vSphere від’єднайте том Minio та перенесіть його зі старої в нову папку, створену на попередньому кроці (2).

  4. В інтерфейсі vSphere видаліть екземпляр Minio.

  5. Після перенесення станів Terraform з релізу 1.9.4 на 1.9.5, видаліть зі стану Minio ресурс vsphere_virtual_machine.vm у папці terraform/minio/vsphere розпакованої Платформи 1.9.5 за допомогою наступної команди:

    $ terraform state rm vsphere_virtual_machine.vm

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

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

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

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

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

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

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

4.1. Кроки для кластерів, розгорнутих на vSphere

  1. В інтерфейсі vSphere під’єднайте старий том до екземпляру Minio.

  2. На jump-хості[1]. у папці розпакованої Платформи 1.9.5 terraform/minio/vsphere/packer перейдіть на екземпляр Minio за допомогою SSH-з’єднання.

    $ cd terraform/minio/vsphere/packer
    $ ssh -i private.key mdtuddm@0.0.0.0 # змініть 0.0.0.0 на IP Minio

    Відновіть дані зі старого тому на новий, виконавши наступні команди:

    $ sudo su
    $ mkdir -p /usr/local/share/minio-backup
    $ lsblk # тут треба переконатися, що новий том знаходиться за шляхом /dev/sdc
    $ echo "/dev/sdc /usr/local/share/minio-backup ext4 defaults 0 0" | tee -a /etc/fstab >/dev/null
    $ mount /usr/local/share/minio-backup
    $ systemctl stop minio
    $ cp -R /usr/local/share/minio-backup/mdtuddm/* /usr/local/share/minio/storage/mdtuddm/
    $ chown -R minio:minio /usr/local/share/minio
    $ systemctl start minio
    $ systemctl status minio
    $ umount /usr/local/share/minio-backup
    $ sed -i '$ d' /etc/fstab
    $ rm -rf usr/local/share/minio-backup
  3. В інтерфейсі Minio перевірте наявність даних, перенесених на попередньому кроці (2).

  4. В інтерфейсі vSphere від’єднайте старий том від екземпляра Minio.

4.2. Оновлення екземплярів для машин-сетів Ceph та Logging

Розділ стосується лише кластерів, розгорнутих у середовищі AWS.

4.2.1. Перевірка полів для машин-сетів Ceph та Logging

Після успішного запуску задачі cluster-mgmt, перевірте, що у машин-сети (machine sets) ceph та logging мають наступні значення полів ami.id та apiVersion:

  • ami.id: ami-094fe1584439e91dd

  • apiVersion: machine.openshift.io/v1beta1

special steps 1.9.5 01
Зображення 1. Приклад перевірки полів для машин-сету Ceph

4.2.2. Видалення машин для машин-сетів Ceph та Logging

Щоби нові поля застосувалися для всіх екземплярів машин-сету, потрібно поступово, по одній, видаляти машини поточного машин-сету через інтерфейс OpenShift.

Цей процес потрібно повторити для всіх машин, які належать до машин-сетів Ceph та Logging.
special steps 1.9.5 02
Зображення 2. Приклад видалення машини для машин-сету ceph

Після видалення машини, нова запуститься автоматично, але вже із новими значеннями полів ami.id та apiVersion.

Зачекайте, доки запуститься нова машина, і лише після цього переходьте до видалення іншої.

Після того, як всі машини для машин-сетів Ceph та Logging будуть перестворені з новими полями ami.id та apiVersion, крок "Оновлення екземплярів для машин-сетів Ceph та Logging" вважається завершеним.

4.3. Оновлення екземплярів для робочих нод кластера

Після оновлення інстансів для машин-сетів Ceph та Logging, оновіть інстанси для робочих нод кластера.

4.3.1. Налаштування полів для робочих нод

Перейдіть до машин-сету робочих нод та змініть значення полів ami.id та apiVersion на наступні:

  • ami.id: ami-094fe1584439e91dd

  • apiVersion: machine.openshift.io/v1beta1

special steps 1.9.5 03
Зображення 3. Приклад налаштування полів ami.id та apiVersion для робочих нод

4.3.2. Видалення машин для машин-сетів робочих нод

Щоб нове поле застосувалося для всіх екземплярів машин-сету, потрібно поступово, по одній, видаляти машини поточного машин-сету.

Машини, що належать до набору machine set робочих нод кластера, часто мають проблеми із видаленням. Щоб уникнути цього, перед видаленням машини потрібно виконати деякі команди через термінал.

Для видалення машини виконайте наступні кроки:

  1. Увійдіть до цільового кластера через термінал:

    special steps 1.9.5 04

    special steps 1.9.5 05

  2. У машин-сеті, який належить до робочих нод кластера, оберіть одну машину, яку плануєте видалити, та скопіюйте назву ноди.

    У цьому прикладі назва — ip-10-0-198-21.eu-central-1.compute.internal.

    special steps 1.9.5 06

  3. Виконайте наступні команди у терміналі, підставивши скопійоване ім’я ноди:

    $ oc adm cordon ip-10-0-198-21.eu-central-1.compute.internal
    $ oc adm drain ip-10-0-198-21.eu-central-1.compute.internal --ignore-daemonsets --delete-emptydir-data

    Може статися, що команда oc adm drain після виконання видасть помилку з подами istiod або istioingressgateway.

    special steps 1.9.5 07
    Зображення 4. Приклад помилки istio-system

    В такому випадку потрібно в OpenShift перейти на ноду, для якої виконуються команди oc adm, та знайти под, та знайти под, через який виникає конфлікт при виконанні команди oc adm drain. Цей под необхідно видалити.

  4. Після успішного виконання команд у терміналі, можна приступати до видалення машини безпосередньо через інтерфейс OpenShift.

    special steps 1.9.5 08
    Зображення 5. Приклад видалення машини в інтерфейсі OpenShift

    Після того, як всі машини для машин-сету робочих нод кластера будуть перестворені з новим полем ami.id, крок "Оновлення екземплярів для робочих нод кластера" вважається завершеним.

4.4. Виправлення помилок для коректної роботи пайплайнів по резервному копіюванню та відновленню з резервної копії

  1. Видаліть файл з репозиторію nexus.

    1. Перейдіть в центральний Gerrit та знайдіть репозиторій components/registry/nexus за допомогою меню BROWSE.

      special steps 1.9.5 09

    2. Відкрийте репозиторій та через бокову панель перейдіть в Commands(1) > Create Change(2). У полі Select branch for new change введіть версію — 1.5.0-SNAPSHOT.72(3), в полі Description введіть опис змін —  Delete keycloakrolebatch(4). Натисніть Create.

      special steps 1.9.5 10

    3. У відкритому Merge Request натисніть Edit > Delete, у текстовому полі виберіть файл deploy-templates/templates/nexus-keycloak-roles.yaml та натисніть Delete. Merge Request має виглядати як на зображенні:

      special steps 1.9.5 11

    4. Після цього треба зробити Reply та Verified +1, Code-Review +2, Submit.

  2. Модифікуйте файл в репозиторії backup-management.

    1. Перейдіть в центральний Gerrit та знайдіть репозиторій components/infra/backup-management за допомогою меню BROWSE.

      special steps 1.9.5 12

    2. Відкрийте репозиторій та через бокову панель перейдіть в Commands(1) > Create Change(2). В полі Select branch for new change введіть версію — 1.9.4.10(3), в полі Description введіть опис змін — Modify configmap(4). Натисніть Create.

      special steps 1.9.5 13

    3. У відкритому Merge Request натисніть Edit > ADD/OPEN/UPLOAD, в текстовому полі виберіть файл bucket-replication/templates/configmap.yaml та натисніть Confirm.

      Далі видалити зміст файлу (Сtrl/command + A > Delete) та скопіюйте наступний код:

      configmap.yaml
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: {{ include "bucket-replication.fullname" . }}
        namespace: {{ .Release.Namespace }}
        labels:
          {{- include "bucket-replication.labels" . | nindent 4 }}
      data:
        bucket-replication.sh: |
          #!/usr/bin/env bash
      
          rook_s3_endpoint=$(oc get cephobjectstore/mdtuddm -n openshift-storage -o=jsonpath='{.status.info.endpoint}')
          bucket=$(oc get objectbucketclaim/"${OBJECT_BUCKET_CLAIM}" -n ${REGISTRY_NAMESPACE} -o=jsonpath="{.spec.bucketName}")
          access_key_rook=$(oc get secret/"${OBJECT_BUCKET_CLAIM}" -n "${REGISTRY_NAMESPACE}" -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 -d)
          access_secret_key_rook=$(oc get secret/"${OBJECT_BUCKET_CLAIM}" -n "${REGISTRY_NAMESPACE}" -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 -d)
      
          mkdir -p ~/.config/rclone
          echo "
          ["${BACKUP_BUCKET}"]
          type = s3
          provider = Other
          endpoint = ${S3_ENDPOINT}
          env_auth = true
          region = eu-central-1
          acl = private
          bucket_acl = private
      
          [rook]
          type = s3
          provider = Ceph
          env_auth = false
          access_key_id = ${access_key_rook}
          secret_access_key = ${access_secret_key_rook}
          endpoint = ${rook_s3_endpoint}
          acl = bucket-owner-full-control
          bucket_acl = authenticated-read" > ~/.config/rclone/rclone.conf
          # append only bucket - data bucket strategy (by label) - copy / other sync
      
      {{- if eq .Values.registryBackup.obc.action "replication" }}
          rclone_command="rclone copy -P --no-traverse --metadata"
      
          if [[ -z $(rclone lsd ${BACKUP_BUCKET}:${BACKUP_BUCKET}/obc-backups/${REGISTRY_NAMESPACE} | grep ${OBJECT_BUCKET_CLAIM}) ]]; then
             echo "[INFO] Destination folder empty, copy full bucket to destination"
          else
             echo "[INFO] Destination folder exists, copy bucket data for ${MAX_AGE}"
             rclone_command="${rclone_command} --max-age ${MAX_AGE}"
          fi
      
          function replication() {
            set +o pipefail
            $rclone_command rook:${bucket} ${BACKUP_BUCKET}:/${BACKUP_BUCKET}/obc-backups/${REGISTRY_NAMESPACE}/${OBJECT_BUCKET_CLAIM}/ -v  > /tmp/rcloneout 2> /tmp/rcloneerror
            return 0
          }
      
          function error_response(){
              return 1
          }
      
          replication
      
          if grep -q 'failed to open source object: NoSuchKey' /tmp/rcloneerror;then
            echo "[WARN] False positive error with NoSuchKey. Ignore"
          elif  [ -s /tmp/rcloneout ];then
            echo "[INFO] Replication completed with no errors."
          else
            if [ ! -z ${DEBUG} ]; then
              echo "[ERROR][DEBUG]Debug flag set to true"
              cat /tmp/rcloneerror
            else
              echo "[ERROR]Please run job in debug mode. Add to enviromnet variable DEBUG with value "true" to return logs to stout"
            fi
            error_response
          fi
      {{- else }}
          rclone -M -v sync ${BACKUP_BUCKET}:/${BACKUP_BUCKET}/obc-backups/${REGISTRY_NAMESPACE}/${OBJECT_BUCKET_CLAIM} rook:${bucket}
      {{- end }}

      Після цього натисніть SAVE & PUBLISH та Mark as active. Merge Request має виглядати як на зображенні:

      special steps 1.9.5 14

    4. Далі натисніть Reply > Verified +1 > Code-Review +2 > Submit.

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

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

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

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

6.1. Оновлення екземплярів реєстру після його оновлення до версії 1.9.5.

Розділ стосується лише кластерів, розгорнутих у середовищі AWS.

Після того, як реєстр було оновлено до версії 1.9.5 та Build-пайплайн пройшов успішно, потрібно оновити інстанси для цього реєстру.

6.1.1. Перевірка полів машин-сету реєстру

Перевірте, що після оновлення реєстру його машин-сет має наступні значення полів ami.id та apiVersion:

  • ami.id: ami-094fe1584439e91dd

  • apiVersion: machine.openshift.io/v1beta1

special steps 1.9.5 15

6.1.2. Видалення машин для машин-сету реєстру

Щоби нові поля застосувалися для всіх інстансів машин-сету, потрібно поступово, по одній, видаляти машини поточного машин-сету через інтерфейс OpenShift.

Цей процес потрібно повторити для всіх машин, які належать до машин-сету реєстру.

special steps 1.9.5 16
Зображення 6. Приклад видалення машини

Після видалення машини, нова запуститься автоматично, але вже із новими значеннями полів ami.id та apiVersion.

Зачекайте, доки запуститься нова машина, і лише після цього переходьте до видалення іншої.

Після того, як всі машини для машин-сету реєстру перестворені з новими полями ami.id та apiVersion, крок "Оновлення екземплярів реєстру після його оновлення на версію 1.9.5" вважається завершеним.

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

Проблема Рішення

Не працює взаємодія між реєстрами

Додавання NetworkPolicy для компонента platform-gateway.

Для коректної роботи функціональності "ДОСТУП ДЛЯ РЕЄСТРІВ ПЛАТФОРМИ ТА ЗОВНІШНІХ СИСТЕМ", треба перейти в OpenShift-консоль, вибрати потрібний реєстр (1), перейти в NetworkPolicies(2) та створити NetworkPolicy через кнопку Create NetworkPolicy(3) як показано нижче:

special steps 1.9.5 17

Після цього потрібно замінити текст у текстовому полі на наступний маніфест:

platform-gateway-policy.yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  annotations:
    meta.helm.sh/release-name: network-management
    meta.helm.sh/release-namespace: <registry-name>
  name: platform-gateway-policy
  labels:
    app.kubernetes.io/managed-by: Helm
spec:
  podSelector:
    matchLabels:
      app: platform-gateway
  ingress:
    - from:
        - namespaceSelector: {}

де <registry-name> — назва реєстру, в якому створюється NetworkPolicy.

Неможливо додати Keycloak DNS у налаштуваннях Платформи.

Додайте додатковий DNS на рівні Платформи.

Необхідно вносити зміни лише в тому випадку, коли DNS-ім’я для Keycloak вже було налаштовано.

Виконайте наступні кроки:

  1. Перейдіть у центральний Vault > registry-kv > cluster > domains.

  2. Натисніть кнопку Create secret, заповніть поле Path for this secret та додайте Key та Value SSL-сертифікату:

    special steps 1.9.5 18

    special steps 1.9.5 19

  3. Після того, як SSL-сертифікат успішно доданий у центральний Vault, перейдіть у центральний Gerrit та знайдіть репозиторій Cluster-mgmt за допомогою меню BROWSE.

  4. Відкрийте репозиторій та через бокову панель перейдіть в Commands(1) > Create Change(2). В полі Select branch for new change введіть версію — master(3), в полі Description введіть опис змін — ADD DNS for keycloak. Натисніть Create.

  5. У відкритому Merge Request натисніть Edit > ADD/OPEN/UPLOAD, в текстовому полі виберіть файл deploy-templates/values.yaml та натисніть Confirm. В кінці YAML сторінки додайте налаштування для додаткового DNS:

    deploy-templates/values.yaml
    keycloak:
        customHosts:
            - certificatePath: registry-kv/cluster/domains/dns-keycloak.openshift.pertesting.com/20231506T094423Z
              host: dns-keycloak.openshift.pertesting.com

    Де:

    • dns-keycloak.openshift.pertesting.com — доменне ім’я для Keycloak.

    • registry-kv/cluster/domains/dns-keycloak.openshift.pertesting.com/20231506T094423Z — шлях зберігання SSL-сертифіката у центральному Vault з кроку №2.

  6. Після цього натисніть SAVE & PUBLISH > Reply та Verified +1, Code-Review +2, Submit.

8. Специфічні та нечасті помилки

Проблема Рішення

Після оновлення реєстру до версії 1.9.5, користувачі Кабінету надавача послуг (officer-portal), у яких є атрибут subjectType або representative, можуть отримати помилку 401 у відповіді на запити до Фабрики даних.

Повторно розгорніть регламент реєстру для перестворення моделі даних.

9. Зворотно несумісні зміни

Обов’язково зверніть увагу на важливі зміни у версії 1.9.5 Платформи.

1. Jump host (також — jump server або bastion host) — це спеціалізований сервер, що контролює доступ до інших серверів чи систем у мережі. Цей сервер використовується як проміжний етап при з’єднанні із внутрішніми ресурсами мережі, що дозволяє забезпечити додатковий рівень безпеки. Наприклад, якщо ви хочете з’єднатися із сервером, що знаходиться в приватній мережі, ви спочатку під’єднаєтеся до jump-хоста, а потім від цього хоста під’єднаєтеся до цільового сервера.