Ідемпотентне розгортання регламенту реєстру

1. Введення

Ця документація описує процес ідемпотентного розгортання регламенту реєстру, який розв’язує проблему неконсистентності стану регламенту через ігнорування неуспішних кроків у попередніх запусках пайплайну. Мета цього процесу - забезпечити, що всі зміни в регламенті застосовуються надійно та послідовно.

2. Проблематика

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

3. Ідемпотентний підхід

3.1. Реалізація та збереження чексум

На Платформі впроваджено ідемпотентний підхід, що включає:

  • Порівняння станів регламенту: поточний стан регламенту порівнюється зі станом на момент останнього успішного виконання кроку.

  • Генерування та зберігання чексум: чексуми директорій та файлів регламенту генеруються з використанням алгоритму шифрування SHA256 та зберігаються як секрети.

Перегляд збережених чексум:

Адміністратор реєстру може переглянути ці секрети через Вебінтерфейс управління кластером OpenShift:

  1. Відкрийте консоль OpenShift .

  2. Перейдіть до розділу Workloads > Secrets.

  3. Знайдіть секрет registry-regulations-state. У розділі Data ви зможете переглянути чексуми відповідних компонентів розгортання регламенту.

    idempotant deployment 1

3.2. Практичне застосування

  1. Внесіть зміни до версії-кандидата регламенту, наприклад, створіть новий бізнес-процес (див. детальніше — Створення бізнес-процесів).

  2. Перевірте та застосуйте зміни до мастер-версії (див. детальніше — Перегляд та управління налаштуваннями версії-кандидата).

    Jenkins і MASTER-Build-пайплайн:

  3. Перейдіть до сервісу Jenkins за посиланням у Кабінеті адміністратора регламентів.

    idempotant deployment 3

  4. У пайплайні MASTER-Build-registry-regulations кожен крок перевіряє чексуми файлів директорій.

    idempotant deployment 2

    Крок розгортання повторно запускається, якщо:

    1. У секреті відсутній крок з таким ім’ям.

    2. Чексума для хоча б однієї з директорій відрізняється від чексуми в секреті.

    3. Відсутня інформація про чексуму файлу у секреті.
    Залежні директорії:

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

3.3. Примусове розгортання

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

Запуск пайплайну публікації регламенту — MASTER-Build-registry-regulations — з активованою опцією FULL_DEPLOY дозволяє правильно і повністю розгорнути регламент.

cleanup job 4

4. Відстеження змін та збереження даних після розгортання

У нашому прикладі створено бізнес-процес, а тому зміни стосуються директорії bpmn. Відповідно коли в директорію bpmn регламенту реєстру вносяться зміни, автоматично запускається крок upload-business-process-changes. Ви можете побачити відповідні записи у логах виконання пайнлайну.

idempotant deployment 4
Зображення 1. Перевірка успішного розгортання змін до bpmn

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

idempotant deployment 5
Зображення 2. Кроки, де зміни до файлів не виявлено
Після кроку розгортання:

  • Запускається утиліта, що зберігає назву кроку, перелік директорій та чексуми у форматі JSON до секрету.

    Приклад. Збереження чексуми до секрету для схеми бізнес-процесу у bpmn
    {
  "bpmn/a-new-bp-test.bpmn": "d206ee947a1f92946401a908f713398066b46f4c85e88c2bff9c27540a15461c"
}

  • Після успішного збереження, статус кроку розгортання позначається як успішно пройдений.

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