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

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

1. Загальний опис

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

registry resources 1

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

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

  1. Відрийте інтерфейс Control Plane .

  2. Оберіть з переліку компонент, для якого потрібно налаштувати ресурси.

    registry resources 2

  3. Натисніть Додати.

    registry resources 3

2. Перелік доступних компонентів

Таблиця 1. Перелік доступних компонентів для конфігурації ресурсів
Компонент Опис

adminPortal

Вебінтерфейс моделювання регламенту (Admin Portal). Клієнтський вебдодаток для адміністрування реєстрів. Інтерфейс дозволяє виконувати необхідну конфігурацію регламенту реєстру без володіння глибокими уміннями програмування.

analyticalInstance

Аналітична база даних реєстру

bpAdminPortal

Вебінтерфейс управління виконанням бізнес-процесів (Business Process Administration). Користувацький інтерфейс для перегляду стану виконання та управління бізнес-процесами реєстру.

bpWebserviceGateway

Сервіс викликів бізнес-процесів зовнішніми системами.

bpms

Сервіс, що керує виконанням бізнес-процесів на Платформі.

citizenPortal

Кабінет отримувача послуг

Crunchy Postgres

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

ddmLanguageServer

Сервер, який надає специфічні для мови програмування інтелектуальні можливості та комунікує з розробницькими інструментами через протокол Language Server Protocol (LSP). Цей протокол стандартизує спосіб комунікації між такими серверами та інструментами розробки, що дозволяє використовувати один і той же Language Server у багатьох інструментах розробки, забезпечуючи підтримку кількох мов програмування з мінімальними зусиллями.

ddmNotificationService

Сервіс нотифікацій користувачів

digitalDocumentService

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

digitalSignatureOps

Сервіс керує операціями створення, перевірки та накладання цифрових підписів та печаток на документи.

excerptServiceApi

Сервіс управління витягами

excerptWorker

Сервіс формування PDF-витягів

excerptWorkerCsv

Сервіс формування CSV-витягів (витяги-звіти)

excerptWorkerDocx

Сервіс формування DOCX-витягів (проєкти наказів)

externalSecrets

Компонент, що дозволяє управляти секретами Kubernetes за допомогою External Secrets Operator. Він підтримує створення єдиного ресурсу Secret на основі декількох записів секретів з HashiCorp Vault. Такий підхід дозволяє централізовано керувати секретними даними та застосовувати різноманітні трансформації до них перед використанням у Kubernetes, забезпечуючи вищий рівень безпеки та ефективності управління конфіденційною інформацією.

formSchemaProvider

Сервіс постачання UI-форм

formSubmissionValidation

Сервіс валідації даних UI-форм

geoServer

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

gerrit

Сервіс інспекції та зберігання змін регламенту (Gerrit). Програмний інструмент, що дозволяє керувати версіями компонентів та конфігурацій.

hashicorpVault

Сервіс управління секретами та шифруванням (Vault). Інструмент для безпечного управління секретами та захисту доступу до конфіденційної інформації в обчислювальних середовищах.

istioIngressGateway

Компонентом сервісної мережі Istio, який забезпечує управління вхідним трафіком. Це ворота (gateway), через які зовнішні запити входять у сервісну мережу. Цей компонент дозволяє детально контролювати та маршрутизувати трафік до різних сервісів у Kubernetes-кластері.

jenkins

Сервіс розгортання регламенту (Jenkins). Програмний комплекс, що забезпечує автоматизацію в життєвому циклі розгортання регламенту реєстру.

kafkaApi

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

kafkaClusterEntityOperator

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

kafkaClusterKafka

Описує основні вузли у Kafka-кластері. Цей компонент відповідає за обробку потокових даних та пов’язаних з ними операцій, таких як публікація та споживання повідомлень.

kafkaClusterKafkaExporter

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

kafkaClusterZookeper

Компонент, що відповідає за координацію та управління станом всередині Kafka кластера. Zookeeper використовується для управління конфігурацією, неймінгом сервісів та синхронізації серед вузлів кластера.

kafkaConnectClusterConnect

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

kafkaSchemaRegistry

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

