Керування ресурсами реєстру
🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію. |
1. Загальний опис
Адміністративна панель Control Plane надає вам гнучке управління параметрами, використовуючи потужність Платформи. Це ефективний інструмент для керування ресурсами, що використовуються контейнерами в рамках вашого екземпляра реєстру, забезпечуючи оптимальну працездатність та ефективність.
Керування ресурсами доступне як при розгортанні, так і при оновленні реєстру. Кожний реєстр має розгорнуту конфігурацію сервісів за замовчуванням, яку надалі можна змінити. |
Ви можете додати окремі компоненти до реєстру та гнучко налаштувати для них ресурси. Також є можливість горизонтально масштабувати ресурси таких компонентів.
-
Відрийте інтерфейс Control Plane .
-
Оберіть з переліку компонент, для якого потрібно налаштувати ресурси.
-
Натисніть
Додати
.
2. Перелік доступних компонентів
Компонент | Опис |
---|---|
|
Вебінтерфейс моделювання регламенту (Admin Portal). Клієнтський вебдодаток для адміністрування реєстрів. Інтерфейс дозволяє виконувати необхідну конфігурацію регламенту реєстру без володіння глибокими уміннями програмування. |
|
Аналітична база даних реєстру |
|
Вебінтерфейс управління виконанням бізнес-процесів (Business Process Administration). Користувацький інтерфейс для перегляду стану виконання та управління бізнес-процесами реєстру. |
|
Сервіс викликів бізнес-процесів зовнішніми системами. |
|
Сервіс, що керує виконанням бізнес-процесів на Платформі. |
|
Кабінет отримувача послуг |
|
Це дистрибутив PostgreSQL, оптимізований для високої доступності та безпеки. Цей сервіс забезпечує зберігання даних у базі даних PostgreSQL. |
|
Сервер, який надає специфічні для мови програмування інтелектуальні можливості та комунікує з розробницькими інструментами через протокол Language Server Protocol (LSP). Цей протокол стандартизує спосіб комунікації між такими серверами та інструментами розробки, що дозволяє використовувати один і той же Language Server у багатьох інструментах розробки, забезпечуючи підтримку кількох мов програмування з мінімальними зусиллями. |
|
Сервіс нотифікацій користувачів |
|
Сервіс керує операціями створення, зберігання та управління цифровими документами. |
|
Сервіс керує операціями створення, перевірки та накладання цифрових підписів та печаток на документи. |
|
Сервіс управління витягами |
|
Сервіс формування PDF-витягів |
|
Сервіс формування CSV-витягів (витяги-звіти) |
|
Сервіс формування DOCX-витягів (проєкти наказів) |
|
Компонент, що дозволяє управляти секретами Kubernetes за допомогою External Secrets Operator. Він підтримує створення єдиного ресурсу |
|
Сервіс постачання UI-форм |
|
Сервіс валідації даних UI-форм |
|
Сервер, призначений для обробки та візуалізації геопросторових даних. Він дозволяє взаємодіяти з базами даних для отримання геопросторової інформації та її подальшої репрезентації у форматі |
|
Сервіс інспекції та зберігання змін регламенту (Gerrit). Програмний інструмент, що дозволяє керувати версіями компонентів та конфігурацій. |
|
Сервіс управління секретами та шифруванням (Vault). Інструмент для безпечного управління секретами та захисту доступу до конфіденційної інформації в обчислювальних середовищах. |
|
Компонентом сервісної мережі Istio, який забезпечує управління вхідним трафіком. Це ворота (gateway), через які зовнішні запити входять у сервісну мережу. Цей компонент дозволяє детально контролювати та маршрутизувати трафік до різних сервісів у Kubernetes-кластері. |
|
Сервіс розгортання регламенту (Jenkins). Програмний комплекс, що забезпечує автоматизацію в життєвому циклі розгортання регламенту реєстру. |
|
Сервіс для обробки потокових даних у реальному часі. Використовується для публікації, підписки, зберігання та обробки потокових даних, забезпечуючи високу пропускну спроможність та надійність. |
|
Забезпечує моніторинг та управління сутностями всередині Kafka кластера, включаючи топіки, користувачів Kafka та Kafka Connect. Цей компонент важливий для адміністрування та оптимізації роботи кластера. |
|
Описує основні вузли у Kafka-кластері. Цей компонент відповідає за обробку потокових даних та пов’язаних з ними операцій, таких як публікація та споживання повідомлень. |
|
Використовується для експорту метрик з Kafka кластера. Це дозволяє здійснювати моніторинг та аналіз продуктивності кластера, сприяючи оптимізації його ефективності. |
|
Компонент, що відповідає за координацію та управління станом всередині Kafka кластера. Zookeeper використовується для управління конфігурацією, неймінгом сервісів та синхронізації серед вузлів кластера. |
|
Забезпечує інтеграцію Kafka кластера з зовнішніми системами для імпорту та експорту даних. Це дозволяє автоматизувати перенесення даних між Kafka та іншими системами, наприклад, базами даних та іншими потоковими джерелами. |
|
Зберігає схеми даних, які використовуються у Kafka топіках. Це забезпечує узгодженість формату даних, які передаються між виробниками та споживачами, знижуючи ймовірність помилок у потоковій обробці. |
|
Графічний інтерфейс користувача для управління Kafka кластером та моніторингу його стану. Цей інструмент забезпечує візуальний огляд кластера, включаючи топіки, споживачів, продуктивність та інші ключові метрики. |
|
Сервіс для авторизації та контролю доступу до внутрішніх API-роутів реєстру. Відповідає за управління роутами, запитами та відповідями API. Також контролює пропускну здатність кількості запитів за одиницю часу від клієнтів до кінцевих сервісів (rate-ліміти). |
|
— |
|
Сховище для зберігання згенерованих артефактів реєстру (Nexus) |
|
Операційна база даних реєстру, що забезпечує зберігання та управління даними, які активно використовуються в робочих процесах. Ця база даних відіграє ключову роль у підтримці операційної ефективності реєстру. |
|
Набір ресурсів, призначений для підтримки операційних потреб реєстру. Це може включати сервери, мережеві ресурси, та інші компоненти інфраструктури, які забезпечують високу доступність, продуктивність та масштабованість для обробки операційних запитів і транзакцій. |
|
Користувацький інтерфейс для перегляду даних та схеми моделі даних реєстру |
|
Шлюзу міжреєстрової взаємодії |
|
Сервіс доступу до історичних даних бізнес-процесів |
|
— |
|
Користувацький інтерфейс для створення та налаштування аналітичних звітів та дашбордів (Redash Admin). |
|
Компонент, призначений для виконання адміністративних завдань на вимогу у Redash. Він обробляє непланові або одноразові запити, такі як генерація специфічних звітів чи виконання користувацьких запитів. |
|
Відповідає за управління базою даних Redis, яка використовується для кешування та сесій в адміністративному інтерфейсі Redash. Цей компонент забезпечує високу швидкість доступу та ефективність операцій з даними. |
|
Планувальник, який керує автоматизованими задачами в Redash Admin, наприклад, регулярним оновленням дашбордів чи звітів. |
|
Використовується для експорту даних з Redash. Це може включати вивантаження звітів, дашбордів або інших аналітичних даних для подальшої обробки чи зберігання. |
|
Вебінтерфейс перегляду аналітичної звітності (Redash Viewer). Надає користувачам можливість переглядати дашборди та звіти, створені в Redash Admin. |
|
Компонент, що обробляє одноразові запити в Redash Viewer. Він забезпечує виконання запитів на перегляд або аналіз даних, які не підлягають регулярному оновленню. |
|
Керує Redis базою даних для Redash Viewer, оптимізуючи швидкість доступу та обробку даних для користувачів, які переглядають звіти та дашборди. |
|
Відповідає за планування та автоматизацію завдань у Redash Viewer, наприклад, регулярне оновлення даних на дашбордах чи у звітах. |
|
Сервіс для зберігання даних у пам’яті, що часто використовується як кеш або брокер повідомлень. Наприклад, |
|
Сервіс управління регламентом |
|
— |
|
Компонент, призначений для експорту звітів та аналітичних даних із системи. Він дозволяє автоматизувати процес вивантаження даних у різні формати, зокрема PDF, Excel, CSV. Це забезпечує зручність у подальшому аналізі даних, їх презентації чи інтеграції з іншими системами. |
|
Сервіс надає інтерфейси REST (Representational State Transfer), які дозволяють взаємодіяти із системою через HTTP-запити. |
|
Сервіс відповідає за моніторинг та сповіщення безпеки на Платформі. |
|
Сервіс надає SOAP (Simple Object Access Protocol) інтерфейси для обміну структурованою інформацією у рамках вебсервісів. |
|
Сервіс відповідає за управління процесами, пов’язаними з користувачами, включаючи створення, відстеження та управління процесами користувачів. |
|
Опис для |
|
Сервіс відповідає за управління задачами користувачів, включаючи створення, відстеження та управління задачами користувачів. |
|
Сервіс, призначений для симуляції API зовнішніх систем. Він дозволяє розробникам імітувати поведінку вебсервісів та API в тестовому середовищі, що спрощує процес тестування та розробки. |
3. Налаштування ресурсів
Принцип налаштування ресурсів для усіх сервісів є однаковим, за винятком |
-
Додайте зі списку сервіс для конфігурації ресурсів. Розглянемо приклад із налаштуваннями для BPMS.
Під час розгортання реєстру усі наявні сервіси налаштовані та передзаповнені відповідними значеннями кількості реплік, запитів, лімітів та змінних оточення за замовчуванням.
Навіть у випадку видалення сервісів зі списку, під час розгортання реєстру Платформа застосує стандартну конфігурацію.
-
Встановіть власні значення для ресурсів (див. опис нижче).
Кількість реплік (Replicas Amount)
Кількість реплік (Replicas Amount) — це параметр, який вказує на число копій (або реплік) певного сервісу. Це ключовий компонент горизонтального масштабування, оскільки дозволяє системі розподіляти навантаження та забезпечувати високу доступність.
За замовчуванням встановлюється одна репліка, але це число може бути збільшене залежно від потреб системи та доступних ресурсів. |
- Основні цілі використання кількості реплік:
-
-
Підвищення доступності: репліки забезпечують високу доступність сервісу чи додатку. Якщо одна з реплік зазнає збою або стає недоступною, інші репліки можуть продовжувати обслуговувати запити, зменшуючи ризик відмови системи.
-
Розподіл навантаження: з декількома репліками, запити можуть бути розподілені між ними, що допомагає уникнути перевантаження одного сервера або вузла. Це покращує загальну продуктивність системи.
-
Горизонтальне масштабування: реплікація є основою для горизонтального масштабування, де ви можете збільшити кількість реплік, щоб впоратися зі збільшеним обсягом запитів або навантаження на систему.
-
Надійність та стійкість: у випадку непередбачених збоїв або планового обслуговування, наявність декількох реплік забезпечує неперервність роботи системи.
-
Ліміти контейнерів (Container Limits)
Основний контейнер (container
) є ключовою частиною додатка в середовищі контейнеризації. Нижче наведені параметри для налаштування мінімальних (Requests
) та максимальних (Limits
) лімітів ресурсів, що мають бути виділені для основного контейнера.
-
Requests — якщо контейнер потребує більше ресурсів, і якщо ці додаткові ресурси доступні, OpenShift може їх надати.
-
Limits — Якщо контейнер спробує використати більше ресурсів за встановлене значення, він може бути примусово зупинений або переведений на нижчий пріоритет у черзі розкладу розгортання подів на нодах.
Параметр | Значення за замовчуванням | Опис |
---|---|---|
CPU Requests |
|
Мінімальна кількість ресурсів CPU, яку OpenShift гарантує контейнеру. Значення |
CPU Limits |
|
Максимальний обсяг ресурсів CPU, який OpenShift дозволяє використовувати контейнеру. Значення |
Memory Requests |
|
Мінімальний обсяг пам’яті, який OpenShift гарантує контейнеру. Значення |
Memory Limits |
|
Максимальний обсяг пам’яті, який OpenShift дозволяє використовувати контейнеру. Значення |
Гібібайт (GiB) і гігабайт (GB) це різні одиниці вимірювання. 1 гібібайт (1 GiB) дорівнює приблизно 1.074 гігабайтам. |
Ліміти Istio Sidecar
Istio Sidecar — це додатковий контейнер, що запускається поряд з основним контейнером у поді OpenShift. Istio використовує підхід sidecar для внесення змін до мережевих налаштувань без необхідності зміни самого додатку. Налаштування лімітів ресурсів для Istio sidecar допомагає управляти використанням ресурсів і забезпечувати стабільність системи.
Istio Sidecar є опційним параметром. Активуйте його за потреби та встановіть необхідну конфігурацію. |
-
Requests — якщо контейнер потребує більше ресурсів, і якщо ці додаткові ресурси доступні, OpenShift може їх надати.
-
Limits — Якщо контейнер спробує використати більше ресурсів за встановлене значення, він може бути примусово зупинений або переведений на нижчий пріоритет у черзі розкладу розгортання подів на нодах.
Параметр | Значення за замовчуванням | Опис |
---|---|---|
CPU Requests |
|
Мінімальна кількість ресурсів CPU, яку OpenShift гарантує Istio Sidecar. Значення |
CPU Limits |
|
Максимальний обсяг ресурсів CPU, який OpenShift дозволяє використовувати Istio Sidecar. Значення |
Memory Requests |
|
Мінімальний обсяг пам’яті, який OpenShift гарантує Istio Sidecar. Значення |
Memory Limits |
|
Максимальний обсяг пам’яті, який OpenShift дозволяє використовувати Istio Sidecar. Значення |
Гібібайт (GiB) і гігабайт (GB) це різні одиниці вимірювання. 1 гібібайт (1 GiB) дорівнює приблизно 1.074 гігабайтам. |
Змінні оточення
Змінні оточення (або environment variables) — це динамічні назви значень, що зберігаються в системі й можуть використовуватися різними програмами. Вони особливо корисні в контейнеризованих та розподілених середовищах, таких як Платформа реєстрів, де кожен контейнер або под може мати свої власні змінні оточення. Це дає змогу керувати конфігурацією та поведінкою кожного контейнера або пода індивідуально.
Наприклад, змінна JAVA_OPTS
часто встановлена за замовчуванням для різних компонентів і використовується для налаштування параметрів JVM (Java Virtual Machine).
У цьому випадку, вказані параметри -Xms1536m
і -Xmx1536m
встановлюють мінімальний (-Xms
) та максимальний (-Xmx
) розмір пам’яті, який JVM може використовувати.
Ви можете прибрати змінні оточення з налаштувань, натиснувши хрестик (х ).
|
Натисніть Далі
, якщо це крок розгортання реєстру, або Підтвердити
, якщо це оновлення конфігурації.
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 гігабайтам. - kafkaApi
-
Сервіс для обробки потокових даних у реальному часі. Дозволяє налаштувати параметри з’єднання із базою даних — Database connection parameters:
Таблиця 5. Конфігурація пулу з’єднань Параметр Значення за замовчуванням Опис Maximum pool size (Допустиме значення параметра > 0)
10
Параметр Maximum pool size вказує на максимальну кількість одночасних з’єднань до бази даних, які можуть бути створені та підтримувані пулом з’єднань.
Пул з’єднань — це набір відкритих з’єднань, які підтримуються з метою підвищення продуктивності та ефективності доступу до бази даних. Замість відкриття нового з’єднання з базою даних при кожному запиті, використовується одне із вже відкритих з’єднань із пулу. Це дозволяє зекономити час та ресурси.
Наприклад, якщо Maximum pool size встановлено у значення
10
, то максимум 10 запитів можуть одночасно взаємодіяти із базою даних через пул. Якщо одинадцятий запит намагається отримати доступ, йому доведеться чекати, поки одне з наявних з’єднань не буде віддано назад до пулу. Вибір правильного розміру пулу з’єднань важливий для оптимальної роботи сервісу. Занадто малий пул може призвести до затримок, оскільки додаткові запити будуть очікувати доступу, але занадто великий пул може використовувати надмірні системні ресурси. - restApi
-
Сервіс надає інтерфейси REST (Representational State Transfer), які дозволяють взаємодіяти із системою через HTTP-запити. Дозволяє налаштувати параметри з’єднання із базою даних — Database connection parameters:
Таблиця 6. Конфігурація пулу з’єднань Параметр Значення за замовчуванням Опис Maximum pool size (Допустиме значення параметра > 0)
10
Параметр Maximum pool size вказує на максимальну кількість одночасних з’єднань до бази даних, які можуть бути створені та підтримувані пулом з’єднань.
Пул з’єднань — це набір відкритих з’єднань, які підтримуються з метою підвищення продуктивності та ефективності доступу до бази даних. Замість відкриття нового з’єднання з базою даних при кожному запиті, використовується одне із вже відкритих з’єднань із пулу. Це дозволяє зекономити час та ресурси.
Наприклад, якщо Maximum pool size встановлено у значення
10
, то максимум 10 запитів можуть одночасно взаємодіяти із базою даних через пул. Якщо одинадцятий запит намагається отримати доступ, йому доведеться чекати, поки одне з наявних з’єднань не буде віддано назад до пулу. Вибір правильного розміру пулу з’єднань важливий для оптимальної роботи сервісу. Занадто малий пул може призвести до затримок, оскільки додаткові запити будуть очікувати доступу, але занадто великий пул може використовувати надмірні системні ресурси.
5. Застосування та розгортання змін до конфігурації
При редагуванні реєстру, в результаті виконаних вище налаштувань, буде сформовано запит на оновлення зі статусом Новий
.
-
Поверніться до розділу Реєстри, прокрутіть бігунок униз сторінки та знайдіть секцію Запити на оновлення.
-
Відкрийте сформований запит, натиснувши іконку перегляду — 👁.
Запропоновані зміни вносяться до конфігурації файлу deploy-templates/values.yaml у разі підтвердження. -
У новому вікні зіставте 2 версії змін, переконайтеся, що внесені вами дані вірні, та натисніть
Підтвердити
. -
В результаті запуститься пайплайн розгортання конфігурації реєстру — MASTER-Build-
<registry-name>
, де<registry-name>
— назва реєстру. Зачекайте кілька хвилин, доки пройде збірка. Після цього компоненти отримають встановлену кількість ресурсів.
6. Пов’язані сторінки
Ознайомтеся з цими ресурсами для отримання додаткової інформації та поглиблення вашого розуміння: