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

Регионы используются для логического разделения инфраструктуры и ресурсов платформы 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-токена из проекта gen-pwd. При использовании ролевой модели это происходит автоматически и может занять около 10 минут.
1. Перейдите в раздел Settings > CI/CD > Job token permissions.
2. В разделе CI/CD job token allowlist нажмите кнопку Add и выберите Group or project.
3. В поле Group or project внесите значение project_k/deployments/gen-pwd.
4. Нажмите кнопку Add.
Выполнение некоторых пайплайнов развёртывания может занимать продолжительное время. Увеличьте таймаут пайплайнов по умолчанию:
1. Перейдите в раздел Settings > CI/CD > General pipelines.
2. Установите значение Timeout — 5h.
Настройте параметры инфраструктуры созданного региона:
1. Откройте файл certificates/ca/ca-bundle.crt и внесите в него корневой и промежуточный сертификаты.
2. Откройте файл inventory.
3. Заполните информацию об узлах инфраструктуры [control], [network], [compute] в формате <имя узла> ansible_host=<IP адрес узла>.
4. Откройте файл 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-адресами.
5. Если вы используете сервис балансировки нагрузки 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.

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

Запустите пайплайн на генерацию паролей и сертификатов для региона:
1. Откройте проект project_k / deployments / gen-pwd.
2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
3. В открывшемся окне добавьте переменную OPENSTACK_ENV, в качестве значения укажите имя созданного региона.
4. Запустите пайплайн New pipeline.
5. Запустите задачу create-config и дождитесь её завершения.
Повторите запуск пайплайна нужное количество раз, если создано несколько регионов.

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

Для реализации автоэвакуации ВМ при сбое гипервизора, задайте пароль интерфейса 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_password — LDAP,
- smtp_password — SMTP,
- cinder_dorado_user_password — СХД.

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

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

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

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

Настройка BGP

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

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

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

Запустите пайплайн по развёртыванию региона:
1. Откройте веб-интерфейс развёрнутого GitLab.
2. Откройте проект project_k / deployments / <имя региона>.
3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
4. В открывшемся окне при необходимости укажите значения переменных:
  KOLLA_ARGS — дополнительные теги:
  
  --limit <имя узла> — выполнить пайплайн для отдельного узла платформы;
  
  --tags <имя компонента> — выполнить пайплайн для отдельного компонента платформы.
  
  KOLLA_ANSIBLE_DEPLOY_ACTION — список задач для kolla-ansible, должно быть указано deploy;
  
  KEYSTACK_RELEASE — версия KeyStack для развёртывания.
5. Запустите пайплайн New pipeline.
6. Дождитесь завершения задачи setup.
7. Запустите задачу bootstrap-servers и дождитесь её завершения. Если после её завершения автоматически запустятся связанные задачи, дождитесь их завершения.
8. Запустите задачу deploy и дождитесь её завершения.

Примечание

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

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

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

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

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

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

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

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

Добавьте новые узлы в файл inventory репозитория региона в соответствующие группы ([control], [network], [compute]).
Запустите пайплайн с дополнительными параметрами:
1. Откройте веб-интерфейс развёрнутого GitLab.
2. Откройте проект project_k / deployments / <имя региона>.
3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
4. В открывшемся окне добавьте переменную 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) во время операции.
5. Запустите пайплайн New pipeline.
6. Дождитесь завершения задачи setup.
7. Запустите задачу bootstrap-servers и дождитесь её завершения.
8. Запустите задачу deploy и дождитесь её завершения.

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

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

Примечание

Для настройки ролевой модели необходимо включить интеграцию с каталогами LDAP на этапе установки LCM (опция auth LDAP for Gitlab and NetBox).

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

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

Откройте веб-интерфейс развернутого GitLab.
Откройте проект project_k / deployments / <имя региона>.

Найдите файл globals.d/REGION.yml и добавьте в него строки:

horizon_keystone_multidomain: "True"
horizon_keystone_domain_choices:
default: default
itkey: itkey

keystone_ldap_url: "ldaps://<адрес вашего сервиса LDAPS>"

Создайте файл config/keystone/domains/keystone.itkey.conf следующего содержания. При необходимости в group_filter и user_filter замените значения CN с префиксом group_ на названия ваших групп LDAP, а в значениях DC= укажите ваши компоненты домена:

[identity]
driver = ldap

[ldap]
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_*))"
password = "{{ ldap_password }}"
query_scope = sub
suffix = "DC=test-keystack,DC=vm,DC=lab,DC=itkey,DC=com"
user_tree_dn = "DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com"
url = "{{ keystone_ldap_url }}"
user = "CN=ldap-ro,CN=Users,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com"
user_filter = "(&(objectClass=person)(objectClass=user)(|(memberof=CN=group_infra_admin,OU=Keystack,OU=Applications,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com)(memberof=CN=group_support_admin,OU=Keystack,OU=Applications,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com)(memberof=CN=group_security_admin,OU=Keystack,OU=Applications,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com)(memberof=CN=group_reader,OU=Keystack,OU=Applications,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com)(memberof=CN=group_member,OU=Keystack,OU=Applications,DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com)))"
user_allow_create = False
user_allow_delete = False
user_allow_update = False
user_enabled_attribute = userAccountControl
user_enabled_default = 512
user_enabled_mask = 2
user_id_attribute = cn
user_mail_attribute = mail
user_name_attribute = sAMAccountName
user_objectclass = person
user_pass_attribute = userPassword
group_tree_dn = "DC=mydomain-keystack,DC=vm,DC=lab,DC=itkey,DC=com"
page_size = 0

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

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

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

$ openstack group list --domain itkey
+------------------------------------------------------------------+----------------------+
| ID                                                               | Name                 |
+------------------------------------------------------------------+----------------------+
| 6588de10efbf97de47b57c9fd0fc5fbbce8bbc26ae7bbcd50511430cc96b8f50 | group_infra_admin    |
| c94274dc724eb1aac6797ac99fd3cae2eeb1d3bc0135dc6bfa586d573736099e | group_member         |
| 1797223b40aa8409eba0ff0fe84c239a25e3f93ced5e8e55d230da5ccda373d2 | group_reader         |
| eb599167d78c91450e1ab74ff4077584a817be9c8f20144badcd88a11d46a0cc | group_security_admin |
| ce17c914eeb85f554332f8ccd7eb9a7d8494dc5b77f006db2984a519e440ec8c | group_support_admin  |
+------------------------------------------------------------------+----------------------+

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

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

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

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

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

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

Добавьте роли auditor и reader:

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

Для проверки настройки ролевой модели войдите в веб-интерфейсы AdminUI и Horizon в домене itkey пользователями с разными ролями. Вход должен быть успешным, доступные элементы соответствовать роли пользователя.