kafkaUi

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

kong

Сервіс для авторизації та контролю доступу до внутрішніх API-роутів реєстру. Відповідає за управління роутами, запитами та відповідями API. Також контролює пропускну здатність кількості запитів за одиницю часу від клієнтів до кінцевих сервісів (rate-ліміти).

kongAdminTools

 — 

nexus

Сховище для зберігання згенерованих артефактів реєстру (Nexus)

operationalInstance

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

operationalPool

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

pgAdmin

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

platformGateway

Шлюзу міжреєстрової взаємодії

processHistoryServiceApi

Сервіс доступу до історичних даних бізнес-процесів

processHistoryServicePersistence

 — 

redashAdmin

Користувацький інтерфейс для створення та налаштування аналітичних звітів та дашбордів (Redash Admin).

redashAdminAdhocworker

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

redashAdminRedisMaster

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

redashAdminScheduler

Планувальник, який керує автоматизованими задачами в Redash Admin, наприклад, регулярним оновленням дашбордів чи звітів.

redashExporter

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

redashViewer

Вебінтерфейс перегляду аналітичної звітності (Redash Viewer). Надає користувачам можливість переглядати дашборди та звіти, створені в Redash Admin.

redashViewerAdhocworker

Компонент, що обробляє одноразові запити в Redash Viewer. Він забезпечує виконання запитів на перегляд або аналіз даних, які не підлягають регулярному оновленню.

redashViewerRedisMaster

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

redashViewerScheduler

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

redis

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

registryRegulationManagement

Сервіс управління регламентом

reloader

 — 

reportExporter

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

restApi

Сервіс надає інтерфейси REST (Representational State Transfer), які дозволяють взаємодіяти із системою через HTTP-запити.

sentinel

Сервіс відповідає за моніторинг та сповіщення безпеки на Платформі.

soapApi

Сервіс надає SOAP (Simple Object Access Protocol) інтерфейси для обміну структурованою інформацією у рамках вебсервісів.

userProcessManagement

Сервіс відповідає за управління процесами, пов’язаними з користувачами, включаючи створення, відстеження та управління процесами користувачів.

userSettingsServiceApi

Опис для userSettingsServiceApi.

userTaskManagement

Сервіс відповідає за управління задачами користувачів, включаючи створення, відстеження та управління задачами користувачів.

wiremock

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

3. Налаштування ресурсів

Принцип налаштування ресурсів для усіх сервісів є однаковим, за винятком Crunchy Postgres, restApi та kafkaApi для яких також передбачені додаткові специфічні параметри, описані у розділі Окремі налаштування сервісів по роботі з даними.

  1. Додайте зі списку сервіс для конфігурації ресурсів. Розглянемо приклад із налаштуваннями для BPMS.

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

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

  2. Встановіть власні значення для ресурсів (див. опис нижче).

Кількість реплік (Replicas Amount)

Кількість реплік (Replicas Amount) — це параметр, який вказує на число копій (або реплік) певного сервісу. Це ключовий компонент горизонтального масштабування, оскільки дозволяє системі розподіляти навантаження та забезпечувати високу доступність.

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

  2. Розподіл навантаження: з декількома репліками, запити можуть бути розподілені між ними, що допомагає уникнути перевантаження одного сервера або вузла. Це покращує загальну продуктивність системи.

  3. Горизонтальне масштабування: реплікація є основою для горизонтального масштабування, де ви можете збільшити кількість реплік, щоб впоратися зі збільшеним обсягом запитів або навантаження на систему.

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

registry resources 5

Ліміти контейнерів (Container Limits)

Основний контейнер (container) є ключовою частиною додатка в середовищі контейнеризації. Нижче наведені параметри для налаштування мінімальних (Requests) та максимальних (Limits) лімітів ресурсів, що мають бути виділені для основного контейнера.

  • Requests — якщо контейнер потребує більше ресурсів, і якщо ці додаткові ресурси доступні, OpenShift може їх надати.

  • Limits — Якщо контейнер спробує використати більше ресурсів за встановлене значення, він може бути примусово зупинений або переведений на нижчий пріоритет у черзі розкладу розгортання подів на нодах.

