Инструкция по установке

Сокращения

Сокращение	Расшифровка
СХД	Система хранения данных
API	Application Programming Interface, интерфейс программирования приложения
BMC	Bare Machine Computing, сырые машинные вычисления
CA	Certification Authority, удостоверяющий центр
CI/CD	Continuous Integration/Continuous Deployment, непрерывная интеграция/непрерывное развертывание
CMDB	Configuration Management Data Base, база данных управления конфигурацией
CPU	Central Processing Unit, центральный процессор
DHCP	Dynamic Host Configuration Protocol, протокол динамической настройки узла
FC	Fibre Channel, волоконный канал
FIP	Floating IP, плавающий IP-адрес
FQDN	Fully Qualified Domain Name, полное доменное имя
HDD	Hard Disk Drive, энергонезависимое запоминающее устройство
IP	Internet Protocol, межсетевой протокол
IPMI	Intelligent Platform Management Interface, интеллектуальный интерфейс управления платформой
iSCSI	Internet Small Computer System Interface, интерфейс малых компьютерных систем интернета
KVM	Kernel-based Virtual Machine
LCM	Life Cycle Manager, менеджер жизненного цикла
LTS	Long term support, длительная поддержка продукта
MTU	Maximum transmission unit, максимальный объем данных за итерацию
NFS	Network File System, сетевая файловая система
NIC	Network Interface Controller, сетевая плата
NTP	Network Time Protocol, протокол сетевого времени
PXE	Pre Execution Environment, среда предварительного исполнения
QoS	Quality of Service, качество обслуживания
RMI	Remote Management Interface, интерфейс удаленного управления
SQL	Structured Query Language, язык структурированных запросов
SSD	Solid-State Drive, твердотельный накопитель
SSL	Secure Sockets Layer, протокол безопасности сокетов
TFTP	Trivial File Transfer Protocol, простой протокол передачи файлов
TLS	Transport Layer Security, протокол защиты транспортного уровня
VIP	Virtual IP, виртуальный IP-адрес
VNC	Virtual Network Computing, виртуальные сетевые вычисления

Введение

Назначение документа: привести подробную инструкцию по установке для облачной платформы KeyStack (далее — Платформа) на инфраструктуре Заказчика (On-Premise).

В общем виде развертывание Платформы состоит из шагов:

1. Подготовка инфраструктуры.

2. Распаковка дистрибутива Платформы.

3. Установка основных компонентов Платформы.

4. Настройка сетевой связности.

5. Ручной запуск пайплайнов.

6. Подключение и настройка служебных сервисов.

7. Проверка работоспособности Платформы.

Целевая аудитория документа

Системные администраторы, которые будут разворачивать и настраивать Платформу на целевой инфраструктуре.

К системным администраторам предъявляются требования:

• Навыки системного администрирования Linux.

• Навыки организации и настройки сетевой связности между серверами (узлами).

• Понимание принципа работы OpenStack-сервисов Платформы.

• Умение собирать диагностические данные для эскалации сложных проблем производителю.

Варианты поставки

Доступные варианты поставки исходного дистрибутива Платформы:

• через сеть Интернет по ссылке от вендора, которую можно получить у менеджера вашего аккаунта;

• в отдельном архиве (если инфраструктура развернута в закрытом контуре).

Important

Ссылка на дистрибутив может изменяться в зависимости от версии релиза.

Типы узлов

Платформа использует для управления инфраструктурой узлы нескольких типов:

• LCM (Seed node) — главный узел управления сервисной инфраструктурой Платформы. На нем хранится кодовая база основных компонентов Платформы и основная конфигурация узлов остальных типов. С этого узла начинается развертывание Платформы и управление ее жизненным циклом.

• Controller — узел с управляющими модулями вычислительных ресурсов, сетевых агентов и вспомогательными службами. В некоторых случаях может совмещать роль узла Network.

• Compute — узел с гипервизором KVM, управляет виртуальными машинами (ВМ) основной инфраструктуры. Для обеспечения сетевой связности ВМ используется агент сетевой службы.

• Storage — узел с дисками блочных хранилищ. Блочные хранилища используются для организации индивидуального и/или совместного дискового пространства для ВМ.

• Network — узел с компонентами программно-определяемых сетей.

Лицензии и зависимости

Во время эксплуатации Платформы должны соблюдаться лицензии разворачиваемых программных компонентов:

• GitLab,

• Nexus,

• Vault,

• Netbox,

• Docker,

• Opensearch,

• Prometheus,

• Grafana,

• Zabbix,

• Fluentd,

• Redis.

Tip

Лицензия на использование для не упомянутых в списке выше компонентов совпадает с лицензией разработчиков этих компонентов.

Требования к инфраструктуре

Аппаратные требования

Требование / Тип узла	LCM	Controller	Compute	Network	Storage*
Обязательность	Да	Да	Да	Да	Нет
Минимальное количество узлов	1	3	2	1	–
Оперативная память	24 ГБ	256 ГБ			–
Процессор	4	2x8	2x12	2x8	–
Архитектура процессора	x86-64 / AMD64
Память	200 ГБ HDD	2x512 ГБ SSD (RAID 1)			–
Сетевая карта	2x10 ГБ NIC	2x10 ГБ NIC	2x10 ГБ NIC (2x 2x10 Gb NIC)		–

*Могут использоваться программные или аппаратные решения. Список поддерживаемых СХД — на сайте KeyStack.

Note

Если количество сетевых интерфейсов на Controller-узле больше, чем указано в требованиях, отключите все незадействованные порты.

Программные требования

Требование / Тип узла	LCM	Controller	Compute	Network	Storage
Операционная система	Ubuntu 22.04 LTS / SberLinux 9.4 (Dzhangitau)
Минимальная версия ядра	5.15.0-76
Наличие сетевой связности между узлами	Да
Поддержка виртуализации	Intel VT-x (Virtualization Technology) или AMD-V (AMD Virtualization)

Подготовительные шаги

1. Создайте узлы необходимых типов согласно указанным аппаратным и программным требованиям.

2. Убедитесь, что на всех узлах время в БИОС настроено в UTC.

3. На LCM-узле под управлением ОС SberLinux должна быть выполнена команда timedatectl set-local-rtc 0.

4. Убедитесь в наличии пользователя root.

   Danger

   Выполняйте все команды руководства от пользователя root.

5. Убедитесь, что на всех узлах включена аппаратная виртуализация, с помощью команды:

   egrep '(vmx|svm)' /proc/cpuinfo

   Вывод должен содержать параметр vmx или svm. Если он отсутствует, включите аппаратную виртуализацию.

6. Получите дистрибутив одним из вариантов поставки.

7. Создайте DNS-зону для сервисов Платформы, в которой необходимо создать записи для следующих сервисов:

   • <GITLAB_NAME>.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ> — для управления жизненным циклом Платформы (CI);

   • <NEXUS_NAME>.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ> — для хранения артефактов Платформы (пакеты, контейнеры и др.);

   • <VAULT_NAME>.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ> — для хранения паролей и сертификатов;

   • <NETBOX_NAME>.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ> — для настроек Baremetal-узлов.

8. (Опционально) Выберите свои доменные имена. По умолчанию используются имена:

   • <GITLAB_NAME> — ks-lcm;

   • <NEXUS_NAME> — nexus;

   • <VAULT_NAME> — vault;

   • <NETBOX_NAME> — netbox.

9. На LCM-узле проверьте сетевую связность:

   1. Настройте доступ до IPMI всех узлов инфраструктуры, MGMT-интерфейсов и VIP-адресов.

   2. Проверьте доступность DHCP-сервера в сети PXE.

   3. Включите поддержку Redfish всех узлов инфраструктуры.

   4. Для всех Baremetal-узлов создайте пользователя с правами administrator.

10. В DNS-зоне для сервисов Платформы создайте DNS-записи вида:

    <IP_АДРЕС> <ИМЯ_УЗЛА>-rmi.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>
    

11. Подготовьте данные для импорта в Netbox сведениями о вашей инфраструктуре:

    1. Скачайте файл netbox2csv.xlsx.

    2. Ознакомьтесь с форматом заполнения тестовых данных и очистите таблицы на вкладках SERVERS и Hardware.

    3. Заполните данные в скачанном файле:

       • на вкладке SERVERS:

         • Tenant — наименование тенанта;

         • Name — имя узла;

         • Role — тип узла;

         • RMI IP/MASK — IP-адрес IPMI-порта в формате <RMI_IP>/<МАСКА>;

         • <MGMT_IP>/<MASK> — IP-адрес MGMT в формате <MGMT_IP>/<МАСКА>;

         • Hardware — марка и модель узла, выбрать из раскрывающегося списка;

         • Tags — теги для группировки узлов.

       • на вкладке Hardware (если совместимого оборудования не было в списке Hardware):

         • Hardware — название сервера;

         • Manufacturer — производитель сервера;

         • Type — марка или модель сервера.

    4. Убедитесь, что на остальных вкладках заполненного файла появились данные о новых серверах.

12. Если для хранилища артефактов будет использовано клиентское хранилище Nexus, необходимо подготовить структуру:

    SberLinuxUbuntu

    Название	Тип	Формат
    docker-sberlinux	hosted	yum
    images	hosted	raw
    k-add	hosted	raw
    k-backup	hosted	raw
    k-images	hosted	docker
    k-pip	hosted	pypi
    sberlinux	hosted	yum

Установка и настройка компонентов

Чтобы установить и настроить основные компоненты Платформы:

1. На LCM-узел установите дистрибутив Платформы.

2. Подготовьте Baremetal-узлы (далее — BMC-узлы) для эксплуатации.

3. Создайте нужное количество регионов.

4. Разверните нужное количество виртуальных сетей и подсетей.

5. Создайте шаблоны образов и типов дисков.

Подробная инструкция по каждому шагу приведена ниже.

Шаг 1. Установите дистрибутив Платформы на LCM-узле

1. Зайдите на LCM-узел по SSH.

2. Получите архив Платформы одним из способов поставки.

3. Переключитесь на пользователя root и распакуйте дистрибутив Платформы. Пример для Ubuntu:

   sudo su
   tar -xf <ПУТЬ_К_ДИСТРИБУТИВУ>/installer-ks2024.4-ubuntu-offline.tgz -C ~/
   cd installer/
   

4. Если для хранилища артефактов будет использовано клиентское хранилище Docker-образов:

   1. На LCM-узле разместите полную цепочку сертификатов сервиса в новом файле <FQDN>.pem директории installer/certs.

   2. Убедитесь, что существует пользователь с правами pull и push в вашем Docker-хранилище.

   Note

   Docker-образ для Openstack и kolla-ansible будут сохранены в клиентском Nexus в пространстве project_k.

5. При интеграции AD/LDAPs с TLS компонентов Keystack:

   1. На LCM-узле разместите полную цепочку сертификатов AD/LDAPs с TLS в новом файле ldaps.pem директории installer/certs.

6. В распакованном архиве запустите скрипт installer.sh.

