Инструкция по инсталляции облачной платформы

Подготовка

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

  1. Узел Infrastructure (он же LCM — Life Cycle Manager) — предназначен для управления жизненным циклом облака;

  2. Узлы Control Plane (контроллеры) — предназначены для выполнения служебных задач по управлению облаком;

  3. Узлы Compute (гипервизоры) — предназначены для размещения рабочих нагрузок в виде виртуальных машин;

  4. Узлы Network (сетевые) — предназначены для размещения компонентов програмно-определяемых сетей.

Процесс развертывания облака состоит из следующих шагов:

  1. Запуск установки (инсталлятора), который установит на сервер LCM необходимые компоненты и сервисы для дальнейшей работы с облаком.

  2. Выполнение сценариев (пайплайнов) системы управления облаком (CI/CD) для задач настройки/конфигурирования облака.

Технические требования

На аппаратных серверах должны быть установлены 64-битные процессоры x86/AMD64 с поддержкой расширения виртуализации аппаратуры — например, Intel VT-x (Virtualization Technology) или AMD-V (AMD Virtualization).

Seed node

Узел Seed предназначен для хранения кода, конфигураций окружений и управления конфигурациями (обновление компонентов, добавление новых и т.д.), а также для установки и настройки операционных систем серверов, которые будут вводиться в эксплуатацию (добавление новых узлов Compute, Controller и т.д.) На сервере с данной ролью размещаются следующие компоненты:

  • GitLab;

  • Nexus;

  • Vault;

  • Netbox.

Требуется базовый сервер Ubuntu 20.04 со следующей конфигурацией:

  • Ядро версии 5.15.0-76 или выше;

  • 24 ГБ оперативной памяти;

  • 4 процессора;

  • 100 ГБ HDD.

Дополнительно:

  • Нет серверов DHCP или TFTP ни в одной сетевой карте.

  • Сеть IPMI с маршрутизируемым доступом для аппаратных серверов.

  • Доступ в Интернет для скачивания всех необходимых артефактов.

Controller

На узле Controller (контроллере) запускается служба идентификации, служба образов, управляющие модули вычислительных ресурсов, управляющие модули сетевых агентов, различные сетевые агенты и панель управления. Также данный узел включает вспомогательные службы, такие как база данных SQL, брокер сообщений и балансировщик нагрузки.

Минимальная конфигурация состоит из трех контроллеров, которые могут совмещать еще и роли сетевых узлов. Требуется базовый сервер Ubuntu 20.04 со следующей конфигурацией:

  • Ядро версии 5.15.0-76 или выше;

  • 256 ГБ оперативной памяти;

  • 2x8 core CPU;

  • 2x512+ GB SSD (RAID 1);

  • 2x10 Gb NIC (лучше 2x 2x10 Gb NIC, если на сервер с ролью Controller совмещает Network).

Compute

На узле Compute (вычислительном узле) работает гипервизорная часть, которая управляет виртуальными машинами. По умолчанию в качестве гипервизора используется KVM. Также на вычислительных узлах размещен агент сетевой службы, который подключает виртуальные машины к виртуальным сетям.

Минимальное рекомендуемое количество вычислительных узлов — 2. Требуется базовый сервер Ubuntu 20.04 со следующей конфигурацией:

  • Ядро версии 5.15.0-76 или выше;

  • 256 ГБ оперативной памяти;

  • 2x12 core CPU;

  • 2x256+ GB SSD (RAID 1);

  • 2x10 Gb NIC (Лучше 2x 2x10 Gb NIC).

Storage

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

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

В качестве хранилища могут быть использованы как программные решения (например, Ceph), так и аппаратные. Подойдут любые СХД из списка поддерживаемых: https://docs.openstack.org/cinder/zed/reference/support-matrix.html#operation_supported.

Развертывание сервера LCM

Инсталлятор разворачивает Облачную платформу на заранее подготовленной инфраструктуре (ВМ или физических серверах).

Требования

Требования, предъявляемые к узлу LCM (он же — узел Seed), одновременно являются требованиями к узлу, на котором возможно проведение процесса разработки и доработки компонентов облачной платформы, поскольку разработка производится при помощи встроенной в Gitlab среды разработки.

Поддерживаемые базовые ОС LCM

Установка облачной платформы возможна с использованием нижеперечисленных дистрибутивов Linux.

Для хоста:

  • Ubuntu 22.04 LTS

  • SberLinux 9.2 (Gestola)

Для LCM:

  • Ubuntu 22.04.3 LTS

  • SberLinux 9.2 (Gestola)

Требования к пакетам

Для корректной работы облачной платформы необходимы пакеты:

  • docker

  • docker compose

  • git версии старше 2.28.0

  • openssl, curl, tar, jq

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

Для установки и коректной работы LCM требуется наличие сетевой связности между сервером LCM и хостами контроллеров и гипервизоров:

  • C узла LCM должен быть доступ до IPMI всех серверов, до mgmt-интерфейсов и до VIP-адресов облака.

  • Со всех хостов должен быть доступен dhcp-сервер на узле LCM в сети PXE.

  • Создан пользователь в BMC серверов с правами administrator и включена опция Enable IPMI Over LAN. Включен Redfish.

Также для облачной инфраструктуры требуется выделить DNS-зону, в котором необходимо создать записи для следующих сервисов LCM:

  • <GITLAB_NAME>.<root domain> — система управления жизненным циклом облака (CI);

  • <NEXUS_NAME>.<root domain> — репозиторий пакетов, контейнеров и других артефактов облака;

  • <VAULT_NAME>.<root domain> — хранилище паролей и сертификатов;

  • <NETBOX_NAME>.<root domain> — хранилище настроек для сервиса Baremetal.

Для сервисов LCM можно выбрать свои доменные имена. По умочанию используются:

  • <GITLAB_NAME> - ks-lcm

  • <NEXUS_NAME> - nexus

  • <VAULT_NAME> - vault

  • <NETBOX_NAME> - netbox

Доменное имя необходимо использовать второго уровня для генерации Wildcard-сертификата для сервисов LCM, например, demo.local.

Возможность разрешения данных имён в IP-адрес сервера LCM является обязательным, поскольку при установке облачной платформы используются сертификаты безопасности, связанные с указанными выше именами. Установка допускает использование разрешения имён либо через сервис DNS, либо через записи в файлах /etc/hosts. Пример записи в /etc/hosts:

<ip адрес LCM> <GITLAB_NAME>.<root domain> <VAULT_NAME>.<root domain> <NEXUS_NAME>.<root domain> <NETBOX_NAME>.<root domain>

Для узлов Compute необходимо создать записи вида:

- 10.10.1.1  <имя сервера>-rmi.<root domain>

Эти записи предназначены для разрешения IP-адреса BMC сервера в имя вида <имя сервера>-rmi.<root domain>. Их нужно изменить на реальные адреса интерфейсов BMC узлов Compute.

Установка LCM

Процесс установки в автоматическом режиме производит развертывание и конфигурирование следующих компонентов на сервере LCM:

  • Пароля системы автоматизации (Gitlab);

  • Генерацию SSH-ключей для беспарольного доступа на сервера;

  • Сертификатов для служб LCM;

  • Репозитория пакетов, контейнеров, артефактов Sonatype Nexus;

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

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

  • Документирования сетей и девайсов Netbox (CMDB).

Все действия выполняются от имени пользователя root.

Ссылка на архив с инсталлятором:

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

tar -xf <path>/installer-ks2024.1.2-<system>-offline.tar.gz -C ~/

Вместо <path> нужно указать путь до директории со скачанным архивом инсталлятора.

Запуск процесса установки облачной платформы осуществляется запуском команды ./installer.sh из директории инсталлятора (необходимо наличие прав root или запуск команды при помощи sudo).

root@lcm:~/installer# ./installer.sh
*** KeyStack Installer v1.0 (ks2024.1.2-<system>) ***
Enter the home dir for the installation [/installer]:
Enter the IP address of this machine [10.220.107.179]:
Use remote\existing Artifactory y/n [n]: y
Enter the remote\existing Artifactory FQDN for the KeyStack: nexus.demo.local
Enter the remote\existing Artifactory user name: admin
Enter the remote\existing Artifactory password: password
Enter the LCM root domain for the KeyStack [demo.local]: test.loc
Enter the LCM Nexus domain name for the KeyStack [nexus]: art
Enter the LCM Gitlab domain name for the KeyStack [ks-lcm]: git
Enter the LCM Vault domain name for the KeyStack [vault]: sec
Enter the LCM Netbox domain name for the KeyStack [netbox]: cmdb
Generate Self-signed certificates for KeyStack LCM services y/n [y]: n

  • Use remote\existing Artifactory y/n [n]: - для использования клиентского хранилища для Docker-образов поставить y

  • Enter the remote\existing Artifactory FQDN for the KeyStack: - при использовании клиентского Nexus написать FQDN клиентского Nexus, не должно совпадать с FQDN для сервиса Nexus в составе инсталлятора

  • Enter the remote\existing Artifactory user name: - при использовании клиентского Nexus написать имя пользователя с правами pull и push в докер-хранилище

  • Enter the remote\existing Artifactory password: - при использовании клиентского Nexus написать пароль для пользователя с правами pull и push в докер-хранилище

  • Enter the LCM root domain for the KeyStack: - корневой домен для сервисов KeyStack

  • Enter the LCM Nexus domain name for the KeyStack [nexus]: - доменое имя сервиса Nexus

  • Enter the LCM Gitlab domain name for the KeyStack [ks-lcm]: - доменое имя сервиса Gitlab

  • Enter the LCM Vault domain name for the KeyStack [vault]: - доменое имя сервиса Vault

  • Enter the LCM Netbox domain name for the KeyStack [netbox]: - доменое имя сервиса Netbox

  • Generate Self-signed certificates for KeyStack LCM services y/n [y]: - по умолчанию использовать самоподписанные сертификаты, созданные инсталлятором. Если нужно использовать сертификаты клиента, поставить n

Домен для сервисов KeyStack должен быть второго уровня.

Использование клиентского Nexus

При использовании клиентского Nexus нужно предоставить полную цепочку сертификатов для него с именем <FQDN>.pem, например nexus.demo.local.pem и положить его в папку installer/certs.

FQDN клиентского Nexus, не должно совпадать с FQDN для сервиса Nexus в составе инсталлятора.

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

Использование сертификатов клиента.

При использовании сертификатов клиента для сервисов Keystack:

  • создать файл ca.crt, который содежит root CA сертификат

  • создать файл chain-ca.pem, который содержит цепочку CA сертификатов

  • создать файлы <NEXUS_NAME>.crt и <NEXUS_NAME>.key, который содержат сертификат и приватный ключ сертификата для сервиса Nexus

  • создать файлы <GITLAB_NAME>.crt и <GITLAB_NAME>.key, который содержат сертификат и приватный ключ сертификата для сервиса

  • создать файлы <VAULT_NAME>.crt и <VAULT_NAME>.key, который содержат сертификат и приватный ключ сертификата для сервиса

  • создать файлы <NETBOX_NAME>.crt и <NETBOX_NAME>.key, который содержат сертификат и приватный ключ сертификата для сервиса

Возможные ошибки при развёртывании LCM

Отсутствие каких-либо репозиториев в Gitlab

Если это пустой репозиторий в Gitlab, значит, при git push могла произойти внутренняя ошибка сервиса Gitlab. В этом случае нужно перейти в каталог, где лежат все репозитории /installer/repo, зайти в каталог репозитория, где произошла ошибка, и выполнить команды:

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

После этого нужно убедиться, что данные репозитория появились в Gitlab.

Развертывание облачной платформы

Требования

Требования к базовой ОС узлов

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

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

Предварительная конфигурация

После успешной установки на экране отобразится сообщение с текущей конфигурацией облачной платформы. Пример такой конфигурации приведён на рисунке ниже:

../_images/image_1.png

Рисунок 1 — Пример сообщения с текущей конфигурацией об инсталляции

Attention

Необходимо сохранить данные с текущей конфигурацией об инсталляции!

Для обеспечения корректной работы браузеров с компонентами облачной платформы требуется добавить Root CA (корневой) сертификат в Доверенные корневые центры сертификации системы пользователя.

После выполнения этих шагов требуется перейти по адресу CI/CD системы https://<GITLAB_NAME>.<root domain> и использовать пароль GitLab root, полученный из сообщения с текущей конфигурацией. В интерфейсе CI/CD системы будет доступно несколько репозиториев. Пример интерфейса приведён на рисунке ниже.

../_images/image_2.png

Рисунок 2 — Репозитории в Gitlab

Пароли и сертификаты Облачной платформы

Все пароли и сертификаты для облака хранятся в сервисе Vault по адресу: https://<VAULT_NAME>.<root domain>.

../_images/image_3.png

Рисунок 3 — Интерфейс хранилища секретов

Все сертификаты автоматически генерируются при инсталляции сервера LCM с помощью программы openssl.

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

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

  • Инсталлятор активирует в Vault хранилище pki с именем installer для хранения сертификатов и создает в этом хранилище Центр сертификации на основе центра сертификации Root CA. Также он создает роль, которая может выписывать сертификаты на основе запросов пользователей. Срок действия — 2 года.

Сервис по наливке Baremetal серверов

Установка и настройка Bifrost

Зайти в Gitlab, перейти в репозиторий project_k → deployments → gen-pwd. Перейти в Build → Pipelines → Run Pipeline. Внести в поле “OPENSTACK_ENV” значение bifrost, как на рисунке ниже, и запустить пайплайн с помощью кнопки “Run Pipeline”.

../_images/image_6.png

Рисунок 4 — Запуск пайплайн-генерации секретов для bifrost

Запустить задачу create-config, как на рисунке ниже.

../_images/image_7.png

Рисунок 5 — Запуск задачи генерации секретов для bifrost

Дождаться окончания работы пайплайна.

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

Ubuntu 22.04 LTS

Открыть на редактирование файл inventory:

  • Заменить LCM_IP на IP-адрес LCM-узла.

Открыть на редактирование файл globals.d/REGION.yml:

  • Заменить eth0 на имя интерфейса на LCM-узле.

Для добавления своего NTP-сервера открыть на редактирование файл config/bifrost/bifrost.yml.

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

SberLinux 9.2

Открыть на редактирование файл inventory:

  • Заменить LCM_IP на IP-адрес LCM-узла.

Открыть на редактирование файл globals.d/REGION.yml:

  • Заменить eth0 на имя интерфейса на LCM-узле.

Открыть на редактирование файл config/bifrost/bifrost.yml:

  • Заменить значения в dhcp_pool_start, dhcp_pool_end, dhcp_pool_mask, dnsmasq_router на значения сети для PXE.

Для добавления своего NTP-сервера открыть на редактирование файл config/bifrost/bifrost.yml:

  • Раскомментировать строку #dnsmasq_ntp_servers: и заменить 10.224.128.1 на IP-адрес своего NTP-сервера;

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

Перейти в Build → Pipelines → Run Pipeline и запустить пайплайн с помощью кнопки “Run Pipeline”.

../_images/image_8.png

Рисунок 6 — Запуск задачи установки bifrost

Дождаться окончания работы задачи setup, запустить задачу deploy-bifrost и дождаться окончания ее работы.

Ubuntu 22.04 LTS

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

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

Поменять значения:

  • listen-address=<IP-адрес LCM-узла>

  • dhcp-boot=tag:ipxe,http://<IP-адрес LCM-узла>:8080/boot.ipxe

Диапазон адресов DHCP для выдачи IP серверам:

  • dhcp-range=10.0.0.10,10.0.0.100,255.255.255.0,24h

Маршрут для IP-адресов, выданных по DHCP:

  • dhcp-option=3,10.0.0.254

Для добавления своего NTP-сервера добавить строку c IP-адресом NTP-сервера:

  • dhcp-option=42,10.224.128.1

Сохранить изменения и выйти.

Перезапустить сервис dnsmasq:

(bifrost-deploy)# systemctl restart dnsmasq

Изменение пользователя и пароля для IPMI серверов гипервизора

Перейти в secret_v2/deployments/bifrost/rmi, где bifrost — название репозитория с настройками сервиса bifrost. Затем поменять пароль в поле “password” на пароль от интерфейса IPMI BMC-серверов, и пользователя в поле “user” на пользователя интерфейса IPMI BMC-серверов.

../_images/image_5.png

Рисунок 7 — Изменение пароля IPMI в хранилище секретов для сервиса Baremetal

На всех серверах в BMC нужно создать одинакового пользователя с именем и паролем, который должен быть записан в Vault. Это необходимо для работы сервиса автоэвакуации ВМ при сбое гипервизора и для сервиса Baremetal.

Развертывание серверов с помощью сервиса Baremetal

Настройка Netbox

До начала работ по наливке серверов необходимо заполнить данные в Netbox.

Наливка серверов

Перейти в Gitlab в репозиторий project_k → services → baremetal.

Перейти в Build → Pipelines → Run Pipeline.

../_images/image_9.png

Рисунок 8 — Запуск пайплайна развертывания серверов

Заполнить переменные для пайплана:

  • TARGET_ROLE — роль для серверов, определенная в Netbox. Для контроллеров — controller, для узлов Network — network, для узлов Compute — compute.

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

  • TARGET_NODE — имя конкретного узла для деплоя только одного узла.

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

  • IRONIC_SSH_KEY — можно добавить свои ключи SSH на узел (формат — один ключ на строку).

  • IRONIC_IMAGE_URL — путь до образа системы Linux, который будет установлен на узел. Образ должен быть в формате qcow2. Тамже рядом с образом должен лежать файл с md5 хэш образа, формат имени {имя-образа}.md5. Для Sberlinux 9.2 указать путь http://$LCM_IP:8080/sberlinux-9.2-x86_64.qcow2.

  • IRONIC_IMAGE_ROOTFS_UUID — для установки системы на софт-рейд нужно указать UUID рутового раздела в образе. Для своих образов можно узнать из https://docs.openstack.org/ironic/latest/admin/raid.html#image-requirements

  • IPA_KERNEL_NAME — путь до IPA kernel image.

  • IPA_RAMDISK_NAME — путь до IPA initramfs image.

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

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

  • CI_DEBUG_TRACE — для выведения отладочной информации в пайплайне поставить значение true.

После заполнения данных нажать кнопку “Run Pipeline”. Запустится пайплан для деплоя серверов, необходимо дождаться окончания работы.

../_images/image_10.png

Рисунок 9 — Пайплайн развертывания серверов

Развертывание облака

Развертывание облачной платформы

Необходимо зайти в Gitlab, перейти в репозиторий project_k → deployments → region1. Здесь находятся демонстрационные настройки для региона region1.

Для создания нового региона нужно сделать форк данного репозитория и назвать его по имени нового региона.

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

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

  • Также можно использовать дефисы, но их нельзя использовать в начале и конце имени региона. Два дефиса вместе не допускаются.

  • Пробелы и специальные символы (например, !, $, &, _ и т. д.) не допускаются.

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

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

Зайти в репозиторий нового региона, перейти в Settings → General → Advanced и нажать кнопку “Remove fork relationship”.

Дальнейшее описание касается демонстрационного региона region1.

Файлы конфигурации облачной платформы

Зайти в Gitlab, перейти в репозиторий project_k → deployments → region1.

Ubuntu 22.04 LTS

Открыть на редактирование файл inventory и заполнить его своими данными:

  • заполнить группы [control], [network], [compute] данными по образцу.