Таблиця 2. Ліміти CPU та Memory для основного контейнера
Параметр Значення за замовчуванням Опис

CPU Requests

1

Мінімальна кількість ресурсів CPU, яку OpenShift гарантує контейнеру. Значення 1 означає одне повне CPU ядро. Якщо вказати, наприклад, значення 100m — це означатиме 100 millicores, або 10% одного ядра CPU тощо.

CPU Limits

1

Максимальний обсяг ресурсів CPU, який OpenShift дозволяє використовувати контейнеру. Значення 1 означає одне повне CPU ядро. Якщо вказати, наприклад, значення 100m — це означатиме 100 millicores, або 10% одного ядра CPU тощо.

Memory Requests

2Gi

Мінімальний обсяг пам’яті, який OpenShift гарантує контейнеру. Значення 2Gi означає 2 гібібайти. Якщо вказати, наприклад, значення 400Mi — це означатиме 400 мебібайтів тощо.

Memory Limits

2Gi

Максимальний обсяг пам’яті, який OpenShift дозволяє використовувати контейнеру. Значення 2Gi означає 2 гібібайти. Якщо вказати, наприклад, значення 400Mi — це означатиме 400 мебібайтів тощо.

Гібібайт (GiB) і гігабайт (GB) це різні одиниці вимірювання. 1 гібібайт (1 GiB) дорівнює приблизно 1.074 гігабайтам.

registry resources 6

Ліміти Istio Sidecar

Istio Sidecar — це додатковий контейнер, що запускається поряд з основним контейнером у поді OpenShift. Istio використовує підхід sidecar для внесення змін до мережевих налаштувань без необхідності зміни самого додатку. Налаштування лімітів ресурсів для Istio sidecar допомагає управляти використанням ресурсів і забезпечувати стабільність системи.

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

  • Limits — Якщо контейнер спробує використати більше ресурсів за встановлене значення, він може бути примусово зупинений або переведений на нижчий пріоритет у черзі розкладу розгортання подів на нодах.

Таблиця 3. Ліміти CPU та Memory для Istio Sidecar
Параметр Значення за замовчуванням Опис

CPU Requests

350m

Мінімальна кількість ресурсів CPU, яку OpenShift гарантує Istio Sidecar. Значення 350m означає 350 millicores, або приблизно 35% одного ядра CPU.

CPU Limits

350m

Максимальний обсяг ресурсів CPU, який OpenShift дозволяє використовувати Istio Sidecar. Значення 350m також означає 350 millicores, обмежуючи використання ресурсів до 35% одного ядра CPU.

Memory Requests

128Mi

Мінімальний обсяг пам’яті, який OpenShift гарантує Istio Sidecar. Значення 128Mi означає 128 мебібайтів.

Memory Limits

128Mi

Максимальний обсяг пам’яті, який OpenShift дозволяє використовувати Istio Sidecar. Значення 128Mi також означає 128 мебібайтів, обмежуючи використання пам’яті до цієї кількості.

Гібібайт (GiB) і гігабайт (GB) це різні одиниці вимірювання. 1 гібібайт (1 GiB) дорівнює приблизно 1.074 гігабайтам.

registry resources 7

Змінні оточення

Змінні оточення (або environment variables) — це динамічні назви значень, що зберігаються в системі й можуть використовуватися різними програмами. Вони особливо корисні в контейнеризованих та розподілених середовищах, таких як Платформа реєстрів, де кожен контейнер або под може мати свої власні змінні оточення. Це дає змогу керувати конфігурацією та поведінкою кожного контейнера або пода індивідуально.

Наприклад, змінна JAVA_OPTS часто встановлена за замовчуванням для різних компонентів і використовується для налаштування параметрів JVM (Java Virtual Machine).

У цьому випадку, вказані параметри -Xms1536m і -Xmx1536m встановлюють мінімальний (-Xms) та максимальний (-Xmx) розмір пам’яті, який JVM може використовувати.

Ви можете прибрати змінні оточення з налаштувань, натиснувши хрестик (х).

registry resources 8

Натисніть Далі, якщо це крок розгортання реєстру, або Підтвердити, якщо це оновлення конфігурації.

4. Окремі налаштування сервісів по роботі з даними

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

Crunchy Postgres

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

Таблиця 4. Конфігурація ресурсів для Crunchy Postgres
Параметр Значення за замовчуванням Опис

Max Connections

200

Вказує на максимальну кількість одночасних з’єднань, які Crunchy Postgres може підтримувати. Наприклад, якщо ви вкажете значення 200, то не більше 200 користувачів або процесів можуть мати відкрите з’єднання із базою даних одночасно.

Storage Size

10Gi

Вказує на розмір сховища даних, виділеного для Crunchy Postgres. Наприклад, якщо ви вкажете значення 10Gi, Crunchy Postgres матиме 10 гібібайтів місця для зберігання даних.

Гібібайт (GiB) і гігабайт (GB) це різні одиниці вимірювання. 1 гібібайт (1 GiB) дорівнює приблизно 1.074 гігабайтам.

registry resources 4

kafkaApi

Сервіс для обробки потокових даних у реальному часі. Дозволяє налаштувати параметри з’єднання із базою даних — Database connection parameters:

Таблиця 5. Конфігурація пулу з’єднань
Параметр Значення за замовчуванням Опис

Maximum pool size (Допустиме значення параметра > 0)

10

Параметр Maximum pool size вказує на максимальну кількість одночасних з’єднань до бази даних, які можуть бути створені та підтримувані пулом з’єднань.

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

Наприклад, якщо Maximum pool size встановлено у значення 10, то максимум 10 запитів можуть одночасно взаємодіяти із базою даних через пул. Якщо одинадцятий запит намагається отримати доступ, йому доведеться чекати, поки одне з наявних з’єднань не буде віддано назад до пулу. Вибір правильного розміру пулу з’єднань важливий для оптимальної роботи сервісу. Занадто малий пул може призвести до затримок, оскільки додаткові запити будуть очікувати доступу, але занадто великий пул може використовувати надмірні системні ресурси.

registry resources 9

restApi

Сервіс надає інтерфейси REST (Representational State Transfer), які дозволяють взаємодіяти із системою через HTTP-запити. Дозволяє налаштувати параметри з’єднання із базою даних — Database connection parameters:

Таблиця 6. Конфігурація пулу з’єднань
Параметр Значення за замовчуванням Опис

Maximum pool size (Допустиме значення параметра > 0)

10

Параметр Maximum pool size вказує на максимальну кількість одночасних з’єднань до бази даних, які можуть бути створені та підтримувані пулом з’єднань.

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

Наприклад, якщо Maximum pool size встановлено у значення 10, то максимум 10 запитів можуть одночасно взаємодіяти із базою даних через пул. Якщо одинадцятий запит намагається отримати доступ, йому доведеться чекати, поки одне з наявних з’єднань не буде віддано назад до пулу. Вибір правильного розміру пулу з’єднань важливий для оптимальної роботи сервісу. Занадто малий пул може призвести до затримок, оскільки додаткові запити будуть очікувати доступу, але занадто великий пул може використовувати надмірні системні ресурси.

registry resources 9

5. Застосування та розгортання змін до конфігурації

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

  1. Поверніться до розділу Реєстри, прокрутіть бігунок униз сторінки та знайдіть секцію Запити на оновлення.

    cp submit mr 1

  2. Відкрийте сформований запит, натиснувши іконку перегляду — 👁.

    Запропоновані зміни вносяться до конфігурації файлу deploy-templates/values.yaml у разі підтвердження.
  3. У новому вікні зіставте 2 версії змін, переконайтеся, що внесені вами дані вірні, та натисніть Підтвердити.

    cp create registry 7 3

  4. В результаті запуститься пайплайн розгортання конфігурації реєстру — MASTER-Build-<registry-name>, де <registry-name> — назва реєстру. Зачекайте кілька хвилин, доки пройде збірка. Після цього компоненти отримають встановлену кількість ресурсів.

6. Пов’язані сторінки

Ознайомтеся з цими ресурсами для отримання додаткової інформації та поглиблення вашого розуміння: