Инструкция по инсталляции облачной платформы ============================================ Подготовка ---------- Перед развертыванием самой облачной платформы необходимо создать несколько типов узлов: 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: - ``.`` — система управления жизненным циклом облака (CI); - ``.`` — репозиторий пакетов, контейнеров и других артефактов облака; - ``.`` — хранилище паролей и сертификатов; - ``.`` — хранилище настроек для сервиса Baremetal. Для сервисов LCM можно выбрать свои доменные имена. По умочанию используются: - ```` - ``ks-lcm`` - ```` - ``nexus`` - ```` - ``vault`` - ```` - ``netbox`` Доменное имя необходимо использовать второго уровня для генерации Wildcard-сертификата для сервисов LCM, например, ``demo.local``. Возможность разрешения данных имён в IP-адрес сервера LCM является обязательным, поскольку при установке облачной платформы используются сертификаты безопасности, связанные с указанными выше именами. Установка допускает использование разрешения имён либо через сервис DNS, либо через записи в файлах ``/etc/hosts``. Пример записи в ``/etc/hosts``: .. code:: bash . . . . Для узлов 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.2-ubuntu-offline.tgz - SberLinux 9.2 - https://repo.itkey.com/repository/k-install/installer-ks2024.1.2-sberlinux-offline.tgz Для начала установки на подготовленном сервере LCM от имени пользователя root требуется распаковать любой удобной утилитой архив с инсталлятором в домашнюю директорию пользователя root. Распаковка должна быть произведена в поддиректорию с именем installer в домашней директории пользователя root. Пример команды разархивирования, выполняемой от имени пользователя root: .. code:: bash tar -xf /installer-ks2024.1.2--offline.tar.gz -C ~/ Вместо нужно указать путь до директории со скачанным архивом инсталлятора. Запуск процесса установки облачной платформы осуществляется запуском команды ./installer.sh из директории инсталлятора (необходимо наличие прав root или запуск команды при помощи sudo). .. code:: bash root@lcm:~/installer# ./installer.sh *** KeyStack Installer v1.0 (ks2024.1.2-) *** 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 нужно предоставить полную цепочку сертификатов для него с именем ``.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 сертификатов - создать файлы ``.crt`` и ``.key``, который содержат сертификат и приватный ключ сертификата для сервиса Nexus - создать файлы ``.crt`` и ``.key``, который содержат сертификат и приватный ключ сертификата для сервиса - создать файлы ``.crt`` и ``.key``, который содержат сертификат и приватный ключ сертификата для сервиса - создать файлы ``.crt`` и ``.key``, который содержат сертификат и приватный ключ сертификата для сервиса Возможные ошибки при развёртывании LCM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Отсутствие каких-либо репозиториев в Gitlab ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Если это пустой репозиторий в Gitlab, значит, при git push могла произойти внутренняя ошибка сервиса Gitlab. В этом случае нужно перейти в каталог, где лежат все репозитории /installer/repo, зайти в каталог репозитория, где произошла ошибка, и выполнить команды: .. code:: bash git push -u origin --all git push -u origin --tags После этого нужно убедиться, что данные репозитория появились в Gitlab. Развертывание облачной платформы -------------------------------- .. _требования-1: Требования ~~~~~~~~~~ Требования к базовой ОС узлов ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Перед развертыванием сервисов облачной платформы необходимо убедиться, что на узлах присутствует пакет python 3, а также включены флаги виртуализации аппаратной платформы. Проверка флагов виртуализации производится при помощи выполнения команды: .. code:: bash egrep '(vmx|svm)' /proc/cpuinfo Предварительная конфигурация ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ После успешной установки на экране отобразится сообщение с текущей конфигурацией облачной платформы. Пример такой конфигурации приведён на рисунке ниже: .. image:: media/image_1.png Рисунок 1 — Пример сообщения с текущей конфигурацией об инсталляции .. attention:: Необходимо сохранить данные с текущей конфигурацией об инсталляции! Для обеспечения корректной работы браузеров с компонентами облачной платформы требуется добавить Root CA (корневой) сертификат в Доверенные корневые центры сертификации системы пользователя. После выполнения этих шагов требуется перейти по адресу CI/CD системы ``https://.`` и использовать пароль GitLab root, полученный из сообщения с текущей конфигурацией. В интерфейсе CI/CD системы будет доступно несколько репозиториев. Пример интерфейса приведён на рисунке ниже. .. image:: media/image_2.png Рисунок 2 — Репозитории в Gitlab Пароли и сертификаты Облачной платформы ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Все пароли и сертификаты для облака хранятся в сервисе Vault по адресу: ``https://.``. .. image:: media/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". .. image:: media/image_6.png Рисунок 4 — Запуск пайплайн-генерации секретов для bifrost Запустить задачу ``create-config``, как на рисунке ниже. .. image:: media/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". .. image:: media/image_8.png Рисунок 6 — Запуск задачи установки bifrost Дождаться окончания работы задачи ``setup``, запустить задачу ``deploy-bifrost`` и дождаться окончания ее работы. .. _ubuntu-22.04-lts-1: Ubuntu 22.04 LTS '''''''''''''''' Зайти на LCM-узел по ssh и выполнить команду: .. code:: bash # docker exec -ti bifrost_deploy bash (bifrost-deploy)# vi /etc/dnsmasq.conf Поменять значения: - ``listen-address=`` - ``dhcp-boot=tag:ipxe,http://: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: .. code:: bash (bifrost-deploy)# systemctl restart dnsmasq Изменение пользователя и пароля для IPMI серверов гипервизора ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Перейти в ``secret_v2/deployments/bifrost/rmi``, где ``bifrost`` — название репозитория с настройками сервиса bifrost. Затем поменять пароль в поле "password" на пароль от интерфейса IPMI BMC-серверов, и пользователя в поле "user" на пользователя интерфейса IPMI BMC-серверов. .. image:: media/image_5.png Рисунок 7 — Изменение пароля IPMI в хранилище секретов для сервиса Baremetal На всех серверах в BMC нужно создать одинакового пользователя с именем и паролем, который должен быть записан в Vault. Это необходимо для работы сервиса автоэвакуации ВМ при сбое гипервизора и для сервиса Baremetal. Развертывание серверов с помощью сервиса Baremetal ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Настройка Netbox '''''''''''''''' До начала работ по наливке серверов необходимо заполнить данные в Netbox. Наливка серверов '''''''''''''''' Перейти в Gitlab в репозиторий project_k → services → baremetal. Перейти в Build → Pipelines → Run Pipeline. .. image:: media/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". Запустится пайплан для деплоя серверов, необходимо дождаться окончания работы. .. image:: media/image_10.png Рисунок 9 — Пайплайн развертывания серверов Развертывание облака ~~~~~~~~~~~~~~~~~~~~ .. _развертывание-облачной-платформы-1: Развертывание облачной платформы ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Необходимо зайти в 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-2: 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-1: SberLinux 9.2 ''''''''''''' Применить настройки из предыдущего пункта. Запуск задачи с предварительной настройкой региона ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ В этой задаче будут сгенерированны пароли и сертификаты для региона. | Необходимо зайти в Gitlab и перейти в репозиторий project_k → deployments → gen-pwd. | Затем перейти в Build → Pipelines → Run Pipeline. | Заполнить переменные для пайплана, как на рисунке ниже: - OPENSTACK_ENV — имя региона и репозитория в Gitlab с настройками региона. .. image:: media/image_11.png Рисунок 10 — Запуск пайплайна генерации секретов для region1 После заполнения данных нажать кнопку "Run Pipeline". Запустить задачу ``create-config``, как на рисунке ниже. .. image:: media/image_7.png Рисунок 11 — Запуск задачи генерации секретов для region1 Дождаться окончания работы пайплайна. Изменение пароля для IPMI серверов гипервизора ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Нужно зайти в Vault и перейти в ``secret_v2/deployments/region1/passwords_yml``, где ``region1`` — название репозитория с настройками региона. Затем поменять пароль в поле "bmc_password" на пароль от интерфейса IPMI BMC серверов гипервизора. .. image:: media/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. .. image:: media/image_12.png Рисунок 13 — Запуск пайплайна развертывания облака для region1. После заполнения данных нажать кнопку "Run Pipeline". .. image:: media/image_13.png Рисунок 14 — Задачи пайплайна развертывания облака для region1. Задачи в пайплайне развертывания облака: - ``setup`` — подготовка паролей и настроек для развертывания облака; - ``bootstrap-servers`` — подготовка узлов для загрузки конфигурации (установка необходимых пакетов и конфигурирование компонентов ОС); - ``deploy`` — развертывание и запуск сервисов Openstack на узлах; - ``postconfig`` — применение квот развернутого облака; - ``states`` — наполнение развернутого облака демо-конфигурацией; - ``rally`` — валидация компонентов облака; - ``tempest`` — тестирование развернутого облака на соответствие конфигурации; - ``backup-db`` — бэкап БД MariaDB развернутого облака. Дождаться окончания работы задачи ``setup``. Запустить задачу ``bootstrap-servers``, дождаться окончания работы задачи. Запустить задачу ``deploy``, дождаться окончания работы задачи. Получение openrc из Vault ^^^^^^^^^^^^^^^^^^^^^^^^^ На LCM-узле в консоли выполнить команду: .. code:: bash # 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. | В конец файла добавить строку: .. code:: bash export OS_CACERT=/installer/data/ca/cert/chain-ca.pem По аналогии сделать для остальных регионов. Transport Level Security (TLS) ------------------------------ LCM TLS ~~~~~~~ .. image:: media/image_lcm.png Рисунок 16 — Схема компонентов LCM При установке компонентов на сервере LCM генерируются самоподписанные сертификаты для каждого компонента `` `` с ``SAN=DNS:.``. Компонент Nginx выполняет SSL-терминацию к остальным компонентам. Openstack TLS ~~~~~~~~~~~~~ Включение TLS на внутреннем и/или внешнем VIP-адресе позволяет клиентам OpenStack аутентифицировать и шифровать сетевое соединение со службами OpenStack. Существует два разных уровня конфигурации TLS для API OpenStack: 1. Включение TLS на внутреннем и/или внешнем VIP, чтобы связь между клиентом OpenStack и HAProxy, прослушивающим VIP, была безопасной. 2. Включение TLS во внутренней сети для обеспечения безопасности связи между HAProxy и серверными службами API. Настройки по умолчанию ^^^^^^^^^^^^^^^^^^^^^^ .. code:: bash 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-1: LCM TLS ^^^^^^^ Во время разворачивания Облачной платформы создаются сертификаты для компонентов LCM. 1. Корневой центр сертификации: Root CA сертификат и приватный ключ - ``/installer/data/ca/root/ca.crt`` - ``/installer/data/ca/root/ca.key`` 2. Сертификат и приватный ключ для каждого компонента `` `` - ``/installer/data/ca/cert/.crt`` - ``/installer/data/ca/cert/.key`` 3. Pem-файл с цепочкой сертификатов для каждого компонента `` `` - ``/installer/data/ca/cert/chain-.pem`` 4. 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`` 2. ``/installer/data/ca/cert/chain-ca.pem`` - ``/etc/docker/certs.d/./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"`` 3. ``/installer/data/ca/cert/chain-.pem`` - ``/installer/data/gitlab-runner/certs/..crt`` 4. ``/installer/data/ca/cert/chain-.pem`` - ``/installer/data/nginx/.pem`` 5. ``/installer/data/ca/cert/.key`` - ``/installer/data/nginx/.key`` После замены сертификатов нужно выполнить команду перезапуска компонентов: .. code:: bash docker restart gitlab nginx .. _openstack-tls-1: Openstack TLS ^^^^^^^^^^^^^ В зависимости от настроек региона, указанных в файле ``globals.d/REGION.yml`` в репозитории региона, для него генерируется несколько сертификатов. Сертификат CA с любыми промежуточными сертификатами складывается в репозиторий региона по пути ``/certificates/ca/ca-bundle.crt``. Сертификаты CA для Octavia складываются в репозиторий региона по путям ``/config/octavia/client_ca.cert.pem`` и ``/config/octavia/server_ca.cert.pem``. Все сертификаты региона складываются в Vault по адресу ``secrets/secret_v2/deployments//ssl_certificates``. 1. По умолчанию: - ``haproxy_pem`` - ``octavia_client`` - ``octavia_server`` 2. Разные сертификаты для внутреннего и внешнего VIP: - ``haproxy_internal_pem`` 3. Включение TLS во внутренней сети. Включение TLS для RabbitMQ: - ``backend_key_pem`` - ``backend_pem`` 4. Включение TLS для Libvirt. Включение TLS для NoVNC: - ``libvirt_cacert`` - ``libvirt_cert`` - ``libvirt_key`` .. image:: media/image_openstack_tls.png Рисунок 17 — Сертификаты региона Openstack в Vault Формат сертификатов ''''''''''''''''''' Для всех сертификатов используется формат PEM. Может содержать один или несколько сертификатов, закрытый ключ или же сертификат(ы) и закрытый ключ одновременно. В этом случае каждый из них обрамляется обязательными строками BEGIN и END. Кроме расширения .pem, для ключа могут также использоваться расширения .crt и .key. - ``/certificates/ca/ca-bundle.crt`` — содержит цепочку CA сертификатов: :: -----BEGIN CERTIFICATE----- Содержимое промежуточного сертификата Base64 ASCII -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Содержимое CA сертификата Base64 ASCII -----END CERTIFICATE----- - ``/config/octavia/server_ca.cert.pem`` — содержит CA сертификат сервера для Остаvia: :: -----BEGIN CERTIFICATE----- Содержимое CA сертификата Base64 ASCII -----END CERTIFICATE----- - ``/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`` и внести в него записи: :: Dorado FC user {{ lookup('hashi_vault', 'secret={{ vault_engine }}/data/{{ vault_prefix }}/{{ OPENSTACK_ENV | lower }}/huawei')['data']['UserPassword'] }} https://IP_ADDRESS:8088/deviceManager/rest/ NAME_POOL Thin 5. Создать файл в каталоге 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 6. Создать файл в каталоге 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 } } 7. Запустить новый пайплайн с 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". .. image:: media/image_15.png Рисунок 15 — Запуск процесса обновления Онлайн-обновление ^^^^^^^^^^^^^^^^^ 1. Перейти в репозиторий project_k → deployments → upgrade Перейти в Build → Pipelines → Run Pipeline. Заполнить переменные для пайплана, как на рисунке ниже: :: - UPGRADE_URL — URL архива с обновлением. .. image:: media/image_14.png Рисунок 14 — Запуск пайплайна обновления 2. Запустить новый пайплайн, нажав кнопку "Run pipeline". .. image:: media/image_15.png Рисунок 15 — Запуск процесса обновления