Открыть на редактирование файл globals.d/REGION.yml и заполнить его своими данными:

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

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

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

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

Открыть на редактирование файл globals.d/octavia.yml и заполнить его своими данными:

  • octavia_amp_network_cidr — блок IP-адресов для amphora сервиса Octavia Openstack.

Открыть на редактирование файл tf_states/settings.tf и заполнить его своими данными.
В блоке variable "pub_net":

  • cidr — блок IP-адресов для FIP;

  • allocation_start — начало блока IP-адресов для FIP;

  • allocation_end — конец блока IP-адресов для FIP;

  • dns — ДНС-сервера для FIP.

В блоке resource "openstack_compute_aggregate_v2" "dev_region":

  • hosts — имена серверов гипервизоров.

SberLinux 9.2

Применить настройки из предыдущего пункта.

Запуск задачи с предварительной настройкой региона

В этой задаче будут сгенерированны пароли и сертификаты для региона.

Необходимо зайти в Gitlab и перейти в репозиторий project_k → deployments → gen-pwd.
Затем перейти в Build → Pipelines → Run Pipeline.
Заполнить переменные для пайплана, как на рисунке ниже:

  • OPENSTACK_ENV — имя региона и репозитория в Gitlab с настройками региона.

../_images/image_11.png

Рисунок 10 — Запуск пайплайна генерации секретов для region1

После заполнения данных нажать кнопку “Run Pipeline”.

Запустить задачу create-config, как на рисунке ниже.

../_images/image_7.png

Рисунок 11 — Запуск задачи генерации секретов для region1

Дождаться окончания работы пайплайна.

Изменение пароля для IPMI серверов гипервизора

Нужно зайти в Vault и перейти в secret_v2/deployments/region1/passwords_yml, где region1 — название репозитория с настройками региона. Затем поменять пароль в поле “bmc_password” на пароль от интерфейса IPMI BMC серверов гипервизора.

../_images/image_4.png

Рисунок 12 — Изменение пароля IPMI в хранилище секретов региона.

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

Запуск задачи по развертыванию региона

Перейти в репозиторий project_k → deployments → region1.
Перейти в Build → Pipelines → Run Pipeline.
Заполнить переменные для пайплана, как на рисунке ниже:

  • KOLLA_ARGS — переменная для передачи дополнительных тегов:

    • –limit host1 — выполнение скрипта для отдельного узла Openstack;

    • –tags cinder — выполнение скрипта для отдельного компонента.

  • KOLLA_ANSIBLE_DEPLOY_ACTION — список задач для kolla-ansible;

  • KOLLA_ANSIBLE_IMG_TAG — переменная для версии образа с kolla-ansible, скачиваемого из репозитория Nexus;

  • KEYSTACK_RELEASE — переменная, в которой указывается ветка git шаблона конфигурации в репозитории project_k → keystack.

../_images/image_12.png

Рисунок 13 — Запуск пайплайна развертывания облака для region1.

После заполнения данных нажать кнопку “Run Pipeline”.

../_images/image_13.png

Рисунок 14 — Задачи пайплайна развертывания облака для region1.

Задачи в пайплайне развертывания облака:

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

  • bootstrap-servers — подготовка узлов для загрузки конфигурации (установка необходимых пакетов и конфигурирование компонентов ОС);

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

  • postconfig — применение квот развернутого облака;

  • states — наполнение развернутого облака демо-конфигурацией;

  • rally — валидация компонентов облака;

  • tempest — тестирование развернутого облака на соответствие конфигурации;

  • backup-db — бэкап БД MariaDB развернутого облака.

Дождаться окончания работы задачи setup.

Запустить задачу bootstrap-servers, дождаться окончания работы задачи.

Запустить задачу deploy, дождаться окончания работы задачи.

Получение openrc из Vault

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

# docker exec -ti vault vault read secret_v2/data/deployments/region1/openrc -format=json | jq -r '.data.data.value' > openrc-region1
Где region1 — название региона и репозитория в Gitlab в группе project_k → deployments.
В конец файла добавить строку:
export OS_CACERT=/installer/data/ca/cert/chain-ca.pem

По аналогии сделать для остальных регионов.

Transport Level Security (TLS)

LCM TLS

../_images/image_lcm.png

Рисунок 16 — Схема компонентов LCM

При установке компонентов на сервере LCM генерируются самоподписанные сертификаты для каждого компонента <NEXUS_NAME> <GITLAB_NAME> <VAULT_NAME> <NETBOX_NAME> с SAN=DNS:<COMPONENT_NAME>.<root domain>.

Компонент Nginx выполняет SSL-терминацию к остальным компонентам.

Openstack TLS

Включение TLS на внутреннем и/или внешнем VIP-адресе позволяет клиентам OpenStack аутентифицировать и шифровать сетевое соединение со службами OpenStack.

Существует два разных уровня конфигурации TLS для API OpenStack:

  1. Включение TLS на внутреннем и/или внешнем VIP, чтобы связь между клиентом OpenStack и HAProxy, прослушивающим VIP, была безопасной.

  2. Включение TLS во внутренней сети для обеспечения безопасности связи между HAProxy и серверными службами API.

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

kolla_enable_tls_external: "yes"
kolla_enable_tls_internal: "yes"
kolla_enable_tls_backend: "no"
rabbitmq_enable_tls: "no"
libvirt_tls: "no"
nova_qemu_vnc_tls: "no"

В настройках по умолчанию включен TLS на внутреннем и/или внешнем VIP. Для внутреннего и внешнего VIP используется один сертификат.

Разные сертификаты для внутреннего и внешнего VIP

  1. Раскомментировать строку # kolla_internal_fqdn_cert: "/etc/kolla/haproxy-internal.pem" в файле globals.d/REGION.yml в репозитории региона.

  2. Перейти в репозиторий project_k/deployments/gen-pwd и запустить новый пайплайн, где указать значение имени региона для OPENSTACK_ENV.

  3. Перейти в репозиторий региона и запустить новый пайплайн с значениями по умолчанию, затем запустить задачу deploy и дождаться окончания ее работы.

Включение TLS во внутренней сети

  1. Установить значение yes для kolla_enable_tls_backendв файле globals.d/REGION.yml в репозитории региона.

  2. Перейти в репозиторий project_k/deployments/gen-pwd и запустить новый пайплайн, где указать значение имени региона для OPENSTACK_ENV.

  3. Перейти в репозиторий региона и запустить новый пайплайн с значениями по умолчанию, далее запустить задачу deploy и дождаться окончания ее работы.

Включение TLS для RabbitMQ

  1. Установить значение yes для rabbitmq_enable_tls в файле globals.d/REGION.yml в репозитории региона.

  2. Перейти в репозиторий project_k/deployments/gen-pwd и запустить новый пайплайн, где указать значение имени региона для OPENSTACK_ENV.

  3. Перейти в репозиторий региона и запустить новый пайплайн с значениями по умолчанию, затем запустить задачу deploy и дождаться окончания ее работы.

Включение TLS для Libvirt

В менее доверенной среде может потребоваться использовать шифрование при доступе к API Libvirt. Для этого нужно включить TLS для Libvirt и заставить Nova использовать его. Настроен Mutual TLS, обеспечивающий аутентификацию клиентов посредством сертификатов.

  1. Установить значение yes для libvirt_tls в файле globals.d/REGION.yml в репозитории региона.

  2. Перейти в репозиторий project_k/deployments/gen-pwd и запустить новый пайплайн, где указать значение имени региона для OPENSTACK_ENV.

  3. Перейти в репозиторий региона и запустить новый пайплайн с значениями по умолчанию, запустить задачу deploy, дождаться окончания ее работы.

Включение TLS для NoVNC

При использовании HTTPS шифрование TLS применяется только к данным между клиентом OpenStack и прокси-сервером. Данные между прокси-сервером и Libvirt вычислительного узла по-прежнему не будут зашифрованы. Чтобы обеспечить защиту последних, необходимо включить схему аутентификации VeNCrypt для VNC как на вычислительных узлах, так и на узлах прокси-серверов noVNC.

  1. Установить значение yes для nova_qemu_vnc_tls в файле globals.d/REGION.yml в репозитории региона.

  2. Перейти в репозиторий project_k/deployments/gen-pwd и запустить новый пайплайн, где указать значение имени региона для OPENSTACK_ENV.

  3. Перейти в репозиторий региона и запустить новый пайплайн с значением KOLLA_ARGS:-t nova, запустить задачу deploy, дождаться окончания ее работы.

Использование своих сертификатов

LCM TLS

Во время разворачивания Облачной платформы создаются сертификаты для компонентов LCM.

  1. Корневой центр сертификации: Root CA сертификат и приватный ключ

  • /installer/data/ca/root/ca.crt

  • /installer/data/ca/root/ca.key

  1. Сертификат и приватный ключ для каждого компонента <NEXUS_NAME> <GITLAB_NAME> <VAULT_NAME> <NETBOX_NAME>

  • /installer/data/ca/cert/<COMPONENT_NAME>.crt

  • /installer/data/ca/cert/<COMPONENT_NAME>.key

  1. Pem-файл с цепочкой сертификатов для каждого компонента <NEXUS_NAME> <GITLAB_NAME> <VAULT_NAME> <NETBOX_NAME>

  • /installer/data/ca/cert/chain-<COMPONENT_NAME>.pem

  1. Pem-файл с цепочкой сертификатов Root CA

  • /installer/data/ca/cert/chain-ca.pem

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

Также эти сертификаты копируются в следующие места:

  1. /installer/data/ca/root/ca.crt

  • /etc/pki/ca-trust/source/anchors/ca.crt — для SberLinux, после копирования выполнить команду update-ca-trust

  • /usr/local/share/ca-certificates/ca.crt — для Ubuntu, после копирования выполнить команду update-ca-certificates

  1. /installer/data/ca/cert/chain-ca.pem

  • /etc/docker/certs.d/<NEXUS_NAME>.<root domain>/ca.crt

  • В Vault secrets/secret_v2/deployments/secrets/ca.crt

  • /installer/data/vault/config/chain-ca.pem — для Ubuntu, после копирования выполнить команду docker exec vault /bin/sh -c "cat /vault/config/chain-ca.pem >> /etc/ssl/certs/ca-certificates.crt" — для SberLinux, после копирования выполнить команду docker exec vault /bin/sh -c "cat /vault/config/chain-ca.pem >> /etc/pki/ca-trust/source/anchors/ca.crt; update-ca-trust"

  1. /installer/data/ca/cert/chain-<GITLAB_NAME>.pem

  • /installer/data/gitlab-runner/certs/<GITLAB_NAME>.<root domain>.crt

  1. /installer/data/ca/cert/chain-<COMPONENT_NAME>.pem

  • /installer/data/nginx/<COMPONENT_NAME>.pem

  1. /installer/data/ca/cert/<COMPONENT_NAME>.key

  • /installer/data/nginx/<COMPONENT_NAME>.key

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

docker restart gitlab nginx

Openstack TLS

В зависимости от настроек региона, указанных в файле globals.d/REGION.yml в репозитории региона, для него генерируется несколько сертификатов.

Сертификат CA с любыми промежуточными сертификатами складывается в репозиторий региона по пути <region>/certificates/ca/ca-bundle.crt.

Сертификаты CA для Octavia складываются в репозиторий региона по путям <region>/config/octavia/client_ca.cert.pem и <region>/config/octavia/server_ca.cert.pem.

Все сертификаты региона складываются в Vault по адресу secrets/secret_v2/deployments/<region>/ssl_certificates.

  1. По умолчанию:

  • haproxy_pem

  • octavia_client

  • octavia_server

  1. Разные сертификаты для внутреннего и внешнего VIP:

  • haproxy_internal_pem

  1. Включение TLS во внутренней сети. Включение TLS для RabbitMQ:

  • backend_key_pem

  • backend_pem

  1. Включение TLS для Libvirt. Включение TLS для NoVNC:

  • libvirt_cacert

  • libvirt_cert

  • libvirt_key

../_images/image_openstack_tls.png

Рисунок 17 — Сертификаты региона Openstack в Vault

Формат сертификатов

Для всех сертификатов используется формат PEM. Может содержать один или несколько сертификатов, закрытый ключ или же сертификат(ы) и закрытый ключ одновременно. В этом случае каждый из них обрамляется обязательными строками BEGIN и END. Кроме расширения .pem, для ключа могут также использоваться расширения .crt и .key.

  • <region>/certificates/ca/ca-bundle.crt — содержит цепочку CA сертификатов:

-----BEGIN CERTIFICATE-----
Содержимое промежуточного сертификата Base64 ASCII
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Содержимое CA сертификата Base64 ASCII
-----END CERTIFICATE-----

  • <region>/config/octavia/server_ca.cert.pem — содержит CA сертификат сервера для Остаvia:

-----BEGIN CERTIFICATE-----
Содержимое CA сертификата Base64 ASCII
-----END CERTIFICATE-----

  • <region>/config/octavia/client_ca.cert.pem — содержит CA сертификат клиента для Остаvia:

-----BEGIN CERTIFICATE-----
Содержимое CA сертификата Base64 ASCII
-----END CERTIFICATE-----

  • octavia_server — содержит приватный ключ сервера для Остаvia:

-----BEGIN ENCRYPTED PRIVATE KEY-----
Содержимое приватного ключа CA сертификата Base64 ASCII
-----END ENCRYPTED PRIVATE KEY-----

  • octavia_client — содержит сертификат и приватный ключ клиента для Остаvia:

-----BEGIN CERTIFICATE-----
Содержимое сертификата клиента Base64 ASCII
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
Содержимое приватного ключа сертификата клиента Base64 ASCII
-----END PRIVATE KEY-----

  • haproxy_pem, haproxy_internal_pem — содержит сертификат и приватный ключ для внутреннего и внешнего VIP:

-----BEGIN CERTIFICATE-----
Содержимое сертификата клиента Base64 ASCII
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
Содержимое приватного ключа сертификата клиента Base64 ASCII
-----END RSA PRIVATE KEY-----

  • backend_pem — содержит сертификат для внутренней сети и RabbitMQ:

-----BEGIN CERTIFICATE-----
Содержимое сертификата клиента Base64 ASCII
-----END CERTIFICATE-----

  • backend_key_pem — содержит приватный ключ внутренней сети и RabbitMQ:

-----BEGIN RSA PRIVATE KEY-----
Содержимое приватного ключа сертификата клиента Base64 ASCII
-----END RSA PRIVATE KEY-----

  • libvirt_cacert — содержит CA сертификат сервера и клиента для Libvirt и noVNC:

-----BEGIN CERTIFICATE-----
Содержимое CA сертификата Base64 ASCII
-----END CERTIFICATE-----

  • libvirt_cert — содержит сертификат сервера и клиента для Libvirt и noVNC:

-----BEGIN CERTIFICATE-----
Содержимое сертификата Base64 ASCII
-----END CERTIFICATE-----

  • libvirt_key — содержит приватный ключ сервера и клиента для Libvirt и noVNC:

-----BEGIN PRIVATE KEY-----
Содержимое приватного ключа сертификата клиента Base64 ASCII
-----END PRIVATE KEY-----

Подключение дисковых массивов

iSCSI

Протокол iSCSI является протоколом хранения данных, инкапсулирующим фреймы SCSI для передачи по IP-сетям. Для подключения iSCSI необходимо выполнить следующие действия:

  1. Зайти в репозиторий региона.

  2. Открыть на редактирование файл globals.d/region.yml.

  3. Внести в файл следующие опции:

    • Enable_cinder_backend_iscsi: “yes”

    • Enable_cinder_backend_lvm: “no”

  4. Запустить новый пайплайн с KOLLA_ARGS: -t cinder.

NFS

NFS – это сетевая файловая система, которая является методом обеспечения доступности файловой системы по сети. Для ее подключения необходимо выполнить следующие действия:

  1. Зайти в репозиторий региона.

  2. Открыть на редактирование файл globals.d/REGION.yml.

  3. Внести в файл следующую опцию:

    • Enable_cinder_backend_nfs: “yes”

  4. Создать новый файл в каталоге config с именем nfs_shares и внести в него записи для каждого узла хранения:

    • storage01:/kolla_nfs

    • storage02:/kolla_nfs

  5. На узлах хранения storage01 и storage02 создать файл /etc/exports, в котором будут храниться тома:

    • /kolla_nfs 192.168.5.0/24(rw,sync,no_root_squash).
      В данном примере /kolla_nfs – это каталог на узле хранения, в который будет смонтирован nfs; 192.168.5.0/24 – сеть хранения; rw,sync,no_root_squash – действие, делающее общий ресурс синхронным для чтения и записи и запрещающее удаленным пользователям root иметь доступ ко всем файлам.

  6. Далее на узлах хранения запустить сервис nfsd:

    • systemctl start nfs

  7. Запустить новый пайплайн с KOLLA_ARGS: -t cinder.

FC

Для подключения Huawei Dorado с поддержкой FC необходимо выполнить следующие действия:

  1. Зайти в репозиторий региона.

  2. Открыть на редактирование файл globals.d/REGION.yml.

  3. Внести в файл следующие опции:

    • Enable_multipathd: “yes”

    • Enable_cinder_backend_lvm: “no”

    • Default_volume_type: “huawei_storage”

  4. Создать новый файл в каталоге config/cinder с именем nfs_shares и внести в него записи:

<?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_ADDRESS:8088/deviceManager/rest/</RestURL>
    </Storage>
    <LUN>
        <StoragePool>NAME_POOL</StoragePool>
        <LUNType>Thin</LUNType>
    </LUN>
    <FC>
        <Initiator Name="*" ALUA="1" FAILOVERMODE="1" PATHTYPE="0" />
    </FC>
</config>

  1. Создать файл в каталоге 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/nfs_shares
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

  1. Создать файл в каталоге 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
  }
}

  1. Запустить новый пайплайн с KOLLA_ARGS:

    • -t cinder, multipath.

Описание системы обновления LCM

Реализованная система обновления разделена на две основные составляющие части:

  1. Обновление репозиториев в Gitlab.

  2. Обновление и добавление новых контейнеров Openstack в Nexus.

Для обновления этих компонентов используются сценарии (пайплайны), созданные в gitlab-ci.

Обновление репозиториев и контейнеров

В репозитории project_k/services/upgrade, который размещен в Gitlab, есть один пункт в пайплайне, отвечающий за обновление компонентов LCM.

Для обновления компонентов необходимо выполнить следующие действия:

Оффлайн-обновление

  1. Зайти на узел LCM по ssh, а затем перейти в каталог /installer/update.

  2. Скачать или переместить ранее скачанное обновление в этот каталог.

  3. Перейти в репозиторий project_k → deployments → upgrade

    Перейти в Build → Pipelines → Run Pipeline.

  4. Запустить новый пайплайн, нажав кнопку “Run pipeline”.

../_images/image_15.png

Рисунок 15 — Запуск процесса обновления

Онлайн-обновление

  1. Перейти в репозиторий project_k → deployments → upgrade

    Перейти в Build → Pipelines → Run Pipeline. Заполнить переменные для пайплана, как на рисунке ниже:

    - UPGRADE_URL — URL архива с обновлением.
../_images/image_14.png

Рисунок 14 — Запуск пайплайна обновления

  1. Запустить новый пайплайн, нажав кнопку “Run pipeline”.

../_images/image_15.png

Рисунок 15 — Запуск процесса обновления