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

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

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

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

Одночасний доступ до кластера А та кластера B.

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

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

ssh sshmyip.com

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

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

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

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

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

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

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

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

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

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

export A_CLUSTER_LOGIN="oc login --token …"

export B_CLUSTER_LOGIN="oc login --token …"

export REGISTRY_NAME="abc-02"

export BACKUP_NAME="<назва резервної копії>"

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

export LARGE_DATA="true"

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

unzip registry-migration.zip -d registry-migration

chmod +x ./migration.sh && ./migration.sh

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

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

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

Перенесіть файли конфігурації values.yaml та values.gotmpl з репозиторію реєстру кластера А на кластер B.

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

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

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

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

Зображення 5. File import

Перенесіть конфігурацію реєстру до values.yaml/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"
       }

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

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

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

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

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

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

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

cd registry-regulations/data-model

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

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

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

git add --all

git commit -m "Update nexus URL"

git push origin refs/heads/master:refs/for/master

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

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

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

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