Мінімізація кількості шаблонів розгортання реєстру

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

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

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

Актори та ролі користувачів

Технічний адміністратор Платформи
Технічний адміністратор реєстру

Функціональні сценарії

Створення реєстрів через адмін-консоль
Редагування реєстрів через адмін-консоль

Поточна реалізація

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

registry-tenant-template-minimal
registry-tenant-template-recommended
registry-tenant-template-geo-server-minimal

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

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

Загальні принципи та положення

Замість декількох шаблонів реєстрів, в control-plane-gerrit присутній тільки один, але параметризований.
Параметри реєстру для єдиного шаблону адміністратор має можливість задавати на окремій табі під час процесу створення реєстру.
Параметри реєстру для винесення на адмін-консоль перелічені в таблиці 1-4.
Адмін-консоль має розпізнавати тип інфраструктури на якій розгорнутий кластер OpenShift (AWS, vSphere тощо) і в залежності від цього показувати або приховувати певні параметри специфічні для конкретного типу інфраструктури.
Таба "Шаблон реєстру" змінює свою назву на "Параметри віртуальних машин" та містить в собі винесені параметри шаблонів для редагування.
Додаються нові таби для параметрів кабінетів користувачів.
Валідації на кнопці "Назад" не має бути.
Адмін-консоль має вносити задані адміністратором значенням (або задані за замовчуванням) у відповідні values.yaml (див. таблицю) та далі вони передаються у відповідні чарти та helmfiles.yaml для подалішого використання при розгортанні ресурсів реєстрів.
Випадаючий елемент з гілками шаблону, що дозволяє обирати версію шаблону переноситься на табу "Загальні".
Параметри, що вводяться в текстові поля повинні валідіруватись на коректність введеної інформації як на рівні адмін-консолі, так і на рівні jenkins пайплайну (у разі редагування напряму через Gerrit).
При редагуванні винесених параметрів повинен створюватись MR.
В скрипті add_template_repositories.sh повинен пакуватись тільки один основний темплейт реєстрів.
Параметр griada.url не виноситься на рівень адмін-консолі за відсутністю кейсів використання, а залишається доступним для зміни через комміт в Gerrit. При цьому, Griada ServiceEntry не повинен створюватись, якщо url не заданий явно.
Зміна deploymentMode після створення реєстру не передбачена.
Тільки технічний адміністратор Платформи має право редагувати параметри віртуальних машин.
AWS регіон для згенерованого MachineSet має відповідати регіону кластера.
Таба "Ресурси реєстру" має керуючи елементи для налаштування HPA/Requests and Limits та кількість реплік.
Значення Requests/Limits мають бути пустими за замовчуванням з можливістю вказати власні значення.
Супутні ресурси для компонентів реєстру (NetworkPolicies, ServiceEntries тощо) не мають розгортатись, якщо компонент вимкнутий для розгортання.
При створенні нового реєстру має відкритись нове модальне вікно з переліком доступних для створення версій.
queryParam з версією реєстру тепер має прокидатись і при створенні реєстру для відображення коректної версії консолі.

Цільовий дизайн

Цільові кластери

Адмін-консоль має розпізнавати тип інфраструктури на якій розгорнутий кластер OpenShift (AWS, vSphere тощо). Це можна зробити через ресурс:
```
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.type}'
```
На основі визначеного типу інфраструктури мають відображатись відповідні параметри для налаштування віртуальних машин реєстру.

Адмін-консоль зберігає вказані параметри до файлу налаштувань реєстру values.yaml наступним чином:

Приклад yaml конфігурації в values.yaml

....
griada:
  enabled: true
  ip: "10.0.0.23"
  port: 3080
global:
  deploymentMode: "development"
  computeResources:
    instanceCount: 3
    awsInstanceType: "r5.2xlarge"
    awsSpotInstance: false
    awsInstanceVolumeType: "gp3"
    awsInstanceVolumeSize: 80
  excludePortals: "[]"
...
  registry:
    geoServer:
      enabled: true
    restApi:
      replicas: 1
      hpa:
        enabled: true
        minReplicas: 1
        maxReplicas: 3
      requestsLimits:
        enabled: true
      istio:
        sidecar:
          enabled: true
          resources:
            requests:
              cpu: 600m
              memory: 512Mi
            limits:
              cpu: 600m
              memory: 512Mi
      container:
        resources:
          limits:
            cpu: 300m
            memory: 1Gi
          requests:
            cpu: 300m
            memory: 1Gi

Для релізу geoServer в основному helmfile.yaml має бути встановлен параметр installed в який передаватись значення з values.yaml:

