Міграція реєстрів

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

Ця сторінка надає практичне керівництво з виконання міграції між OKD кластерами SRC та DEST.

1. Позначення та скорочення

  • SRC кластер — кластер, на якому розгорнуто наявний реєстр.

  • DEST кластер — кластер, куди буде перенесено наявний реєстр (цільовий кластер).

Міграція реєстру виконується з останньої резервної копії наявного реєстру та, відповідно до інструкції, буде переноситися із SRC кластеру до DEST кластеру й відновлюватися вже на цьому кластері.

2. Передумови для міграції

📌 Примітка до організації міграції

  1. Планування: важливо розробити чіткий графік міграції. Він має включати:

    • Дату та час створення бекапу.

    • Час відновлення.

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

  2. Комунікація: важливо забезпечити, щоб усі користувачі-надавачі послуг були вчасно повідомлені:

    • Сповіщайте користувачів за допомогою зовнішніх комунікаційних каналів поза межами Платформи.

    • Вкажіть їм про необхідність завершення роботи до визначеного у графіку часу.

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

  1. Процес міграції включає запуск bash-скрипту, що здійснює перенесення даних з SRC кластеру до DEST кластеру. Для успішної міграції, цей скрипт має бути виконаний на платформі Linux з архітектурою мікропроцесора x86-64 (відомою також як AMD64, Intel 64, чи x64)

  2. Користувач, який буде переносити реєстр на інший кластер, повинен бути доданий до адміністраторів Платформи на обох кластерах через control-plane-console.

    Див. детальніше — Створення адміністратора платформи.

  3. На кластері, на який переноситься реєстр, повинна бути розгорнута та версія платформи, у якої версія control-plane-gerrit буде дорівнювати версії самого реєстру (наприклад, версія платформи — 1.9.4.11, версія реєстру — 1.9.4.7, версія control-plane-gerrit – 1.9.4.7). Цю версію можна перевірити наявністю гілки у репозиторії cluster-mgmt в центральному Gerrit. Якщо гілка з версією реєстру існує, то версію реєстру можна переносити на DEST кластер. Якщо ні, то існує два шляхи:

    • Оновити платформу на DEST кластері, яка буде відповідати версії самого реєстру.

    • Оновити реєстр на SRC кластері до версії, яка вже існує на DEST кластері.

  4. Одночасний доступ до SRC кластеру та DEST кластеру.

  5. Наявність наступних команд в Terminal:

    • oc

    • velero

    • rclone

    • vault

    • helm

    • jq

  6. Стабільне з’єднання з інтернетом. Чим більша пропускна здатність, тим швидше буде проходити міграція. В іншому випадку, можна використовувати jumpbox (із доступом до обох кластерів), який знаходиться або в AWS, або в іншого cloud-провайдера. Використання jumpbox зменшить час перенесення резервної копії з одного кластера на інший.

    Якщо ви використовуєте jumpbox, то необхідно перевірити доступ до таких ресурсів:

    • Платформний MinIO.

    • Платформний Vault.

    • Центральний Vault у проєкті user-management.

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

    curl sshmyip.com | jq '.ip'

    Далі переконайтеся, що виконані такі дії:

    1. IP-адресу jumpbox додано до переліку дозволених CIDR на рівні керування платформою для кластерів SRC та DEST.

    2. NAT IP DEST-кластера додано до списку дозволених CIDR на рівні SRC-кластера. Ви можете дізнатися NAT IP DEST-кластера, запустивши под у Jenkins проєкту control-plane та виконавши ту ж саму команду:

      curl sshmyip.com | jq '.ip'

    (Деталі додавання IP адрес через інтерфейс адміністратора, детальніше дивіться на сторінці CIDR: Обмеження доступу до Платформних та реєстрових компонентів).

    Якщо відсутній доступ до control-plane-console, зверніться до L2-команди для перевірки доступу.

    При міграції реєстру, важливо щоб перед початком міграції, на DEST кластері не було ресурсів пов’язаних із реєстром. Якщо раніше реєстр не існував на цьому кластері, то подальші дії можна не виконувати.

    Якщо реєстр існував, то для видалення усіх ресурсів потрібно перевірити/видалити наступне:

    • Видаліть реєстр через інтерфейс адміністративної панелі Control Plane.

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

    • Підтвердьте зміни та дочекатися видалення реєстру.

    • Після видалення перевірте відсутність проєкту у центральному компоненті Gerrit.

      • Перейдіть до Gerrit (Openshift-консоль > Projects > control-plane > Networking > Routes > control-plane-gerrit ).

      • Автентифікуйтеся через openshift-sso, відкрийте меню Browse > Repositories та виконайте пошук за назвою реєстру.

      • Якщо пошук знаходить репозиторій, то перейдіть до Openshift-консоль > Projects > control-plane > Home > API Explorer > у пошуку ( Filter by kind …​ ) знайдіть gerritproject > <назва реєстру> > Actions > Delete GerritProject.

      • Після видалення Gerrit-проєкту, перейдіть до Gerrit-консолі та перевірте, що репозиторій відсутній. Якщо репозиторій існує, видаліть його через Gerrit-консоль ( відкрийте репозиторій реєстру > Commands > Delete project).

    • Видаліть директорію в Minio.

      • Для перевірки створених директорій в Minio, перейдіть до MinioUI (для кластерів vSphere цей Route можна знайти в OpenShift-консолі > Projects > control-plane > Networking > Routes > platform-minio-ui.

      • У випадку відсутності Route, перейдіть до секретів за шляхом:
        Openshift-консоль > Project > control-plane > Workloads > Secrets > backup-credentials, скопіюйте поле backup-s3-like-storage-url та додайте до URL порт (Наприклад, https://endpoint.com:9001 ).

        Дані для аутентифікації в Minio знаходяться в Openshift-консолі > Project > control-plane > Secrets > backup-credentials, де username — це поле backup-s3-like-storage-access-key-id, а password —  backup-s3-like-storage-secret-access-key.

      • Після аутентифікації перевірте/видаліть директорії, пов’язані у реєстрі в бакеті. Такими є:

        • openshift-backups/backups/<назва-реєстру>*;

        • openshift-backups/restic/<назва-реєстру>;

        • obc-backups/<назва реєстру>.

3. Підготовка реєстру до міграції

Перед початком міграції необхідно повністю обмежити доступ для кінцевих користувачів до цього реєстру.

  1. Створіть резервну копію реєстру на кластері SRC.

    Перед перенесенням реєстру на новий кластер, необхідно запустити Jenkins-процес Create-registry-backup-<назва реєстру>.

    Якщо Jenkins pipeline завершився зі статусом Success, то резервна копія виконана успішно.

    Для отримання назви резервної копії, перейдіть до логів/журналів подій останнього запуску Jenkins pipeline (Console Output), та за пошуком на сторінці знайдіть повідомлення накшталт:

    [INFO] Velero backup - <назва реєстру>-<час> done with Completed status

    Наприклад, таке:

    [INFO] Velero backup - abc-02-2023-04-18-19-03-14 done with Completed status

    • де abc-02-2023-04-18-19-03-14 — назва резервної копії.

    Для версій реєстру < 1.9.3 необхідно виконати у Terminal наступну команду:

    velero backup describe <назва бекапу>

    Назву бекапу можна знайти в логах останнього запуску Jenkins-процесу Create-registry-backup-<назва реєстру>.

    Детальніше про створення резервних копій та відновлення реєстрів див. у розділі Резервне копіювання та відновлення.

  2. Якщо останній velero backup завершився зі статусом Completed, то можна переходити далі. У випадку, коли статус velero backup відрізняється від Completed, необхідно долучати спеціалістів із технічної підтримки L2-L3 для перевірки працездатності Jenkins-пайплайну.

  3. Отримайте консистентні дані у бекапах бакетів реєстру, що мігрується.

    1. Для початку, отримайте актуальні бекапи S3-бакетів реєстру в проєкті velero. Відкрийте розділ Workloads, потім перейдіть до CronJobs. Тут використовуйте пошукову панель для фільтрації бакетів за назвою реєстру, наприклад, migrationreg.

      migrate registry 01
      Зображення 1. CronJobs

    2. Відкрийте кожну CronJob і змініть час її запуску на найближчий можливий, та додайте value для змінної оточення MAX_AGE. Для прикладу, встановіть запуск через 10-15 хвилин. Щоб це зробити, перейдіть до налаштувань кожної CronJob, відкрийте її YAML-конфігурацію і змініть параметр spec.schedule. Наприклад, для запуску CronJob щодня о 10:50 за UTC, використовуйте наступну конфігурацію:

      CronJob details. YAML-конфігурація
      spec:
  schedule: 50 10 * * *

      При роботі з cron, час вказується за UTC.
      migrate registry 02
      Зображення 2. CronJob details. Schedule

      Для конфігурації MAX_AGE використовуйте наступну конфігурацію:

      spec:
  ...
  jobTemplate:
    ...
    spec:
      template:
        ...
        spec:
          ...
          containers:
            ...
            env:
            - name: MAX_AGE
              value: '2y'

    3. Після цього дочекайтеся запуску і завершення усіх CronJob. Прогрес і статус можна перевірити в розділі Jobs, обравши відповідний Job і переглянувши розділ Status, де має бути позначка ✅ Complete.

      migrate registry 03
      Зображення 3. CronJob details. Jobs
      migrate registry 04
      Зображення 4. Job details. Status

    4. Завдяки цим діям ви отримаєте консистентні дані з бекапів бакетів реєстру, який перебуває у процесі міграції.

  4. Забороніть робити зміни у реєстрі за допомогою Jenkins пайплайнів.

    У кожному пайплайні для реєстру перейдіть до секції Configure та знайдіть параметр Disable this project у секції Build Triggers, встановіть напроти нього прапорець та збережіть зміни за допомогою кнопки Save.

4. Міграція резервної копії із кластера SRC до кластера DEST

  1. Отримайте логін-команди для обох кластерів.

    Для цього виконайте вхід до Openshift-консолі та у правому верхньому кутку, натисканням на свій username, перейдіть до Copy login command, скопіюйте токен доступу у полі Log in with token та збережіть його у текстовому редакторі.

    Операцію потрібно повторити для обох кластерів: SRC та DEST.

  2. Отримайте назву останньої резервної копії, яка була створена на кластері SRC (наприклад, abc-02-2023-04-18-19-03-14).

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

    Експорт логіну для кластера SRC
    export SRC_CLUSTER_LOGIN="oc login --token …"

    Вставте між лапок "…​" після --token отриману в пункті 1 команду логіну для кластера SRC. В кінці логін-команди не повинно бути перенесення на наступний рядок.

    Експорт логіну для кластера В
    export DEST_CLUSTER_LOGIN="oc login --token …"

    Вставте між лапок "…​" після --token отриману в пункті 1 команду логіну для кластера В. В кінці логін-команди не повинно бути перенесення на наступний рядок.

    Експорт назви реєстру
    export REGISTRY_NAME="abc-02"
    abc-02 — назва реєстру
    Експорт назви резервної копії
    export BACKUP_NAME="<назва резервної копії>"
    Приклад назви резервної копії: abc-02-2023-04-18-19-03-14.
    Експорт значення шифрування резервних копій в MinIO на кластері SRC
    export MINIO_SRC_SSE="true"/"false"
    За замовчуванням це значення дорівнює - "false". Приклад значення при увімкненому шифруванні резервної копії на кластері SRC: "true".
    Експорт значення шифрування резервних копій в MinIO на кластері DEST
    export MINIO_DEST_SSE="true"/"false"
    За замовчуванням це значення дорівнює - "false". Приклад значення при увімкненому шифруванні резервної копії на кластері DEST: "true".

У випадку, коли реєстр попередньо був мігрований на кластер SRC, а не розгорнутий на цій Платформі, виконайте додатковий export:

export VAULT_KEY="<назва ключа>"

  • де <назва ключа> — ключ для unseal процесу, який можна знайти в Openshift-консолі ( Кластер А ) > Projects > <назва реєстру> > ConfigMaps > hashicorp-vault-config. Поле key_name і є назвою ключа.

    Наприклад:

    key_name        = "autounseal-migration"

  1. Збережіть архів, розархівуйте його в нову директорію наступною командою:

    unzip registry-migration.zip -d registry-migration

    Перейдіть в директорію registry-migration (cd) та виконайте команду:

    bash migration.sh

    Якщо виконання скрипта завершилось з помилкою на етапі міграції бакетів (наприклад, через помилку Helm), то процес міграції бакетів можна запустити окремо, виконавши наступну команду:

    export MIGRATE_BUCKETS_ONLY="true"

    Якщо необхідно замінити посилання на MinIO SRC, виконайте команду:

    export MINIO_SRC_ENDPOINT_OVERWRITE="<посилання на MinIO>"

    Якщо необхідно замінити посилання на MinIO DEST, виконайте команду:

    export MINIO_DEST_ENDPOINT_OVERWRITE="<посилання на MinIO>"

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

  2. В результаті виконання скрипта будуть виконані наступні дії:

    • Перенесено Velero backup на DEST кластер

    • На jumpbox хості, створенна директорія - keycloak-export-<назва-реєстру>

    • Перенесена інформація з Vault в проєкті user-management

    • На DEST кластері в проекті velero створені Kubertnets Job для перенесення данних бакетів з MinIO SRC до MiniIO DEST

  3. Після виконання скрипту, виконайте логін у терміналі за допомогою oc cli на кластері DEST, та перевірте наступне:

    • Наявність velero backup на кластері DEST.

    • Наявність директорій із назвою keycloak-export у папці, де знаходиться скрипт.

    • Завершення Kubernetes Job з переносу інформації з MinIO SRC до MiniIO DEST

5. Підготовка до відновлення на кластері DEST

  1. Створіть реєстр через control-plane-console.

    • Створіть реєстр з тим же ім’ям, і такою ж версією на кластері DEST. При створенні реєстру призначте усіх адміністраторів, що були у реєстрі на кластері SRC, та вкажіть актуальні дані.

      Дані про ключ

      Поля заповніть або з актуальними ключами для цього реєстру, або використовуйте тестові ключі. У майбутньому, після міграції, інформацію про ключі можна актуалізувати через консоль Control Plane. За даними для ключів звертатись до L2-L3 підтримки.

      Детальніше про оновлення ключів реєстру — див. на сторінці Оновлення ключів та сертифікатів цифрового підпису для реєстру.

      Шаблон реєстру

      Оберіть такий самий шаблон, як і шаблон цього реєстру на кластері SRC. Для отримання назви шаблону, перейдіть до Openshift-консолі > Projects > control-plane > API Explorer > У пошуку визначте codebase > Перейдіть до codebase > Instances > Відкрийте codebase <назва реєстру> > Перевірте наступні налаштування:

      Приклад 1. codebase.yaml
      metadata:
  annotations:
    registry-parameters/template-name: templates/registry-tenant-template-minimal

      • де templates/registry-tenant-template-minimal — назва шаблону розгортання реєстру.
      Якщо функціональність консолі дозволяє додати DNS для keycloak або порталів, на цьому етапі необхідно пропустити цей крок, адже трафік поки налаштований на кластер SRC).

    • Після створення, одразу перейдіть до Jenkins (namespace control-plane > Networking > Routes > jenkins), та зупиніть першу збірку MASTER-Build-<назва реєстру>.

      Дочекайтеся створення директорії <назва реєстру> та створення Jenkins-пайплайну. Після запуску одразу зробити Abort збірки.

  2. Залишаючись у консолі Jenkins, змініть конфігурацію MASTER-Build-<назва реєстру>:
    Перейдіть до MASTER-Build-<назва реєстру> > Configure, та у секції Build Triggers встановіть прапорець на параметрі Disable this project. Далі збережіть зміни кнопкою Save.

  3. Перенесіть файли конфігурації values.yaml, values.gotmpl та helmfile.yaml з репозиторію реєстру кластера SRC на кластер DEST.

    • Перейдіть до репозиторію реєстру на кластері А:
      Відкрийте Control-plane-console > Дашборд > Gerrit > Browse > Repositories > оберіть репозиторій <назва реєстру>.
      У репозиторії реєстру перейдіть до Branches > master, далі перейдіть до deploy-templates, відкрийте файл values.yaml ( values.gotmpl, helmfile.yaml) > Скопіюйте raw-код до буфера обміну.

    • Далі перейдіть до репозиторію реєстру на кластері DEST:
      Control-plane-console > Дашборд > Gerrit ) > Browse > Repositories та оберіть репозиторій <назва реєстру>. Через commands > Create change створіть зміну (change) із наступними параметрами:

      • Select branch for new change: master.

      • Description: Update registry before migration.

        Після створення зміни, у самому change натисніть Edit > ADD/OPEN/UPLOAD — знайдіть файл values.yaml (values.gotmpl, helmfile.yaml). Перенесіть до цього файлу скопійовану конфігурацію values.yaml (values.gotmpl) із кластера SRC.

    • Повторіть операцію для файлів: values.yaml, values.gotmpl та helmfile.yaml.

    • Збережіть зміни, дочекайтеся проходження пайплайну Code Review (СІ Jenkins +1), проставте Code-review +2,та виконайте злиття змін до master-гілки кнопкою Submit.

  4. Перенесіть усі версії компонент які були застосовані для реєстру як кастомізація(Gerrit гілка, Docker Image).

    Від виконання цього пункту залежить подальше відновлення рєестра

  5. Перейдіть у консоль Jenkins, змініть конфігурацію MASTER-Build-<назва реєстру>:
    Перейдіть до MASTER-Build-<назва реєстру> > Configure, та у секції Build Triggers приберіть прапорець на параметрі Disable this project. Далі збережіть зміни кнопкою Save.

  6. Заміна файла в репозиторії backup-management

    Цей розділ описує процес заміни файлу bucket-replication/templates/configmap.yaml у репозиторії backup-management.

    Кроки виконання:

    1. Знайти версію backup-management для змін:

      • Відкрити гілку cluster-mgmt.

      • Перейти у файл properties/cluster-mgmt.yaml.

      • Знайти версію у релізі backup-management, яка використовується.

    2. Зробити зміни у версії backup-management:

      Замість поточного файлу bucket-replication/templates/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}
    {{- if .Values.global.registryBackup.obc.sse }}
    server_side_encryption = aws:kms
    {{- end }}
    env_auth = true
    region = ${S3_REGION}

    [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
    rclone_command="rclone copy --progress --no-traverse --metadata --s3-no-check-bucket --transfers=16 --checkers=32 --buffer-size=32Mi"

{{- if eq .Values.registryBackup.obc.action "replication" }}

    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

    $rclone_command rook:${bucket} ${BACKUP_BUCKET}:/${BACKUP_BUCKET}/obc-backups/${REGISTRY_NAMESPACE}/${OBJECT_BUCKET_CLAIM}/

{{- else }}
    $rclone_command ${BACKUP_BUCKET}:/${BACKUP_BUCKET}/obc-backups/${REGISTRY_NAMESPACE}/${OBJECT_BUCKET_CLAIM} rook:${bucket}
{{- end }}

      Вставте цей код, замінивши поточний вказаний файл у відповідній версії backup-management.

      У випадку коли на Minio DEST кластеру увімкнене шифрування, треба зробити додаткові зміни в bucket-replication/values.yaml. Зміни передбачають додавання значення для ключа .global.registryBackup.obc.sse зі значенням true наступним чином:

      global:
  registryBackup:
    obc:
      sse: true

  7. Оновити версію edp-library-stages-fork

    1. Визначити поточну версію edp-library-stages-fork:

      • Відкрити Jenkins pipeline Restore-registry*.

      • Перейти до секції Configure у пайплайні.

      • У Pipeline script знайти поточну версію edp-library-stages-fork.

    2. Оновити репозиторій edp-library-stages-fork:

      • У файлі репозиторію edp-library-stages-fork за шляхом:

        src/com/epam/edp/customStages/impl/registrytenanttemplate/RestoreRegistry.groovy

        Знайти ряд:

        deployHelper.deployOBCBackupRestoreHelm(
        "${veleroNamespace}",
        "${backupManagementDir}/bucket-replication",
        "s3-restore-${script.env.NAMESPACE}",
        parametersMap,
        "${context.workDir}/${context.helmValuesPath}",
        true
)

        Видалити прапорець та замініть їх на:

        deployHelper.deployOBCBackupRestoreHelm(
        "${veleroNamespace}",
        "${backupManagementDir}/bucket-replication",
        "s3-restore-${script.env.NAMESPACE}",
        parametersMap,
        "${context.workDir}/${context.helmValuesPath}",
        false
)

  8. Зберегти зміни у Gerrit:

    • Перейти в репозиторій edp-library-stages-fork у Gerrit.

    • Виконати необхідні правки в файлі, створивши новий change.

    • Після цього підтвердити зміни:

      • Проставити позначки (Code-Review +2).

      • Виконати злиття змін за допомогою кнопки Submit.

  9. Перевірити оновлення:

    • Переконатися, що зміни в репозиторії збережені.

    • У Jenkins pipeline Restore-registry* підтвердити, що застосовано нову версію репозиторію edp-library-stages-fork.

      1. Змініть файл і змерджіть зміни:

    • Виконайте заміну файлу bucket-replication/templates/configmap.yaml у відповідній гілці репозиторію backup-management.

    • Надішліть зміни на Code Review.

    • Дочекайтеся підтвердження змін (Code-Review +2).

    • Натисніть Submit для злиття змін.

6. Відновлення реєстру на кластері DEST

Увімкніть доступ для кінцевих користувачів до реєстру ЛИШЕ після завершення процесу відновлення реєстру.

  1. Відрийте до Jenkins (namespace control-plane > Networking > Routes > jenkins), перейдіть до папки із назвою реєстру та запустіть Jenkins-пайплайн Restore-registry-<назва реєстру>. Після запуску пайплайну оберіть версію (на етапі cleanup-registry-before-restore) та дочекайтеся, коли процес завершиться.

    У випадку, коли процес завершується помилкою або триває понад 1-2 години, зверніться до спеціалістів команди технічної підтримки L2-L3 "ЕПАМ".

    Після внесених змін в репозиторій edp-library-stages-fork, процес відновлення реєстру запускає паралельний підпроцес відновлення бакетів реєстру. Для повного завершення процесу міграції та відновлення на кластері DEST необхідно дочекатися завершення Job з префіксом <назва-реєстру>-restore-.

    Цей процес виконується паралельно і результат його завершення впливає виключно на кінцевий результат відновлення реєстра. Очікування завершення процесу відновлення бакетів реєстру є важливим для коректного завершення процесу відновлення.

    Процесс відновлення OBC не впливає на подальші виконання кроків в інструкції.

  2. Після завершення пайплайну перейдіть в Openshift-консоль → Projects → <registry-name>, та перевірте, що немає под у статусі помилок.

    У випадку, коли пода із назвою bpms-* не запущена і має статус помилки, виправте паролі у postgres для operational-instance та analytical-instance под, для цього потрібно:

    • Перейдіть в Openshift-консоль > Secrets, знайдіть secret для operational-instance — operational-pguser-postgres (для analytical-instance — це analytical-pguser-postgres).

    • Перейдіть в Secret та скопіюйте поле password.

    • Перейдіть в Openshift-консоль > Pods > знайдіть поду operational-instance або analytical-instance та виконайте по черзі наступні команди:

      psql
      ALTER ROLE postgres WITH PASSWORD '<password>';

      • де <password> — поле password, скопійоване у Secret, для відповідного екземпляра — operational або analytical.

    • Після виконання усіх операцій, видаліть поду bpms та дочекайтеся, коли вона буде у статусі Running (активна/запущена).

    У випадку, коли пода registry-rest-api запускається з помилкою ImagePullBackOff, додайте IP кластера DEST до анотації Openshift Route > Nexus.

    • Для цього перейдіть в Openshift-консоль > Project > <назва реєстру> > Routes > Nexus > YAML та перевірте наступне поле у .yaml-конфігурації:.

      Приклад 2. route.yaml
      metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: <NAT Cluster IP>/32,....

      Якщо IP-адреса кластера DEST відсутня, додайте її до haproxy.router.openshift.io/ip_whitelist із маскою /32.

    У випадку коли пода nexus-* зі статусом CrashLoopBackOff, треба видалити поду і дочекатись коли вона буде в статусі Running.

    Якщо пода в реєстрі має статус 1/2, 0/1 або 2/3, перезапустіть поду шляхом видалення.

  3. Перенесіть користувачів.

    • В Openshift-консолі знайдіть проєкт (namespace) user-management, відкрийте Networking > Routes та перейдіть за посиланням до сервісу keycloak.

      Дані для логіну можна отримати із секретів keycloak у тому ж проєкті. Для цього перейдіть до Workloads > Secrets, знайдіть у пошуку секрет із назвою keycloak, та у розділі Data скопіюйте дані для входу до сервісу.

      Перейдіть в адмін-консоль Keycloak, перейдіть до реалму (1), та у лівому меню реалму оберіть Import (2) (при імпорті оберіть стратегію SKIP), далі натисніть Select file (3) та виберіть файл із директорії keycloak-export-<назва реєстру>/<ім’я реалму>-users-*.json.

      Перенесення користувачів треба повторити для усіх реалмів реєстру.
      Якщо файлів більше одного, то виконайте імпорт усіх файлів.
    image
    Зображення 5. File import

  4. Перенесіть конфігурацію реєстру до values.yaml/values.gotmpl.

    • Увійдіть до control-plane-gerrit (Openshift-консоль > Projects → control-plane → Networking → gerrit > Логін через openshift-sso).

      У Gerrit перейдіть до Browse > Repositories та оберіть репозиторій <назва реєстру>. Через commands > Create change створіть зміну (change) із наступними параметрами:

      • Select branch for new change: master.

      • Description: Update registry after migration.

        Після створення change, у самому change натисніть Edit.

    • Додайте конфігурацію vault у values.gotmpl.

      Для цього візьміть актуальну конфігурацію vault з config-map hashicorp-vault-config (Openshift-консоль > Projects > <назва реєстру> > Workloads > ConfigMaps > hashicorp-vault-config) та скопіюйте поле як у наступному прикладі:

      ui = true

listener "tcp" {
  tls_disable = 1
  address = "[::]:8200"
  cluster_address = "[::]:8201"
}
storage "file" {
  path = "/vault/data"
}
seal "transit" {
   address         = "https://<vault url>"
   disable_renewal = "false"
   key_name        = "<key name>"
   mount_path      = "transit/"
   tls_skip_verify = "true"
}

    • де <vault URL> — посилання до vault, <key name> — назва ключа (у конфігурації з config-map поле не актуальне, треба замінити на autounseal-<назва реєстру>-migration>).

      У випадку, коли реєстр попередньо був мігрований на кластер SRC, а не розгорнутий на цій Платформі, <key name> буде дорівнювати <VAULT_KEY>-<назва реєстру>-migration>, де VAULT_KEY - це зміна оточення з пункту 4.3.

    • Далі в change натисніть ADD/OPEN/UPLOAD, у пошуку вкажіть values.gotmpl та виберіть потрібний файл. В самому файлі додайте конфігурацію як у прикладі:

      vault:
  platformVaultToken: {{ env "platformVaultToken" }}
  openshiftApiUrl: {{ env "openshiftApiUrl" }}
  centralVaultUrl: {{ b64dec $centralVaultUrl }}
  server:
    dataStorage:
      storageClass: ocs-storagecluster-ceph-rbd
    auditStorage:
      storageClass: ocs-storagecluster-ceph-rbd

    standalone:
      config: |
       ui = true

       listener "tcp" {
         tls_disable = 1
         address = "[::]:8200"
         cluster_address = "[::]:8201"
       }
       storage "file" {
         path = "/vault/data"
       }
       seal "transit" {
          address         = "https://<vault url>"
          disable_renewal = "false"
          key_name        = "<key name>"
          mount_path      = "transit/"
          tls_skip_verify = "true"
       }

    • Після додавання натисніть Save.

    • Змініть розмір kafka-дисків. Залишаючись у цьому файлі, знайдіть поле:

      storage:
  zookeeper:
    size: 5Gi
  kafka:
    size: 20Gi

    • Змініть розмір kafka.size відповідно до розміру актуального диска в Openshift-консолі (Openshift-консоль > Project → <назва реєстру> → Storage > PersistentVolumeClaims ). У пошуку знайдіть data-0-kafka-cluster-kafka-0 та його Capacity. Поверніться до редагування values.gtmpl та встановіть бажаний розмір диска:

      storage:
  zookeeper:
    size: 5Gi
  kafka:
    size: 40Gi

      • де 40Gi - актуальний розмір диска з Capacity.

    • Видаліть усіх GerritGroupMember. Для цього виконайте вхід до кластера DEST через ос cli та виконати наступну команду:

      oc -n <назва-реєстру> delete gerritgroupmember --all

  5. Після застосування змін має запуститися Jenkins-процес MASTER-Build-<назва реєстру>.

  6. Після з завершення Jenkins-пайплайну MASTER-Build-<назва реєстру>, виправте Jenkins Credentials у Jenkins реєстру.

    У випадку, коли доступу немає, додайте себе як адміністратора реєстру через control-plane-console.

    • Для цього перейдіть в Openshift-консоль > Projects > <назва реєстру> > Workloads > Secrets > gerrit-control-plane-sshkey та скопіюйте поле id_rsa.

    • Після цього перейдіть у реєстровий Jenkins (Networking > Routes > jenkins) > Manage Jenkins > Manage Credentials > gerrit-ci-users-sshkey (gerrit-control-plane-sshkey) > натисніть Update.

    • У полі Private Key за допомогою Replace вставте скопійоване значення.

  7. Оновіть посилання на Nexus у репозиторії регламенту.

    Для цього перейдіть до Openshift-консолі > Project → <назва реєстру> > Gerrit та виконайте логін.

    Далі перевірте наявність доступу до проєктів у Gerrit та клонуйте локально репозиторій registry-regulations. Для цього:

    • У вебінтерфейсі Gerrit, перейдіть у налаштування > HTTP Credentials > згенеруйте новий пароль за допомогою Generate New Password, та збережіть цей пароль у нотатках.

    • Перейдіть до репозиторію registry-regulations > та скопіюйте команду для клону Anonymous HTTP > Clone with commit-msg hook.

    • Вставте команду для клону репозиторію до термінала та виконайте. Команда запитає логін та пароль. Логін в цьому випаду буде ваш email, а пароль — той, який ви згенерували у першому підпункті.

      Детальніше про роботу з репозиторієм Gerrit див. на сторінці Операції з регламентом в Gerrit.

      Якщо в системі git user відрізняється від вашого user на сервері Gerrit, виконайте наступні команди:

      git config --global user.name "New Author Name"
git config --global user.email "<email@address.example>"

      Наприклад:

      git config --global user.name "Jonh Doe"
git config --global user.email "jong_doe@doemail.com"

  8. Змініть мінорну версію в settings.yaml у кореневій (root) директорії репозиторію registry-regulations згідно із приладом:

    settings:
  general:
    package: ua.gov.mdtu.ddm.dataplatform.template
    register: registry
    version: 2.21.0

    Наприклад, додайте до версії +1:

    settings:
  general:
    package: ua.gov.mdtu.ddm.dataplatform.template
    register: registry
    version: 2.21.1

  9. Замініть згадування DNS-кластера SRC на кластер DEST. Для цього у терміналі перейдіть до директорії registry-regulations/data-model

    cd registry-regulations/data-model

    Та виконайте наступну команду по заміні DNS:

    find "." \( -type d -name .git -prune \) -o -type f -print0 | xargs -0 sed -i -e  's/<Cluster SRC DNS wildcard> /<Cluster DEST DNS Wildcard> /g'

    Cluster SRC DNS wildcard/Cluster DEST DNS wildcard — це apps.* (наприклад, apps.reestr1.eua.gov.ua). Як повинно виглядати sed правило:

    's/apps.cluster-a.dns.wildcard.com/apps.cluster-b.dns.wildcard.com/g'

  10. Виконайте commit змін та push до репозиторію:

    git add --all
    git commit -m "Update nexus URL"
    git push origin refs/heads/master:refs/for/master

  11. Перейдіть у реєстровий Gerrit, проставте відмітки Code-Review +2, та за допомогою кнопки Submit застосуйте зміни до master-гілки.

  12. Після внесення змін до master-гілки перейдіть до Jenkins реєстру та перевірте, що Jenkins-пайплайни у Jenkins Folder registry-regulations завершилися зі статусом Success.

7. Перевірка реєстру

  1. Переконайтеся, що Кабінети користувачів працюють у штатному режимі, та бізнес-процеси мігрували успішно.

  2. Усі Jenkins pipeline мають завершитися зі статусом Success.

8. Перенесення конфігурації реєстру

Перенесіть конфігурацію реєстру із кластера SRC на кластер DEST відповідно до документації: