Збірка матеріалів для навчання технічних адміністраторів реєстру

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

Ми надаємо можливість не лише теоретично ознайомитися з навчальними матеріалами, а й перевірити на практиці роботу та налаштування всього, що описано на цій сторінці, за допомогою тестового реєстру. Його може розгорнути Адміністратор Платформи в окремому проєкті (namespace) на Платформі.

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

Окрім цього, Адміністратор Платформи може розгорнути для вас демо-реєстр — еталонний реєстр, що містить референтні та інші приклади для створення цифрового регламенту. Він містить різноманітні елементи для розробки моделі даних, бізнес-процесів, UI-форм, аналітичної звітності, витягів, сповіщень, зовнішніх інтеграцій та багато іншого.

Детальну інструкцію по розгортанню демо-реєстру ви знайдете на сторінці Розгортання демо-реєстру із референтними прикладами.

1. Вступ

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

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

Також надається детальний огляд централізованого адміністративного інтерфейсу для керування реєстрами — адмін-панелі Control Plane. Пояснюється процес створення адміністраторів реєстру з необхідними правами доступу.

Навчальний матеріал також звертає увагу на управління користувачами та доступом до реєстру через інструмент автентифікації та авторизації користувачів, відомий як Keycloak.

Курс охоплює такі теми, як процеси автентифікації для кінцевих користувачів, резервне копіювання та відновлення компонентів реєстру, включаючи базу даних, з використанням автоматизованих процесів у Jenkins.

Пояснюється процес оновлення компонентів реєстру, керування ресурсами сервісів реєстру, інтеграція з іншими реєстрами та зовнішніми системами за допомогою REST та SOAP API.

Курс надає знання про налаштування ключів і сертифікатів цифрового підпису для реєстру, налаштування доменних імен для вебпорталів реєстру та сервісу Keycloak.

Також пояснюється, як обмежувати доступ до компонентів реєстру за допомогою CIDR, підтверджувати або відхиляти запити на зміни реєстру (Merge Requests).

Курс також включає адміністрування бізнес-процесів з використанням Camunda BPM, налаштування та використання VCS git та Gerrit, а також управління налаштуваннями та лімітами доступу (rate limits) до внутрішніх ресурсів з використанням Kong API-шлюзу.

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

2. Обов’язки та вимоги до адміністратора реєстру

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

Детальніше ви можете ознайомитися на сторінці Посадова інструкція для адміністратора реєстру.

3. Хто такий адміністратор реєстру та як він з’являється на Платформі

Адміністратор Платформи створює реєстр і додає найпершого адміністратора цього реєстру. Надалі такий адміністратор реєстру створює інших адміністраторів.

Надалі адміністратори мають змогу працювати з реєстром, зокрема вони можуть редагувати налаштування шляхом внесення змін до конфігурації реєстру.

Ознайомтеся з роллю технічного адміністратора реєстру та зоною його відповідальності на прикладі Структурної діаграми Платформи.

4. Як розгортається реєстр та як оновлюється його конфігурація

Розгортання та оновлення конфігурацій реєстрів відбувається за GitOps-підходом.

Що таке GitOps-підхід?

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

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

Основні конфігурації реєстру зберігаються у файлі deploy-templates/values.yaml компонента control-plane-gerrit, у Gerrit-репозиторії вашого реєстру. Gerrit-репозиторій є системою рецензування коду, що побудована на базі git VCS.

Частина конфігурацій також зберігається у файлах:

  • deploy-templates/helmfile.yaml — налаштування helm-релізів для компонентів реєстру.

  • deploy-templates/values.gotmpl — налаштування розміру дисків компонентів реєстру.

За розгортання конфігурацій реєстру відповідає компонент control-plane-jenkins, а саме автоматизований Jenkins-процес (також — job) MASTER-Build-<registry-name>, де <registry-name> — назва реєстру. Цей процес запускається за подією git merge змін до master-гілки репозиторію вашого реєстру у центральному компоненті Gerrit Платформи.

Власне налаштування вносяться до реєстру через зручний інтерфейс компонента Control Plane — адміністративної панелі керування Платформою та реєстрами (див. детальніше у розділі Керування реєстрами в адміністративній панелі Control Plane).

5. Що необхідно для початку роботи

5.1. Налаштування локального середовища

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

Назва інструмента Призначення

