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

Подготовка

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

Узел Infrastructure (он же LCM — Life Cycle Manager) — предназначен для управления жизненным циклом облака;
Узлы Control Plane (контроллеры) — предназначены для выполнения служебных задач по управлению облаком;
Узлы Compute (гипервизоры) — предназначены для размещения рабочих нагрузок в виде виртуальных машин;
Узлы Network (сетевые) — предназначены для размещения компонентов програмно-определяемых сетей.

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

Запуск установки (инсталлятора), который установит на сервер LCM необходимые компоненты и сервисы для дальнейшей работы с облаком.
Выполнение сценариев (пайплайнов) системы управления облаком (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 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-зону, в котором необходимо создать записи для следующих сервисов:

ks-lcm.<имя домена> — система управления жизненным циклом облака (CI);
gitlab-runner.<имя домена> — исполнитель сценариев (пайплайнов);
nexus.<имя домена> — репозиторий пакетов, контейнеров и других артефактов облака;
vault.<имя домена> — хранилище паролей и сертификатов;
netbox.<имя домена> — хранилище настроек для сервиса Baremetal.

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

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

<ip адрес LCM> ks-lcm.<имя домена> gitlab-runner.<имя домена> vault.<имя домена> nexus.<имя домена> netbox.<имя домена>

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

10.10.1.1 <имя сервера>-rmi.<имя домена>

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

Установка LCM

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

Пароля системы автоматизации (Gitlab);
SSH-ключей для беспарольного доступа на сервера;
Сертификатов для служб LCM;
Репозитория пакетов, контейнеров, артефактов Sonatype Nexus;
Системы автоматизации (GitLab-CI);
Репозиториев управления облаком (CI/CD);
Документирования сетей и девайсов Netbox (CMDB).

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

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

Ubuntu 22.04 LTS - https://repo.itkey.com/repository/k-install/installer-ks2024.1-ubuntu-offline.tgz
SberLinux 9.2 - https://repo.itkey.com/repository/k-install/installer-ks2024.1.1-sber-offline.tgz

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

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

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

root@lcm:~/installer# ./installer.sh
*** KeyStack Installer v1.0 (ks2024.1-<system>) ***
Enter the home dir for the installation [/installer]:
Enter the IP address of this machine [10.220.107.179]:
Enter the root domain name for the KeyStack: demo.local

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

Возможные ошибки при развёртывании 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

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

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

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

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

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

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

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

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

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

Рутовый токен можно найти на сервере LCM в файле /installer/data/vault/config/unseal_info. Там же находятся ключи для разблокировки Vault после перезагрузки.

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

Инсталлятор создает корневой центр сертификации: Root CA сертификат и приватный ключ. Срок действия — 10 лет.
Инсталлятор создает Wildcard сертификат и приватный ключ для сервисов 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”.

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

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

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

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

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

Ubuntu 22.04 LTS

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

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

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

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

SberLinux 9.2

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

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

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

заменить eth0 на имя интерфейса на LCM-узле;
заменить в kolla_base_distro значение на rocky;
заменить в openstack_tag_suffix значение на -sber.

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

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

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

Рисунок 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

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

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

(bifrost-deploy)# systemctl restart dnsmasq

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

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

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

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

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

Настройка Netbox

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

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

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

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

Рисунок 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”. Запустится пайплан для деплоя серверов, необходимо дождаться окончания работы.

Рисунок 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

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

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

заменить в kolla_base_distro значение на rocky
заменить в openstack_tag_suffix значение на -sber
заменить в enable_docker_repo значение на true

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

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

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

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

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

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

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

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

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

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

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

Рисунок 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.

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

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

Рисунок 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-cert.pem

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

Transport Level Security (TLS)

LCM TLS

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

При установке компонентов на сервере LCM генерируется самоподписанный wildcard-сертификат для всех компонентов с SAN=DNS:<DOMAIN>,DNS:*.<DOMAIN>,IP:<LCM_IP>.

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

Openstack TLS

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

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

Включение TLS на внутреннем и/или внешнем VIP, чтобы связь между клиентом OpenStack и HAProxy, прослушивающим VIP, была безопасной.
Включение 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

Раскомментировать строку # kolla_internal_fqdn_cert: "/etc/kolla/haproxy-internal.pem" в файле globals.d/REGION.yml в репозитории региона.
Перейти в репозиторий project_k/deployments/gen-pwd и запустить новый пайплайн, где указать значение имени региона для OPENSTACK_ENV.
Перейти в репозиторий региона и запустить новый пайплайн с значениями по умолчанию, затем запустить задачу deploy и дождаться окончания ее работы.

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

Установить значение yes для kolla_enable_tls_backendв файле globals.d/REGION.yml в репозитории региона.
Перейти в репозиторий project_k/deployments/gen-pwd и запустить новый пайплайн, где указать значение имени региона для OPENSTACK_ENV.
Перейти в репозиторий региона и запустить новый пайплайн с значениями по умолчанию, далее запустить задачу deploy и дождаться окончания ее работы.

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

Установить значение yes для rabbitmq_enable_tls в файле globals.d/REGION.yml в репозитории региона.
Перейти в репозиторий project_k/deployments/gen-pwd и запустить новый пайплайн, где указать значение имени региона для OPENSTACK_ENV.
Перейти в репозиторий региона и запустить новый пайплайн с значениями по умолчанию, затем запустить задачу deploy и дождаться окончания ее работы.

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

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

Установить значение yes для libvirt_tls в файле globals.d/REGION.yml в репозитории региона.
Перейти в репозиторий project_k/deployments/gen-pwd и запустить новый пайплайн, где указать значение имени региона для OPENSTACK_ENV.
Перейти в репозиторий региона и запустить новый пайплайн с значениями по умолчанию, запустить задачу deploy, дождаться окончания ее работы.

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

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

Установить значение yes для nova_qemu_vnc_tls в файле globals.d/REGION.yml в репозитории региона.
Перейти в репозиторий project_k/deployments/gen-pwd и запустить новый пайплайн, где указать значение имени региона для OPENSTACK_ENV.
Перейти в репозиторий региона и запустить новый пайплайн с значением KOLLA_ARGS:-t nova, запустить задачу deploy, дождаться окончания ее работы.

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

LCM TLS

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

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

/installer/data/ca/root/ca.crt
/installer/data/ca/root/ca.key

Wildcard-сертификат и приватный ключ

/installer/data/ca/cert/cert.crt
/installer/data/ca/cert/cert.key

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

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

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

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

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

/installer/data/gitlab-runner/certs/ca.crt
/etc/docker/certs.d/nexus.<DOMAIN>/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
В Vault secrets/secret_v2/deployments/secrets/ca.crt
/installer/data/vault/config/ca.crt — для Ubuntu, после копирования выполнить команду docker exec vault /bin/sh -c "cat /vault/config/ca.crt >> /etc/ssl/certs/ca-certificates.crt" — для SberLinux, после копирования выполнить команду docker exec vault /bin/sh -c "cat /vault/config/ca.crt >> /etc/pki/ca-trust/source/anchors/ca.crt; update-ca-trust"

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

/installer/data/nginx/cert.pem

/installer/data/ca/cert/cert.key

/installer/data/nginx/cert.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.

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

haproxy_pem
octavia_client
octavia_server

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

haproxy_internal_pem

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

backend_key_pem
backend_pem

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

libvirt_cacert
libvirt_cert
libvirt_key

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

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

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

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

<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:

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

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 необходимо выполнить следующие действия:

Зайти в репозиторий региона.
Открыть на редактирование файл globals.d/region.yml.
Внести в файл следующие опции:

Enable_cinder_backend_iscsi: “yes”

Enable_cinder_backend_lvm: “no”

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

NFS

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

Зайти в репозиторий региона.
Открыть на редактирование файл globals.d/REGION.yml.
Внести в файл следующую опцию:

Enable_cinder_backend_nfs: “yes”

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

storage01:/kolla_nfs

storage02:/kolla_nfs

На узлах хранения 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 иметь доступ ко всем файлам.

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

systemctl start nfs

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

FC

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

Зайти в репозиторий региона.
Открыть на редактирование файл globals.d/REGION.yml.
Внести в файл следующие опции:

Enable_multipathd: “yes”

Enable_cinder_backend_lvm: “no”

Default_volume_type: “huawei_storage”

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

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

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

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

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

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

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

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

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

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

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

Зайти на узел LCM по ssh, а затем перейти в каталог /installer/update.
Скачать или переместить ранее скачанное обновление в этот каталог.
Перейти в репозиторий project_k → deployments → upgrade Перейти в Build → Pipelines → Run Pipeline.
Запустить новый пайплайн, нажав кнопку “Run pipeline”.

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

После успешного завершения пайплайна необходимо удалить все из каталога /installer/update.