Процес роботи інсталятора Платформи

Для перегляду діаграми послідовності для роботи інсталятора, перейдіть на архітектуру відповідної підсистеми обслуговування Платформи

Кастомне оновлення control-plane компонентів

Як видно із діаграми послідовності, компонент підсистеми розгортання та налаштування Платформи / реєстрів не керується з адмін-консолі, а з самого інсталятора і таким чином, при оновленні Платформи можуть виникнути проблеми при оновленні компонентів control-plane якщо в них були ручні зміни (наприклад в розмірі диску). Для вирішення цієї проблеми розглянемо два типи кластерів:

Автономні (standalone) кластера Платформи

Такі кластери були підняті вручну, без використання автоматизації кластера CICD2, тому для редагування values.yaml в компонентах control-plane можна скористатись розпакованим архівом інсталятора Платформи та в потрібному компоненті змінити значення на потрібні. Наприклад, values.yaml для компонента control-plane-jenkins знаходяться за шляхом mdtu-ddm-platform-x.x.x.x/repositories/components/control-plane/control-plane-jenkins.git/deploy-templates/values.yaml Відповідно, необхідно змінити значення за замовчуванням

jenkins:
  logLevel: WARNING
  clusterRoleName: jenkins-clusterrole
  serviceAccountName: jenkins
  initImage:
    name: busybox
  image:
    name: epamedp/edp-jenkins
    version: 2.7.0
  storage:
    size: 10Gi

та запустити інсталятор з флагом --update.

Кластера, що оновлюються та керуються з CICD2

Інша ситуація з кластерами які були розгорнуті та керуються з розробницького кластера CICD2. Є два способи:

  1. Потрібно внести зміни в пайплайн platform-deploy щоб мати змогу завантажити свій кастомний values.yaml з власними значеннями параметрів розгортання компонентів.

  2. Зробити тимчасовий МР в репозиторій edp-library-stages-fork в стейдж platform-deploy та між 130-131 рядком коду додати додаткову команду sleep 600, як показано в наступному прикладі:

    ...
"sudo docker tag \${IMAGE_CHECKSUM} control-plane-installer:latest; " +
"sleep 600" +
"sudo docker run --rm --name control-plane-installer-${context.cluster.name} " +
...

    Після цього запустити пайплайн platform-deploy з флагом оновлення, зайти по ssh на docker-external інстанс, знайти розпакований архів інсталятора Платформи та в потрібному компоненті змінити значення на потрібні.

Висновки

  1. Для standalone кластерів, необхідно створити інструкцію по кастомізації values.yaml для таких компонентів під час апдейту.

  2. Для кластерів що керуються з CICD2 (envone, envtwo) потрібно покращити пайплайн функціоналом, що дозволить підкласти свої кастомні values під час деплою (поки це не зроблено можно користуватись workaround, який дозволить підкласти їх без окремого функціоналу)