Розгортання Платформи з нуля у приватному хмарному середовищі vSphere

На цій сторінці:
🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.
Будь ласка, зверніться до вашого постачальника, щоб отримати необхідний vSphere-інсталятор.

1. Необхідні елементи початкового етапу

Перед початком будь-яких дій потрібно мати в наявності набір ресурсів, які обов’язкові для подальших кроків:

Документація:
Сертифікати цифрового підпису (digital-signature-ops сертифікати):

  • Key-6.dat — приватний ключ організації (лише для файлового ключа);

  • allowed-key.yaml — перелік усіх виданих ключів. Спочатку це лише первинний Key-6.dat. При зміні ключа, туди додається інформація про новий ключ, не видаляючи старий;

  • CAs.json — перелік всіх АЦСК, береться з сайту ІІТ;

  • CACertificates.p7b - публічний ключ, береться з сайту ІІТ.

Файли конфігурації для файлового та апаратного ключів:

  • 3 файли, заповнені значеннями — для файлового носія (див. закріплені приклади):

  • sign.key.device-type — вкажіть тип носія для ключа (файловий);

  • sign.key.file.issuer — вкажіть АЦСК, що видав ключ (замініть у файлі значення на своє);

  • sign.key.file.password — вкажіть пароль до файлового ключа (замініть у файлі значення на своє).

    4 файли із порожніми значеннями — для апаратного носія (створіть 4 порожні файли із відповідними назвами):

  • sign.key.hardware.device — тип носія для ключа (апаратний);

  • sign.key.hardware.password —  пароль апаратного ключа;

  • sign.key.hardware.type — тип ключа;

  • osplm.ini — INI-конфігурація.

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

2. Підготовка інфраструктури vSphere для встановлення OKD

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

2.1. Налаштування довіреного інтерфейсу vCenter API

Інсталер вимагає доступу до довіреного інтерфейсу vCenter API, який надає можливість завантажити довірені кореневі сертифікати CA vCenter.

Перед підключенням до API, сертифікати vCenter root CA повинні бути додані до системи, з якої запускатиметься OKD-інсталер.

2.2. Завантаження CA-сертифікатів

Сертифікати можуть бути завантажені з домашньої сторінки vCenter.

За замовчуванням сертифікати зберігаються за посиланням <vCenter>/certs/download.zip. Після завантаження і розархівування буде створено директорію, що містить сертифікати для ОС Linux, macOS та Windows.

2.2.1. Приклад перегляду структури

Структуру директорій із розміщеними в ній сертифікатами можна переглянути за допомогою команди:

$ tree certs

В результаті буде зображено наступну структуру:

certs

├── lin

│   ├── 108f4d17.0

│   ├── 108f4d17.r1

│   ├── 7e757f6a.0

│   ├── 8e4f8471.0

│   └── 8e4f8471.r0

├── mac

│   ├── 108f4d17.0

│   ├── 108f4d17.r1

│   ├── 7e757f6a.0

│   ├── 8e4f8471.0

│   └── 8e4f8471.r0

└── win

    ├── 108f4d17.0.crt

    ├── 108f4d17.r1.crl

    ├── 7e757f6a.0.crt

    ├── 8e4f8471.0.crt

    └── 8e4f8471.r0.crl


3 directories, 15 files

2.2.2. Приклад додавання сертифікатів

Необхідно додати відповідні сертифікати для вашої операційної системи.

Приклад для ОС Fedora:

$ sudo cp certs/lin/* /etc/pki/ca-trust/source/anchors

$ sudo update-ca-trust extract

2.3. Ресурси стандартної інсталяції

Стандартна інсталяція (Installer-Provisioned Infrastructure) створює наступні ресурси інфраструктури:

  • одну папку (1 Folder)

  • одну тег-категорію (1 Tag Category)

  • 1 тег (1 Tag)

  • віртуальні машини (Virtual machines):

    • один шаблон (1 template)

    • одну тимчасову ноду bootstrap (1 temporary bootstrap node)

    • три ноди консолі для управління Платформою (3 control-plane nodes)

    • три обчислювальні машини (3 compute machines)

2.3.1. Необхідні вимоги до ресурсів

2.3.1.1. Сховище даних

Разом із ресурсами, описаними вище, стандартне розгортання OKD вимагає мінімум 800 Гб простору для сховища даних.

2.3.1.2. DHCP

Розгортання вимагає налаштування DHCP-сервера для конфігурації мережі.

3. Розгортання та налаштування DNS і DHCP-компонентів

3.1. IP-адреси

Розгортання інфраструктури vSphere (Іnstaller-provisioned vSphere) вимагає двох статичних IP-адрес:

  • Адреса програмного інтерфейсу (API) - використовується для доступу до API-кластера.

  • Вхідна IP-адреса (Ingress) - використовується для вхідного трафіку кластера.

Віртуальні ІР-адреси для кожного з них повинні бути визначені у файлі install-config.yaml.

3.2. DNS-записи

DNS-записи (DNS records) повинні бути створені для двох ІР-адрес на будь-якому DNS-сервері, призначеному для середовища. Записи повинні містити значення, описані в таблиці:

Назва Значення

api.${cluster-name}.${base-domain}

API VIP

*.apps.${cluster-name}.${base-domain}`

Ingress VIP
${cluster-name} та ${base-domain} - це змінні, що взято із відповідних значень, вказаних у файлі install-config.yaml.

4. Створення конфігураційного файлу install-config.yaml

Передумови

  1. Увійдіть у свій обліковий запис Red Hat. Якщо у вас немає облікового запису, вам потрібно створити його.

  2. Придбайте платну підписку на DockerHub, якщо у вас її немає.

  3. Згенеруйте та додайте ssh-ключ до вашого конфігураційного файлу. Це необхідно для доступу до консолей ваших нод.

Створення файлу install-config.yaml, необхідного для розгортання OKD кластеру, виконується наступною командою:

$ openshift-installer create install-config

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

Конфігурація install-config.yaml 
apiVersion: v1
baseDomain: eua.gov.ua
compute:
- architecture: amd64
  hyperthreading: Enabled
  name: worker
  platform: {}
  replicas: 3
controlPlane:
  architecture: amd64
  hyperthreading: Enabled
  name: master
  platform: {}
  replicas: 3
metadata:
  creationTimestamp: null
  name: mdtuddm
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes
  serviceNetwork:
  - 172.30.0.0/16
platform:
  vsphere:
    apiVIP: 10.9.1.110
    cluster: HX-02
    datacenter: HXDP-02
    defaultDatastore: NCR_Data2
    ingressVIP: 10.9.1.111
    network: EPAM_OKD_Vlan9_EPG
    password: <password>
    username: epam_dev1@vsphere.local
    vCenter: vcsa.ncr.loc
publish: External
pullSecret: '{"auths":{"fake":{"auth":"aWQ6cGFzcwo="}}}'
sshKey: |
  <ssh_key>

  • Під час створення конфігураційного файлу замініть <password> на ваш пароль, а <ssh_key> — на ваш згенерований ssh-ключ.

  • Також скопіюйте параметри автентифікації з облікового запису Red Hat та підставте у поле pullSecret.

  • Зверніть увагу, що деякі параметри, можливо, доведеться змінити, щоб вони відповідали вашій інфраструктурі та потребам.

5. Запуск OKD4-інсталера та розгортання порожнього кластера OKD4

Після створення файлу install-config.yaml, для розгортання OKD-кластера необхідно виконати наступну команду:

$ openshift-installer create cluster
Процес розгортання кластера зазвичай займає до 1,5 години часу.

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

  • логін;

  • пароль;

  • посилання на веб-консоль кластера.

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

Також в цій директорії з’явиться папка /auth, в якій буде збережено два файли для автентифікації для роботи з кластером через вебконсоль та інтерфейс командного рядка OKD (OKD CLI).

Після запуску процесу розгортання кластера, Інсталер видаляє install-config.yaml, тому рекомендовано виконати резервування цього файлу, якщо є потреба розгортання кількох кластерів.

6. Заміна самопідписаних сертифікатів на довірені сертифікати

Для заміни самопідписаних (self-signed) сертифікатів на довірені (trusted) необхідно спочатку отримати ці сертифікати.

В цьому пункті розглянуто отримання безкоштовних сертифікатів Let’s Encrypt та їх встановлення на сервер.

Отримання сертифікатів Let’s Encrypt здійснено за допомогою утиліти acme.sh.

Для отримання розширених деталей щодо використання Let’s Encrypt на базі ACME-протоколу, зверніться до офіційного джерела.

6.1. Підготовка

Необхідно клонувати утиліту acme.sh із репозиторію GitHub:

$ cd $HOME
$ git clone https://github.com/neilpang/acme.sh
$ cd acme.sh

6.2. Запит на отримання сертифікатів

  1. Щоб полегшити процес отримання сертифікатів, необхідно задати дві змінні середовища. Перша змінна повинна вказувати на API Endpoint. Переконайтесь, що ви увійшли до OKD як system:admin і використовуєте CLI-консоль Openshift, щоб знайти API Endpoint URL.

    $ oc whoami --show-server
    Приклад отриманої відповіді
    https://api.e954.ocp4.opentlc.com:6443

  2. Тепер встановіть змінну LE_API для повністю визначеного доменного імені API:

    $ export LE_API=$(oc whoami --show-server | cut -f 2 -d ':' | cut -f 3 -d '/' | sed 's/-api././')

  3. Встановіть другу змінну LE_WILDCARD для вашого Wildcard Domain:

    $ export LE_WILDCARD=$(oc get ingresscontroller default -n openshift-ingress-operator -o jsonpath='{.status.domain}')

  4. Запустіть скрипт acme.sh:

    $ ${HOME}/acme.sh/acme.sh --issue -d ${LE_API} -d *.${LE_WILDCARD} --dns
    Приклад отриманої відповіді
    $  ./acme.sh --issue -d  ${LE_API} -d \*.${LE_WILDCARD} --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please
[Wed Jul 28 18:37:33 EEST 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Wed Jul 28 18:37:33 EEST 2021] Creating domain key
[Wed Jul 28 18:37:33 EEST 2021] The domain key is here: $HOME/.acme.sh/api.e954.ocp4.opentlc.com/api.e954.ocp4.opentlc.com.key
[Wed Jul 28 18:37:33 EEST 2021] Multi domain='DNS:api.e954.ocp4.opentlc.com,DNS:*.apps.e954.ocp4.opentlc.com'
[Wed Jul 28 18:37:33 EEST 2021] Getting domain auth token for each domain
[Wed Jul 28 18:37:37 EEST 2021] Getting webroot for domain='cluster-e954-api.e954.ocp4.opentlc.com'
[Wed Jul 28 18:37:37 EEST 2021] Getting webroot for domain=‘*.apps.cluster-e954-api.e954.ocp4.opentlc.com’
[Wed Jul 28 18:37:38 EEST 2021] Add the following TXT record:
[Wed Jul 28 18:37:38 EEST 2021] Domain: '_acme-challenge.api.e954.ocp4.opentlc.com'
[Wed Jul 28 18:37:38 EEST 2021] TXT value: 'VZ2z3XUe4cdNLwYF7UplBj7ZTD8lO9Een0yTD7m_Bbo'
[Wed Jul 28 18:37:38 EEST 2021] Please be aware that you prepend _acme-challenge. before your domain
[Wed Jul 28 18:37:38 EEST 2021] so the resulting subdomain will be: _acme-challenge.api.e954.ocp4.opentlc.com
[Wed Jul 28 18:37:38 EEST 2021] Add the following TXT record:
[Wed Jul 28 18:37:38 EEST 2021] Domain: '_acme-challenge.apps.e954.ocp4.opentlc.com'
[Wed Jul 28 18:37:38 EEST 2021] TXT value: 'f4KeyXkpSissmiLbIIoDHm5BJ6tOBTA0D8DyK5sl46g'
[Wed Jul 28 18:37:38 EEST 2021] Please be aware that you prepend _acme-challenge. before your domain
[Wed Jul 28 18:37:38 EEST 2021] so the resulting subdomain will be: _acme-challenge.apps.e954.ocp4.opentlc.com
[Wed Jul 28 18:37:38 EEST 2021] Please add the TXT records to the domains, and re-run with --renew.
[Wed Jul 28 18:37:38 EEST 2021] Please add '--debug' or '--log' to check more details.
    DNS-записи з попередньої відповіді необхідно додати на DNS-сервері, що відповідає за зону e954.ocp4.opentlc.com (значення зони тут є прикладом). Таким чином, TXT-записи повинні мати наступний вигляд:
    TXT-запис 1
    _acme-challenge.api.e954.ocp4.opentlc.com TXT value: 'VZ2z3XUe4cdNLwYF7UplBj7ZTD8lO9Een0yTD7m_Bbo'
    TXT-запис 2
    _acme-challenge.apps.e954.ocp4.opentlc.com TXT value: 'f4KeyXkpSissmiLbIIoDHm5BJ6tOBTA0D8DyK5sl46g'

  5. Після цього необхідно повторно запустити команду acme.sh:

    $ acme.sh --renew -d e954.ocp4.opentlc.com --yes-I-know-dns-manual-mode-enough-go-ahead-please

  6. Після успішного виконання попередніх пунктів необхідно запустити наступні команди.

    Зазвичай, хорошим підходом є перенесення сертифікатів зі шляху acme.sh за замовчуванням (default path) до більш зручної директорії. Для цього можна використати —install-cert-ключ скрипту acme.sh для копіювання сертифікатів до $HOME/certificates, для прикладу:

    $ export CERTDIR=$HOME/certificates

$ mkdir -p ${CERTDIR} ${HOME}/acme.sh/acme.sh --install-cert -d ${LE_API} -d *.${LE_WILDCARD} --cert-file ${CERTDIR}/cert.pem --key-file ${CERTDIR}/key.pem --fullchain-file ${CERTDIR}/fullchain.pem --ca-file ${CERTDIR}/ca.cer

6.2.1. Встановлення сертифікатів для Router

  1. Необхідно створити секрет. Для цього виконайте наступну команду:

    $ oc create secret tls router-certs --cert=${CERTDIR}/fullchain.pem --key=${CERTDIR}/key.pem -n openshift-ingress

  2. Після виконання попередніх кроків, необхідно оновити Custom Resource:

    $ oc patch ingresscontroller default -n openshift-ingress-operator --type=merge --patch='{"spec": 	{ "defaultCertificate": { "name": "router-certs" }}}'

7. Підготовка та запуск Інсталера для розгортання Платформи на цільовому OKD-кластері

Інсталер — набір команд (скрипт) для розгортання Платформи.

Для запуску Інсталера, необхідно виконати ряд умов з підготовки робочої станції, з якої запускатиметься Інсталер. Нижче розглянуто приклад такої підготовки на базі Ubuntu 20.04 LTS.

7.1. Передумови

Встановіть Docker з офіційного джерела: https://docs.docker.com/engine/install/.

7.2. Розгортання та оновлення Платформи

7.2.1. Розгортання Платформи з нуля

7.2.1.1. Передумови

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

    tar -xvzf /tmp/mdtu-ddm-platform-<VERSION>.tar.gz -d /home/<user>/workdir/installer-<version>

  2. Перенесіть kubeconfig після встановлення кластера:

    cd /home/<user>/workdir/installer-<version>
cp /path/to/kubeconfig ./

  3. Перенесіть папку certificates із файлами ключів та сертифікатів цифрового підпису для сервісу DSO (digital-signature-ops), які визначені у розділі Необхідні елементи початкового етапу цього документа.

    cp /path/to/folder/certificates ./
7.2.1.2. Додавання окремого конфігураційного файлу для розгортання у середовищі vSphere

  1. Відредагуйте exports.list для vSphere. Усі значення необхідно взяти після інсталяції кластера.

    vi exports.list

### vSphere Credentials ###
export VSPHERE_SERVER=""
export VSPHERE_USER=""
export VSPHERE_PASSWORD=""
export VSPHERE_CLUSTER=""
export VSPHERE_DATASTORE=""
export VSPHERE_DATACENTER=""
export VSPHERE_NETWORK=""
export VSPHERE_NETWORK_GATEWAY=""
export VSPHERE_RESOURCE_POOL="" #якщо не використовується, ставимо "/"
export VSPHERE_FOLDER=""

### Minio and Vault IPs ###
export VSPHERE_VAULT_INSTANCE_IP=""
export VSPHERE_MINIO_INSTANCE_IP=""

### id.gov.ua ###
export ID_GOV_UA_CLIENT_ID="mock"
export ID_GOV_UA_CLIENT_SECRET="mock"
7.2.1.3. Розгортання Інсталера

  1. Виконайте наступні команди:

    IMAGE_CHECKSUM=$(sudo docker load -i control-plane-installer.img | sed -r "s#.*sha256:(.*)#\\1#" | tr -d '\n');
echo $IMAGE_CHECKSUM
sudo docker tag ${IMAGE_CHECKSUM} control-plane-installer:<version>;

  2. Розгорніть нову версію Платформи з образами з нуля:

    sudo docker run --rm \ (1)
    --name control-plane-installer-<version> \
    --user root:$(id -g) \
    --net host \
    -v $(pwd):/tmp/installer \
    --env KUBECONFIG=/tmp/installer/kubeconfig \
    --env ID_GOV_UA_CLIENT_ID=mock \
    --env ID_GOV_UA_CLIENT_SECRET=mock \
    --env PLATFORM_DEPLOYMENT_MODE=development \ (2)
    --env PLATFORM_LANGUAGE=uk \ (3)
    --env PLATFORM_REGION=ua \ (4)
    --entrypoint "/bin/bash" control-plane-installer:<version> \
    -c "./install.sh -i" (5)
    1 --rm — цей параметр автоматично видалить контейнер після завершення його роботи. Параметр можна прибрати, якщо потрібно дізнатися статус та лог завершеного контейнера або при нестабільному інтернет-з’єднанні;
    2 PLATFORM_DEPLOYMENT_MODE:

    • development — для розгортання у режимі розробки;

    • production — для розгортання у виробничому середовищі;
    3 PLATFORM_LANGUAGE:

    • uk — значення вказує на застосування української мови за замовчуванням для вебпорталів Платформи. Після розгортання Платформи, мову інтерфейсів можна змінити в Адміністративній панелі Control Plane та Адміністративному порталі.

    • en — значення вказує на застосування англійської мови за замовчуванням для вебпорталів Платформи. Після розгортання Платформи мову інтерфейсів можна змінити в Адміністративній панелі Control та Адміністративному порталі.
    4 PLATFORM_REGION — для забезпечення підтримки роботи Платформи в різних регіонах або країнах, Платформний інсталятор підтримує вибір параметрів регіону обслуговування при створенні нової Платформи. Обране значення регіону обслуговування застосовується як для Платформи, так і для реєстрів, що будуть розгорнуті на ній. Після успішного проходження пайплайну, інстанс Платформи створюється з урахуванням обраного регіону. Значення регіону не відображається в Control Plane і не може бути змінено при редагуванні Платформи. При створенні нового реєстру для нього застосовується значення регіону обслуговування, обраного для усієї Платформи. Можливі значення параметра:

    • ua — значення вказує на розгортання інстансу Платформи відповідно до специфіки та потреб українського регіону обслуговування;

    • global — значення вказує на розгортання інстансу Платформи відповідно до специфіки та потреб міжнародного регіону обслуговування, що передбачає адаптацію та універсалізацію частини функціональності Платформи для інших міжнародних ринків, окрім України.
    5 -i — атрибут вказує на інсталювання Платформи.

7.2.2. Оновлення Платформи

7.2.2.1. Передумови

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

    tar -xvzf mdtu-ddm-platform-(version).tar.gz -C ./installer-<VERSION>

  2. Перенесіть kubeconfig після встановлення кластера:

    cd /home/<user>/workdir/installer-<version>
cp /path/to/kubeconfig ./

  3. Перенесіть папку certificates із файлами ключів та сертифікатів цифрового підпису для сервісу DSO (digital-signature-ops), які визначені у розділі Необхідні елементи початкового етапу цього документа.

    Якщо сертифікати не змінювалися, цей крок можна пропустити. 
    cp /path/to/folder/certificates ./
7.2.2.2. Додавання окремого конфігураційного файлу для розгортання у середовищі vSphere

  1. Перенесіть exports.list з минулого релізу.

    cp /home/<user>/workdir/installer-<previous_version>/exports.list ./
7.2.2.3. Налаштування компонента MinIO при оновленні кластера у середовищі vSphere

  1. Перенесіть tfstate MinIO з минулого релізу для vSphere.

    cp /home/<user>/workdir/installer-<version>/terraform/minio/vsphere/terraform.tfstate ./terraform/minio/vsphere/

  2. Перенесіть tfstate MinIO (Packer) з минулого релізу для vSphere.

    сp /home/<user>/workdir/installer-<version>/terraform/minio/vsphere/packer/terraform.tfstate ./terraform/minio/vsphere/packer/

  3. Перенесіть публічний та приватний SSH ключі для інстанса MinIO з минулого релізу для vSphere.

    сp /home/<user>/workdir/installer-<version>/terraform/minio/vsphere/packer/*.key ./terraform/minio/vsphere/packer/
7.2.2.4. Налаштування компонента Vault при оновленні кластера у середовищі vSphere

  1. Перенесіть tfstate Vault з минулого релізу.

    cp /home/<user>/workdir/installer-<version>/terraform/vault/vsphere/terraform.tfstate ./terraform/vault/vsphere/

  2. Перенесіть tfstate Vault (Packer) з минулого релізу.

    сp /home/<user>/workdir/installer-<version>/terraform/vault/vsphere/packer/terraform.tfstate ./terraform/vault/vsphere/packer/

  3. Перенесіть публічний та приватний SSH ключі для інстанса Vault з минулого релізу для vSphere.

    сp /home/<user>/workdir/installer-<version>/terraform/vault/vsphere/packer/*.key ./terraform/vault/vsphere/packer/
7.2.2.5. Розгортання Інсталера

  1. Виконайте наступні команди:

    IMAGE_CHECKSUM=$(sudo docker load -i control-plane-installer.img | sed -r "s#.*sha256:(.*)#\\1#" | tr -d '\n');
echo $IMAGE_CHECKSUM
sudo docker tag ${IMAGE_CHECKSUM} control-plane-installer:<version>;

  2. Оновіть версію Платформи з образами оновлення.

    sudo docker run --rm \ (1)
    --name control-plane-installer-<version> \
    --user root:$(id -g) \
    --net host \
    -v $(pwd):/tmp/installer \
    --env KUBECONFIG=/tmp/installer/kubeconfig \
    --env ID_GOV_UA_CLIENT_ID=mock \
    --env ID_GOV_UA_CLIENT_SECRET=mock \
    --env PLATFORM_DEPLOYMENT_MODE=development \ (2)
    --env PLATFORM_LANGUAGE=uk \ (3)
    --env PLATFORM_REGION=ua \ (4)
    --entrypoint "/bin/bash" control-plane-installer:<version> \
    -c "./install.sh -u" (5)
    1 --rm — цей параметр автоматично видалить контейнер після завершення його роботи. Параметр можна прибрати, якщо потрібно дізнатися статус та лог завершеного контейнера або при нестабільному інтернет-з’єднанні;
    2 PLATFORM_DEPLOYMENT_MODE:

    • development — для розгортання у режимі розробки;

    • production — для розгортання у виробничому середовищі;
    3 PLATFORM_LANGUAGE:

    • uk — значення вказує на застосування української мови за замовчуванням для вебпорталів Платформи. Після розгортання Платформи, мову інтерфейсів можна змінити в Адміністративній панелі Control Plane та Адміністративному порталі.

    • en — значення вказує на застосування англійської мови за замовчуванням для вебпорталів Платформи. Після розгортання Платформи мову інтерфейсів можна змінити в Адміністративній панелі Control та Адміністративному порталі.
    4 PLATFORM_REGION — для забезпечення підтримки роботи Платформи в різних регіонах або країнах, Платформний інсталятор підтримує вибір параметрів регіону обслуговування при створенні нової Платформи. Обране значення регіону обслуговування застосовується як для Платформи, так і для реєстрів, що будуть розгорнуті на ній. Після успішного проходження пайплайну, інстанс Платформи створюється з урахуванням обраного регіону. Значення регіону не відображається в Control Plane і не може бути змінено при редагуванні Платформи. При створенні нового реєстру для нього застосовується значення регіону обслуговування, обраного для усієї Платформи. Можливі значення параметра:

    • ua — значення вказує на розгортання інстансу Платформи відповідно до специфіки та потреб українського регіону обслуговування;

    • global — значення вказує на розгортання інстансу Платформи відповідно до специфіки та потреб міжнародного регіону обслуговування, що передбачає адаптацію та універсалізацію частини функціональності Платформи для інших міжнародних ринків, окрім України.
    5 -u — атрибут вказує на оновлення Платформи.

8. Управління налаштуваннями Платформи

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

Метадані усіх компонентів, для яких реалізовано управління через GitOps-підхід, зберігаються в компоненті cluster-mgmt.

Нижче представлено список компонентів, для яких наразі імплементований GitOps-підхід:

  • catalog-source

  • monitoring

  • storage

  • logging

  • service-mesh

  • backup-management

  • user-management

  • control-plane-nexus

  • external-integration-mocks

  • cluster-kafka-operator

  • smtp-server

  • redis-operator

  • postgres-operator