- name: geo-server
  namespace: '{{ env "NAMESPACE" }}'
  labels:
    type: remote
    update_scc: true
    repoURL: ssh://jenkins@gerrit.mdtu-ddm-edp-cicd:32114/mdtu-ddm/devops/geo-server.git
    path: components/registry/
  chart: /opt/repositories/geo-server/deploy-templates
  version: 1.0.0-SNAPSHOT.28
  values:
  - values.yaml
  - values.gotmpl
  installed: '{{ .Values.global.geoServer }}'
  missingFileHandler: Warn
  needs:
  - '{{ env "NAMESPACE" }}/registry-postgres'

Для передачі значення параметра installed можна використати або задання його на рівні пайплайну як змінну оточення або прочитати з values.yaml через helmfile environment values

Параметри налаштування Гряди не повинні мати окремих елементів вводу з UI адмін-консолі, а повинні задаватись з вже існуючих в табі "Дані про ключ"

Figure 1. Конфігурація Griada

Оточення для розробки CICD2

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

Перший етап — це збереження поточного процесу шляхом переносу CICD2 шаблонів в окремий від control-plane-gerrit суто технічний репозиторій та зміна в стейджі checkout-registry-tenant посилання з control-plane-gerrit на новий репозиторій. Це забезпечить швидкий та простий перехід для оточення розробки зі збереженням всіх автоматизованих операцій для розгортання реєстрів. Але цей спосіб несе ризики в процесах тестування тим, що процеси створення реєстрів на розробницьких та промислових оточеннях будуть відрізнятись. Для запобігання цьому розглянемо другий пункт.
Розширити Jenkins CD pipeline можливістю:
- задавати параметри для helmfile шаблону з сторінки запуску джоби
- завантаженням власного values.yaml на стейджі підготовки до розгортання оточення.

Специфікація параметрів у values.yaml

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

Table 1. spec parameters
Поле	Тип	Значення за замовчуванням	Приналежність	Призначення
`griada`	griada	-	Registry values.yaml	Налаштування програмно-апаратного криптомодуля "Гряда"
`global`	global	-	Registry values.yaml Cluster values.yaml	Глобальні параметри налаштувань реєстрів або Платформи

Table 2. griada object
Поле	Тип	Значення за замовчуванням	Призначення
`enabled`	string	Пусте значення. Встановлюється в залежності від попередньо заданого типу носія ключа на табі "Дані про ключ". Файловий носій — `false`, апаратний — `true`.	Поле для вказання, чи використовується апаратний ключ для реєстру.
`ip`	string	Пусте значення. Задається з поля `Хост ключа` на табі "Дані про ключ" при вибраному апаратному носію ключа.	Поле для вказання ip-адреси програмно-апаратного криптомодуля "Гряда".
`port`	string	Пусте значення. Задається з поля `Порт ключа` на табі "Дані про ключ" при вибраному апаратному носію ключа.	Поле для вказання порту програмно-апаратного криптомодуля "Гряда".

Параметр griada.url не виноситься на рівень адмін-консолі за відсутністю кейсів використання, а залишається доступним для зміни через комміт в Gerrit. При цьому, Griada ServiceEntry не повинен створюватись, якщо url не заданий явно.

Table 3. global object
Поле	Тип	Значення за замовчуванням	Приналежність	Призначення
`deploymentMode`	string	`development`	Registry values.yaml Cluster values.yaml	Поле для вказання режиму розгортання реєстру. Дозволені значення `development` або `production`.
`excludePortals`	list	Пусте значення.	Registry values.yaml	Поле для вказання, які портали не мають бути розгорнуті. За замовчуванням розгортаються всі. Дозволені значення в листі `citizen-portal`, `officer-portal`, `admin-portal`.
`computeResources`	computeResources	-	Registry values.yaml	Поле для вказання налаштувань віртуальних машин реєстру.
`registry`	registry	-	Registry values.yaml	Поле для вказання налаштувань компонентів реєстрів.

Table 4. computeResources object
Поле	Тип	Значення за замовчуванням	Призначення
`instanceCount`	integer	`2`	Поле для вказання кількості віртуальних машин для розгортання реєстру з типом інфраструктури `AWS` або `vSphere`.
`awsInstanceType`	string	`r5.2xlarge`	Поле для вказання типу AWS EC2-інстансу для розгортання реєстру з типом інфраструктури `AWS`.
`awsSpotInstance`	bool	`false`	Поле для вказання spot типу для AWS EC2-інстансу реєстру
`awsSpotInstanceMaxPrice`	string	Пусте значення	Поле для вказання максимальної ціни для AWS EC2 spot-інстансу
`awsInstanceVolumeType`	string	`gp3`	Поле для вказання типу системного диска AWS EC2-інстансу для розгортання реєстру з типом інфраструктури `AWS`.
`instanceVolumeSize`	integer	`80`	Поле для вказання розміру системного диска віртуальної машини реєстру з типом інфраструктури `AWS` або `vSphere`.
`vSphereInstanceCPUCount`	integer	`8`	Поле для вказання кількості vCPU віртуальної машини реєстру з типом інфраструктури `vSphere`.
`vSphereInstanceCoresPerCPUCount`	integer	`1`	Поле для вказання кількості ядер у кожного vCPU віртуальної машини реєстру з типом інфраструктури `vSphere`.
`vSphereInstanceRAMSize`	integer	`32768`	Поле для вказання кількості RAM віртуальної машини реєстру з типом інфраструктури `vSphere`.

