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

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

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

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

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

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

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

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

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

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

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

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

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

    • oc

    • velero

    • rclone

    • vault

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Експорт назви реєстру
    export REGISTRY_NAME="<назва реєстру>"
    Приклад назви реєстру: abc-02.
    Експорт назви резервної копії
    export BACKUP_NAME="<назва резервної копії>"
    Приклад назви резервної копії: abc-02-2023-04-18-19-03-14.

  4. Збережіть архів, розархівуйте його до бажаної директорії, та перейдіть в цю директорію (cd) та виконайте наступну команду:

    chmod +x && ./migration.sh

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

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

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

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

  1. Перенесіть реалми.

    Для перенесення реалмів, виконайте вхід до Keycloak на кластері B:

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

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

    • За допомогою Select realm (1) > Add realm (2) > Import (3), виберіть файл keycloak-export-<назва реєстру>-/-realm.json та створити реалми. Так пройдіться по усіх директоріях із назвою keycloak-export-<назва реєстру>-*.

    image

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

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

    Якщо файлів більше одного, то виконайте імпорт усіх файлів.

    image

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

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

      Якщо функціональність консолі дозволяє додати DNS для keycloak або порталів, на цьому етапі необхідно пропустити цей крок, адже трафік поки налаштований на кластер A).

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

  4. Перевірка наявності CustomResourceDefintition.

    Якщо до цього на кластері не було жодного реєстру, обов’язково перевірте наявність існування CustomResourceDefintition. Для цього виконайте логін через oc cli на кластері B та виконати наступну команду:

    oc get customresourcedefinition ingressclassparameterses.configuration.konghq.com

    Якщо команда завершиться з помилкою та видасть у консолі No resources found, то перейдіть до директорії, де знаходиться скрипт migration.sh, та з кореневого шляху виконайте наступну команду:

    for file in $(ls crds); do oc apply -f crds/$file; done

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

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

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

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

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

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

    • Для цього перейдіть в Openshift Project > <назва реєстру> → 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 вставте скопійоване значення.

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

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

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

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

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

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

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

    cd 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'
    Cluster A DNS wildcard/Cluster B DNS wildcard — це apps.* (наприклад, apps.reestr1.eua.gov.ua).

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

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

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

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

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

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

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

У випадку будь-яких проблем із міграцією, зверніться до Anatolii_Stoliarov@epam.com.