Создание региона¶

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

Примечание

В этой инструкции в качестве базового доменного имени облачной платформы используется cloud.itkey.com и имена сервисов по умолчанию. При выполнении инструкции указывайте ваши действительные имена.

Совет

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

Создание и подготовка репозитория нового региона¶

Откройте веб-интерфейс развёрнутого GitLab по адресу https://ks-lcm.cloud.itkey.com.
Создайте форк GitLab-репозитория region1. Это репозиторий-шаблон, который используется для создания новых регионов. Для этого выполните действия:
1. Перейдите в проект project_k / deployments / region1.
2. Нажмите кнопку Fork.
3. В открывшемся окне укажите параметры:
  Project name — имя региона.
  
  Важно
  
  Имя региона должно удовлетворять условиям:
  
  содержать латинские буквы [a-z] и цифры [0–9];
  
  дефисы не могут быть в начале и конце имени;
  
  не должно содержать два дефиса одновременно;
  
  не должно содержать пробелы и специальные символы (например, !, $, &, _ и т. д.);
  
  минимальная длина — 3, максимальная — 63 символа;
  
  нечувствительно к регистру.
  
  Project slug — укажите точно такой же как имя региона.
  
  Select a namespace — выберите namespace для проекта, например, project_k/deployments.
4. Нажмите кнопку Fork project.
Перейдите в созданный репозиторий нового региона.
Удалите связь с родительским репозиторием. При использовании ролевой модели это происходит автоматически и может занять около 10 минут.
1. Перейдите в раздел Settings > General > Advanced.
2. Нажмите кнопку Remove fork relationship.
3. Введите название региона для подтверждения действия.
Разрешите использование job-токена из других проектов. При использовании ролевой модели это происходит автоматически и может занять около 10 минут.
1. Перейдите в раздел Settings > CI/CD > Job token permissions.
2. В разделе CI/CD job token allowlist нажмите кнопку Add и выберите Group or project.
3. В поле Group or project внесите значение project_k.
4. Нажмите кнопку Add.
Выполнение некоторых пайплайнов развёртывания может занимать продолжительное время. Увеличьте таймаут пайплайнов по умолчанию:
1. Перейдите в раздел Settings > CI/CD > General pipelines.
2. Установите значение Timeout — 5h.
Создайте ветку согласно вашему релизу keystack:
1. Перейдите в репозиторий нового региона.
2. Перейдите в раздел Code > Branches > New branch.
3. В разделе Create from выберите тег вашего релиза keystack.
4. В разделе Branch name — укажите имя ветки master-<имя релиза keystack>.
5. Нажмите Create branch.
Настройте параметры инфраструктуры созданного региона. Для этого:
1. Откройте веб-интерфейс Vault (https://vault.<DOMAIN>) и авторизуйтесь с помощью реквизитов, полученных при установке платформы.
2. Перейдите в Secrets Engines, а затем — в директорию installer. В директории откройте вкладку Issuers.
3. Нажмите на имя нужного issuer. Откроется страница View Issuer Certificate. Скопируйте содержимое поля CA Chain — это цепочка сертификатов, которая будет использоваться при следующих шагах настройки параметров инфраструктуры.
4. Войдите в GitLab и перейдите в репозиторий региона project_k / deployments / <имя региона>.
5. Откройте файл certificates/ca/ca-bundle.crt и разместите в него следующие сертификаты:
  - цепочку сертификатов Vault PKI (корневой и промежуточный сертификаты), полученную при шагах ранее;
  - цепочки CA, выпустившего сертификаты для сервисов LCM и для публичных/приватных эндпоинтов, в случае если используются внешние сертификаты:
    
    для сервисов LCM — используйте файл chain-ca.pem, подготовленный в директории installer/certs/ на этапе установки платформы — подробнее см. в разделе Установка инсталлятора;
    
    для публичных/приватных эндпоинтов — если вы планируете использовать собственные сертификаты, разместите их в Vault в директорию secret_v2 / deployments / <LCM FQDN> / <имя региона> / ssl_certificates до запуска пайплайна: haproxy_pem — при включённом kolla_enable_tls_external, haproxy_internal_pem — при включённом kolla_enable_tls_internal. Значение каждого ключа может содержать сертификат, приватный ключ или их комбинацию. Также добавьте в текущий файл цепочку CA, выпустившего эти сертификаты — источник цепочки зависит от используемого PKI. Если сертификаты будут сгенерированы автоматически пайплайном, этот шаг можно пропустить.
6. Откройте файл inventory.
7. Заполните информацию об узлах инфраструктуры [control], [network], [compute] в формате <имя узла> ansible_host=<IP адрес узла>.
8. Откройте файл globals.d/REGION.yml и укажите значения параметров:
  kolla_internal_vip_address — виртуальный IP-адрес для внутреннего VIP-интерфейса (используется для балансировки запросов);
  
  kolla_internal_fqdn — DNS-имя для внутреннего VIP-адреса, например, internal.cloud.itkey.com;
  
  kolla_external_vip_address — виртуальный IP-адрес для внешнего VIP-интерфейса (используется для балансировки запросов);
  
  kolla_external_fqdn — DNS-имя для внешнего VIP-адреса, например, external.cloud.itkey.com;
  
  network_interface — имя интерфейса для MGMT-сети, на котором будет разворачиваться OpenStack;
  
  neutron_external_interface — имя интерфейса для связи с внешней инфраструктурой, например, сетями провайдеров, маршрутизаторами и плавающими IP-адресами.
9. Если вы используете сервис балансировки нагрузки Octavia, откройте файл globals.d/octavia.yml и укажите значения параметра octavia_amp_network_cidr — IP-префикс подсети управления сервиса Octavia.
Для изменения ТУЗ admin по умолчанию в OpenStack добавьте в файл <region_name>/globals.d/REGION.yml переменную keystone_admin_user: "<custom_name>". Данная опция задаст новое имя ТУЗ администратора (вместо стандартного admin).
Для того чтобы скрыть домен default и использовать собственный домен по умолчанию, в файл <region_name>/globals.d/REGION.yml добавьте переменную keystone_default_domain: "<custom_domain>". Данная опция настроит Keystone так, чтобы он использовал заданный домен по умолчанию для аутентификации в OpenStack.

Настройка правила второй руки¶

При подключении GitLab к внешнему каталогу пользователей LDAP пользователям с ролью admin автоматически назначаются права Maintainer. Изменения конфигурационных файлов в репозитории региона должны вноситься через Merge Request и быть одобрены вторым пользователем с ролью admin. Такой подход называется правилом второй руки: ни один пользователь с ролью admin не может единолично изменить конфигурацию региона.

Для этого выполните следующие действия:

Настройте правила слияния для репозитория региона в соответствии с разделом Настройка правил Merge Request.
Убедитесь, что для согласования Merge Request доступны минимум два пользователя с ролью admin. Подробнее о процессе утверждения см. раздел Процесс создания и утверждения Merge Request.

Генерация паролей и сертификатов для региона¶

Запустите пайплайн на генерацию паролей и сертификатов для региона:
1. Откройте проект нового региона.
2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
3. Выберите ветку вашего релиза в выпадающем списке Run for branch name or tag master-<имя релиза keystack>.
4. Запустите пайплайн New pipeline.
5. Запустится задача setup, дождитесь её завершения.
Для каждого созданного региона повторите запуск пайплайна в его проекте.

Настройка паролей внешних сервисов¶

Для реализации автоэвакуации ВМ при сбое гипервизора, задайте пароль интерфейса IPMI baremetal-узлов:
1. Перейдите в веб-интерфейс развёрнутого Vault.
2. Перейдите в директорию с настройками региона secret_v2 / deployments / <LCM FQDN> / <имя региона> / passwords_yml.
3. Нажмите Create new version.
4. Найдите и замените значение параметра bmc_password на пароль от интерфейса IPMI BMC-узлов.
По аналогии с предыдущим шагом в директории с настройками региона secret_v2 / deployments / <LCM FQDN> / <имя региона> / passwords_yml укажите пароли от своих сервисов в соответствующих полях, например:
- ldap_user — LDAP пользователь в формате ldap-ro,
- ldap_password — пароль LDAP пользователя,
- smtp_user — SMTP пользователь,
- smtp_password — пароль SMTP пользователя,
- cinder_dorado_user_password — СХД,
- bird_external_bgp_password — пароль для подключения к автономной системе через сервис Bird.
  
  Примечание
  
  Переменные ldap_user, ldap_password, smtp_user и smtp_password используются для настройки автоматической ротации пользователей и паролей. Процесс настройки автоматической ротации описан в разделе Автоматическая ротация пользователей и паролей.
Имя пользователя для подключения к Redfish API задаётся в переменной bmc_monitoring_user (по умолчанию prometheus) в конфигурационном файле региона (по умолчанию /globals.d/REGION.yml). Пароль для учётной записи необходимо внести в Vault в качестве значения ключа bmc_monitoring_password в файле passwords_yml. Для безопасной работы с секретами реализована поддержка взаимодействия с Vault-агентом. Подробнее в разделе Prometheus redfish exporter.

Настройка правил межсетевого экрана (nftables)¶

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

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

Для описания настроек перейдите к разделу Настройка механизма фильтрации трафика.

Конфигурация BGP¶

В базовой конфигурации платформы механизм мониторинга состояния и сетевой доступности узлов реализуется сервисом keepalived на основе протокола VRRP. Альтернативно, для этих целей возможно использовать протокол BGP, который также поддерживается платформой.

Настройка BGP

Дополнительная настройка узлов перед развёртыванием¶

Выполните дополнительную конфигурацию узлов перед развёртыванием региона. Для этого используйте конфигурационный файл host_config/host-config.yml. Следуйте инструкциям по редактированию файла host-config.yml в разделе Использование host-config для настройки региона, не запуская пайплайн. Все выполненные вами конфигурации будут применены ниже при запуске задачи bootstrap-servers пайплайна развёртывания региона.

Запуск пайплайна развёртывания региона¶

Войдите в хранилище секретов Vault и перейдите в директорию secret_v2 / deployments / <LCM FQDN> / <имя региона> / ssl_certificates.
Внесите корректную цепочку сертификатов для внутреннего эндпоинта в параметр haproxy_internal_pem и корректную цепочку сертификатов для публичного эндпоинта в параметр haproxy_pem.
Запустите пайплайн по развёртыванию региона:
1. Откройте веб-интерфейс развёрнутого GitLab.
2. Перейдите в репозиторий project_k / deployments / <имя региона>.
3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
4. Выберите ветку вашего релиза в выпадающем списке Run for branch name or tag master-<имя релиза keystack>.
5. В открывшемся окне при необходимости укажите значения переменных:
  KOLLA_ARGS — дополнительные теги:
  
  --limit <имя узла> — выполнить пайплайн для отдельного узла платформы;
  
  --tags <имя компонента> — выполнить пайплайн для отдельного компонента платформы.
  
  KOLLA_ANSIBLE_DEPLOY_ACTION — список задач для kolla-ansible, должно быть указано deploy;
  
  KEYSTACK_RELEASE — версия KeyStack для развёртывания.
6. Запустите пайплайн New pipeline.
7. Дождитесь завершения задач setup.
  
  Примечание
  
  Задачи bootstrap-servers и deploy требуют ручного запуска — нажмите кнопку ▶ напротив соответствующей задачи в интерфейсе GitLab.
8. Запустите задачу bootstrap-servers и дождитесь её завершения. Если после её завершения автоматически запустятся связанные задачи, дождитесь их завершения.
9. Запустите задачу deploy и дождитесь её завершения.

Примечание

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

setup — подготовка паролей и настроек для развёртывания платформы;
backup-db — создание резервной копии базы данных MariaDB;
bootstrap-servers — установка необходимых пакетов и настройка компонентов ОС;
deploy — развёртывание и запуск сервисов KeyStack на узлах;
rally — валидация компонентов платформы;
tempest — тестирование платформы на соответствие конфигурации.

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

Добавление новых узлов в существующий регион¶

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

Предупреждение

В версии 2025.1 при запуске пайплайна без добавления специальных тегов и ограничения по узлам происходит рестарт всех контейнеров в регионе. Это может привести к временной недоступности сервисов управляющего слоя.

Для безопасного добавления новых узлов выполните следующие действия:

Добавьте новые узлы в файл inventory репозитория региона в соответствующие группы ([control], [network], [compute]).
Запустите пайплайн с дополнительными параметрами:
1. Откройте веб-интерфейс развёрнутого GitLab.
2. Перейдите в репозиторий project_k / deployments / <имя региона>.
3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
4. Выберите ветку вашего релиза в выпадающем списке Run for branch name or tag master-<имя релиза keystack>.
5. В открывшемся окне добавьте переменную KOLLA_ARGS со следующим значением:
  --skip-tags keepalived,rabbitmq,mariadb --limit control,new_servers* -e kolla_serial=1
  
  Где:
  
  --skip-tags keepalived,rabbitmq,mariadb — пропускает рестарт критически важных сервисов управляющего слоя, которые не участвуют в процессе добавления новых узлов. Предотвращает ненужный рестарт, способный привести к кратковременной недоступности.
  
  --limit control,new_servers* — ограничивает выполнение задач контроллерами и новыми серверами. Использование wildcard-символа (*) позволяет добавить сразу группу серверов с похожими именами (например, при добавлении целой стойки).
  
  -e kolla_serial=1 — обеспечивает последовательное обновление узлов (по одному за раз), гарантируя доступность сервисов пользовательского интерфейса (Horizon, AdminUI) во время операции.
6. Запустите пайплайн New pipeline.
7. Дождитесь завершения задачи setup.
8. Запустите задачу bootstrap-servers и дождитесь её завершения.
9. Запустите задачу deploy и дождитесь её завершения.

После завершения работы пайплайна новые узлы будут добавлены в регион без прерывания работы существующей инфраструктуры.

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

Примечание

Для настройки ролевой модели необходимо включить интеграцию с каталогами LDAP.

Примечание

Если конфигурация ролевой модели была подготовлена до развёртывания региона, параметры LDAPS, Keystone и ролевой модели уже применены. В этом случае пропустите шаги по настройке конфигурационных файлов и перейдите к созданию домена и настройке пользователей и групп в OpenStack.

Добавьте сертификат для LDAPS:
1. Откройте веб-интерфейс развёрнутого GitLab.
2. Перейдите в репозиторий project_k / deployments / <имя региона>.
3. Выберите ветку вашего релиза в выпадающем списке Run for branch name or tag master-<имя релиза keystack>.
4. Перейдите в директорию certificates/ca. Откройте файл ldaps.crt или создайте его. Добавьте в файл ваш сертификат LDAPS.
Создайте домен (в этом примере — itkey) и добавьте в него пользователя admin:
1. Зайдите на узел LCM по SSH.
2. Выполните команды:
  $ openstack domain create itkey $ openstack role add --domain itkey --user admin admin

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

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

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

Выберите ветку вашего релиза в выпадающем списке Run for branch name or tag master-<имя релиза keystack>.
Найдите файл globals.d/REGION.yml и добавьте в него строки:
Предупреждение

При использовании ОС SberLinux параметры horizon_keystone_multidomain и horizon_keystone_domain_choices не указывайте — Horizon в KeyStack недоступен.
horizon_keystone_multidomain: "True"
horizon_keystone_domain_choices:
  default: default
  itkey: itkey

keystone_ldap_url: "ldaps://<адрес вашего сервиса LDAPS>"
Перейдите в директорию config/keystone/domains и создайте файл keystone.itkey.conf со следующим содержанием. При необходимости в group_filter и user_filter замените значения CN с префиксом group_ на названия ваших групп LDAP, а в значениях DC= укажите ваши компоненты домена:
[identity]
driver = ldap

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

Добавьте пароль пользователя LDAPS в Vault:
1. Откройте веб-интерфейс Vault.
2. Авторизуйтесь с помощью реквизитов для Vault, полученных на этапе установки дистрибутива KeyStack.
3. Перейдите в директорию секретов региона: secret_v2 / deployments / <LCM FQDN> / <имя региона> / passwords_yml.
4. Перейдите на вкладку Secret и нажмите Create new version.
5. Отредактируйте файл, замените значение поля ldap_password на пароль пользователя LDAPS.
Запустите развёртывание компонентов Keystone, Horizon и AdminUI:
1. Откройте веб-интерфейс развернутого GitLab.
2. Перейдите в репозиторий project_k / deployments / <имя региона>.
3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
4. Выберите ветку вашего релиза в выпадающем списке Run for branch name or tag master-<имя релиза keystack>.
5. В открывшемся окне добавьте параметр KOLLA_ARGS со значением -t keystone,horizon,adminui для запуска пайплайна только для этих компонентов.
6. Запустите пайплайн: New pipeline.
7. Дождитесь завершения выполнения задач на шаге setup.
8. Запустите задачу deploy на шаге deploy и дождитесь её завершения.
Перезапустите контейнеры Keystone:
1. Зайдите на узел LCM по SSH.
2. Выполните команду:
  $ docker restart keystone

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

$ openstack user list --domain itkey
+------------------------------------------------------------------+----------------+
| ID                                                               | Name           |
+------------------------------------------------------------------+----------------+
| 40d88d5463e910003e73ef9a3285c3fd907fb56c255ba27d938b48559a200a2b | member1        |
| 9016b4c6ff10b980b1556b39fa995c9349a4bb64fed26d79d1c36ea5e4dde0dd | member2        |
| 50b5b30a1aef6c6784344e95e62b53308606916d8953926cde3f26c46537e876 | member3        |
| f84e98454612eda80d34d2ef1fe1a3624e2e6c597d3f57b30d64881d12b3c060 | infra_admin    |
| 68245853200911bb930b6c1d5f245c3f3444914a841b0a3ac226dbc59614e9f1 | support_admin  |
| f4b4749ba49d7223626f36fc91389fc061c37af11d4a8c8f4cb436bbbfd181ae | security_admin |
| ccecd465ca6b617f81e6c6f803c8bb51c933f8def25439997a3984ff71a31f0f | reader         |
+------------------------------------------------------------------+----------------+

$ openstack group list --domain itkey
+------------------------------------------------------------------+------------------------+
| ID                                                               | Name                   |
+------------------------------------------------------------------+------------------------+
| 6588de10efbf97de47b57c9fd0fc5fbbce8bbc26ae7bbcd50511430cc96b8f50 | group_admin            |
| c94274dc724eb1aac6797ac99fd3cae2eeb1d3bc0135dc6bfa586d573736099e | group_member           |
| 1797223b40aa8409eba0ff0fe84c239a25e3f93ced5e8e55d230da5ccda373d2 | group_reader           |
| eb599167d78c91450e1ab74ff4077584a817be9c8f20144badcd88a11d46a0cc | group_security_auditor |
+------------------------------------------------------------------+------------------------+

Создайте новый проект в домене itkey:
$ openstack project create demo --domain itkey

Назначьте группам роли в проекте OpenStack в соответствии с ролевой моделью. В командах указывайте конкретные идентификаторы групп из вывода команды openstack group list --domain itkey:

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

$ openstack role add --project demo --group <ID группы group_member> --user-domain itkey member

Добавьте роль admin:

$ openstack role add --project demo --group <ID группы group_admin> --user-domain itkey admin

Добавьте роль reader для групп security_auditor и reader:

$ openstack role add --project demo --group <ID группы group_security_auditor> --user-domain itkey reader
$ openstack role add --project demo --group <ID группы group_reader> --user-domain itkey reader

Активируйте ролевую модель в Портале администратора через конфигурацию региона:
1. Откройте веб-интерфейс GitLab.
2. Перейдите в репозиторий региона project_k / deployments / <имя региона>.
3. Выберите ветку вашего релиза в выпадающем списке Run for branch name or tag master-<имя релиза keystack>.
4. Откройте файл globals.d/REGION.yml и укажите в нём значения переменных:
  enable_rbac_model: "yes" opensearch_admin_tls: "CN=backend.{{ kolla_external_fqdn }}"
  
  Параметр enable_rbac_model включает ролевую модель.
  
  Параметр opensearch_admin_tls настраивает интеграцию с системой логирования. В случае использования внешних сервисов (например, SecMan) в значение данного параметра необходимо включить дополнительные поля:
  
  opensearch_admin_tls: "CN=backend.external.<имя региона>.<имя домена>,OU=<organizational unit>,O=<organization>,STREET=<street or address>,C=<country>"
  
  Валидные значения для полей OU, O, STREET, C необходимо уточнять у администратора PKI-системы, выпустившей сертификат.
5. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
6. Выберите ветку вашего релиза в выпадающем списке Run for branch name or tag master-<имя релиза keystack>.
7. В открывшемся окне добавьте значение переменной KOLLA_ARGS равное -t grafana,opensearch,adminui.
8. Запустите пайплайн, нажав кнопку New pipeline.
9. Дождитесь завершения задач на этапе setup.
10. Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Для проверки настройки ролевой модели войдите в веб-интерфейс Портала администратора в домене itkey пользователями с разными ролями. Вход должен быть успешным, доступные элементы соответствовать роли пользователя.