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

ЗМІСТ

1. Перелік доступних сервісів
2. Налаштування ресурсів
- Окремі налаштування сервісів по роботі з даними

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

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

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

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

Таблиця 1. Перелік доступних сервісів для конфігурації ресурсів
Сервіс	Опис
`bpms`	Сервіс, що керує моделюванням і виконанням бізнес-процесів на Платформі.
`digitalDocumentService`	Сервіс керує операціями, пов’язаними з цифровими документами, такими як створення, зберігання та управління цифровими документами.
`digitalSignatureOps`	Сервіс керує операціями, пов’язаними з цифровими підписами, наприклад, створення, перевірка та накладання цифрових підписів та печаток на документи.
`formManagementProvider`	Сервіс відповідає за управління формами, включаючи створення, редагування та обробку форм даних.
`kafkaApi`	Сервіс для обробки потокових даних у реальному часі.
`kong`	Сервіс для авторизації та контролю доступу до внутрішніх API-роутів реєстру. Відповідає за управління роутами, запитами та відповідями API. Також контролює пропускну здатність кількості запитів за одиницю часу від клієнтів до кінцевих сервісів (rate-ліміти).
`redis`	Сервіс для зберігання даних у пам’яті, що часто використовується як кеш або брокер повідомлень. Наприклад, redis зберігає частину даних бізнес-процесів.
`restApi`	Сервіс надає інтерфейси REST (Representational State Transfer), які дозволяють взаємодіяти із системою через HTTP-запити.
`soapApi`	Сервіс надає SOAP (Simple Object Access Protocol) інтерфейси для обміну структурованою інформацією у рамках вебсервісів.
`sentinel`	Сервіс відповідає за моніторинг та сповіщення безпеки на Платформі.
`userProcessManagement`	Сервіс відповідає за управління процесами, пов’язаними з користувачами, включаючи створення, відстеження та управління процесами користувачів.
`userTaskManagement`	Сервіс відповідає за управління задачами користувачів, включаючи створення, відстеження та управління задачами користувачів.
`Crunchy Postgres`	Це дистрибутив PostgreSQL, оптимізований для високої доступності та безпеки. Цей сервіс забезпечує зберігання даних у базі даних PostgreSQL.

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

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

Оберіть зі списку сервіс для конфігурації ресурсів і натисніть + (Додати).

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

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

cp create registry 7

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

Налаштуйте параметри Requests i Limits.

Ці параметри вказують на оптимальні (Requests) та максимальні (Limits) ресурси, які мають бути виділені для Istio sidecar.

Requests — це мінімум ресурсів, які OpenShift гарантує для контейнера. У нашому прикладі — це 350m CPU і 128Mi пам’яті для Istio sidecar. Якщо контейнер потребує більше ресурсів, і якщо ці додаткові ресурси доступні, OpenShift зможе їх надати.

Limits — це максимум ресурсів, які OpenShift дозволить контейнеру використовувати. У нашому прикладі — це 350m CPU, 128Mi пам’яті для Istio sidecar. Якщо контейнер спробує використати більше ресурсів, він може бути примусово зупинений або переведений на нижчий пріоритет у черзі розкладу розгортання подів на нодах.
Container
Container — основний контейнер із додатком.
Налаштуйте параметри Requests i Limits.

Ці параметри вказують на оптимальні (Requests) та максимальні (Limits) ресурси, які мають бути виділені для основного контейнера.

Requests — це мінімум ресурсів, які OpenShift гарантує для контейнера. У нашому прикладі — це 1 CPU, 2Gi пам’яті для основного контейнера. Якщо контейнер потребує більше ресурсів, і якщо ці додаткові ресурси доступні, OpenShift може їх надати.

Limits — це максимум ресурсів, які OpenShift дозволить контейнеру використовувати. У нашому прикладі — це 1 CPU, 2Gi пам’яті для основного контейнера. Якщо контейнер спробує використати більше ресурсів, він може бути примусово зупинений або переведений на нижчий пріоритет у черзі розкладу розгортання подів на нодах.

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

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

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

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

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

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

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

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

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

Crunchy Postgres

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

Max Connections: вказує на максимальну кількість одночасних з’єднань, які Crunchy Postgres може підтримувати. Тобто, якщо ви вкажете значення 200, то не більше 200 користувачів або процесів можуть мати відкрите з’єднання із базою даних одночасно.
Storage Size: вказує на розмір сховища даних, виділеного для Crunchy Postgres. Тобто якщо ви вкажете значення 10Gi, Crunchy Postgres матиме 10 гігабайтів місця для зберігання даних.

kafkaApi

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

Maximum pool size (за замовчуванням 10):

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

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

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

restApi

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

Maximum pool size (за замовчуванням 10):

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

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

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