Git та Git Bash-консоль

Система контролю версій (VCS) та консоль, яка необхідна для роботи із git-репозиторіями (Gerrit, GitHub, GitLab тощо) за допомогою git-команд.

Середовище розробки (IDE):

- VSCode

- IntelliJ IDEA

Середовище розробки надає зручний візуалізований інтерфейс для роботи з регламентом у локальному Gerrit-репозиторії.

Оберіть одне з двох на вибір.

Camunda Modeler, плагіни й типові розширення бізнес-процесів

Настільний застосунок Camunda Modeler для локального перегляду та моделювання бізнес-процесів, плагіни й типові розширення до нього.

Текстовий редактор:

- Notepad++

- Sublime Text

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

Оберіть одне з двох на вибір.

Postman

Інструмент для розробки та тестування API. Він надає зручне середовище для створення, надсилання, тестування та документування HTTP-запитів.

За допомогою Postman можна легко взаємодіяти з різними типами API, включаючи REST, SOAP, GraphQL та інші. Інтерфейс Postman є інтуїтивно зрозумілим і має багато корисних функцій, які допомагають розробникам простіше працювати з API, зокрема:

- Взаємодія з Keycloak API (для управління користувачами, перевірки та відлагодження автентифікації тощо).

- Взаємодія з API бізнес-процесів та Фабрики даних для емуляції виклику реєстру зовнішніми системами через REST або SOAP API.

- Взаємодія з Redash API для створення візуалізацій, дашбордів при роботі з аналітичною звітністю у реєстрі.

DBeaver

Інструмент, який надає зручний і потужний інтерфейс для управління різними типами баз даних. Він є безплатним та з відкритим вихідним кодом (Open Source) і доступний для використання на різних операційних системах, включаючи Windows, macOS і Linux.

DBeaver підтримує багато різних типів баз даних, включаючи відомі системи, зокрема MySQL, PostgreSQL, Oracle та багато інших.

OpenShift CLI

OpenShift CLI (Command-Line Interface) — це інструмент командного рядка, який надає доступ до управління та взаємодії з кластером OpenShift.

OpenShift CLI надає доступ до різних команд, які можна виконувати з командного рядка. Ці команди дозволяють керувати різними аспектами OpenShift.

5.2. Інструменти розробки: робоче середовище

Адміністративна панель Control Plane надає адміністраторам та розробникам реєстру зручний спосіб доступу до всіх необхідних інструментів в одному місці.

У розділ Реєстри ви побачите вкладку Швидкі посилання. Тут представлені посилання до вебінтерфейсів різних сервісів з коротким описом їх призначення.

quick links 1

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

6. Керування реєстрами в адміністративній панелі Control Plane

Адміністративна панель Control Plane — центральний інтерфейс, відправна точка для адміністраторів реєстру, що надає повний доступ до необхідних сервісів для ефективного виконання адміністративних функцій. За його допомогою ви контролюєте ресурси, конфігурації та інструменти, необхідні для повноцінного управління реєстром, а також легко і просто здійснюєте переходи до інших важливих сервісів Платформи.
control plane overview

Control Plane дозволяє керувати конфігураціями двох типів компонентів, які розгортаються на Платформі:

  • інфраструктурні компоненти — управління здійснює адміністратор Платформи;

  • компоненти реєстру — управління здійснює адміністратор реєстру.

Адміністратор реєстру має доступ до вкладки Реєстри та може редагувати налаштування реєстру і його складові (регламент — registry-regulations).

Основні реєстрові налаштування зберігаються у файлі deploy-templates/values.yaml компонента control-plane-gerrit, у Gerrit-репозиторії вашого реєстру. Gerrit-репозиторій є системою рецензування коду, що побудована на базі git VCS.

Частина конфігурацій також зберігається у файлах:

  • deploy-templates/helmfile.yaml — налаштування helm-релізів для компонентів реєстру.

  • deploy-templates/values.gotmpl — налаштування розміру дисків компонентів реєстру.

6.1. Редагування конфігурації реєстру

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

Детальніше про це дивіться на сторінці Перегляд та внесення змін до конфігурації реєстру

6.2. Створення та видалення адміністраторів реєстру

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

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

Після Створення адміністраторів Платформи та розгортання реєстру, можна додавати адміністраторів цього реєстру.

Найпершого службового адміністратора реєстру має створити адміністратор Платформи з відповідними правами доступу. Надалі службовий адміністратор реєстру може додавати інших адміністраторів реєстру самостійно.
Детальніше про створення адміністраторів та призначення їм прав доступу див. на сторінці Створення адміністраторів реєстру.

6.3. Налаштування ключів та сертифікатів цифрового підпису

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

Секція Дані про ключ має містити налаштування для ініціалізації криптосервісу (под digital-signature-ops) та накладання системного підпису (цифрової печатки системи). Без внесення цих даних под криптосервісу не запуститься.

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

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

6.4. Керування ресурсами реєстру

Адміністративна панель Control Plane надає можливість гнучко та ефективно керувати ресурсами, що використовуються контейнерами в рамках вашого екземпляра реєстру, забезпечуючи оптимальну працездатність та ефективність.

Ви можете регулювати значення ресурсів, що виділяються для певних сервісів реєстру, зокрема bpms, redis, kong, restApi, soapApi тощо. Система дозволяє встановлювати власні значення оперативної пам’яті (RAM) та кількості залучених ядер (CPU), також керувати змінними оточення (environment variables).

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

6.5. Налаштування власних DNS-імен

В адміністративному інтерфейсі керування Платформою та реєстрами Control Plane реалізовано можливість використання власного DNS-імені для публічних Кабінетів отримувача послуг та посадової особи.

Щобільше, ви можете налаштувати власні DNS-імена для сервісу управління користувачами та ролями Keycloak. Це дозволяє створити зручні URL-адреси для входу користувачів та забезпечує правильну роботу аутентифікації та міжсервісної взаємодії у приватних мережах.

Детальна інформація доступна у розділі Налаштування власних DNS-імен.

6.6. Обмеження доступу до компонентів реєстру (CIDR)

Задля безпечного доступу до компонентів (API-роутів) кластера OpenShift 4.x, можна обмежувати доступ до компонентів, що використовуються на Платформі.

Можна виділити 3 основних типи компонентів у системі, до яких можна обмежити доступ :

  • Платформні

  • Реєстрові

  • Інфраструктурні

Адміністратор реєстру має змогу налаштувати CIDR для реєстрових компонентів (роутів) через консоль Control Plane.

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

6.7. Налаштування автентифікації користувачів

Ви можете налаштувати автентифікацію для двох ключових груп користувачів: посадових осіб (надавачів послуг) та отримувачів послуг. Всі налаштування виконуються через консоль Control Plane, яка надає зручний єдиний інтерфейс для основних конфігурацій реєстру.

Платформа дозволяє адміністраторам налаштувати тип автентифікації для Кабінету посадової особи, використовуючи власний IIT-віджет для аутентифікації за допомогою КЕП або інтегруючись із зовнішнім провайдером, таким як ID.GOV.UA (ICEI). В результаті, посадові особи реєстру зможуть використовувати один з двох типів автентифікації при вході до Кабінету: або КЕП, або ID.GOV.UA.

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

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

Щодо отримувачів послуг, система передбачає можливість налаштування перевірки наявності активного запису в ЄДР для бізнес-користувачів. Такий механізм забезпечує зв’язок між КЕП користувача та їх юридичною особою чи фізичною особою-підприємцем, зареєстрованими в Єдиному державному реєстрі (ЄДР). Він відіграє важливу роль у забезпеченні відповідності даних користувача та підтвердження їх особистості, що є важливим аспектом безпеки та надійності системи.

Детальніше про це дивіться на сторінці Налаштування автентифікації отримувачів послуг.

6.8. Керування обмеженнями на завантаження цифрових документів

Адміністративна панель Control Plane надає зручний інтерфейс, який дозволяє адміністраторам керувати обмеженнями на завантаження цифрових документів до реєстру користувачами та бізнес-процесами.

Ви можете визначати на рівні реєстру Максимальний розмір файлу для завантаження (MB), а також Максимальний сумарний розмір групи файлів для завантаження (MB) до системи.

Детальніше про це дивіться на сторінці Керування обмеженнями на завантаження цифрових документів.

6.9. Налаштування взаємодії із зовнішніми системами

Адміністратор реєстру має змогу конфігурувати взаємодію із зовнішніми системами в інтерфейсі Control Plane.

Платформа дозволяє гнучко інтегруватися з іншими реєстрами та системами й підтримує 2 типи взаємодії:

SOAP API

Взаємодія через інтерфейси ШБО "Трембіта" за допомогою SOAP-інтеграційних конекторів. Це основний тип інтеграційної взаємодії.

Екземпляр ШБО встановлюється один для всіх реєстрів, у тому ж центрі обробки даних (ЦОД), що й екземпляр Платформи. Кожна подібна зовнішня система повинна мати встановлений екземпляр ШБО на своїй стороні та бути зареєстрованим учасником єдиного захищеного простору, який називають СЕВ ДЕІР "Трембіта", де основним протоколом інтеграційної взаємодії є SOAP.

REST API

Взаємодія з іншими реєстрами на Платформі та зовнішніми системами поза її межами через REST-інтерфейси. Це додатковий тип підключення розширення можливостей інтеграційної взаємодії.

Більш детальну інформацію щодо налаштування зовнішніх інтеграцій ви можете отримати на сторінках:

6.10. Обмеження доступу на рівні IP до SOAP-роутів ШБО "Трембіта"

Ви можете регулювати доступ до SOAP API-інтерфейсів реєстру через адміністративну панель Control Plane.

SOAP-інтерфейси використовуються для вхідної взаємодії із зовнішніми системами через Шлюз Безпечного Обміну (ШБО) "Трембіта", коли зовнішня система хоче отримати дані з вашого реєстру.

На рівні інфраструктури Платформи такі SOAP-інтерфейси називають роутами (routes). Кожен роут є відповідним API-сервісом, який розгортається на певному хості (host) та має свій унікальний шлях (path), до якого й обмежується доступ.

Детальніше про це дивіться на сторінці Обмеження доступу на рівні IP до SOAP-роутів ШБО "Трембіта".

6.11. Налаштування поштового сервера

Ви можете налаштувати з’єднання із попередньо налаштованим поштовим сервером в інтерфейсі Control Plane на етапах створення та редагування реєстру. Усі налаштування поштового сервера виконує адміністратор Платформи.

Адміністратор реєстру може налаштувати підключення до такого сервера в інтерфейсі Control Plane для відправлення поштових повідомлень користувачам реєстру.

Наразі Платформа підтримує одну з наступних опцій налаштувань поштового сервера, залежно від вимог реєстру:

  • Внутрішній поштовий сервер (platform-mail-server) — поштовий сервер, який розповсюджується як платформний сервіс та доступний для використання усіма реєстрами одного екземпляра Платформи.

  • Зовнішній поштовий сервер (external-mail-server) — зовнішній відносно Платформи поштовий сервіс (Gmail, тощо).

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

7. Внесення користувачів до реєстру

Усі користувачі Платформи створюються у проєкті user-management, у сервісі управління користувачами та доступом Keycloak. Вони створюються в різних реалмах[1], залежно від повноважень. При наданні доступу, на Платформі діє принцип мінімальних привілеїв.

Можна виділити 3 основних типи користувачів у реєстрі:

  • Адміністратор реєстру

  • Посадова особа

  • Отримувач послуг

Окремо варто визначити 4-й тип — системні користувачі, які використовуються для взаємодії "система-система" при зовнішніх API-інтеграціях.

Виділяють кілька основних реалмів для зберігання користувачів реєстру у Keycloak:

Таблиця 1. Реалми реєстру та їх призначення
Realm Призначення

-admin

Реалм для доступу до адміністративних інструментів, таких як Gerrit, Jenkins та Camunda реєстру.

-officer-portal

Призначення ролей для доступу до Кабінету посадової особи (Officer Portal) та звітів (Redash).

-citizen-portal

Призначення ролей для доступу до Кабінету отримувача послуг (Citizen Portal).

-external-system

Призначення ролей для взаємодії із зовнішніми системами

Наприклад, "Трембіта" та ін.

Повна назва реалму складається із назви вашого реєстру та відповідного суфікса. Наприклад, <registry-name>-officer-portal.

realms list

Детальну інформацію щодо створення користувачів ви можете отримати у розділі Внесення користувачів до системи.

8. Резервне копіювання та відновлення реєстру та його компонентів

Після успішного розгортання реєстру та регламенту, адміністратор має можливість створити резервну копію (бекап) реєстру. За створення бекапів на Платформі відповідає механізм Velero, який зберігає резервні копії до захищеного об’єктного сховища бекапів — Minio.