Table 5. registry object
Поле	Тип	Значення за замовчуванням	Призначення
`geoServer`	geoServer	-	Поле для вказання, чи має бути розгорнута підсистема управління геоданими.
`restApi`	restApi	-	Поле для вказання налаштувань компонента `registry-rest-api`
….	….	….	….
<N інших компонентів>	-	-	Поле для вказання налаштувань N компонента.

Table 6. geoserver object
Поле	Тип	Значення за замовчуванням	Призначення
`enabled`	bool	`false`	Поле для вказання, чи має бути розгорнута підсистема управління геоданими.

Table 7. restapi object
Поле	Тип	Значення за замовчуванням	Призначення
`replicas`	integer	-	Поле для вказання кількості реплік.
`hpa`	hpa	-	Поле для вказання налаштування Horizontal Pod Autoscaler для компонента реєстру.
`requestsLimits`	requestsLimits	-	Поле для вказання налаштувань Requests/Limits для компонента реєстру.
`istio`	istio	-	Поле для вказання налаштування Istio Sidecar для компонента реєстру.
`container`	container	-	Поле для вказання налаштування ресурсів контейнера компонента реєстру.

Table 8. hpa object
Поле	Тип	Значення за замовчуванням	Призначення
`enabled`	bool	`false`	Поле для вказання, чи має бути налаштоване автоматичне масштабування.
`minReplicas`	integer	1	Поле для вказання мінімальної кількості реплік компонента.
`maxReplicas`	integer	3	Поле для вказання максимальної кількості реплік компонента.

Table 9. requestslimits object
Поле	Тип	Значення за замовчуванням	Призначення
`enabled`	bool	`false`	Поле для вказання, чи мають бути налаштовані Requests/Limits для компонента реєстру.

Table 10. istio object
Поле	Тип	Значення за замовчуванням	Призначення
`sidecar`	sidecar	-	Налаштування ресурсів для Istio Sidecar

Table 11. container object
Поле	Тип	Значення за замовчуванням	Призначення
`resources`	resources	-	Налаштування ресурсів контейнерів

Table 12. sidecar object
Поле	Тип	Значення за замовчуванням	Призначення
`enabled`	bool	`false`	Поле для вказання, чи має бути доданий Istio Sidecar до компонента.
`resources`	resources	-	Налаштування ресурсів контейнера.

Table 13. resources object
Поле	Тип	Значення за замовчуванням	Призначення
`requests`	requests	`false`	Поле для вказання, чи мають бути налаштовані Requests/Limits для компонента реєстру.
`limits`	limits	`false`	Поле для вказання, чи мають бути налаштовані Requests/Limits для компонента реєстру.

Table 14. requests object
Поле	Тип	Значення за замовчуванням	Призначення
`cpu`	string	-	Поле для вказання кількості виділеного CPU. Приклад: 100m (millicores).
`memory`	string	-	Поле для вказання кількості виділеного RAM. Приклад: 400mi (mebibytes).

Table 15. limits object
Поле	Тип	Значення за замовчуванням	Призначення
`cpu`	string	-	Поле для вказання кількості виділеного CPU. Приклад: 100m (millicores).
`memory`	string	-	Поле для вказання кількості виділеного RAM. Приклад: 400mi (mebibytes).

Високорівневий план розробки

Технічні експертизи

DevOps
FE

Попередній план розробки

[DevOps] Параметризація шаблонів та helm-чартів в control-plane-gerrit
[DevOps] Прибрати фільтрацію по cicd2 шаблонам в add_templates_repository.sh в control-plane-gerrit
[DevOps] Видалити зайві темплейти з control-plane-gerrit
[DevOps] Додати валідацію на рівні jenkins стейджів для параметрів
[DevOps] Підготувати CICD2 оточення для змін в підході до створення реєстру
[FE] Розширити сторінку створення/редагування реєстру табою "Параметри реєстру"
[FE] Винести параметри на UI з валідацією користувацього вводу та зберігати в відповідні values.yaml
[DevOps] Special Steps інструкція

Підтримка зворотної сумісності

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

Додатково пропонується Special Step при оновленні існуючих реєстрів у вигляді заповнення нової конфігурації адміністратором реєстру у values.yaml вручну з параметрами за інструкцією та оновленням в Codebase ресурсі існуючих реєстрів анотації з новим іменем шаблону:

annotations:
    registry-parameters/template-name: templates/registry-tenant-template