7. Последовательно введите запрашиваемые данные:

   • home dir for the installation: путь к директории с установщиком, по умолчанию /installer;

   • IP address of this machine: IP-адрес LCM-узла или адрес конкретного интерфейса, если их несколько;

   • Use remote/existing Artifactory:

     • y — использовать собственное хранилище артефактов; при выборе этого варианта укажите:

       • FQDN хранилища Nexus, не должно совпадать с FQDN для Nexus в составе дистрибутива Платформы;

       • имя пользователя с правами pull и push в Docker-хранилище;

       • пароль пользователя с правами pull и push в Docker-хранилище, длина — не менее 8 символов.

     • n — развернуть новый Nexus (вариант по умолчанию).

   • auth LDAP for Gitlab and Netbox:

     • y — включить поддержку ролевой модели в Gitlab и Netbox; при выборе этого варианта укажите:

       • LDAP Server URI: адрес AD/LDAPs в формате ldaps://<IP_ИЛИ_FQDN>;

       • LDAP BIND DN: пользователь в AD/LDAPs с правами просмотра, используется для подключения к AD/LDAP;

       • LDAP BIND Password: пароль пользователя для подключения к AD/LDAPs;

       • LDAP USER SEARCH BASEDN: имя контейнера (Distinguished Name), в AD, откуда начинается поиск пользователей;

       • LDAP GROUP SEARCH BASEDN: группа для поиска пользователя; вернет все группы, к которым принадлежит пользователь;

       • LDAP GROUP for reader role: группа AD/LDAPs, пользователи из которой соответствуют роли reader;

       • LDAP GROUP for auditor role: группа AD/LDAPs, пользователи из которой соответствуют роли auditor;

       • LDAP GROUP for operator role: группа AD/LDAPs, пользователи из которой соответствуют роли operator;

       • LDAP GROUP for admin role: группа AD/LDAPs, пользователи из которой соответствуют роли admin.

   • root domain name: доменное имя второго уровня для сервисов Платформы, далее — <ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>;

   • Nexus domain name: доменное имя сервиса Nexus;

   • GitLab domain name: доменное имя сервиса GitLab;

   • Vault domain name: доменное имя сервиса Vault;

   • Netbox domain name: доменное имя сервиса Netbox;

   • Generate Self-signed certificates:

     • y — сгенерировать новые самоподписанные сертификаты (вариант по умолчанию);

     • n — использовать существующие сертификаты; при выборе этого варианта положите в папку installer/certs сертификаты:

       • ca.crt — корневой сертификат (root CA);

       • chain-ca.pem — цепочка CA-сертификатов;

       • <NEXUS_NAME>.crt и <NEXUS_NAME>.key — сертификат и приватный ключ сертификата для сервиса Nexus;

       • <GITLAB_NAME>.crt и <GITLAB_NAME>.key — сертификат и приватный ключ сертификата для сервиса Gitlab;

       • <VAULT_NAME>.crt и <VAULT_NAME>.key — сертификат и приватный ключ сертификата для сервиса Vault;

       • <NETBOX_NAME>.crt и <NETBOX_NAME>.key — сертификат и приватный ключ сертификата для сервиса Netbox.

8. Дождитесь завершения операции. При успешной установке появятся реквизиты для доступа к компонентам Платформы.

   Note

   На LCM-узле будут установлены и настроены компоненты:

   • SSH-ключи для беспарольного доступа на узлы;

   • самоподписанные сертификаты для служб LCM;

   • хранилище Sonatype Nexus (если был выбран вариант нового хранилища);

   • система автоматизации (GitLab-CI);

   • репозитории управления облаком (CI/CD);

   • Netbox (CMDB).

9. Сохраните реквизиты доступа к компонентам:

   • GitLab root password;

   • GitLab runner token;

   • GitLab SSH private key;

   • GitLab SSH public key;

   • Nexus admin password;

   • Netbox admin password;

   • Netbox postrges password;

   • Netbox redis password;

   • Netbox redis cache password;

   • Vault Initial Root Token;

   • Vault Unseal Key 1;

   • Root CA Certificate.

   Danger

   После закрытия или очищения терминала реквизиты доступа будут удалены безвозвратно с LCM-узла!

   Данные с текущей конфигурацией об инсталляции сохраняются в Vault в secret_v2/deployments/secrets/accounts.

10. Добавьте корневой сертификат (значение параметра Root CA Certificate) в формате Base64 ASCII в доверенные корневые Центры сертификации для корректной работы веб-интерфейсов Платформы.

Настройка собственного корневого сертификата

Все пароли и сертификаты Платформы должны храниться в сервисе Vault (vault.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>).

Note

Инсталлятор генерирует собственные сертификаты Платформы с помощью программы openssl:

1. Создает корневой центр сертификации: корневой сертификат и приватный ключ. Срок действия — 10 лет.

2. Создает Wildcard-сертификат и приватный ключ для сервисов GitLab, Nexus, Vault, Netbox и делает их доверенными Центру сертификации. Также создается цепочка сертификатов вида chain-cert.pem для сервисов. Срок действия — 2 года.

3. Создает в Vault репозиторий installer для хранения сертификатов и создает в этом хранилище Центр сертификации на основе корневого центра. Срок действия — 2 года.

4. Создает роль, с помощью которой можно выписывать сертификаты на основе запросов пользователей.

Чтобы использовать собственные сертификаты:

1. Подготовьте цепочку сертификатов для своего Nexus в файле <FQDN>.pem.

2. Откройте веб-интерфейс развернутого Vault (vault.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>).

3. Авторизуйтесь с помощью реквизитов для Vault, полученных на этапе установки дистрибутива Платформы.

4. Откройте на редактирование файл secret_v2/deployments/secrets/ca.crt и дополните его цепочкой сертификатов для своего Nexus.

Настройка ролевой модели в Gitlab и Netbox

1. Настройка ролевой модели в Netbox

   1. После инсталляции зайдите в Web-интерфейс Netbox одним пользователем из каждой сопоставленной группы LDAP. При этом действии каждая группа будет зарегистрирована в Netbox.

   2. Зайдите пользователем с ролью admin.

   3. Перейдите в Администратор → Аутентификация → Группы.

   4. Отредактируйте группы и выставите им разрешения:

      1. Для групп с ролью operator, security_auditor и reader укажите разрешение perm_ro.

      2. Для групп с ролью admin укажите разрешение perm_rw.

2. Настройка ролевой модели в Gitlab

   1. После инсталляции зайдите в Web-интерфейс Gitlab пользователем root. При аутентификации выбирайте вариант входа “Standard”.

   2. Перейдите в репозиторий project_k/services/gitlab-ldap-sync, откройте на редактирование файл gitlab-ldap-sync.conf:

      1. В секции [gitlab] в строке groups= укажите названия ваших сопоставляемых AD/LDAPs групп. Отредактируйте значения ключа ldap: для каждой группы. Руководствуйтесь назначением сопоставляемых групп, описанным в Описание ролевой модели.

      2. В секции [ldap] в строке admingroup= укажите название AD/LDAPs группы, которая сопоставляется с ролью admin.

   3. Запустите пайплайн по умолчанию для первичной синхронизации пользователей из AD/LDAPs. При запуске пайплайна убедитесь, что в переменной KEYSTACK_RELEASE указано актуальное значение релиза.

   4. В репозитории project_k/services/gitlab-ldap-sync в разделе Build → Pipeline schedules настройте периодичность запуска пайплайна.

3. Проверка настройки

   1. Войдите в Web-интерфейс Netbox и Gitlab пользователями с разными ролями. При аутентификации выбирайте вариант входа “LDAP”. Вход должен быть успешным, доступные элементы соответствовать роли пользователя.

Шаг 2. Подготовьте BMC-узлы инфраструктуры

1. Запустите пайплайн на генерацию паролей и сертификатов для Bifrost:

   1. Откройте веб-интерфейс развернутого GitLab (ks-lcm.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>).

   2. Авторизуйтесь с помощью реквизитов для GitLab, полученных на этапе установки дистрибутива Платформы.

   3. Откройте проект project_k → deployments → gen-pwd.

   4. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

   5. В открывшемся окне добавьте переменную OPENSTACK_ENV со значением bifrost и запустите пайплайн.

   6. Запустите задачу create-config в созданном пайплайне.

   7. Дождитесь завершения выполнения операции.

2. Перейдите в репозиторий project_k → deployments → bifrost.

3. Установите Bifrost:

   1. Откройте файл inventory и замените в нем значение LCM_IP на IP-адрес LCM-узла.

   2. Откройте файл globals.d/REGION.yml и замените значение eth0 параметра network_interface на имя интерфейса на LCM-узле (например, mgmt).

   3. Откройте файл config/bifrost/bifrost.yml и внесите в него изменения:

      • Добавьте или измените строки ipa_kernel_url: "http://LCM_IP:8080/ipa-centos9-debug-anthelope.kernel" и ipa_ramdisk_url: "http://LCM_IP:8080/ipa-centos9-debug-anthelope.initramfs", заменив LCM_IP на IP-адрес LCM-узла.

      • Если требуется добавить свой NTP-сервер, раскомментируйте строку #inspector_extra_kernel_options: и замените в ней ipa-ntp-server=10.224.128.1 на IP-адрес своего NTP-сервера.

   4. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

   5. Дождитесь завершения выполнения операции.

4. Настройте dnsmasq в Bifrost:

   1. Зайдите на LCM-узел по ssh и выполните команду:

      # docker exec -ti bifrost_deploy bash
      (bifrost-deploy)# vi /etc/dnsmasq.conf
      

   2. В открывшемся файле поменяйте значения:

      • listen-address=LCM_IP, заменив LCM_IP на IP-адрес LCM-узла.

      • dhcp-boot=tag:ipxe,http://LCM_IP:8080/boot.ipxe, заменив LCM_IP на IP-адрес LCM-узла.

      • dhcp-range=10.0.0.10,10.0.0.100,255.255.255.0,24h - укажите диапазон адресов DHCP для выдачи IP серверам.

      • dhcp-option=3,10.0.0.254 - укажите маршрут по умолчанию для IP-адресов, выдаваемых по DHCP.

   3. Сохраните изменения закройте файл. Перезапустите сервис dnsmasq командой:

      (bifrost-deploy)# systemctl enable dnsmasq
      (bifrost-deploy)# systemctl restart dnsmasq
      

5. Настройте правила firewall для Bifrost (опционально):

   SberLinuxUbuntu

   1. Зайти на LCM-узел по ssh и выполнить команду:

      # firewall-cmd --add-service=dhcp --permanent
      # firewall-cmd --add-port=8080/tcp --permanent
      # firewall-cmd --add-service=tftp --permanent
      # firewall-cmd --add-port=5050/tcp --permanent
      # firewall-cmd --add-port=6385/tcp --permanent
      # firewall-cmd --reload
      

6. Для всех BMC-узлов задайте одинакового пользователя и пароль:

   1. Перейдите в веб-интерфейс развернутого Vault.

   2. Перейдите в директорию с настройками Bifrost secret_v2/deployments/bifrost/rmi.

   3. Нажмите Create new version для параметра с именем пользователя.

   4. Задайте имя пользователя интерфейса IPMI BMC-узлов.

   5. Повторите операцию для пароля, указав пароль от интерфейса IPMI BMC-узлов.

   Note

   Указание одинаковых пользователей необходимо для автоэвакуации ВМ при сбое гипервизора.