Платформа передбачає два типи резервного копіювання для середовища реєстру:

  • Ручне резервне копіювання

  • Автоматичне резервне копіювання

За створення резервних копій компонентів реєстру відповідає автоматизований Jenkins-процес Create-registry-backup.
Відновити реєстр зі створеної резервної копії можна за допомогою Jenkins-процесу Restore-registry.

Додатково система реплікує деякі дані бізнес-процесів. Ці дані зберігаються у вигляді ObjectBucketClaim (obc) в S3-бакетах. Реплікація цих бакетів відбувається автоматично та полягає в автоматичному копіюванні даних з одного бакета до іншого, що може бути корисним, наприклад, для створення резервних копій даних в інших географічних регіонах, що забезпечує високу доступність та надійність. Ви можете налаштувати резервне копіювання для таких реплікацій через адміністративну панель Control Plane.

Детальніше про резервне копіювання ви можете дізнатися на сторінках:

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

Відновити базу даних реєстру таким шляхом може лише адміністратор Платформи.

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

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

Керування оновленнями реєстру відбувається за підходом GitOps. Це означає, що будь-які зміни у конфігурації реєстру, або його компонентах відбуваються через внесення змін до конфігурації відповідного компонента у git-гілці цього компонента. Кожен компонент є окремим git-репозиторієм.

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

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

Перейдіть до розділу Оновлення компонентів Платформи та реєстру, щоб розпочати процес.

10. Логування подій (Kibana)

Адміністратор реєстру може використовувати інструмент Kibana, яка є частиною EFK-стека (Elasticsearch, Fluentd, Kibana) для логування в системі. EFK-стек відповідає за збір, обробку та візуалізацію журналів подій (логів), що сприяє прозорості та відстеженню стану системи.

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

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

Детальніше з особливостями логування ви можете ознайомитися на сторінках:

11. Моніторинг метрик Платформи (Grafana)

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

Детальніше з особливостями моніторингу ви можете ознайомитися на сторінці Моніторинг показників виконання бізнес-процесів.

12. Адміністрування та відлагодження бізнес-процесів

Для адміністрування бізнес-процесів адміністратор реєстру використовує сервіс Business Process Administration Portal, також відомий як Camunda Cockpit.

Camunda Cockpit є потужним інструментом для керування та моніторингу бізнес-процесів на платформі Camunda BPM, що допомагає адміністраторам та користувачам ефективно управляти своїми процесами та забезпечувати їхню оптимальну продуктивність.

Основні функціональні можливості Camunda Cockpit включають:

  • Моніторинг бізнес-процесів: Cockpit надає графічне представлення активних та завершених екземплярів процесів, дозволяючи адміністраторам переглядати стан процесів, їх послідовність, час виконання та іншу важливу інформацію.

  • Аналіз діаграм процесів: Cockpit дозволяє переглядати та аналізувати діаграми бізнес-процесів, що допомагає зрозуміти послідовність кроків, умови та дії, які відбуваються під час виконання процесу.

  • Моніторинг таймерів та подій: Cockpit дозволяє переглядати активні таймери та події, які використовуються у процесах, а також їхній стан та час спрацювання.

  • Перегляд журналу активності: Cockpit надає можливість переглядати журнал активності, що містить інформацію про події, які відбуваються під час виконання процесів, такі як завдання, зміна стану тощо.

  • Керування процесами: Cockpit дозволяє адміністраторам призначати завдання, відновлювати призупинені процеси, розв’язувати проблеми зі станом процесу та виконувати інші дії для керування процесами.

  • Перегляд статистики та звітів: Cockpit надає можливість переглядати статистику процесів, таку як середній час виконання, кількість завершених інстанцій, час очікування тощо. Також можна генерувати звіти для аналізу та моніторингу ефективності бізнес-процесів.

Дивіться детальніше про це на сторінці Адміністрування бізнес-процесів у Camunda Cockpit.

13. Робота з геоданими

Адміністратори реєстрів та розробники регламенту мають змогу налаштовувати роботу із геопросторовими даними[2] у рамках бізнес-процесів завдяки геомодулю ГІС[3], який був імплементований у систему.

Модуль ГІС розгортається автоматично, разом із реєстром, із шаблону geo-server.

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

14. Робота з регламентом реєстру

Адміністратори мають розуміти специфіку роботи з регламентом реєстру. Регламент — набір сутностей, які визначають логіку роботи реєстру, зокрема модель даних, бізнес-процеси, UI-форми введення даних тощо.

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

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

  1. Під час роботи безпосередньо із Gerrit-репозиторієм реєстру. У такому випадку ви працюєте з Git та каталогами файлів регламенту напряму.

    Детальніше про роботу з регламентом у Gerrit читайте на сторінках:

    На Платформі розгортається 2 Gerrit-сервіси:

    • Центральний Gerrit — містить код для розгортання компонентів усіх реєстрів на Платформі. Управляється адміністратором Платформи.

    • Gerrit реєстру — містить регламент певного реєстру. Управляється адміністраторами та розробниками реєстру.

  2. Під час роботи у Кабінеті адміністратора регламентів, відомому також як адміністративний портал (admin-portal).

    Детальніше про роботу з регламентом у Кабінеті адміністратора регламентів читайте на сторінках розділу Кабінет адміністратора регламентів).

Розгортання регламенту — автоматизований процес, що має назву MASTER-Build-registry-regulations. Він запускається сервісом Jenkins автоматично, після внесення змін до master-гілки Gerrit-репозиторію з регламентом.

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

Детальніше зі сценаріями спрацьовування перевірки ви можете ознайомитися на сторінці Автоматична валідація змін до регламенту.

Насамкінець, Платформа надає можливість видалити або частково очистити регламент вашого реєстру. Для цього передбачений Cleanup-процес (cleanup-job) у Jenkins — автоматизований процес, розроблений для підтримки оптимального стану регламенту реєстру шляхом видалення застарілих або непотрібних даних, ресурсів та компонентів. Процес включає очищення тимчасових реплік БД, які розгортаються для версій-кандидатів, видалення ресурсів та сервісів, очищення репозиторію Nexus, а також можливість вибору додаткових опцій відповідно до потреб адміністратора.

Використовуйте cleanup лише на середовищах розробки реєстрів. Рекомендуємо НЕ запускати Cleanup-процес на виробничих середовищах, оскільки це може призвести до втрати важливих даних.
Детальніше із процесом очищення регламенту ви можете ознайомитися на сторінці Cleanup-процес видалення регламенту.

15. Використання демо-реєстру при розробці цифрового регламенту

Адміністратор реєстру може використовувати демо-реєстр як еталонний зразок для роботи із цифровим регламентом.

Регламент демо-реєстру включає референтні приклади, які позначені префіксом reference-, та приклади для тестування, позначені префіксом feature-. Це можуть бути зразки .bpmn-схем бізнес-процесів, .json-форм для внесення даних до процесів, а також .xml-схем для розгортання моделі даних реєстру тощо.

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

Якщо такий реєстр вже розгорнуто, зверніться із запитом про надання доступу.

16. Автентифікація користувачів реєстру

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

  • drfo (РНОКПП) — ідентифікаційний номер, або серія і номер паспорта особи.

  • edrpou (ЄДРПОУ) — код організації, до якої належить особа.

  • fullName (ПІБ) — прізвище, ім’я та по батькові особи.

Наразі Платформа підтримує 2 типи автентифікації :

  • автентифікація користувача за допомогою кваліфікованого електронного підпису (КЕП);

  • автентифікація користувача за допомогою інтегрованої системи електронної ідентифікації ID.GOV.UA (ІСЕІ) — зовнішнього постачальника ідентифікаційних даних.

Керувати автентифікацією користувачів реєстру можна в інтерфейсі адміністративної панелі Control Plane, що описано у розділі Налаштування автентифікації користувачів цього документа.

Опис механізму та логіки автентифікації у системі, а також процес автентифікації у Кабінетах доступний на сторінці Автентифікація користувачів реєстру.
1. Realm - це концепція в Keycloak, яка належить до об’єкта, що керує набором користувачів, а також їхніми обліковими даними, ролями та групами.
2. Геопросторові дані — це дані, які мають географічне положення та можуть бути пов’язані з конкретними географічними об’єктами, такими як міста, річки, ліси, будівлі тощо.
3. ГІС (Геоінформаційна система) — це програмне забезпечення, яке дозволяє збирати, зберігати, аналізувати, візуалізувати та навіть прогнозувати різні геопросторові дані.

© 2023 Платформа Реєстрів.