======================= Инструкция по установке ======================= ---------- Сокращения ---------- ========== =========== Сокращение Расшифровка ========== =========== СХД Система хранения данных 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). **В общем виде развертывание Платформы состоит из шагов**: #. Подготовка инфраструктуры. #. Распаковка дистрибутива Платформы. #. Установка основных компонентов Платформы. #. Настройка сетевой связности. #. Ручной запуск пайплайнов. #. Подключение и настройка служебных сервисов. #. Проверка работоспособности Платформы. Целевая аудитория документа =========================== Системные администраторы, которые будут разворачивать и настраивать Платформу на целевой инфраструктуре. К системным администраторам предъявляются требования: * Навыки системного администрирования 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) | +---------------------------+------------+------------+----------+----------+---------+ --------------------- Подготовительные шаги --------------------- #. Создайте узлы необходимых типов согласно указанным аппаратным и программным требованиям. #. Убедитесь, что на всех узлах время в БИОС настроено в UTC. #. На LCM-узле под управлением ОС SberLinux должна быть выполнена команда ``timedatectl set-local-rtc 0``. #. Убедитесь в наличии пользователя ``root``. .. DANGER:: Выполняйте все команды руководства от пользователя ``root``. #. Убедитесь, что на всех узлах включена аппаратная виртуализация, с помощью команды: ``egrep '(vmx|svm)' /proc/cpuinfo`` Вывод должен содержать параметр ``vmx`` или ``svm``. Если он отсутствует, включите аппаратную виртуализацию. #. Получите дистрибутив одним из вариантов поставки. #. Создайте DNS-зону для сервисов Платформы, в которой необходимо создать записи для следующих сервисов: * ``.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>`` — для управления жизненным циклом Платформы (CI); * ``.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>`` — для хранения артефактов Платформы (пакеты, контейнеры и др.); * ``.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>`` — для хранения паролей и сертификатов; * ``.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>`` — для настроек Baremetal-узлов. #. (Опционально) Выберите свои доменные имена. По умолчанию используются имена: * ```` — ``ks-lcm``; * ```` — ``nexus``; * ```` — ``vault``; * ```` — ``netbox``. #. На LCM-узле проверьте сетевую связность: #. Настройте доступ до IPMI всех узлов инфраструктуры, MGMT-интерфейсов и VIP-адресов. #. Проверьте доступность DHCP-сервера в сети PXE. #. Включите поддержку **Redfish** всех узлов инфраструктуры. #. Для всех Baremetal-узлов создайте пользователя с правами ``administrator``. #. В DNS-зоне для сервисов Платформы создайте DNS-записи вида:: <ИМЯ_УЗЛА>-rmi.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ> #. Подготовьте данные для импорта в Netbox сведениями о вашей инфраструктуре: #. Скачайте файл :download:`netbox2csv.xlsx `. #. Ознакомьтесь с форматом заполнения тестовых данных и очистите таблицы на вкладках **SERVERS** и **Hardware**. #. Заполните данные в скачанном файле: * на вкладке **SERVERS**: * **Tenant** — наименование тенанта; * **Name** — имя узла; * **Role** — тип узла; * **RMI IP/MASK** — IP-адрес IPMI-порта в формате ``/<МАСКА>``; * **/** — IP-адрес MGMT в формате ``/<МАСКА>``; * **Hardware** — марка и модель узла, выбрать из раскрывающегося списка; * **Tags** — теги для группировки узлов. * на вкладке **Hardware** (если совместимого оборудования не было в списке **Hardware**): * **Hardware** — название сервера; * **Manufacturer** — производитель сервера; * **Type** — марка или модель сервера. #. Убедитесь, что на остальных вкладках заполненного файла появились данные о новых серверах. #. Если для хранилища артефактов будет использовано клиентское хранилище Nexus, необходимо подготовить структуру: .. tabs:: .. tab:: SberLinux +------------------+--------+--------+ | Название | Тип | Формат | +==================+========+========+ | 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 | +------------------+--------+--------+ .. tab:: Ubuntu +------------------+--------+--------+ | Название | Тип | Формат | +==================+========+========+ | docker-ubuntu | hosted | yum | +------------------+--------+--------+ | images | hosted | raw | +------------------+--------+--------+ | k-add | hosted | raw | +------------------+--------+--------+ | k-backup | hosted | raw | +------------------+--------+--------+ | k-images | hosted | docker | +------------------+--------+--------+ | k-pip | hosted | pypi | +------------------+--------+--------+ | ubuntu | hosted | yum | +------------------+--------+--------+ --------------------------------- Установка и настройка компонентов --------------------------------- Чтобы установить и настроить основные компоненты Платформы: #. На LCM-узел установите дистрибутив Платформы. #. Подготовьте Baremetal-узлы (далее — BMC-узлы) для эксплуатации. #. Создайте нужное количество регионов. #. Разверните нужное количество виртуальных сетей и подсетей. #. Создайте шаблоны образов и типов дисков. Подробная инструкция по каждому шагу приведена ниже. Шаг 1. Установите дистрибутив Платформы на LCM-узле =================================================== #. Зайдите на LCM-узел по SSH. #. Получите архив Платформы одним из способов поставки. #. Переключитесь на пользователя ``root`` и распакуйте дистрибутив Платформы. Пример для Ubuntu:: sudo su tar -xf <ПУТЬ_К_ДИСТРИБУТИВУ>/installer-ks2024.4-ubuntu-offline.tgz -C ~/ cd installer/ #. Если для хранилища артефактов будет использовано клиентское хранилище Docker-образов: #. На LCM-узле разместите полную цепочку сертификатов сервиса в новом файле ``.pem`` директории ``installer/certs``. #. Убедитесь, что существует пользователь с правами ``pull`` и ``push`` в вашем Docker-хранилище. .. NOTE:: Docker-образ для Openstack и kolla-ansible будут сохранены в клиентском Nexus в пространстве ``project_k``. #. При интеграции AD/LDAPs с TLS компонентов Keystack: #. На LCM-узле разместите полную цепочку сертификатов AD/LDAPs с TLS в новом файле ``ldaps.pem`` директории ``installer/certs``. #. В распакованном архиве запустите скрипт ``installer.sh``. #. Последовательно введите запрашиваемые данные: * **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`` — включить поддержку :doc:`ролевой модели ` в Gitlab и Netbox; при выборе этого варианта укажите: * **LDAP Server URI**: адрес AD/LDAPs в формате ``ldaps://``; * **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-сертификатов; * ``.crt`` и ``.key`` — сертификат и приватный ключ сертификата для сервиса Nexus; * ``.crt`` и ``.key`` — сертификат и приватный ключ сертификата для сервиса Gitlab; * ``.crt`` и ``.key`` — сертификат и приватный ключ сертификата для сервиса Vault; * ``.crt`` и ``.key`` — сертификат и приватный ключ сертификата для сервиса Netbox. #. Дождитесь завершения операции. При успешной установке появятся реквизиты для доступа к компонентам Платформы. .. NOTE:: На LCM-узле будут установлены и настроены компоненты: * SSH-ключи для беспарольного доступа на узлы; * самоподписанные сертификаты для служб LCM; * хранилище Sonatype Nexus (если был выбран вариант нового хранилища); * система автоматизации (GitLab-CI); * репозитории управления облаком (CI/CD); * Netbox (CMDB). #. Сохраните реквизиты доступа к компонентам: * **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``. #. Добавьте корневой сертификат (значение параметра **Root CA Certificate**) в формате Base64 ASCII в доверенные корневые Центры сертификации для корректной работы веб-интерфейсов Платформы. Настройка собственного корневого сертификата ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Все пароли и сертификаты Платформы должны храниться в сервисе Vault (``vault.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>``). .. NOTE:: Инсталлятор генерирует собственные сертификаты Платформы с помощью программы ``openssl``: #. Создает корневой центр сертификации: корневой сертификат и приватный ключ. Срок действия — 10 лет. #. Создает Wildcard-сертификат и приватный ключ для сервисов GitLab, Nexus, Vault, Netbox и делает их доверенными Центру сертификации. Также создается цепочка сертификатов вида ``chain-cert.pem`` для сервисов. Срок действия — 2 года. #. Создает в Vault репозиторий **installer** для хранения сертификатов и создает в этом хранилище Центр сертификации на основе корневого центра. Срок действия — 2 года. #. Создает роль, с помощью которой можно выписывать сертификаты на основе запросов пользователей. Чтобы использовать собственные сертификаты: #. Подготовьте цепочку сертификатов для своего Nexus в файле ``.pem``. #. Откройте веб-интерфейс развернутого Vault (``vault.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>``). #. Авторизуйтесь с помощью реквизитов для Vault, полученных на этапе установки дистрибутива Платформы. #. Откройте на редактирование файл ``secret_v2/deployments/secrets/ca.crt`` и дополните его цепочкой сертификатов для своего Nexus. Настройка :doc:`ролевой модели ` в Gitlab и Netbox ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. Источник: https://wiki.itkey.com/pages/viewpage.action?pageId=136810470 #. Настройка ролевой модели в Netbox #. После инсталляции зайдите в Web-интерфейс Netbox одним пользователем из каждой сопоставленной группы LDAP. При этом действии каждая группа будет зарегистрирована в Netbox. #. Зайдите пользователем с ролью **admin**. #. Перейдите в **Администратор** → **Аутентификация** → **Группы**. #. Отредактируйте группы и выставите им разрешения: #. Для групп с ролью **operator**, **security_auditor** и **reader** укажите разрешение ``perm_ro``. #. Для групп с ролью **admin** укажите разрешение ``perm_rw``. #. Настройка ролевой модели в Gitlab #. После инсталляции зайдите в Web-интерфейс Gitlab пользователем **root**. При аутентификации выбирайте вариант входа "Standard". #. Перейдите в репозиторий project_k/services/gitlab-ldap-sync, откройте на редактирование файл ``gitlab-ldap-sync.conf``: #. В секции ``[gitlab]`` в строке ``groups=`` укажите названия ваших сопоставляемых AD/LDAPs групп. Отредактируйте значения ключа ``ldap:`` для каждой группы. Руководствуйтесь назначением сопоставляемых групп, описанным в :ref:`role-model-description`. #. В секции ``[ldap]`` в строке ``admingroup=`` укажите название AD/LDAPs группы, которая сопоставляется с ролью **admin**. #. Запустите пайплайн по умолчанию для первичной синхронизации пользователей из AD/LDAPs. При запуске пайплайна убедитесь, что в переменной ``KEYSTACK_RELEASE`` указано актуальное значение релиза. #. В репозитории project_k/services/gitlab-ldap-sync в разделе **Build** → **Pipeline schedules** настройте периодичность запуска пайплайна. #. Проверка настройки #. Войдите в Web-интерфейс Netbox и Gitlab пользователями с разными ролями. При аутентификации выбирайте вариант входа "LDAP". Вход должен быть успешным, доступные элементы соответствовать роли пользователя. Шаг 2. Подготовьте BMC-узлы инфраструктуры ========================================== #. Запустите пайплайн на генерацию паролей и сертификатов для Bifrost: #. Откройте веб-интерфейс развернутого GitLab (``ks-lcm.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>``). #. Авторизуйтесь с помощью реквизитов для GitLab, полученных на этапе установки дистрибутива Платформы. #. Откройте проект **project_k** → **deployments** → **gen-pwd**. #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте переменную ``OPENSTACK_ENV`` со значением ``bifrost`` и запустите пайплайн. #. Запустите задачу **create-config** в созданном пайплайне. #. Дождитесь завершения выполнения операции. #. Перейдите в репозиторий **project_k** → **deployments** → **bifrost**. #. Установите Bifrost: #. Откройте файл ``inventory`` и замените в нем значение ``LCM_IP`` на IP-адрес LCM-узла. #. Откройте файл ``globals.d/REGION.yml`` и замените значение ``eth0`` параметра ``network_interface`` на имя интерфейса на LCM-узле (например, ``mgmt``). #. Откройте файл ``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-сервера. #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. Дождитесь завершения выполнения операции. #. Настройте dnsmasq в Bifrost: #. Зайдите на LCM-узел по ssh и выполните команду: .. code-block:: bash # docker exec -ti bifrost_deploy bash (bifrost-deploy)# vi /etc/dnsmasq.conf #. В открывшемся файле поменяйте значения: * ``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. #. Сохраните изменения закройте файл. Перезапустите сервис dnsmasq командой: .. code-block:: bash (bifrost-deploy)# systemctl enable dnsmasq (bifrost-deploy)# systemctl restart dnsmasq #. Настройте правила firewall для Bifrost (опционально): .. tabs:: .. tab:: SberLinux #. Зайти на LCM-узел по ssh и выполнить команду: .. code-block:: bash # 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 .. tab:: Ubuntu #. Зайти на LCM-узел по ssh и: * Открыть tcp порты 8080, 5050, 6385 * Открыть udp порты 67,69 #. Для всех BMC-узлов задайте одинакового пользователя и пароль: #. Перейдите в веб-интерфейс развернутого Vault. #. Перейдите в директорию с настройками Bifrost ``secret_v2/deployments/bifrost/rmi``. #. Нажмите **Create new version** для параметра с именем пользователя. #. Задайте имя пользователя интерфейса IPMI BMC-узлов. #. Повторите операцию для пароля, указав пароль от интерфейса IPMI BMC-узлов. .. NOTE:: Указание одинаковых пользователей необходимо для автоэвакуации ВМ при сбое гипервизора. #. Откройте веб-интерфейс развернутого Netbox (``netbox.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>``). #. Авторизуйтесь с помощью реквизитов для Netbox, полученных на этапе установки дистрибутива Платформы. #. Импортируйте данные из 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**. #. Завершите настройку Netbox: #. В Netbox, разделе **API tokens**, скопируйте токен. #. На LCM-узле выполните скрипт из XLSX-файла в CLI, вкладка **update_ctx.sh**, предварительно заменив значения: * ``NETBOX_TOKEN`` — токен Netbox из раздела **API tokens**; * ``NETBOX_URI`` — адрес Netbox в формате ``https://netbox.demo.local/``. #. Настройте контекст для одного из типов узлов: #. В веб-интерфейсе Netbox перейдите в раздел **Provisioning** → **Config Contexts**. #. Нажмите кнопку **Add**. #. Вставьте конфигурацию в поле **Data**: * пример для Compute-узлов: .. code-block:: JSON { "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-узлов: .. code-block:: JSON { "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`` — шлюз для подсети для подсети по умолчанию в формате ``/<МАСКА>``. * ``dns_name`` — имя DNS-сервера. * ``dns_server`` — IP-адрес DNS-сервера. * ``Interface`` — наименование интерфейса. * ``MTU`` — значение MTU. * ``Parent`` — наименование родительского интерфейса, если предусмотрена иерархия. * ``"id": "40"`` — MGMT VLAN на гипервизорах. * ``"id": "39"`` — MGMT VLAN на Controller-узлах. * ``"id": "484"`` — VLAN сети управления IPMI. #. Повторите настройку контекста (предыдущий шаг) для остальных типов узлов. #. Перейдите в раздел **IPAM** → **Prefixes**. #. Убедитесь, что значение **Prefix** совпадает с указанным ``default_gateway``: если это не так, измените его и сохраните изменения. #. Активируйте все BMC-узлы инфраструктуры: #. В веб-интерфейсе Netbox перейдите в раздел **Devices**. #. Нажмите на иконку редактирования для нужного узла. #. В открывшейся форме для параметра **Custom Fields** → **state** установите значение **ready**. #. Сохраните изменения. #. Запустите пайплайн для одного из типов BMC-узлов: #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **services** → **baremetal**. #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте переменные: * ``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://: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`` — не выводить отладочную информацию. #. Запустите пайплайн, нажав кнопку **Run pipeline**. #. Дождитесь завершения выполнения операции. #. Повторите запуск пайплайна (предыдущий шаг) для остальных типов узлов. #. Перейдите в раздел **Device** в Netbox и убедитесь, что все узлы были добавлены в список, статус — **production**. Шаг 3. Создайте регионы ======================= Регионы логически разделяют узлы инфраструктуры Платформы. .. TIP:: Чтобы создать несколько регионов, повторите инструкцию из раздела нужное количество раз. Чтобы создать один регион: #. Откройте веб-интерфейс развернутого GitLab. #. Создайте форк GitLab-репозитория **project_k** → **deployments** → **region1**: #. Перейдите в проект **region1**. #. Нажмите кнопку **Fork**. #. В открывшемся окне укажите параметры: * **Project name**: имя региона ``<ИМЯ_РЕГИОНА>``. .. IMPORTANT:: Имя региона должно удовлетворять условиям: * содержать латинские буквы *[a-z]* и цифры *[0–9]*; * дефисы не могут быть в начале и конце имени; * не должно содержать два дефиса одновременно; * не должно содержать пробелы и специальные символы (например, ``!``, ``$``, ``&``, ``_`` и т. д.); * минимальная длина — *3*, максимальная — *63* символа; * нечувствительно к регистру. * **Select a namespace**: выберите namespace для проекта. #. Нажмите кнопку **Fork project**. #. Перейдите в репозиторий созданного региона. #. Перейдите в раздел **Settings** → **General** → **Advanced**. #. Удалите связь репозиториев, нажав кнопку **Remove fork relationship**. #. Настройте созданный регион: .. tabs:: .. tab:: SberLinux #. Откройте файл ``inventory``. #. Заполните информацию об узлах инфраструктуры ``[control]``, ``[network]``, ``[compute]`` в формате ``<ИМЯ_УЗЛА> ansible_host=``. #. Откройте файл ``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-адресами. #. Откройте файл ``globals.d/octavia.yml`` и укажите значения параметра ``octavia_amp_network_cidr`` — IP-адреса для Amphora сервиса Octavia. .. tab:: Ubuntu #. Откройте файл ``inventory``. #. Заполните информацию об узлах инфраструктуры ``[control]``, ``[network]``, ``[compute]`` в формате ``<ИМЯ_УЗЛА> ansible_host=``. #. Откройте файл ``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-адресами. #. Откройте файл ``globals.d/octavia.yml`` и укажите значения параметра ``octavia_amp_network_cidr`` — IP-адреса для Amphora сервиса Octavia. #. Запустите пайплайн на генерацию паролей и сертификатов для региона: #. Откройте проект **project_k** → **deployments** → **gen-pwd**. #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте переменную ``OPENSTACK_ENV`` — имя созданного региона. #. Запустите пайплайн **Run pipeline**. #. Запустите задачу **create-config** и дождитесь ее завершения. #. (Опционально) Повторите запуск пайплайна нужное количество раз, если создано несколько регионов. #. Настройте автоэвакуацию ВМ при сбое гипервизора, изменив пароль для IPMI-узлов гипервизора: #. Перейдите в веб-интерфейс развернутого Vault. #. Перейдите в директорию с настройками региона ``secret_v2/deployments/<ИМЯ_РЕГИОНА>/passwords_yml``. #. Нажмите **Create new version**. #. Найдите и замените значение параметра ``bmc_password`` на пароль от интерфейса IPMI BMC-узлов гипервизора. #. По аналогии с предыдущим шагом в директорию с настройками региона ``secret_v2/deployments/<ИМЯ_РЕГИОНА>/passwords_yml`` укажите пароли от своих сервисов: * LDAP, * SMTP пользователя, * GitLab (пароль root-пользователя), * СХД. #. В зависимости от серверных ресурсов, работа пайплайна по развертыванию региона может занимать продолжительное время и не укладываться в стандартный таймаут. Увеличьте таймаут для пайплайнов в репозитории региона: #. Откройте веб-интерфейс развернутого Gitlab. #. Откройте проект **project_k** → **deployments** → **<ИМЯ_РЕГИОНА>**. #. Откройте настройки : **Settings** → **CI/CD** → **General pipelines**. #. Установите значение **Timeout** ``3h``. #. Запустите пайплайн по развертыванию региона: #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **<ИМЯ_РЕГИОНА>**. #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте переменные: * ``KOLLA_ARGS`` — дополнительные теги: * ``--limit <ИМЯ_УЗЛА>`` — выполнить пайплайн для отдельного узла Платформы; * ``--tags <ИМЯ_КОМПОНЕНТА>`` — выполнить пайплайн для отдельного компонента Платформы. * ``KOLLA_ANSIBLE_DEPLOY_ACTION`` — список задач для kolla-ansible, укажите ``deploy``; * ``KEYSTACK_RELEASE`` — версия KeyStack в git-репозитории **project_k** → **keystack**. #. Запустите пайплайн **Run pipeline**. #. Дождитесь завершения задачи **setup**. #. Запустите задачу **bootstrap-servers** и дождитесь ее завершения. #. Запустите задачу **deploy** и дождитесь ее завершения. .. NOTE:: Общий список задач в пайплайне: * **setup** — подготовка паролей и настроек для развертывания Платформы; * **bootstrap-servers** — установка необходимых пакетов и настройка компонентов ОС; * **deploy** — развертывание и запуск сервисов OpenStack на узлах; * **postconfig** — применение квот; * **states** — применение конфигурации к узлам Платформы; * **rally** — валидация компонентов Платформы; * **tempest** — тестирование Платформы на соответствие конфигурации; * **backup-db** — создание резервной копии БД MariaDB. Шаг 4. Создайте сети и подсети в каждом регионе =============================================== .. TIP:: Если у вас несколько регионов, повторите инструкцию из раздела нужное количество раз. #. Включите поддержку VLAN Tagging: #. Откройте веб-интерфейс развернутого GitLab. #. Перейдите в репозиторий созданного региона. #. Найдите файл ``globals.d/REGION.yml`` и добавьте в него строки. В параметре ``global_physnet_mtu`` укажите допустимое вашей сетевой инфраструктурой значение MTU: .. code-block:: yaml enable_neutron_provider_networks: "yes" global_physnet_mtu: "9000" #. Создайте файл ``config/neutron/neutron.conf`` с содержимым: .. code-block:: ini [DEFAULT] global_physnet_mtu = {{ global_physnet_mtu }} #. Создайте файл ``config/neutron/ml2_conf.ini`` со следующим содержимым. В параметре ``network_vlan_ranges`` укажите допустимый вашей сетевой инфраструктурой диапазон номеров VLAN: .. code-block:: ini [ml2_type_vlan] network_vlan_ranges = physnet1:1000:2000 #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте переменную ``KOLLA_ARGS`` со значением ``-t neutron``. #. Запустите пайплайн, нажав кнопку **Run pipeline**. #. Дождитесь завершения выполнения операции. #. В Horizon создайте сеть для проекта с параметрами: * **Provider Network Type**: ``VLAN``; * **Physical Network**: ``physnet1``; * **Segmentation ID**: UUID нужной VLAN. #. Получите openrc-файл из Vault: #. Зайдите на LCM-узел через SSH. #. Выполните команду импорта openrc-файла:: docker exec -ti vault vault read secret_v2/data/deployments/<ИМЯ_РЕГИОНА>/openrc -format=json | jq -r '.data.data.value' > openrc-<ИМЯ_РЕГИОНА> #. Если вы используете собственный CA-сертификат: убедитесь, что цепочка CA-сертификатов ``chain-cert.pem`` сохранена в директории ``/installer/data/ca/cert/`` сервиса Vault. #. В импортированный файл добавьте строку:: export OS_CACERT=/installer/data/ca/cert/chain-ca.pem #. Импортируйте содержимое openrc-файла в переменные окружения с помощью команды:: source openrc-<ИМЯ_РЕГИОНА> #. Создайте виртуальную сеть с помощью openstack-команды: .. code-block:: bash openstack network create [--extra-property type=,name=,value=] [--share | --no-share] [--enable | --disable] [--project ] [--description ] [--mtu ] [--project-domain ] [--availability-zone-hint ] [--enable-port-security | --disable-port-security] [--external | --internal] [--default | --no-default] [--qos-policy ] [--transparent-vlan | --no-transparent-vlan] [--provider-network-type ] [--provider-physical-network ] [--provider-segment ] [--dns-domain ] [--tag | --no-tag] --subnet Здесь: * ``--extra-property type=,name=,value=`` — дополнительные параметры, по умолчанию в формате ``string``. Возможные форматы: ``dict``, ``list``, ``str``, ``bool``, `int`. При типе ``list`` значения могут перечисляться через точку с запятой. Для типа ``dict`` используется список пар ``<КЛЮЧ>:<ЗНАЧЕНИЕ>``, разделенных точкой с запятой; * ``--share`` — сделать сеть общей для всех проектов; * ``--no-share`` — не делать сеть общей для всех проектов; * ``--enable`` — признак доступности сети (действует по умолчанию); * ``--disable`` — признак недоступности сети; * ``--description `` — описание сети; * ``--mtu `` — установить значение MTU; * ``--project-domain `` — присвоить сеть домену проекта (по наименованию или ID). Опция используется в случае конфликтов между названиями проектов; * ``--availability-zone-hint `` — зона доступности сети ````; указать опцию нужное количество раз для задания нескольких зон доступности; * ``--enable-port-security`` — установить защиту портов для сети (действует по умолчанию); * ``--disable-port-security`` — отключить защиту портов для сети; * ``--external`` — установить сеть как внешнюю; * ``--internal`` — установить сеть как внутреннюю (действует по умолчанию); * ``--default`` — использовать в виде внешней сети по умолчанию; * ``--no-default`` — не использовать в виде внешней сети по умолчанию; * ``--qos-policy `` — политика QoS для подключения к этой сети (имя или идентификатор); * ``--transparent-vlan`` — добавить доступ в интернет для сети; * ``--no-transparent-vlan`` — не добавлять доступ в интернет для сети; * ``--provider-network-type `` — тип сети. Возможные варианты: ``flat``, ``geneve`, ``gre``, ``local`, ``vlan``, ``vxlan``; * ``--provider-physical-network `` — соответствие виртуальной сети физической сети ````; * ``--provider-segment `` — идентификатор VLAN для сетей VLAN или идентификатором Tunnel ID для сетей GENEVE/GRE/VXLAN; * ``--dns-domain `` — DNS-имя для сети; * ``--tag `` — добавление тега ```` для сети; повторить опцию для добавления нескольких тегов; * ``--no-tag`` — не добавлять теги для сети; * ``--subnet `` — подсеть IPv4 для фиксированных IP (в нотации CIDR); **обязательный параметр**; * ``name`` — наименование создаваемой сети; **обязательный параметр**. Создайте нужное количество сетей, повторив команду нужное количество раз. #. (Опционально) Создайте нужное количество виртуальных подсетей с помощью openstack-команды: .. code-block:: bash openstack subnet create [--project [--project-domain ]] [--subnet-pool | --use-default-subnet-pool [--prefix-length ]] [--subnet-range ] [--allocation-pool start=,end=] [--dhcp | --no-dhcp] [--dns-nameserver ] [--gateway ] [--host-route destination=,gateway=] [--ip-version {4,6}] [--description ] [--network-segment ] [--service-type ] [--tag | --no-tag] --network Здесь: * ``--project `` — наименование проекта, в котором создается подсеть; * ``--project-domain `` — присвоить подсеть домену проекта (по наименованию или ID). Опция используется в случае конфликтов между названиями проектов; * ``--subnet-pool `` — пул подсети ````, из которого эта подсеть получит CIDR (наименование или ID); * ``--use-default-subnet-pool`` — использовать пул подсети по умолчанию для опции ``--ip-version``; * ``--prefix-length `` — длина префикса для выделения подсети из пула подсетей; * ``--subnet-range `` — диапазон подсетей ```` в нотации CIDR (обязательный параметр, если не указан ``--subnet-pool``); * ``--allocation-pool start=,end=`` — пулы распределения IP-адресов; * ``--dhcp`` — использовать DHCP (по умолчанию); * ``--no-dhcp`` — не использовать DHCP; * ``--dns-nameserver `` — наименование DNS-сервера для подсети; повторить опцию для указания нескольких серверов; * ``--gateway `` — шлюз для подсети. Возможные значения: * ```` — конкретный IP-адрес, например, ``192.168.9.1``; * ``auto`` — выбор адреса шлюза автоматически; * ``none`` — подсеть не использует шлюз. * ``--host-route destination=,gateway=`` — дополнительные маршрутизаторы, назначенные узлам; * ``--ip-version {4,6}`` — версия IP для подсети (значение по умолчанию `4`); версия ``6`` не используется в Платформе; * ``--description `` — описание подсети; * ``--network-segment `` — диапазон сети ```` для создаваемой подсети (наименование или ID); * ``--service-type `` — тип службы для подсети, например, ``network:floatingip_agent_gateway``; * ``--tag `` — добавить тегов для подсети; повторить опцию для добавления нескольких тегов; * ``--no-tag`` — не добавлять теги для подсети; * ``--network `` — сеть ````, частью которой будет являться данная подсеть (наименование или ID); **обязательный параметр**; * ```` — наименование подсети; **обязательный параметр**. Создайте нужное количество подсетей, повторив команду нужное количество раз. #. Проверьте создание сетей и подсетей с помощью команды: ``openstack network list --long`` Отобразится таблица с подробной информацией о созданных сетях и подсетях. .. TIP:: Подробная инструкция по управлению виртуальными сетями и подсетями в Платформе приведена в Руководстве администратора. Шаг 5. Создайте шаблоны образов и типы дисков =============================================== Выполните инструкцию по созданию шаблонов образов и типов дисков согласно Руководству администратора. Настройка :doc:`ролевой модели ` в OpenStack ============================================================================ .. Источник: https://wiki.itkey.com/pages/viewpage.action?pageId=136810470 #. Добавьте сертификат для LDAPS: #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **<имя региона>**. #. Добавьте ваш сертификат LDAPS в ``certificates/ca/ldaps.crt``. При необходимости создайте этот файл. .. #. Настройте :ref:`интеграцию OpenStack с LDAP `. #. Создайте домен (в этом примере — ``itkey``) и добавьте в него пользователя ``admin``: #. Перейдите в интерфейс OpenStack CLI. #. Выполните команды:: openstack domain create itkey openstack role add --domain itkey --user admin admin #. Добавьте конфигурацию LDAPS для Keystone: #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **<имя региона>**. #. Найдите файл ``globals.d/REGION.yml`` и добавьте в него строки:: horizon_keystone_multidomain: "True" horizon_keystone_domain_choices: default: default itkey: itkey keystone_ldap_url: "ldaps://<адрес вашего сервиса LDAPS>" #. Создайте файл ``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 #. Добавьте пароль пользователя LDAPS в Vault: #. Откройте веб-интерфейс Vault. #. Откройте путь ``secrets_v2/deployments`` и далее ваш регион. Откройте файл секретов ``passwords_yml``. #. Перейдите на вкладку **Secret** и нажмите **Create new version**. #. Отредактируйте файл, замените значение поля ``ldap_password`` на пароль пользователя LDAPS. #. Запустите деплой компонентов Keystone и Horizon: #. Откройте веб-интерфейс развернутого GitLab. #. Перейдите в репозиторий созданного региона. #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте параметр ``KOLLA_ARGS`` со значением ``-t keystone,horizon``. #. Запустите пайплайн: **Run pipeline**. #. Дождитесь завершения выполнения задач на шаге **setup**. #. Запустите задачу **deploy** на шаге **deploy** и дождитесь ее завершения. #. Чтобы проверить настройку пользователей и групп 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 | +------------------------------------------------------------------+----------------------+ #. Создайте новый проект в домене itkey:: openstack project create demo --domain itkey #. Добавьте ваши группы в этот проект в OpenStack с соответствующими ролями. В качестве ID_GROUP_group_* указывайте конкретные идентификаторы групп из вывода команды ``openstack group list --domain itkey``: #. Добавьте роль member:: openstack role add --project demo --group ID_GROUP_group_member --user-domain itkey member #. Добавьте роли 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 #. Добавьте роли 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 #. Проверка настройки #. Войдите в Web-интерфейс Horizon в домене itkey пользователями с разными ролями. Вход должен быть успешным, доступные элементы соответствовать роли пользователя. ------------------------------ Подключение служебных сервисов ------------------------------ Портал администратора ===================== .. IMPORTANT:: Варианты установки мультирегионального и однорегионального портала отличаются. Чтобы установить портал администратора с одним регионом: #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **<ИМЯ_РЕГИОНА>**. #. Найдите файл ``globals.d/REGION.yml`` и убедитесь, что в нём есть строки:: enable_adminui: "yes" adminui_gitlab_username: "root" #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте параметр ``KOLLA_ARGS`` со значением ``-t adminui``. #. Запустите пайплайн: **Run pipeline**. #. Дождитесь завершения выполнения операции. Чтобы подключить дополнительный регион к порталу администратора: #. Зайдите на любой Control-узел подключаемого региона по SSH. #. Откройте файл ``/etc/kolla/adminui-backend/adminui-backend-regions.conf``. Информация из этого файла понадобится позже. #. Откройте веб-интерфейс развернутого GitLab целевого региона. #. Откройте проект **project_k** → **deployments** → **<ИМЯ_РЕГИОНА>**. #. Создайте файл ``config/adminui/adminui-backend-regions.conf`` и добавьте в него раздел ``[DEFAULT]`` с перечислением регионов и раздел для подключаемого региона, заменив параметры соответствующими значениями. Не указывайте в файле динамические параметры, в том числе пароли, в явном виде:: [DEFAULT] region_names=<имя целевого региона>, <имя подключаемого региона> [<имя подключаемого региона>] type=keystack prometheus_url=https://:9091 gitlab_project_name=<имя подключаемого региона> gitlab_repo_address=https://ks-lcm.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>/project_k/devregion grafana_url=https://:3000 opensearch_url=https://:5601 horizon_url=https:// 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://: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://:12998 #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте параметр ``KOLLA_ARGS`` со значением ``-t adminui``. #. Запустите пайплайн: **Run pipeline**. #. Дождитесь завершения выполнения операции. Мониторинг ========== Мониторинг в Платформе реализован на базе Opensearch, Cloud Auditing Data Federation (CADF), Prometheus и Grafana. Доступ к компонентам — через веб-интерфейс: * Opensearch — ``https://opensearch.<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>:5601/``; * Prometheus — ``http://<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>:9091/``; * Alertmanager — ``http://<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>:9093/``; * Grafana — ``http://<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>:3000/``. По умолчанию все перечисленные компоненты разворачиваются для каждого региона. Если этого не произошло, запустите их вручную: #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **<ИМЯ_РЕГИОНА>**. #. Откройте файл ``globals.d/REGION.yml`` и измените значения ``no`` на ``yes`` для нужных компонентов:: enable_grafana: "yes" enable_prometheus: "yes" enable_prometheus_alertmanager: "yes" enable_opensearch: "yes" enable_cadf_audit: "yes" #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте параметры: * ``KOLLA_ANSIBLE_DEPLOY_ACTION`` — ``deploy``; * ``KOLLA_ARGS`` с именем нужного компонента: * Grafana — ``-t grafana``; * Prometheus — ``-t prometheus``; * Opensearch — ``-t opensearch``. .. TIP:: Если нужно развернуть несколько компонентов одновременно, укажите их через запятую. .. IMPORTANT:: CADF является настройкой сервисов, поэтому для его включения необходимо запускать деплой без тегов. #. Запустите пайплайн: **Run pipeline**. #. Дождитесь завершения выполнения операции. Чтобы настроить глубину хранения метрик в Prometheus: #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **<ИМЯ_РЕГИОНА>**. #. Внесите изменения в файл ``globals.d/REGION.yml``:: prometheus_cmdline_extras: "--storage.tsdb.retention.time=60d --storage.tsdb.retention.size=500GB" #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте параметры: * ``KOLLA_ANSIBLE_DEPLOY_ACTION`` — ``deploy``; * ``KOLLA_ARGS`` — ``-t prometheus``. #. Запустите пайплайн: **Run pipeline**. #. Дождитесь завершения выполнения операции. Чтобы создать шаблон индекса в Opensearch: #. Откройте веб-интерфейс развернутого Opensearch. При первом входе вы будете перенаправлены на страницу создания шаблонов. #. Нажмите кнопку **Create index pattern**. #. В открывшемся окне в поле **Index pattern name** укажите значение ``flog*``. #. Нажмите кнопку **Next Step**. #. В поле **Time field** выберите вариант ``@timestamp``. #. Нажмите кнопку **Create index pattern**. .. TIP:: Подробная инструкция по управлению перечисленными компонентами в Платформе приведена в Руководстве администратора. Аудит ===== Для вывода логов в удаленный сервис системного журнала (syslog) используется ``fluent-plugin-remote_syslog`` — плагин Fluentd. .. NOTE:: Настройка плагина по умолчанию:: @type remote_syslog host 10.120.120.125 port 514 protocol tcp Чтобы настроить плагин: #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **<ИМЯ_РЕГИОНА>**. #. Перейдите в директорию ``config``. Если такой директории нет, создайте ее. #. Создайте файл ``fluentd/output/fluent-plugin-remote_syslog.conf`` с содержимым:: > @type copy @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 @type file path /var/lib/fluentd/data/opensearch.buffer/openstack.* flush_interval 15s @type remote_syslog host port <ПОРТ_ДЛЯ_ПЛАГИНА> protocol <ПРОТОКОЛ_ПЕРЕДАЧИ_ДАННЫХ> #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте параметры: * ``KOLLA_ANSIBLE_DEPLOY_ACTION`` — ``deploy``; * ``KOLLA_ARGS`` — ``-t opensearch``. #. Запустите пайплайн: **Run pipeline**. #. Дождитесь завершения выполнения операции. #. (Опционально) Убедитесь, что конфигурационный файл Fluentd ``td-agent.conf`` содержит добавленные данные. Пример конфигурационного файла OpenSearch для отправки данных в syslog: .. code-block:: @type copy @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 @type file path /var/lib/fluentd/data/opensearch.buffer/openstack.* flush_interval 15s @type remote_syslog host 10.10.140.100 port 7710 protocol udp Адреса файлов с логами для компонентов приведены в Руководстве администратора. Системы хранения данных ======================= Платформа поддерживает подключение дополнительных СХД следующих типов: * iSCSI, * FC, * NFS. iSCSI ^^^^^ #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **<ИМЯ_РЕГИОНА>**. #. Добавьте строки в файл ``globals.d/REGION.yml``:: Enable_cinder_backend_iscsi: "yes" Enable_cinder_backend_lvm: "no" #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте параметры: * ``KOLLA_ANSIBLE_DEPLOY_ACTION`` — ``deploy``; * ``KOLLA_ARGS`` — ``-t cinder``. #. Запустите пайплайн: **Run pipeline**. #. Дождитесь завершения выполнения операции. FC ^^ .. WARNING:: В разделе приведен пример подключения Huawei Dorado с поддержкой FC — шаги по подключению других вендоров могут различаться. #. Настройте Cinder: #. Создайте новый проект ``internal_cinder`` и пользователя ``internal_cinder_user``. #. Назначьте пользователю ``internal_cinder_user`` права ``member`` в созданном проекте.\ #. Сохраните идентификаторы проекта и пользователя. Далее для примера будут использоваться ``adcece5761d3440d974f0ddc93623a84`` и ``823b9c2d25814962a135a18777421507`` для проекта и пользователя соответственно. #. (Опционально) Увеличьте квоты в проекте ``internal_cinder`` для дисков. #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **<ИМЯ_РЕГИОНА>**. #. Добавьте строки в файл ``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" #. Создайте файл ``config/cinder/cinder-volume/vendor-configs/dorado.xml`` с содержимым: .. code-block:: xml Dorado FC user {{ lookup('hashi_vault', 'secret={{ vault_engine }}/data/{{ vault_prefix }}/{{ OPENSTACK_ENV | lower }}/huawei')['data']['UserPassword'] }} https://IP_ADDRESS1:8088/deviceManager/rest/;https://IP_ADDRESS2:8088/deviceManager/rest/ 3 NAME_POOL Thin #. Создайте файл ``config/cinder.conf`` с содержимым: .. code-block:: [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 #. Создайте файл ``config/multipath.conf`` с содержимым: .. code-block:: 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 } } #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте параметры: * ``KOLLA_ANSIBLE_DEPLOY_ACTION`` — ``deploy``; * ``KOLLA_ARGS`` — ``-t cinder, multipath``. #. Запустите пайплайн: **Run pipeline**. #. Дождитесь завершения выполнения операции. NFS ^^^ #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **<ИМЯ_РЕГИОНА>**. #. Добавьте строку в файл ``globals.d/REGION.yml``:: enable_cinder_backend_nfs: "yes" #. Создайте файл ``config/nfs_shares`` с записями о каждом Storage-узле:: storage01:/kolla_nfs storage02:/kolla_nfs #. На каждом Storage-узле: #. Создайте файл ``/etc/exports`` с информацией о монтировании хранилища, пример записи:: /kolla_nfs 192.168.5.0/24(rw,sync,no_root_squash) #. Запустите сервис nfsd с помощью команды ``systemctl start nfs``. #. Создайте новый пайплайн: **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне добавьте параметры: * ``KOLLA_ANSIBLE_DEPLOY_ACTION`` — ``deploy``; * ``KOLLA_ARGS`` — ``-t cinder``. #. Запустите пайплайн: **Run pipeline**. #. Дождитесь завершения выполнения операции. ---------------------------------- Проверка работоспособности системы ---------------------------------- #. На LCM-узле выполните пинг на IP-адреса остальных узлов инфраструктуры — должны проходить без ошибок. #. Перейдите на каждый из развернутых сервисов по адресу, заданному в DNS: * GitLab, * Nexus (если создан новый), * Netbox. Для входа используйте реквизиты, полученные на этапе установки дистрибутива Платформы. #. Убедитесь, что в GitLab добавлены проекты и репозитории: * **deployments** — основные сервисы развертывания инфраструктуры Платформы и их конфигурация; * **services** — вспомогательные инструменты, например, Bifrost; * **ci** — пайплайны LCM-узла; * **keystack** — рекомендуемые конфигурации сервисов OpenStack. #. Убедитесь, что в Vault добавлены директории (раздел **Secrets**): * **installer** — сертификаты Платформы; * **secret_v2** — пароли и ключи для доступа к служебным компонентам Платформы. #. Скопируйте пароль для Horizon и портала администратора: #. Перейдите в веб-интерфейс развернутого Vault. #. Перейдите в директорию с настройками региона ``secret_v2/deployments/<ИМЯ_РЕГИОНА>/passwords_yml``. #. Найдите и скопируйте значение параметра ``keystone_admin_password``. #. Убедитесь, что открывается интерфейс Horizon: #. Перейдите в веб-интерфейс Horizon: ``https://<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>``. #. Войдите с помощью логина ``admin`` и скопированного пароля ``keystone_admin_password``. #. Перейдите в раздел **Вычислительные ресурсы** → **Гипервизоры**. При успешной установке в списке отобразятся подключенные гипервизоры инфраструктуры. #. Убедитесь, что открывается портал администратора: #. Перейдите в веб-интерфейс портала администратора: ``https://<ДОМЕННОЕ_ИМЯ_ВТОРОГО_УРОВНЯ>:12999``. #. Войдите с помощью логина ``admin`` и скопированного пароля ``keystone_admin_password``. При успешной установке отобразится общий дэшборд по Платформе. #. Проверьте статус мониторинга и логирования, на LCM-узле выполнив команду: ``docker ps -a | egrep 'opensearch|prometheus|fluentd|grafana'`` Все контейнеры в появившемся списке должны быть в состоянии ``Up``. Возможные ошибки и варианты их устранения ========================================= **Описание ошибки**: в GitLab нет репозиториев. **Вариант решения**: #. Перейдите в распакованный дистрибутив Платформы, директорию ``installer/repo``. #. Последовательно выполните команды:: git push -u origin --all git push -u origin --tags #. Повторно проверьте список репозиториев в 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. **Вариант решения**: #. Подождите 5-10 минут. #. Перезапустите задачу **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). Выполните шаги дополнительной конфигурации: #. Зайдите на узел Control по SSH пользователем root. #. Откройте на редактирование файл ``/etc/kolla/consul/region-config_<имя региона>.json``. #. Найдите значение поля ``"bmc": {"suffix": "-<суффикс>"}`` и добавьте к нему базовое доменное имя. Например, замените ``-rmi`` на ``-rmi.cloud.itkey.com``. #. Перезапустите сервис Consul командой ``docker restart consul``. --------------------- Обновление платформы --------------------- Перед обновлением платформы необходимо: ======================================= #. Проверить состояние сервисов на Controller-узлах. #. Проверить доступность всех узлов и сервисов на них. #. Проверить ``inventory`` на закомментированные узлы. Обновления компонентов платформы: ================================= .. tabs:: .. tab:: Онлайн #. Получите архив Платформы одним из способов поставки. #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **upgrade**. #. Создайте новый пайплайн **Build** → **Pipelines** → **Run Pipeline**. #. В открывшемся окне укажите значение параметра ``UPGRADE_URL`` — URL архива с обновлением. #. Запустите задачу **update**. #. Дождитесь завершения выполнения операции. .. tab:: Без доступа к интернету #. Получите архив Платформы одним из способов поставки. #. Зайдите на LCM-узел по SSH. #. Переместите обновление в директорию ``installer/update``. #. Откройте веб-интерфейс развернутого GitLab. #. Откройте проект **project_k** → **deployments** → **upgrade**. #. Создайте новый пайплайн **Build** → **Pipelines** → **Run Pipeline**. #. Запустите задачу **update**. #. Дождитесь завершения выполнения операции. #. Удалите содержимое каталога ``installer/update``. Обновление региона ================== #. Укажите имя целевого релиза в ``.gitlab-ci.yml`` обновляемого региона. #. Запустите пайплайн. Обновление LCM-узла =================== Для стабильной работы платформы необходимо вовремя обновлять LCM-узел, поскольку он управляет жизненным циклом виртуальных машин, контейнеров и сетевых устройств. Регулярно проводите обновления LCM-узла, чтобы синхронизировать состояние всех компонентов, избегать конфликтов версий и обеспечить стабильную работу платформы. Обновление LCM-узла осуществляется последовательно от более ранней версии к более новой. Если необходимо обновить узел на две и более версии, нужно пройти по цепочке обновлений в несколько этапов. Ниже приведены инструкции для каждого такого этапа, начиная с перехода с версии ks2024.1 на ks2024.2. Во всех случаях для обновлений будут задействованы работы на LCM-узле, в веб-интерфейсе развернутого GitLab и в Nexus. **ks2024.1** → **ks2024.2** Обновление с ks2024.1 на следующую по порядку версию гарантирует, что все новые возможности будут внедрены правильно. Данный этап можно считать обязательной частью обновления LCM-узла. #. Зайдите на LCM-узел по SSH. .. tabs:: .. tab:: SberLinux #. Загрузите архив ``upgrade-ks2024.2-sberlinux.tgz`` в папку ``/installer/update``. #. Для последующего обновления репозитория в GitLab, выполните команду:: git config --global --add safe.directory '*' #. Добавьте строки в файлы ``~/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= #. Замените в файлах строку ``export RELEASE=ks2024.1-sber`` на ``export RELEASE=ks2024.2-sberlinux``. .. tab:: Ubuntu #. Загрузите архив ``upgrade-ks2024.2-ubuntu.tgz`` в папку ``/installer/update``. #. Для последующего обновления репозитория в GitLab, выполните команду:: git config --global --add safe.directory '*' #. Добавьте строки в файлы ``~/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= #. Замените в файлах строку ``export RELEASE=ks2024.1-ubuntu`` на ``export RELEASE=ks2024.2-ubuntu``. #. Откройте веб-интерфейс развернутого GitLab. #. Найдите репозиторий **project_k** → **deployments** → **bifrost** и удалите его. Для этого перейдите в **Project settings** → **Advanced** и нажмите **Delete project**. #. Перейдите в репозиторий **project_k** → **services** → **upgrade**. #. Перейдите в раздел **Settings** → **CI/CD** → **General pipelines** и поставьте ``Timeout - 5h``. #. Запустите пайплайн **Run pipeline** по умолчанию. Дождитесь его завершения. #. Перейдите на 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" #. Дождитесь когда откроется страница ``https:///admin/background_migrations``. Дождитесь завершения всех задач на этой странице. #. Перейдите в веб-интерфейс развернутого GitLab. #. В группе ``project_k`` перейдите в раздел **Settings** → **CI/CD** → **Variables** и добавьте новые переменные:: .. tabs:: .. tab:: SberLinux * BASE: sberlinux * NEXUS_NAME: nexus .. tab:: Ubuntu * BASE: ubuntu * NEXUS_NAME: nexus #. В группах ``deployments`` и ``services`` перейдите в раздел **Settings** → **CI/CD** → **Variables** и добавьте новые переменные: * vault_secman: false #. Перейдите на 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: при переходе на более новую версию меняется база данных с настройками. #. Зайдите на LCM-узел по SSH. .. tabs:: .. tab:: SberLinux #. Загрузите архив ``upgrade-ks2024.3-sberlinux.tgz`` в папку ``/installer/update``. #. Для последующего обновления репозитория в GitLab, выполните команду:: git config --global --add safe.directory '*' #. Замените в файле ``/installer/config/settings``строку ``export RELEASE=ks2024.2-sberlinux`` на ``export RELEASE=ks2024.3-sberlinux``. #. Добавьте строки в файл ``/installer/config/settings``:: export NEXUS_FQDN=nexus.$DOMAIN export CURL_CA_BUNDLE=/installer/data/ca/cert/chain-ca.pem .. tab:: Ubuntu #. Загрузите архив ``upgrade-ks2024.3-ubuntu.tgz`` в папку ``/installer/update``. #. Для последующего обновления репозитория в GitLab, выполните команду:: git config --global --add safe.directory '*' #. Замените в файле ``/installer/config/settings`` строку ``export RELEASE=ks2024.2-ubuntu`` на ``export RELEASE=ks2024.3-ubuntu``. #. Добавьте строки в файл ``/installer/config/settings``:: export NEXUS_FQDN=nexus.$DOMAIN export CURL_CA_BUNDLE=/installer/data/ca/cert/chain-ca.pem #. Зайдите в Nexus. .. tabs:: .. tab:: SberLinux #. Удалите существующий репозиторий ``sberlinux``. #. Создайте репозитории ``docker-sberlinux`` и ``sberlinux`` с типом ``hosted`` и форматом ``yum``. #. Укажите параметры:: Repodata Depth: 0. Layout Policy: Strict. Deployment Policy: Disable redeploy .. tab:: Ubuntu #. Создайте репозитории ``docker-ubuntu`` и ``ubuntu`` с типом ``hosted`` и форматом ``apt``. #. Укажите параметры:: Distribution: ``jammy``. Signing Key: <Взять данные из настроек репозитория ubuntu22.04>. Deployment Policy: Disable redeploy #. Для проведения обновления необходимо восстановить пароли доступа Netbox. #. Перейдите на LCM-узел. #. Извлеките из архива инсталлятора файлы ``installer/netbox-docker/env/*.env``. #. Переместите эти файлы в ``/installer/data/netbox/env/`` на LCM-узле, заменив существующие. #. Перейдите в веб-интерфейс развернутого GitLab. #. Найдите репозиторий **project_k** → **deployments** → **bifrost** и удалите его. Для этого перейдите в **Project settings** → **Advanced** и нажмите **Delete project**. #. Перейдите в репозиторий **project_k** → **services** → **upgrade**. #. Перейдите в раздел **Settings** → **CI/CD** → **General pipelines** и поставьте ``Timeout - 5h``. #. Запустите новый пайплайн **Run pipeline** по умолчанию. Дождитесь его завершения. #. Перейдите на 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" .. tabs:: .. tab:: SberLinux :: 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" .. tab:: Ubuntu :: docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "cat /vault/config/chain-ca.pem >> /etc/ssl/certs/ca-certificates.crt" :: 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 - </admin/background_migrations``. Дождитесь завершения всех задач на этой странице. #. Обновление Nexus: Обновление Nexus с ``ks2024.х`` на ``ks2024.3`` и позднее невозможно сделать напрямую, поскольку меняется база данных с настройками: https://help.sonatype.com/en/migrating-to-a-new-database.html . #. Запустите контейнер 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 #. Сделайте резервную копию базы данных Nexus штатными средствами в папку внутри контейнера ``/nexus-data/backup-db``. #. Перейдите в раздел **System** → **Tasks**. #. Запустите готовую задачу **Admin - Export databases for backup**. #. Дождитесь выполнения задачи. Статус задачи должен смениться с **Running** на **Waiting**, а **Last Result** на **OK**. .. .. figure:: media/Nexus_DB_backup.png :alt: Резервное копирование базы данных Nexus #. Выполните следующие команды для конвертации базы данных 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 #. Перейдите в веб-интерфейс развернутого GitLab. #. В группе ``project_k`` перейдите в раздел **Settings** → **CI/CD** → **Variables**. Добавьте новые переменные: * NEXUS_USER: admin * NEXUS_FQDN: nexus.$DOMAIN #. (Опционально) В группах ``deployments`` и ``services`` перейдите в раздел **Settings** → **CI/CD** → **Variables** и переместите все переменные в группу ``project_k``. #. Перейдите на 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-узла. #. Зайдите на LCM-узел по SSH. .. tabs:: .. tab:: SberLinux #. Загрузите архив ``upgrade-ks2024.4-sberlinux.tgz`` в папку ``/installer/update``. #. Для последующего обновления репозитория в GitLab, выполните команду:: git config --global --add safe.directory '*' #. Замените в файлах ``~/installer/settings`` и ``/installer/settings`` строку ``export RELEASE=ks2024.3-sberlinux`` на ``export RELEASE=ks2024.4-sberlinux``. .. tab:: Ubuntu #. Загрузите архив ``upgrade-ks2024.4-ubuntu.tgz`` в папку ``/installer/update``. #. Для последующего обновления репозитория в GitLab, выполните команду:: git config --global --add safe.directory '*' #. Замените в файлах ``~/installer/settings`` и ``/installer/settings`` строку ``export RELEASE=ks2024.3-ubuntu`` на ``export RELEASE=ks2024.4-ubuntu``. #. Откройте веб-интерфейс развернутого GitLab. #. Найдите репозиторий **project_k** → **deployments** → **bifrost** и удалите его. Для этого перейдите в **Project settings** → **Advanced** и нажмите **Delete project**. #. Перейдите в репозиторий **project_k** → **services** → **upgrade**. #. Перейдите в раздел **Settings** → **CI/CD** → **General pipelines** и поставьте ``Timeout - 5h``. #. Запустите пайплайн **Run pipeline** по умолчанию. Дождитесь его завершения. #. Для проведения обновления необходимо восстановить пароли доступа Netbox. #. Перейдите на LCM-узел. #. Извлеките из архива инсталлятора файлы ``installer/netbox-docker/env/*.env``. #. Переместите эти файлы в ``/installer/data/netbox/env/`` на LCM-узле, заменив существующие. #. Перейдите на 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" .. tabs:: .. tab:: SberLinux :: 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" .. tab:: Ubuntu :: docker compose -f $CFG_HOME/compose.yaml exec vault /bin/sh -c "cat /vault/config/chain-ca.pem >> /etc/ssl/certs/ca-certificates.crt" :: 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" #. Перейдите на 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** . Выполните шаги из инструкций, приведенных выше, по порядку. Неправильный порядок или пропуск какого-либо шага может привести к ошибкам, потерям данных или сбоям в работе платформы. Проверка работоспособности после обновления: ============================================ #. Проверить версии контейнеров. #. Проверить состояние Controller-узлов. #. Проверить состояние сервисов ``compute service list``. #. Проверить состояние сетевых агентов ``network agent list``. #. Проверить состояние службы томов ``volume service list``. #. Проверить состояние виртуальных машин ``server list``. #. Проверить лог на наличие ошибок. #. Создать несколько виртуальных машин с различными флейворами. #. Провести live-миграцию виртуальных машин.