7. Откройте веб-интерфейс развернутого Netbox (netbox.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>).

8. Авторизуйтесь с помощью реквизитов для Netbox, полученных на этапе установки дистрибутива Платформы.

9. Импортируйте данные из XLSX-файла, заполненного при подготовительных шагах, в разделах:

   • Tenants — содержимое вкладки netbox_tenant.csv.

   • Sites — содержимое вкладки netbox_site.csv.

   • Devices — содержимое вкладки netbox_device.csv.

   • Interfaces — содержимое вкладки netbox_interface.csv.

   • IP Addresses — содержимое вкладки netbox_ip.csv.

   • Customization → Customization → Tags — добавьте все добавленные теги вручную из вкладки SERVERS.

10. Завершите настройку Netbox:

    1. В Netbox, разделе API tokens, скопируйте токен.

    2. На LCM-узле выполните скрипт из XLSX-файла в CLI, вкладка update_ctx.sh, предварительно заменив значения:

       • NETBOX_TOKEN — токен Netbox из раздела API tokens;

       • NETBOX_URI — адрес Netbox в формате https://netbox.demo.local/.

11. Настройте контекст для одного из типов узлов:

    1. В веб-интерфейсе Netbox перейдите в раздел Provisioning → Config Contexts.

    2. Нажмите кнопку Add.

    3. Вставьте конфигурацию в поле Data:

       • пример для Compute-узлов:

         {
            "bonds": [
               {
                  "Interface": "bond0",
                  "MTU": 9000,
                  "Slaves": [
                     "ens1f0np0",
                     "ens2f0np0"
                  ],
                  "Tagged_vlan": [
                     "40"
                  ]
               },
               {
                  "Interface": "bond1",
                  "MTU": 9000,
                  "Slaves": [
                     "ens2f1np1",
                     "ens1f1np1"
                  ],
                  "Tagged_vlan": []
               },
               {
                  "Interface": "bond2",
                  "MTU": 9000,
                  "Slaves": [
                     "eno1",
                     "eno2",
                     "eno3",
                     "eno4"
                  ],
                  "Tagged_vlan": []
               }
            ],
            "default_gateway": "10.30.55.60/20",
            "dns_name": "lab.cloud.cfg_fake.ru",
            "dns_server": [
               "11.55.70.153",
               "11.25.44.11"
            ],
            "vlans": [
               {
                  "Interface": "mgmt",
                  "MTU": "9000",
                  "Parent": "bond0",
                  "id": "40"
               }
            ]
         }
         

       • пример для Controller-узлов:

         {
            "bonds": [
               {
                  "Interface": "bond0",
                  "MTU": 9000,
                  "Slaves": [
                     "ens1f0np0",
                     "ens2f0np0"
                  ],
                  "Tagged_vlan": [
                     "39",
                     "484"
                  ]
               },
               {
                  "Interface": "bond1",
                  "MTU": 9000,
                  "Slaves": [
                     "ens2f1np1",
                     "ens1f1np1"
                  ],
                  "Tagged_vlan": []
               },
               {
                  "Interface": "bond2",
                  "MTU": 9000,
                  "Slaves": [
                     "eno1",
                     "eno2",
                     "eno3",
                     "eno4"
                  ],
                  "Tagged_vlan": []
               }
            ],
            "default_gateway": "10.30.55.60/20",
            "dns_name": "lab.cloud.cfg_fake.ru",
            "dns_server": [
               "11.55.70.153",
               "11.25.44.11"
            ],
            "route_vxlan": [
               {
                  "gw": "10.10.10.150/10",
                  "route": "10.10.10.0/24"
               },
               {
                  "gw": "10.10.10.150/10",
                  "route": "10.10.20.0/24"
               }
            ],
            "vlans": [
               {
                  "Interface": "mgmt",
                  "MTU": "9000",
                  "Parent": "bond0",
                  "id": "39"
               },
               {
                  "Interface": "vxlan",
                  "MTU": "9000",
                  "Parent": "bond0",
                  "id": "484"
               }
            ]
         }
         

         Здесь:

         • default_gateway — шлюз для подсети для подсети по умолчанию в формате <IP_АДРЕС>/<МАСКА>.

         • dns_name — имя DNS-сервера.

         • dns_server — IP-адрес DNS-сервера.

         • Interface — наименование интерфейса.

         • MTU — значение MTU.

         • Parent — наименование родительского интерфейса, если предусмотрена иерархия.

         • "id": "40" — MGMT VLAN на гипервизорах.

         • "id": "39" — MGMT VLAN на Controller-узлах.

         • "id": "484" — VLAN сети управления IPMI.

12. Повторите настройку контекста (предыдущий шаг) для остальных типов узлов.

13. Перейдите в раздел IPAM → Prefixes.

14. Убедитесь, что значение Prefix совпадает с указанным default_gateway: если это не так, измените его и сохраните изменения.

15. Активируйте все BMC-узлы инфраструктуры:

    1. В веб-интерфейсе Netbox перейдите в раздел Devices.

    2. Нажмите на иконку редактирования для нужного узла.

    3. В открывшейся форме для параметра Custom Fields → state установите значение ready.

    4. Сохраните изменения.

16. Запустите пайплайн для одного из типов BMC-узлов:

    1. Откройте веб-интерфейс развернутого GitLab.

    2. Откройте проект project_k → services → baremetal.

    3. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

    4. В открывшемся окне добавьте переменные:

       • TARGET_ROLE — название типа узлов, определенная в Netbox:

         • controller — для Controller-узлов,

         • network — для Network-узлов,

         • compute — для Compute-узлов.

       • TARGET_CLOUD — имя тега в Netbox для региона;

       • TARGET_NODE — имя конкретного узла для развертывания;

       • IRONIC_ENV — окружение для развертывания узлов (по умолчанию BIFROST);

       • IRONIC_SSH_KEY — собственные SSH-ключи (формат — один ключ на строку);

       • IRONIC_IMAGE_URL — путь до образа системы, который будет установлен на узел. Требования к образу:

         • только поддерживаемый тип операционной системы;

         • формат — QCOW2;

         • hash-файл образа в формате <ИМЯ_ОБРАЗА>.md5 располагается в одной папке с самим образом;

         • укажите путь http://<IP_АДРЕС_LCM_УЗЛА>:8080/sberlinux-9.4-x86_64.qcow2 (только для SberLinux 9.4).

       • IRONIC_IMAGE_ROOTFS_UUID — UUID корневого раздела в образе, если используется software RAID;

       • IPA_KERNEL_NAME — путь до образа агента Ironic Python Agent (IPA) kernel image;

       • IPA_RAMDISK_NAME — путь до образа агента Ironic Python Agent (IPA) initramfs image;

       • KOLLA_ANSIBLE_IMG_TAG — тег контейнера с kolla-ansible, используемый для пайплайна;

       • EXPERIMENTAL_NETBOX_INTROSPECTION: true — использовать автозаполнение интерфейсов устройств в Netbox.

       • KEYSTACK_RELEASE — тег релиза Keystack;

       • CI_DEBUG_TRACE:

         • true — выводить отладочную информацию в пайплайне.

         • false — не выводить отладочную информацию.

    5. Запустите пайплайн, нажав кнопку Run pipeline.

    6. Дождитесь завершения выполнения операции.

17. Повторите запуск пайплайна (предыдущий шаг) для остальных типов узлов.

18. Перейдите в раздел Device в Netbox и убедитесь, что все узлы были добавлены в список, статус — production.

Шаг 3. Создайте регионы

Регионы логически разделяют узлы инфраструктуры Платформы.

Tip

Чтобы создать несколько регионов, повторите инструкцию из раздела нужное количество раз.

Чтобы создать один регион:

1. Откройте веб-интерфейс развернутого GitLab.

2. Создайте форк GitLab-репозитория project_k → deployments → region1:

   1. Перейдите в проект region1.

   2. Нажмите кнопку Fork.

   3. В открывшемся окне укажите параметры:

      • Project name: имя региона <ИМЯ_РЕГИОНА>.

        Important

        Имя региона должно удовлетворять условиям:

        • содержать латинские буквы [a-z] и цифры [0–9];

        • дефисы не могут быть в начале и конце имени;

        • не должно содержать два дефиса одновременно;

        • не должно содержать пробелы и специальные символы (например, !, $, &, _ и т. д.);

        • минимальная длина — 3, максимальная — 63 символа;

        • нечувствительно к регистру.

      • Select a namespace: выберите namespace для проекта.

   4. Нажмите кнопку Fork project.

3. Перейдите в репозиторий созданного региона.

4. Перейдите в раздел Settings → General → Advanced.

5. Удалите связь репозиториев, нажав кнопку Remove fork relationship.

6. Настройте созданный регион:

   SberLinuxUbuntu

   1. Откройте файл inventory.

   2. Заполните информацию об узлах инфраструктуры [control], [network], [compute] в формате <ИМЯ_УЗЛА> ansible_host=<IP_АДРЕС_УЗЛА>.

   3. Откройте файл globals.d/REGION.yml и укажите значения параметров:

      • kolla_internal_vip_address — виртуальный IP-адрес для внутреннего VIP-адреса (используется для балансировки запросов);

      • kolla_internal_fqdn - ДНС-имя для внутреннего VIP-адреса

      • kolla_external_vip_address — виртуальный IP-адрес для внешнего VIP-адреса (используется для балансировки запросов);

      • kolla_external_fqdn - ДНС-имя для внешнего VIP-адреса

      • network_interface — имя интерфейса для MGMT-сети, на которых будет разворачиваться OpenStack;

      • neutron_external_interface — имя интерфейса для связи с внешней инфраструктурой, например, сетями провайдеров, маршрутизаторами и плавающими IP-адресами.

   4. Откройте файл globals.d/octavia.yml и укажите значения параметра octavia_amp_network_cidr — IP-адреса для Amphora сервиса Octavia.

7. Запустите пайплайн на генерацию паролей и сертификатов для региона:

   1. Откройте проект project_k → deployments → gen-pwd.

   2. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

   3. В открывшемся окне добавьте переменную OPENSTACK_ENV — имя созданного региона.

   4. Запустите пайплайн Run pipeline.

   5. Запустите задачу create-config и дождитесь ее завершения.

8. (Опционально) Повторите запуск пайплайна нужное количество раз, если создано несколько регионов.

9. Настройте автоэвакуацию ВМ при сбое гипервизора, изменив пароль для IPMI-узлов гипервизора:

   1. Перейдите в веб-интерфейс развернутого Vault.

   2. Перейдите в директорию с настройками региона secret_v2/deployments/<ИМЯ_РЕГИОНА>/passwords_yml.

   3. Нажмите Create new version.

   4. Найдите и замените значение параметра bmc_password на пароль от интерфейса IPMI BMC-узлов гипервизора.

10. По аналогии с предыдущим шагом в директорию с настройками региона secret_v2/deployments/<ИМЯ_РЕГИОНА>/passwords_yml укажите пароли от своих сервисов:

    • LDAP,

    • SMTP пользователя,

    • GitLab (пароль root-пользователя),

    • СХД.

11. В зависимости от серверных ресурсов, работа пайплайна по развертыванию региона может занимать продолжительное время и не укладываться в стандартный таймаут. Увеличьте таймаут для пайплайнов в репозитории региона:

    1. Откройте веб-интерфейс развернутого Gitlab.

    2. Откройте проект project_k → deployments → <ИМЯ_РЕГИОНА>.

    3. Откройте настройки : Settings → CI/CD → General pipelines.

    4. Установите значение Timeout 3h.

12. Запустите пайплайн по развертыванию региона:

    1. Откройте веб-интерфейс развернутого GitLab.

    2. Откройте проект project_k → deployments → <ИМЯ_РЕГИОНА>.

    3. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

    4. В открывшемся окне добавьте переменные:

       • KOLLA_ARGS — дополнительные теги:

         • --limit <ИМЯ_УЗЛА> — выполнить пайплайн для отдельного узла Платформы;

         • --tags <ИМЯ_КОМПОНЕНТА> — выполнить пайплайн для отдельного компонента Платформы.

       • KOLLA_ANSIBLE_DEPLOY_ACTION — список задач для kolla-ansible, укажите deploy;

       • KEYSTACK_RELEASE — версия KeyStack в git-репозитории project_k → keystack.

    5. Запустите пайплайн Run pipeline.

    6. Дождитесь завершения задачи setup.

    7. Запустите задачу bootstrap-servers и дождитесь ее завершения.

    8. Запустите задачу deploy и дождитесь ее завершения.

Note

Общий список задач в пайплайне:

• setup — подготовка паролей и настроек для развертывания Платформы;

• bootstrap-servers — установка необходимых пакетов и настройка компонентов ОС;

• deploy — развертывание и запуск сервисов OpenStack на узлах;

• postconfig — применение квот;

• states — применение конфигурации к узлам Платформы;

• rally — валидация компонентов Платформы;

• tempest — тестирование Платформы на соответствие конфигурации;

• backup-db — создание резервной копии БД MariaDB.

Шаг 4. Создайте сети и подсети в каждом регионе

Tip

Если у вас несколько регионов, повторите инструкцию из раздела нужное количество раз.

1. Включите поддержку VLAN Tagging:

   1. Откройте веб-интерфейс развернутого GitLab.

   2. Перейдите в репозиторий созданного региона.

   3. Найдите файл globals.d/REGION.yml и добавьте в него строки. В параметре global_physnet_mtu укажите допустимое вашей сетевой инфраструктурой значение MTU:

      enable_neutron_provider_networks: "yes"
      global_physnet_mtu: "9000"
      

   4. Создайте файл config/neutron/neutron.conf с содержимым:

   [DEFAULT]
   global_physnet_mtu = {{ global_physnet_mtu }}
   

   1. Создайте файл config/neutron/ml2_conf.ini со следующим содержимым. В параметре network_vlan_ranges укажите допустимый вашей сетевой инфраструктурой диапазон номеров VLAN:

   [ml2_type_vlan]
   network_vlan_ranges = physnet1:1000:2000
   

   1. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

   2. В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t neutron.

   3. Запустите пайплайн, нажав кнопку Run pipeline.

   4. Дождитесь завершения выполнения операции.

2. В Horizon создайте сеть для проекта с параметрами:

   • Provider Network Type: VLAN;

   • Physical Network: physnet1;

   • Segmentation ID: UUID нужной VLAN.

3. Получите openrc-файл из Vault:

   1. Зайдите на LCM-узел через SSH.

   2. Выполните команду импорта openrc-файла:

      docker exec -ti vault vault read secret_v2/data/deployments/<ИМЯ_РЕГИОНА>/openrc -format=json | jq -r '.data.data.value' > openrc-<ИМЯ_РЕГИОНА>
      

4. Если вы используете собственный CA-сертификат: убедитесь, что цепочка CA-сертификатов chain-cert.pem сохранена в директории /installer/data/ca/cert/ сервиса Vault.

5. В импортированный файл добавьте строку:

   export OS_CACERT=/installer/data/ca/cert/chain-ca.pem
   

6. Импортируйте содержимое openrc-файла в переменные окружения с помощью команды:

   source openrc-<ИМЯ_РЕГИОНА>
   

7. Создайте виртуальную сеть с помощью openstack-команды:

   openstack network create
      [--extra-property type=<property_type>,name=<property_name>,value=<property_value>]
      [--share | --no-share]
      [--enable | --disable]
      [--project <project>]
      [--description <description>]
      [--mtu <mtu>]
      [--project-domain <project-domain>]
      [--availability-zone-hint <availability-zone>]
      [--enable-port-security | --disable-port-security]
      [--external | --internal]
      [--default | --no-default]
      [--qos-policy <qos-policy>]
      [--transparent-vlan | --no-transparent-vlan]
      [--provider-network-type <provider-network-type>]
      [--provider-physical-network <provider-physical-network>]
      [--provider-segment <provider-segment>]
      [--dns-domain <dns-domain>]
      [--tag <tag> | --no-tag]
      --subnet <subnet>
      <name>
   

   Здесь:

   • --extra-property type=<property_type>,name=<property_name>,value=<property_value> — дополнительные параметры, по умолчанию в формате string. Возможные форматы: dict, list, str, bool, int. При типе list значения могут перечисляться через точку с запятой. Для типа dict используется список пар <КЛЮЧ>:<ЗНАЧЕНИЕ>, разделенных точкой с запятой;

   • --share — сделать сеть общей для всех проектов;

   • --no-share — не делать сеть общей для всех проектов;

   • --enable — признак доступности сети (действует по умолчанию);

   • --disable — признак недоступности сети;

   • --description <description> — описание сети;

   • --mtu <mtu> — установить значение MTU;

   • --project-domain <project-domain> — присвоить сеть домену проекта (по наименованию или ID). Опция используется в случае конфликтов между названиями проектов;

   • --availability-zone-hint <availability-zone> — зона доступности сети <availability-zone>; указать опцию нужное количество раз для задания нескольких зон доступности;

   • --enable-port-security — установить защиту портов для сети (действует по умолчанию);

   • --disable-port-security — отключить защиту портов для сети;

   • --external — установить сеть как внешнюю;

   • --internal — установить сеть как внутреннюю (действует по умолчанию);

   • --default — использовать в виде внешней сети по умолчанию;

   • --no-default — не использовать в виде внешней сети по умолчанию;

   • --qos-policy <qos-policy> — политика QoS для подключения к этой сети (имя или идентификатор);

   • --transparent-vlan — добавить доступ в интернет для сети;

   • --no-transparent-vlan — не добавлять доступ в интернет для сети;

   • --provider-network-type <provider-network-type> — тип сети. Возможные варианты: flat, geneve`, ``gre, local`, ``vlan, vxlan;

   • --provider-physical-network <provider-physical-network> — соответствие виртуальной сети физической сети <provider-physical-network>;

   • --provider-segment <provider-segment> — идентификатор VLAN для сетей VLAN или идентификатором Tunnel ID для сетей GENEVE/GRE/VXLAN;

   • --dns-domain <dns-domain> — DNS-имя для сети;

   • --tag <tag> — добавление тега <tag> для сети; повторить опцию для добавления нескольких тегов;

   • --no-tag — не добавлять теги для сети;

   • --subnet <subnet> — подсеть IPv4 для фиксированных IP (в нотации CIDR); обязательный параметр;

   • name — наименование создаваемой сети; обязательный параметр.

   Создайте нужное количество сетей, повторив команду нужное количество раз.

8. (Опционально) Создайте нужное количество виртуальных подсетей с помощью openstack-команды:

   openstack subnet create
      [--project <project> [--project-domain <project-domain>]]
      [--subnet-pool <subnet-pool> | --use-default-subnet-pool [--prefix-length <prefix-length>]]
      [--subnet-range <subnet-range>]
      [--allocation-pool start=<ip-address>,end=<ip-address>]
      [--dhcp | --no-dhcp]
      [--dns-nameserver <dns-nameserver>]
      [--gateway <gateway>]
      [--host-route destination=<subnet>,gateway=<ip-address>]
      [--ip-version {4,6}]
      [--description <description>]
      [--network-segment <network-segment>]
      [--service-type <service-type>]
      [--tag <tag> | --no-tag]
      --network <network>
      <name>
   

   Здесь:

   • --project <project> — наименование проекта, в котором создается подсеть;

   • --project-domain <project-domain> — присвоить подсеть домену проекта (по наименованию или ID). Опция используется в случае конфликтов между названиями проектов;

   • --subnet-pool <subnet-pool> — пул подсети <subnet-pool>, из которого эта подсеть получит CIDR (наименование или ID);

   • --use-default-subnet-pool — использовать пул подсети по умолчанию для опции --ip-version;

   • --prefix-length <prefix-length> — длина префикса для выделения подсети из пула подсетей;

   • --subnet-range <subnet-range> — диапазон подсетей <subnet-range> в нотации CIDR (обязательный параметр, если не указан --subnet-pool);

   • --allocation-pool start=<ip-address>,end=<ip-address> — пулы распределения IP-адресов;

   • --dhcp — использовать DHCP (по умолчанию);

   • --no-dhcp — не использовать DHCP;

   • --dns-nameserver <dns-nameserver> — наименование DNS-сервера для подсети; повторить опцию для указания нескольких серверов;

   • --gateway <gateway> — шлюз для подсети. Возможные значения:

     • <IP_АДРЕС> — конкретный IP-адрес, например, 192.168.9.1;

     • auto — выбор адреса шлюза автоматически;

     • none — подсеть не использует шлюз.

   • --host-route destination=<subnet>,gateway=<ip-address> — дополнительные маршрутизаторы, назначенные узлам;

   • --ip-version {4,6} — версия IP для подсети (значение по умолчанию 4); версия 6 не используется в Платформе;

   • --description <description> — описание подсети;

   • --network-segment <network-segment> — диапазон сети <network-segment> для создаваемой подсети (наименование или ID);

   • --service-type <service-type> — тип службы для подсети, например, network:floatingip_agent_gateway;

   • --tag <tag> — добавить тегов для подсети; повторить опцию для добавления нескольких тегов;

   • --no-tag — не добавлять теги для подсети;

   • --network <network> — сеть <network>, частью которой будет являться данная подсеть (наименование или ID); обязательный параметр;

   • <name> — наименование подсети; обязательный параметр.

   Создайте нужное количество подсетей, повторив команду нужное количество раз.

9. Проверьте создание сетей и подсетей с помощью команды:

   openstack network list --long

   Отобразится таблица с подробной информацией о созданных сетях и подсетях.

Tip

Подробная инструкция по управлению виртуальными сетями и подсетями в Платформе приведена в Руководстве администратора.

Шаг 5. Создайте шаблоны образов и типы дисков

Выполните инструкцию по созданию шаблонов образов и типов дисков согласно Руководству администратора.

Настройка ролевой модели в OpenStack

1. Добавьте сертификат для LDAPS:

   1. Откройте веб-интерфейс развернутого GitLab.

   2. Откройте проект project_k → deployments → <имя региона>.

   3. Добавьте ваш сертификат LDAPS в certificates/ca/ldaps.crt. При необходимости создайте этот файл.

2. Создайте домен (в этом примере — itkey) и добавьте в него пользователя admin:

   1. Перейдите в интерфейс OpenStack CLI.

   2. Выполните команды:

      openstack domain create itkey
      openstack role add --domain itkey --user admin admin
      

3. Добавьте конфигурацию LDAPS для Keystone:

   1. Откройте веб-интерфейс развернутого GitLab.

   2. Откройте проект project_k → deployments → <имя региона>.

   3. Найдите файл globals.d/REGION.yml и добавьте в него строки:

      horizon_keystone_multidomain: "True"
      horizon_keystone_domain_choices:
         default: default
         itkey: itkey
      
      keystone_ldap_url: "ldaps://<адрес вашего сервиса LDAPS>"
      

   4. Создайте файл config/keystone/domains/keystone.itkey.conf следующего содержания. При необходимости в group_filter и user_filter замените значения CN с префиксом group_ на названия ваших групп LDAP, а в значениях DC= укажите ваши компоненты домена.

      [identity]
      driver = ldap
      
      [ldap]
      group_allow_create = False
      group_allow_delete = False
      group_allow_update = False
      group_desc_attribute = description
      group_id_attribute = cn
      group_member_attribute = member
      group_name_attribute = cn
      group_objectclass = group
      group_filter = "(|(cn=group_*))"
      password = "{{ ldap_password }}"
      query_scope = sub
      suffix = "DC=test-keystack,DC=vm,DC=lab,DC=itkey,DC=com"
      user_tree_dn = "DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com"
      url = "{{ keystone_ldap_url }}"
      user = "CN=ldap-ro,CN=Users,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com"
      user_filter = "(&(objectClass=person)(objectClass=user)(|(memberof=CN=group_infra_admin,OU=Keystack,OU=Applications,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com)(memberof=CN=group_support_admin,OU=Keystack,OU=Applications,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com)(memberof=CN=group_security_admin,OU=Keystack,OU=Applications,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com)(memberof=CN=group_reader,OU=Keystack,OU=Applications,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com)(memberof=CN=group_member,OU=Keystack,OU=Applications,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com)))"
      user_allow_create = False
      user_allow_delete = False
      user_allow_update = False
      user_enabled_attribute = userAccountControl
      user_enabled_default = 512
      user_enabled_mask = 2
      user_id_attribute = cn
      user_mail_attribute = mail
      user_name_attribute = sAMAccountName
      user_objectclass = person
      user_pass_attribute = userPassword
      group_tree_dn = "DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com"
      page_size = 0
      

4. Добавьте пароль пользователя LDAPS в Vault:

   1. Откройте веб-интерфейс Vault.

   2. Откройте путь secrets_v2/deployments и далее ваш регион. Откройте файл секретов passwords_yml.

   3. Перейдите на вкладку Secret и нажмите Create new version.

   4. Отредактируйте файл, замените значение поля ldap_password на пароль пользователя LDAPS.

5. Запустите деплой компонентов Keystone и Horizon:

   1. Откройте веб-интерфейс развернутого GitLab.

   2. Перейдите в репозиторий созданного региона.

   3. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

   4. В открывшемся окне добавьте параметр KOLLA_ARGS со значением -t keystone,horizon.

   5. Запустите пайплайн: Run pipeline.

   6. Дождитесь завершения выполнения задач на шаге setup.

   7. Запустите задачу deploy на шаге deploy и дождитесь ее завершения.

6. Чтобы проверить настройку пользователей и групп LDAP, выполните команды в OpenStack CLI:

   openstack --insecure user list --domain itkey
   +------------------------------------------------------------------+----------------+
   | ID                                                               | Name           |
   +------------------------------------------------------------------+----------------+
   | 40d88d5463e910003e73ef9a3285c3fd907fb56c255ba27d938b48559a200a2b | member1        |
   | 9016b4c6ff10b980b1556b39fa995c9349a4bb64fed26d79d1c36ea5e4dde0dd | member2        |
   | 50b5b30a1aef6c6784344e95e62b53308606916d8953926cde3f26c46537e876 | member3        |
   | f84e98454612eda80d34d2ef1fe1a3624e2e6c597d3f57b30d64881d12b3c060 | infra_admin    |
   | 68245853200911bb930b6c1d5f245c3f3444914a841b0a3ac226dbc59614e9f1 | support_admin  |
   | f4b4749ba49d7223626f36fc91389fc061c37af11d4a8c8f4cb436bbbfd181ae | security_admin |
   | ccecd465ca6b617f81e6c6f803c8bb51c933f8def25439997a3984ff71a31f0f | reader         |
   +------------------------------------------------------------------+----------------+
   
   openstack group list --domain itkey
   +------------------------------------------------------------------+----------------------+
   | ID                                                               | Name                 |
   +------------------------------------------------------------------+----------------------+
   | 6588de10efbf97de47b57c9fd0fc5fbbce8bbc26ae7bbcd50511430cc96b8f50 | group_infra_admin    |
   | c94274dc724eb1aac6797ac99fd3cae2eeb1d3bc0135dc6bfa586d573736099e | group_member         |
   | 1797223b40aa8409eba0ff0fe84c239a25e3f93ced5e8e55d230da5ccda373d2 | group_reader         |
   | eb599167d78c91450e1ab74ff4077584a817be9c8f20144badcd88a11d46a0cc | group_security_admin |
   | ce17c914eeb85f554332f8ccd7eb9a7d8494dc5b77f006db2984a519e440ec8c | group_support_admin  |
   +------------------------------------------------------------------+----------------------+
   

7. Создайте новый проект в домене itkey:

   openstack project create demo --domain itkey
   

8. Добавьте ваши группы в этот проект в OpenStack с соответствующими ролями. В качестве ID_GROUP_group_* указывайте конкретные идентификаторы групп из вывода команды openstack group list --domain itkey:

   1. Добавьте роль member:

      openstack role add --project demo --group ID_GROUP_group_member --user-domain itkey member
      

   2. Добавьте роли admin и operator:

      openstack role add --project demo --group ID_GROUP_group_infra_admin --user-domain itkey admin
      openstack role add --project demo --group ID_GROUP_group_support_admin --user-domain itkey admin
      

   3. Добавьте роли auditor и reader:

      openstack role add --project demo --group ID_GROUP_group_security_admin --user-domain itkey reader
      openstack role add --project demo --group ID_GROUP_group_reader --user-domain itkey reader
      

9. Проверка настройки

   1. Войдите в Web-интерфейс Horizon в домене itkey пользователями с разными ролями. Вход должен быть успешным, доступные элементы соответствовать роли пользователя.

Подключение служебных сервисов

Портал администратора

Important

Варианты установки мультирегионального и однорегионального портала отличаются.

Чтобы установить портал администратора с одним регионом:

1. Откройте веб-интерфейс развернутого GitLab.

2. Откройте проект project_k → deployments → <ИМЯ_РЕГИОНА>.

3. Найдите файл globals.d/REGION.yml и убедитесь, что в нём есть строки:

   enable_adminui: "yes"
   adminui_gitlab_username: "root"
   

4. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

5. В открывшемся окне добавьте параметр KOLLA_ARGS со значением -t adminui.

6. Запустите пайплайн: Run pipeline.

7. Дождитесь завершения выполнения операции.

Чтобы подключить дополнительный регион к порталу администратора:

1. Зайдите на любой Control-узел подключаемого региона по SSH.

2. Откройте файл /etc/kolla/adminui-backend/adminui-backend-regions.conf. Информация из этого файла понадобится позже.

3. Откройте веб-интерфейс развернутого GitLab целевого региона.

4. Откройте проект project_k → deployments → <ИМЯ_РЕГИОНА>.

5. Создайте файл config/adminui/adminui-backend-regions.conf и добавьте в него раздел [DEFAULT] с перечислением регионов и раздел для подключаемого региона, заменив параметры соответствующими значениями. Не указывайте в файле динамические параметры, в том числе пароли, в явном виде:

   [DEFAULT]
   region_names=<имя целевого региона>, <имя подключаемого региона>
   
   [<имя подключаемого региона>]
   type=keystack
   prometheus_url=https://<VIP_АДРЕС_PROMETHEUS>:9091
   gitlab_project_name=<имя подключаемого региона>
   gitlab_repo_address=https://ks-lcm.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>/project_k/devregion
   grafana_url=https://<VIP_АДРЕС_GRAFANA>:3000
   opensearch_url=https://<VIP_АДРЕС_OPENSEARCH>:5601
   horizon_url=https://<VIP_АДРЕС_HORIZON>
   gitlab_username={{ adminui_gitlab_username }}
   gitlab_password={{ lookup('hashi_vault', 'secret={{ vault_engine }}/data/{{ vault_prefix }}/<имя подключаемого региона>/passwords_yml:adminui_gitlab_password') }}
   vault_url={{ vault_addr }}/ui/vault/secrets/{{ vault_engine }}/list/{{ vault_prefix }}/<имя подключаемого региона>
   os_region_name=<имя подключаемого региона>
   os_auth_url=https://<VIP_АДРЕС_ПОРТАЛА_АДМИНИСТРАТОРА>:5000
   os_interface=internal
   os_endpoint_type=internalURL
   os_username=admin
   os_password={{ lookup('hashi_vault', 'secret={{ vault_engine }}/data/{{ vault_prefix }}/<имя подключаемого региона>/passwords_yml:keystone_admin_password') }}
   os_project_name=admin
   os_project_domain_name=Default
   os_user_domain_name=Default
   drs_endpoint = https://<VIP_АДРЕС_DRS>:12998
   

6. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

7. В открывшемся окне добавьте параметр KOLLA_ARGS со значением -t adminui.

8. Запустите пайплайн: Run pipeline.

9. Дождитесь завершения выполнения операции.

Мониторинг

Мониторинг в Платформе реализован на базе Opensearch, Cloud Auditing Data Federation (CADF), Prometheus и Grafana. Доступ к компонентам — через веб-интерфейс:

• Opensearch — https://opensearch.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>:5601/;

• Prometheus — http://<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>:9091/;

• Alertmanager — http://<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>:9093/;

• Grafana — http://<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>:3000/.

По умолчанию все перечисленные компоненты разворачиваются для каждого региона. Если этого не произошло, запустите их вручную:

1. Откройте веб-интерфейс развернутого GitLab.

2. Откройте проект project_k → deployments → <ИМЯ_РЕГИОНА>.

3. Откройте файл globals.d/REGION.yml и измените значения no на yes для нужных компонентов:

   enable_grafana: "yes"
   enable_prometheus: "yes"
   enable_prometheus_alertmanager: "yes"
   enable_opensearch: "yes"
   enable_cadf_audit: "yes"
   

4. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

5. В открывшемся окне добавьте параметры:

   • KOLLA_ANSIBLE_DEPLOY_ACTION — deploy;

   • KOLLA_ARGS с именем нужного компонента:

     • Grafana — -t grafana;

     • Prometheus — -t prometheus;

     • Opensearch — -t opensearch.

     Tip

     Если нужно развернуть несколько компонентов одновременно, укажите их через запятую.

     Important

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

6. Запустите пайплайн: Run pipeline.

7. Дождитесь завершения выполнения операции.

Чтобы настроить глубину хранения метрик в Prometheus:

1. Откройте веб-интерфейс развернутого GitLab.

2. Откройте проект project_k → deployments → <ИМЯ_РЕГИОНА>.

3. Внесите изменения в файл globals.d/REGION.yml:

   prometheus_cmdline_extras: "--storage.tsdb.retention.time=60d --storage.tsdb.retention.size=500GB"
   

4. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

5. В открывшемся окне добавьте параметры:

   • KOLLA_ANSIBLE_DEPLOY_ACTION — deploy;

   • KOLLA_ARGS — -t prometheus.

6. Запустите пайплайн: Run pipeline.

7. Дождитесь завершения выполнения операции.

Чтобы создать шаблон индекса в Opensearch:

1. Откройте веб-интерфейс развернутого Opensearch. При первом входе вы будете перенаправлены на страницу создания шаблонов.

2. Нажмите кнопку Create index pattern.

3. В открывшемся окне в поле Index pattern name укажите значение flog*.

4. Нажмите кнопку Next Step.

5. В поле Time field выберите вариант @timestamp.

6. Нажмите кнопку Create index pattern.

Tip

Подробная инструкция по управлению перечисленными компонентами в Платформе приведена в Руководстве администратора.

Аудит

Для вывода логов в удаленный сервис системного журнала (syslog) используется fluent-plugin-remote_syslog — плагин Fluentd.

Note

Настройка плагина по умолчанию:

<match **>
@type remote_syslog
host 10.120.120.125
port 514
protocol tcp
</match>

Чтобы настроить плагин:

1. Откройте веб-интерфейс развернутого GitLab.

2. Откройте проект project_k → deployments → <ИМЯ_РЕГИОНА>.

3. Перейдите в директорию config. Если такой директории нет, создайте ее.

4. Создайте файл fluentd/output/fluent-plugin-remote_syslog.conf с содержимым:

   <match <РЕГУЛЯРНОЕ ВЫРАЖЕНИЕ_ФИЛЬТРАЦИИ_ЗАПИСЕЙ>>
      @type copy
      <store>
         @type opensearch
         host {{ opensearch_address }}
         port {{ opensearch_port }}
         scheme {{ fluentd_opensearch_scheme }}
   {% if fluentd_opensearch_path != '' %}
         path {{ fluentd_opensearch_path }}
   {% endif %}
   {% if fluentd_opensearch_scheme == 'https' %}
         ssl_version {{ fluentd_opensearch_ssl_version }}
         ssl_verify {{ fluentd_opensearch_ssl_verify }}
   {% if fluentd_opensearch_cacert | length > 0 %}
         ca_file {{ fluentd_opensearch_cacert }}
   {% endif %}
   {% endif %}
   {% if fluentd_opensearch_user != '' and fluentd_opensearch_password != ''%}
         user {{ fluentd_opensearch_user }}
         password {{ fluentd_opensearch_password }}
   {% endif %}
         logstash_format true
         logstash_prefix {{ opensearch_log_index_prefix }}
         reconnect_on_error true
         request_timeout {{ fluentd_opensearch_request_timeout }}
         suppress_type_name true
         <buffer>
         @type file
         path /var/lib/fluentd/data/opensearch.buffer/openstack.*
         flush_interval 15s
         </buffer>
      </store>
      <store>
         @type remote_syslog
         host <IP_АДРЕС_ПЛАГИНА>
         port <ПОРТ_ДЛЯ_ПЛАГИНА>
         protocol <ПРОТОКОЛ_ПЕРЕДАЧИ_ДАННЫХ>
      </store>
   </match>
   

5. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

6. В открывшемся окне добавьте параметры:

   • KOLLA_ANSIBLE_DEPLOY_ACTION — deploy;

   • KOLLA_ARGS — -t opensearch.

7. Запустите пайплайн: Run pipeline.

8. Дождитесь завершения выполнения операции.

9. (Опционально) Убедитесь, что конфигурационный файл Fluentd td-agent.conf содержит добавленные данные.

Пример конфигурационного файла OpenSearch для отправки данных в syslog:

<match **>
   @type copy
   <store>
      @type opensearch
      host {{ opensearch_address }}
      port {{ opensearch_port }}
      scheme {{ fluentd_opensearch_scheme }}
{% if fluentd_opensearch_path != '' %}
      path {{ fluentd_opensearch_path }}
{% endif %}
{% if fluentd_opensearch_scheme == 'https' %}
      ssl_version {{ fluentd_opensearch_ssl_version }}
      ssl_verify {{ fluentd_opensearch_ssl_verify }}
{% if fluentd_opensearch_cacert | length > 0 %}
      ca_file {{ fluentd_opensearch_cacert }}
{% endif %}
{% endif %}
{% if fluentd_opensearch_user != '' and fluentd_opensearch_password != ''%}
      user {{ fluentd_opensearch_user }}
      password {{ fluentd_opensearch_password }}
{% endif %}
      logstash_format true
      logstash_prefix {{ opensearch_log_index_prefix }}
      reconnect_on_error true
      request_timeout {{ fluentd_opensearch_request_timeout }}
      suppress_type_name true
      <buffer>
       @type file
       path /var/lib/fluentd/data/opensearch.buffer/openstack.*
       flush_interval 15s
      </buffer>
   </store>
   <store>
      @type remote_syslog
      host 10.10.140.100
      port 7710
      protocol udp
   </store>
</match>

Адреса файлов с логами для компонентов приведены в Руководстве администратора.

Системы хранения данных

Платформа поддерживает подключение дополнительных СХД следующих типов:

• iSCSI,

• FC,

• NFS.

iSCSI

1. Откройте веб-интерфейс развернутого GitLab.

2. Откройте проект project_k → deployments → <ИМЯ_РЕГИОНА>.

3. Добавьте строки в файл globals.d/REGION.yml:

   Enable_cinder_backend_iscsi: "yes"
   Enable_cinder_backend_lvm: "no"
   

4. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

5. В открывшемся окне добавьте параметры:

   • KOLLA_ANSIBLE_DEPLOY_ACTION — deploy;

   • KOLLA_ARGS — -t cinder.

6. Запустите пайплайн: Run pipeline.

7. Дождитесь завершения выполнения операции.

FC

Warning

В разделе приведен пример подключения Huawei Dorado с поддержкой FC — шаги по подключению других вендоров могут различаться.

1. Настройте Cinder:

   1. Создайте новый проект internal_cinder и пользователя internal_cinder_user.

   2. Назначьте пользователю internal_cinder_user права member в созданном проекте.

   3. Сохраните идентификаторы проекта и пользователя. Далее для примера будут использоваться adcece5761d3440d974f0ddc93623a84 и 823b9c2d25814962a135a18777421507 для проекта и пользователя соответственно.

   4. (Опционально) Увеличьте квоты в проекте internal_cinder для дисков.

2. Откройте веб-интерфейс развернутого GitLab.

3. Откройте проект project_k → deployments → <ИМЯ_РЕГИОНА>.

4. Добавьте строки в файл globals.d/REGION.yml:

   enable_multipathd: "yes"
   enable_cinder_backend_lvm: "no"
   default_volume_type: "huawei_storage"
   cinder_internal_tenant_project_id: "adcece5761d3440d974f0ddc93623a84"
   cinder_internal_tenant_user_id: "823b9c2d25814962a135a18777421507"
   

5. Создайте файл config/cinder/cinder-volume/vendor-configs/dorado.xml с содержимым:

   <?xml version='1.0' encoding='UTF-8'?>
   <config>
      <Storage>
         <Product>Dorado</Product>
         <Protocol>FC</Protocol>
         <UserName>user</UserName>
         <UserPassword>{{ lookup('hashi_vault', 'secret={{ vault_engine }}/data/{{ vault_prefix }}/{{ OPENSTACK_ENV | lower }}/huawei')['data']['UserPassword'] }}</UserPassword>
         <RestURL>https://IP_ADDRESS1:8088/deviceManager/rest/;https://IP_ADDRESS2:8088/deviceManager/rest/</RestURL>
      </Storage>
      <LUN>
         <LUNCopySpeed>3</LUNCopySpeed>
         <StoragePool>NAME_POOL</StoragePool>
         <LUNType>Thin</LUNType>
      </LUN>
      <FC>
         <Initiator Name="*" ALUA="1" FAILOVERMODE="1" PATHTYPE="0" />
      </FC>
   </config>
   

6. Создайте файл config/cinder.conf с содержимым:

   [DEFAULT]
   default_volume_type = {{ default_volume_type }}
   enabled_backends = huawei_storage
   enforce_multipath_for_image_xfer = true
   use_multipath_for_image_xfer = true
   
   [huawei_storage_high]
   allowed_direct_url_schemes = cinder
   cinder_huawei_conf_file = /etc/cinder/vendor-configs/dorado.xml
   enforce_multipath_for_image_xfer = true
   use_multipath_for_image_xfer = true
   volume_backend_name = huawei_storage
   volume_driver = cinder.volume.drivers.huawei.huawei_driver.HuaweiFCDriver
   backend_host = huawei
   
   image_volume_cache_enabled = true
   

7. Создайте файл config/multipath.conf с содержимым:

   defaults {
      user_friendly_names no
      find_multipaths yes
   }
   
   blacklist {
   }
   
   devices {
      device {
         vendor "HUAWEI"
         product "XSG1"
         path_grouping_policy "multibus"
         path_selector "service-time 0"
         path_checker "tur"
         prio "const"
         failback "immediate"
         dev_loss_tmo 30
         fast_io_fail_tmo 5
         no_path_retry 15
      }
   }
   

8. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

9. В открывшемся окне добавьте параметры:

   • KOLLA_ANSIBLE_DEPLOY_ACTION — deploy;

   • KOLLA_ARGS — -t cinder, multipath.

10. Запустите пайплайн: Run pipeline.

11. Дождитесь завершения выполнения операции.

NFS

1. Откройте веб-интерфейс развернутого GitLab.

2. Откройте проект project_k → deployments → <ИМЯ_РЕГИОНА>.

3. Добавьте строку в файл globals.d/REGION.yml:

   enable_cinder_backend_nfs: "yes"
   

4. Создайте файл config/nfs_shares с записями о каждом Storage-узле:

   storage01:/kolla_nfs
   storage02:/kolla_nfs
   

5. На каждом Storage-узле:

   1. Создайте файл /etc/exports с информацией о монтировании хранилища, пример записи:

      /kolla_nfs 192.168.5.0/24(rw,sync,no_root_squash)
      

   2. Запустите сервис nfsd с помощью команды systemctl start nfs.

6. Создайте новый пайплайн: Build → Pipelines → Run Pipeline.

7. В открывшемся окне добавьте параметры:

   • KOLLA_ANSIBLE_DEPLOY_ACTION — deploy;

   • KOLLA_ARGS — -t cinder.

8. Запустите пайплайн: Run pipeline.

9. Дождитесь завершения выполнения операции.

Проверка работоспособности системы

1. На LCM-узле выполните пинг на IP-адреса остальных узлов инфраструктуры — должны проходить без ошибок.

2. Перейдите на каждый из развернутых сервисов по адресу, заданному в DNS:

   • GitLab,

   • Nexus (если создан новый),

   • Netbox.

   Для входа используйте реквизиты, полученные на этапе установки дистрибутива Платформы.

3. Убедитесь, что в GitLab добавлены проекты и репозитории:

   • deployments — основные сервисы развертывания инфраструктуры Платформы и их конфигурация;

   • services — вспомогательные инструменты, например, Bifrost;

   • ci — пайплайны LCM-узла;

   • keystack — рекомендуемые конфигурации сервисов OpenStack.

4. Убедитесь, что в Vault добавлены директории (раздел Secrets):

   • installer — сертификаты Платформы;

   • secret_v2 — пароли и ключи для доступа к служебным компонентам Платформы.

5. Скопируйте пароль для Horizon и портала администратора:

   1. Перейдите в веб-интерфейс развернутого Vault.

   2. Перейдите в директорию с настройками региона secret_v2/deployments/<ИМЯ_РЕГИОНА>/passwords_yml.

   3. Найдите и скопируйте значение параметра keystone_admin_password.

6. Убедитесь, что открывается интерфейс Horizon:

   1. Перейдите в веб-интерфейс Horizon: https://<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>.

   2. Войдите с помощью логина admin и скопированного пароля keystone_admin_password.

   3. Перейдите в раздел Вычислительные ресурсы → Гипервизоры. При успешной установке в списке отобразятся подключенные гипервизоры инфраструктуры.

7. Убедитесь, что открывается портал администратора:

   1. Перейдите в веб-интерфейс портала администратора: https://<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>:12999.

   2. Войдите с помощью логина admin и скопированного пароля keystone_admin_password. При успешной установке отобразится общий дэшборд по Платформе.

8. Проверьте статус мониторинга и логирования, на LCM-узле выполнив команду:

   docker ps -a | egrep 'opensearch|prometheus|fluentd|grafana'

   Все контейнеры в появившемся списке должны быть в состоянии Up.

Возможные ошибки и варианты их устранения

Описание ошибки: в GitLab нет репозиториев.

Вариант решения:

1. Перейдите в распакованный дистрибутив Платформы, директорию installer/repo.

2. Последовательно выполните команды:

   git push -u origin --all
   git push -u origin --tags
   

3. Повторно проверьте список репозиториев в GitLab.

Описание ошибки: GitLab-пайплайн завершился с ошибкой на задаче inspect:

openstack baremetal node inspect cmp-039 --wait
Error contacting Ironic server: Node 11111111-1111-1111-1111-111111111111 is locked by host seed, please retry after the current operation is completed. (HTTP 409). Attempt 6 of 6

Вариант решения: перезапустите задачу inspect.

Описание ошибки: GitLab-пайплайн завершился с ошибкой на задаче done:

Server is unavailable. Exiting.

Вариант решения:

1. Подождите 5-10 минут.

2. Перезапустите задачу done.

Описание ошибки: Ошибка протокола Redfish при автоэвакуации ВМ:

INFO autoevacuator.config [-] Starting fence/disable for bmc.
WARNING sushy.connector [-] We have encountered an AccessError when using 'basic' authentication. HTTP GET https://<имя сервера>-bmc/redfish/v1/Systems returned code 401. Security.1.0.AccessDenied: While attempting to establish a connection to /redfish/v1/Systems, the service was denied access.

Вариант решения:

Вероятная причина возникновения этой ошибки - особенности некоторых реализаций RedFish, которые требуют обращения по полному доменному имени (FQDN). Выполните шаги дополнительной конфигурации:

1. Зайдите на узел Control по SSH пользователем root.

2. Откройте на редактирование файл /etc/kolla/consul/region-config_<имя региона>.json.

3. Найдите значение поля "bmc": {"suffix": "-<суффикс>"} и добавьте к нему базовое доменное имя. Например, замените -rmi на -rmi.cloud.itkey.com.

4. Перезапустите сервис Consul командой docker restart consul.

Обновление платформы

Перед обновлением платформы необходимо:

1. Проверить состояние сервисов на Controller-узлах.

2. Проверить доступность всех узлов и сервисов на них.

3. Проверить inventory на закомментированные узлы.

Обновления компонентов платформы:

ОнлайнБез доступа к интернету

1. Получите архив Платформы одним из способов поставки.

2. Откройте веб-интерфейс развернутого GitLab.

3. Откройте проект project_k → deployments → upgrade.

4. Создайте новый пайплайн Build → Pipelines → Run Pipeline.

5. В открывшемся окне укажите значение параметра UPGRADE_URL — URL архива с обновлением.

6. Запустите задачу update.

7. Дождитесь завершения выполнения операции.

Обновление региона

1. Укажите имя целевого релиза в .gitlab-ci.yml обновляемого региона.

2. Запустите пайплайн.

Обновление LCM-узла

Для стабильной работы платформы необходимо вовремя обновлять LCM-узел, поскольку он управляет жизненным циклом виртуальных машин, контейнеров и сетевых устройств. Регулярно проводите обновления LCM-узла, чтобы синхронизировать состояние всех компонентов, избегать конфликтов версий и обеспечить стабильную работу платформы.

Обновление LCM-узла осуществляется последовательно от более ранней версии к более новой. Если необходимо обновить узел на две и более версии, нужно пройти по цепочке обновлений в несколько этапов. Ниже приведены инструкции для каждого такого этапа, начиная с перехода с версии ks2024.1 на ks2024.2.

Во всех случаях для обновлений будут задействованы работы на LCM-узле, в веб-интерфейсе развернутого GitLab и в Nexus.

ks2024.1 → ks2024.2

Обновление с ks2024.1 на следующую по порядку версию гарантирует, что все новые возможности будут внедрены правильно. Данный этап можно считать обязательной частью обновления LCM-узла.

1. Зайдите на LCM-узел по SSH.

   SberLinuxUbuntu

   1. Загрузите архив upgrade-ks2024.2-sberlinux.tgz в папку /installer/update.

   2. Для последующего обновления репозитория в GitLab, выполните команду:

      git config --global --add safe.directory '*'
      

   3. Добавьте строки в файлы ~/installer/settings и /installer/settings:

      export NEXUS_NAME=nexus
      export GITLAB_NAME=ks-lcm
      export VAULT_NAME=vault
      export NETBOX_NAME=netbox
      export CLIENT_NEXUS_NAME=
      

   4. Замените в файлах строку export RELEASE=ks2024.1-sber на export RELEASE=ks2024.2-sberlinux.

2. Откройте веб-интерфейс развернутого GitLab.

   1. Найдите репозиторий project_k → deployments → bifrost и удалите его. Для этого перейдите в Project settings → Advanced и нажмите Delete project.

   2. Перейдите в репозиторий project_k → services → upgrade.

   3. Перейдите в раздел Settings → CI/CD → General pipelines и поставьте Timeout - 5h.

   4. Запустите пайплайн Run pipeline по умолчанию. Дождитесь его завершения.

3. Перейдите на LCM-узел и выполните команды, приведенные ниже.

   cd /installer/config
   source settings
   sed -i "/netbox.dump/d" $CFG_HOME/netbox-compose.yml
   sed -i "s|nexus3|nexus.\$DOMAIN/project_k/lcm/nexus3|" compose.yaml
   sed -i "s|nginx:\$RELEASE|nexus.\$DOMAIN/project_k/lcm/nginx:\$RELEASE|" compose.yaml
   docker compose -f $CFG_HOME/netbox-compose.yml up -d
   docker compose -f $CFG_HOME/compose.yaml up -d
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "cat /vault/config/ca.crt >> /etc/ssl/certs/ca-certificates.crt"
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "cat /vault/config/ca.crt >> /etc/pki/ca-trust/source/anchors/ca.crt; update-ca-trust"
   docker restart vault
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault operator unseal"
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault login"
   

4. Дождитесь когда откроется страница https://<FQDN_GITLAB>/admin/background_migrations. Дождитесь завершения всех задач на этой странице.

5. Перейдите в веб-интерфейс развернутого GitLab.

   1. В группе project_k перейдите в раздел Settings → CI/CD → Variables и добавьте новые переменные:

   SberLinuxUbuntu

   • BASE: sberlinux

   • NEXUS_NAME: nexus

   1. В группах deployments и services перейдите в раздел Settings → CI/CD → Variables и добавьте новые переменные:

      • vault_secman: false

6. Перейдите на LCM-узел и выполните команды:

   cd /installer/config
   source settings
   
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault kv put -mount=secret_v2 deployments/secrets/accounts      gitlab_root_password=\"$(<$CFG_HOME/gitlab_root_password)\" gitlab_runner_token=\"$(<$CFG_HOME/gitlab_runner_token)\"   nexus_admin_password=\"$(<$CFG_HOME/nexus_admin_password)\" netbox_admin_password=\"$(<$CFG_HOME/netbox_admin_password)\"   netbox_db_password="$netbox_db_password" netbox_redis_password="$netbox_redis_password" netbox_redis_cache_password="$netbox_redis_cache_password""
   
   rm -f $CFG_HOME/gitlab_root_password
   rm -f $CFG_HOME/nexus_admin_password
   rm -f $CFG_HOME/netbox_admin_password
   echo "" > $CFG_HOME/gitlab_runner_token
   

ks2024.2 → ks2024.3

Шаги для обновления с версии ks2024.2 на ks2024.3 будут отличаться от предыдущей инструкции. В первую очередь это касается GitLab, поскольку обновление для него потребуется делать в два этапа. Также обратите внимание на этап работы с Nexus: при переходе на более новую версию меняется база данных с настройками.

1. Зайдите на LCM-узел по SSH.

   SberLinuxUbuntu

   1. Загрузите архив upgrade-ks2024.3-sberlinux.tgz в папку /installer/update.

   2. Для последующего обновления репозитория в GitLab, выполните команду:

      git config --global --add safe.directory '*'
      

   3. Замените в файле /installer/config/settings``строку ``export RELEASE=ks2024.2-sberlinux на export RELEASE=ks2024.3-sberlinux.

   4. Добавьте строки в файл /installer/config/settings:

      export NEXUS_FQDN=nexus.$DOMAIN
      export CURL_CA_BUNDLE=/installer/data/ca/cert/chain-ca.pem
      

2. Зайдите в Nexus.

   SberLinuxUbuntu

   1. Удалите существующий репозиторий sberlinux.

   2. Создайте репозитории docker-sberlinux и sberlinux с типом hosted и форматом yum.

   3. Укажите параметры:

      Repodata Depth: 0. Layout Policy: Strict. Deployment Policy: Disable redeploy
      

3. Для проведения обновления необходимо восстановить пароли доступа Netbox.

   1. Перейдите на LCM-узел.

   2. Извлеките из архива инсталлятора файлы installer/netbox-docker/env/*.env.

   3. Переместите эти файлы в /installer/data/netbox/env/ на LCM-узле, заменив существующие.

4. Перейдите в веб-интерфейс развернутого GitLab.

   1. Найдите репозиторий project_k → deployments → bifrost и удалите его. Для этого перейдите в Project settings → Advanced и нажмите Delete project.

   2. Перейдите в репозиторий project_k → services → upgrade.

   3. Перейдите в раздел Settings → CI/CD → General pipelines и поставьте Timeout - 5h.

   4. Запустите новый пайплайн Run pipeline по умолчанию. Дождитесь его завершения.

5. Перейдите на LCM-узел и выполните команды, приведенные ниже.

   cd /installer/config
   source settings
   sed -i "/netbox.dump/d" $CFG_HOME/netbox-compose.yml
   docker compose -f $CFG_HOME/netbox-compose.yml up -d
   docker compose -f $CFG_HOME/compose.yaml up -d nginx
   docker compose -f $CFG_HOME/compose.yaml up -d vault
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault operator unseal"
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault login"
   

   SberLinuxUbuntu

   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "cat /vault/config/chain-ca.pem >> /etc/pki/ca-trust/source/anchors/ca.crt; update-ca-trust"
   

   docker restart vault
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault operator unseal"
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault login"
   
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault write auth/jwt/role/itkey-deployments - <<EOF
   {
      \"role_type\": \"jwt\",
      \"policies\": [\"secret_v2/deployments\"],
      \"token_explicit_max_ttl\": 3600,
      \"user_claim\": \"user_email\",
      \"bound_audiences\": \"http://vault:8200\",
      \"bound_claims\": {
      \"namespace_id\": [\"3\", \"4\"]
      }
   }
   EOF
   "
   

6. Обновление GitLab необходимо делать в два этапа:

   1. Обновите GitLab до версии 16.11.10:

      sed -i "s|\$NEXUS_FQDN/project_k/lcm/gitlab:\$RELEASE|\$NEXUS_FQDN/project_k/lcm/gitlab:\$RELEASE-16.11.10-ce.0|" compose.yaml
      docker compose -f $CFG_HOME/compose.yaml up -d gitlab
      

   2. Дождитесь запуска или завершения работы контейнера. Проверить состояние запуска контейнера можно с помощью команды:

      docker logs gitlab -f -n 100
      

      Note

      Если в процессе запуска контейнер завершил свою работу, то перейдите к следующему пункту.

   3. Обновите GitLab до версии ks2024.3:

      sed -i "s|\$NEXUS_FQDN/project_k/lcm/gitlab:\$RELEASE-16.11.10-ce.0|\$NEXUS_FQDN/project_k/lcm/gitlab:\$RELEASE|" compose.yaml
      docker compose -f $CFG_HOME/compose.yaml up -d gitlab gitlab-runner
      

   4. Контейнер с GitLab поднимается очень долго. Проверить состояние запуска контейнера можно с помощью команды:

      docker logs gitlab -f -n 100
      

   5. Дождитесь когда откроется страница https://<FQDN_GITLAB>/admin/background_migrations. Дождитесь завершения всех задач на этой странице.

7. Обновление Nexus:

   Обновление Nexus с ks2024.х на ks2024.3 и позднее невозможно сделать напрямую, поскольку меняется база данных с настройками: https://help.sonatype.com/en/migrating-to-a-new-database.html .

   1. Запустите контейнер Nexus:

      sed -i "s|\$NEXUS_FQDN/project_k/lcm/nexus3:\$RELEASE|\$NEXUS_FQDN/project_k/lcm/nexus3:\$RELEASE-3.70.3|" compose.yaml
      docker compose -f $CFG_HOME/compose.yaml up -d nexus
      

   2. Сделайте резервную копию базы данных Nexus штатными средствами в папку внутри контейнера /nexus-data/backup-db.

      1. Перейдите в раздел System → Tasks.

      2. Запустите готовую задачу Admin - Export databases for backup.

      3. Дождитесь выполнения задачи. Статус задачи должен смениться с Running на Waiting, а Last Result на OK.

   3. Выполните следующие команды для конвертации базы данных Nexus в новый формат:

      docker compose -f $CFG_HOME/compose.yaml exec nexus /bin/sh -c "cp /nexus-db-migrator-3.70.3-01.jar /nexus-data/backup-db/nexus-db-migrator-3.70.3-01.jar"
      docker stop nexus
      
      [root@ks2024-2]# docker run -it --rm --net host -v /installer/data/nexus/:/nexus-data $NEXUS_FQDN/project_k/lcm/nexus3:$RELEASE-3.70.3 /bin/bash
      bash-4.4$ cd /nexus-data/backup-db/
      bash-4.4$ java -Xmx16G -Xms1G -XX:+UseG1GC -XX:MaxDirectMemorySize=28672M -jar nexus-db-migrator-*.jar --migration_type=h2 -y
      bash-4.4$ cp nexus.mv.db /nexus-data/db/
      bash-4.4$ echo "nexus.datastore.enabled = true" >> /nexus-data/etc/nexus.properties
      bash-4.4$ exit
      
      docker start nexus
      
      sed -i "s|\$NEXUS_FQDN/project_k/lcm/nexus3:\$RELEASE-3.70.3|\$NEXUS_FQDN/project_k/lcm/nexus3:\$RELEASE|" compose.yaml
      docker compose -f $CFG_HOME/compose.yaml up -d nexus
      

8. Перейдите в веб-интерфейс развернутого GitLab.

   1. В группе project_k перейдите в раздел Settings → CI/CD → Variables. Добавьте новые переменные:

      • NEXUS_USER: admin

      • NEXUS_FQDN: nexus.$DOMAIN

   2. (Опционально) В группах deployments и services перейдите в раздел Settings → CI/CD → Variables и переместите все переменные в группу project_k.

9. Перейдите на LCM-узел и выполните команды:

   cd /installer/config
   source settings
   sed -i "s|DB_PASSWORD=.*|DB_PASSWORD=netbox_db_password|" $NETBOX_HOME/env/netbox.env
   sed -i "s|REDIS_CACHE_PASSWORD=.*|REDIS_CACHE_PASSWORD=netbox_redis_cache_password|" $NETBOX_HOME/env/netbox.env
   sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=netbox_redis_password|" $NETBOX_HOME/env/netbox.env
   sed -i "s|SUPERUSER_PASSWORD=.*|SUPERUSER_PASSWORD=netbox_admin_password|" $NETBOX_HOME/env/netbox.env
   sed -i "s|AUTH_LDAP_BIND_PASSWORD: .*|AUTH_LDAP_BIND_PASSWORD: \"LDAP-BIND-PASSWORD\"|" $NETBOX_HOME/env/netbox.env
   sed -i "s|POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=netbox_db_password|" $NETBOX_HOME/env/postgres.env
   sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=netbox_redis_password|" $NETBOX_HOME/env/redis.env
   sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=netbox_redis_cache_password|" $NETBOX_HOME/env/redis-cache.env
   

ks2024.3 → ks2024.4

Обновление с ks2024.3 на следующую по порядку версию гарантирует, что все новые возможности будут внедрены правильно. Данный этап можно считать обязательной частью обновления LCM-узла.

1. Зайдите на LCM-узел по SSH.

   SberLinuxUbuntu

   1. Загрузите архив upgrade-ks2024.4-sberlinux.tgz в папку /installer/update.

   2. Для последующего обновления репозитория в GitLab, выполните команду:

      git config --global --add safe.directory '*'
      

   3. Замените в файлах ~/installer/settings и /installer/settings строку export RELEASE=ks2024.3-sberlinux на export RELEASE=ks2024.4-sberlinux.

2. Откройте веб-интерфейс развернутого GitLab.

   1. Найдите репозиторий project_k → deployments → bifrost и удалите его. Для этого перейдите в Project settings → Advanced и нажмите Delete project.

   2. Перейдите в репозиторий project_k → services → upgrade.

   3. Перейдите в раздел Settings → CI/CD → General pipelines и поставьте Timeout - 5h.

   4. Запустите пайплайн Run pipeline по умолчанию. Дождитесь его завершения.

3. Для проведения обновления необходимо восстановить пароли доступа Netbox.

   1. Перейдите на LCM-узел.

   2. Извлеките из архива инсталлятора файлы installer/netbox-docker/env/*.env.

   3. Переместите эти файлы в /installer/data/netbox/env/ на LCM-узле, заменив существующие.

4. Перейдите на LCM-узел и выполните команды, приведенные ниже.

   cd /installer/config
   source settings
   sed -i "/netbox.dump/d" $CFG_HOME/netbox-compose.yml
   docker compose -f $CFG_HOME/netbox-compose.yml up -d
   docker compose -f $CFG_HOME/compose.yaml up -d
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault operator unseal"
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault login"
   

   SberLinuxUbuntu

   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "cat /vault/config/chain-ca.pem >> /etc/pki/ca-trust/source/anchors/ca.crt; update-ca-trust"
   

   docker restart vault
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault operator unseal"
   docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "vault login"
   

5. Перейдите на LCM-узел и выполните команды:

   cd /installer/config
   source settings
   sed -i "s|DB_PASSWORD=.*|DB_PASSWORD=netbox_db_password|" $NETBOX_HOME/env/netbox.env
   sed -i "s|REDIS_CACHE_PASSWORD=.*|REDIS_CACHE_PASSWORD=netbox_redis_cache_password|" $NETBOX_HOME/env/netbox.env
   sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=netbox_redis_password|" $NETBOX_HOME/env/netbox.env
   sed -i "s|SUPERUSER_PASSWORD=.*|SUPERUSER_PASSWORD=netbox_admin_password|" $NETBOX_HOME/env/netbox.env
   sed -i "s|AUTH_LDAP_BIND_PASSWORD: .*|AUTH_LDAP_BIND_PASSWORD: \"LDAP-BIND-PASSWORD\"|" $NETBOX_HOME/env/netbox.env
   sed -i "s|POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=netbox_db_password|" $NETBOX_HOME/env/postgres.env
   sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=netbox_redis_password|" $NETBOX_HOME/env/redis.env
   sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=netbox_redis_cache_password|" $NETBOX_HOME/env/redis-cache.env
   

ks2024.1 → ks2024.4

Чтобы обновить LCM-узел на три версии, необходимо пройти по следующей цепочке обновлений: ks2024.1 → ks2024.2 → ks2024.3 → ks2024.4 . Выполните шаги из инструкций, приведенных выше, по порядку. Неправильный порядок или пропуск какого-либо шага может привести к ошибкам, потерям данных или сбоям в работе платформы.

Проверка работоспособности после обновления:

1. Проверить версии контейнеров.

2. Проверить состояние Controller-узлов.

3. Проверить состояние сервисов compute service list.

4. Проверить состояние сетевых агентов network agent list.

5. Проверить состояние службы томов volume service list.

6. Проверить состояние виртуальных машин server list.

7. Проверить лог на наличие ошибок.

8. Создать несколько виртуальных машин с различными флейворами.

9. Провести live-миграцию виртуальных машин.