Подготовка параметров для инсталляции

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

1. Подготовка Inventory-окружения.
2. Настройка внешних сетей Платформы.
3. Настройка параметров производительности Платформы.
4. Настройка прочих параметров Платформы.
5. Организация IaC-кода для инсталлятора.
6. Проверка полученных артефактов.
7. Правка конфигурации Ansible.

После настройки всех параметров inventory перейдите к запуску инсталлятора (подробнее — в разделе Запуск инсталлятора).

Для создания первоначального inventory при первичной установке Платформы используется Inventory-генератор (invgen).

Inventory-генератор выполняет следующие функции:

• Копирование необходимых уникальных параметров из файла конфигурации minimal.yml в структуру inventory.

• Включение или отключение установки определенных компонентов Платформы (DBaaS, Kubernetes и прочее).

• Генерирование случайных секретных переменных Платформы (сложные уникальные пароли, ключи в правильном формате, токены с правильной длиной и прочее).

Подготовьте параметры для автоматической Inventory-генерации:

1. Перейдите в ранее распакованную директорию с генератором:

    
   $ ls /opt/vkcloud/invgen_box-${RELEASE_NAME}invgen-darwin-amd64  invgen-darwin-arm64  invgen-linux-amd64  invgen-linux-arm64  invgen-windows-amd64.exe

   Архив содержит пять исполняемых файлов для Inventory-генерации:

   • invgen-darwin-amd64 — для macOS с архитектурой amd64.
   • invgen-darwin-arm64 — для macOS с архитектурой arm64.
   • invgen-linux-amd64 — для Linux с архитектурой amd64 (подходит для РЕД ОС).
   • invgen-linux-arm64 — для Linux с архитектурой arm64.
   • invgen-windows-amd64.exe — для Windows с архитектурой amd64.

2. Скопируйте исполняемый файл в рабочую директорию /opt/vkcloud:

    
   $ cp /opt/vkcloud/invgen_box-${RELEASE_NAME}/invgen-linux-amd64 /opt/vkcloud

3. Перейдите в эту директорию и запустите выгрузку основных параметров в minimal.yml:

    
   $ chmod 755 /opt/vkcloud/invgen-linux-amd64$ ./invgen-linux-amd64 config-example > minimal.yml

В файле minimal.yml приведено описание переменных с примерами заполнения в виде комментариев. Заполните его в соответствии со значениями из Технического паспорта.

При установке Платформы в трех зонах доступности, учтите особенности заполнения файла minimal.yml (подробнее — в разделе Особенности установки Платформы в нескольких зонах доступности).

 
$ vi minimal.yml

Файл minimal.yml поделен на разделы:

1. equipment — управление количеством узлов для серверов определенных ролей (control, compute и пр.).
2. components — управление компонентами Платформы. Именно его в первую очередь необходимо сверять с таблицей в разделе Конфигурации VK Private Cloud.
3. vars — переменные, которые необходимо заполнить под вашу среду (IP, домены, названия VLAN и прочее).
4. networks — параметры для подключения Платформы к внешней корпоративной среде (BGP, MTU и прочее).
5. host_templates — правила именования и нумерации узлов по hostname и по IP.
6. hosts — дополнительные переменные для определенных узлов.
7. groups — включение определенных узлов в определенные группы. Пример: включение поддержки SCSI не на всех вычислительных узлах, а только на некоторых.
8. vault — секретные данные, которые не могут быть сгенерированы самостоятельно на этапе первичной установки. Примеры: доступы к AD/LDAP, к электронной почте, сертификаты и прочее.

В разделе equipment указывается желаемое количество физических серверов определенных ролей Платформы:

1. controller — управляющие узлы для организации работы с облачными сервисами.

   Минимальное количество зависит от варианта установки:

   • Single AZ — 3 узла. Пример значения: [3].

   • Multi AZ — 9 узлов. Пример значения: [3,3,3].

2. network — отдельные узлы для возможности перемещения сервисов обеспечения сетевой нагрузки пользовательских сущностей:

   • Использование опционально как для Single AZ, так и для Multi AZ. Если указать [0], обеспечение сетевой нагрузки пользовательских сущностей автоматически переместится на управляющие узлы.
   • При использовании в варианте Single AZ количество узлов может быть любым.
   • При использовании в варианте Multi AZ должно быть не меньше 2 узлов в каждой зоне доступности. Пример значения: [2,2,2].
   • Разверните узлы этой роли в инсталляциях, где количество виртуальных портов потенциально превышает 5000.

3. compute — вычислительные узлы для физического расположения пользовательской нагрузки:

   • Может быть любое количество.
   • Указывается общее количество узлов, а поддержка дополнительных подключений highiops, lld или nvmebox настраивается поверх указанного количества узлов (подробнее — в разделе Раздел components).

4. ceph — узлы для реализации Ceph-кластера:

   • В production-среде может быть от 3 до 9 узлов.
   • В production-среде может быть несколько Ceph-кластеров.
   • Для тестовой среды может быть установлен 1 узел, но в виде исключения.
   • При отключении компонента ceph (подробнее — в разделе Раздел components) укажите значение [[0]].
   • Пример значения в варианте Multi AZ: [[3],[3],[3]]
   • Если в одной зоне доступности несколько Ceph-кластеров, укажите количество ВМ через запятую. Пример: [[9,3],[3],[3,6]].

5. rs — узлы для организации BGP-пиров Платформы:

   • Возможное количество: 0, 1 или 2. Пример значения: [1].
   • При использовании корпоративной BGP-сети для работы Платформы можно указать 0.
   • Пример значения в варианте Multi AZ: [1,1,1].

6. logging — узлы, обеспечивающие функции мониторинга и логирования:

   • Возможное количество: 1 или 3. Пример значения: [3].
   • Эти серверы работают исключительно с серверами Платформы и не являются частью компонентов maas и laas.

7. evh — отдельные узлы для поддержки нагрузки, генерируемой пользователями при работе с компонентами maas и laas:

   • Возможное количество: 0 или 3. Пример значения: [] или [3].
   • При значении 0 нагрузка от метрик компонента maas и логов компонента laas переместится на управляющие узлы.
   • Разверните узлы этой роли в инсталляциях, где количество потребителей maas и laas потенциально превышает 1000.

8. dns — серверы для реализации функций PublicDNS. Не используются в VK Private Cloud версии 4.3, поэтому укажите [].

В разделе components можно включать или отключать компоненты Платформы.

В зависимости от включенных компонентов в разделе components файла minimal.yml Inventory-генератор создаст inventory с нужными параметрами для выбранной конфигурации.

Компоненты раздела components делятся на два вида:

• Функциональные.
• Дополнительные.

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

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

• Конфигурация #2: audit20, ceph, billing, highiops, manila, octavia, xaas.
• Конфигурация #4: audit20, billing, laas, maas, magnum, manila, nvmebox, octavia, trove, xaas.
• Конфигурация #5: audit20, billing, ceph, gpu, highiops, laas, lld, maas, magnum, manila, nvmebox, octavia, trove, vdi, xaas.
• Конфигурация #7: audit20, billing, ceph, gpu, highiops, laas, maas, magnum, manila, nvmebox, octavia, trove, vdi, xaas.
• Конфигурация #8: ceph, billing, highiops, laas, lld, maas, octavia.

Указанный состав наборов не является окончательным для запуска Платформы. Ориентируйтесь на таблицу в разделе Конфигурации VK Private Cloud. Параметры, зависящие от конфигурации, отмечены в тексте номерами конфигураций.

Включите компоненты в соответствии с выбранной конфигурацией:

1. Cloud Audit (Audit 2.0) — фиксация действий пользователей с Платформой. Чтобы включить, добавьте параметр audit20 в раздел components.

2. Billing — биллинг. Чтобы включить, добавьте параметр billing в раздел components.

3. Cloud Logging — Logging as a Service. Чтобы включить:

   • Добавьте параметр laas в раздел components.
   • Заполните переменную laas_public_endpoint_domain.

4. Cloud Monitoring — Monitoring as a Service. Чтобы включить:

   • Добавьте параметр maas в раздел components.
   • Заполните переменную maas_public_endpoint_domain.

5. Magnum — Kubernetes as a Service. Чтобы включить:

   • Добавьте параметр magnum в раздел components.
   • Заполните переменную helm_nexus_proxy_domain — URL Docker-репозитория с Kubernetes-образами.

6. Manila — подключение удаленных файловых хранилищ к ВМ по протоколам CIFS или NFS. Чтобы включить, добавьте параметр manila в раздел components.

7. Octavia — Load Balancer as a Service. Чтобы включить:

   • Добавьте параметр octavia в раздел components.
   • Заполните переменную controller.addresses.network_address_octavia в разделе host_templates — виртуальная подсеть для управления клиентскими балансировщиками.

8. Trove — Databases as a Service. Чтобы включить:

   • Добавьте параметр trove в раздел components.

   • Заполните переменные:

     • helm_nexus_proxy_domain — URL raw-репозитория с расширениями для БД.
     • trove_s3_static_access_key и trove_s3_static_secret_key — S3-ключи для выгрузки резервных копий БД на S3.

9. VDI — Virtual Desktop Infrastructure. Чтобы включить:

   • Добавьте параметр vdi в раздел components.
   • Заполните переменную vdi_public_endpoint_domain.

10. XaaS — Everything as a service. Чтобы включить, добавьте параметр xaas в раздел components.

11. NVMeBox — вид хранилища, организованного путем подключения внешних СХД к Платформе по iSCSI. Чтобы включить:

    • Добавьте параметр nvmebox в раздел components.

    • Заполните переменные:

      • nvmebox_shared_lun_device — путь до iSCSI-дисков (глобальные блокировки).
      • nvmebox_lock_lun_device — путь до iSCSI-дисков (клиентские данные).
      • nvmebox_announce_ip — IP-адрес API NVMeBox в сети Management.
      • nvmebox_number_of_types — общее количество типов дисков СХД на Платформе.

12. High IOPS — вид хранилища, реализованного поверх нескольких SSD- или NVMe-дисков. Чтобы включить:

    • Добавьте параметр highiops в раздел components.

    • Заполните переменные:

      • cinder_hiops_cinder_state_vol_size — размер тома, используемого для конвертации образов.
      • lvm_mirrors_count — количество зеркал для LVM-томов.
      • hiops_disk_format_name — фильтр устройств High IOPS-дисков.
      • hiops_disks_regexp — regex-фильтр iSCSI-устройств.
      • groups.highiops — перечень узлов, где будут развернуты High IOPS-диски.

13. LLD — вид хранилища, реализованного поверх нескольких SSD- или NVMe-дисков. Диски презентуются непосредственно как LV-том. Чтобы включить:

    • Добавьте параметр lld в раздел components.

    • Заполните переменные:

      • cinder_hiops_cinder_state_vol_size — размер тома, используемого для конвертации образов.
      • lvm_mirrors_count — количество зеркал для LVM-томов.
      • lld_disk_format_name — фильтр устройств LLD-дисков.
      • lld_disks_regexp — regex-фильтр дисков, которые будут использованы под LLD.
      • groups.lld — перечень узлов, где будут развернуты LLD-диски.

14. Ceph — вид хранилища, реализованного путем подключения Ceph-кластера. Чтобы включить:

    • Добавьте параметр ceph в раздел components.

    • Заполните переменные:

      • network_address_cephexternal — внешняя сеть для доступа к данным Ceph.
      • network_address_cephinternal — внутренняя кластерная сеть Ceph.
      • disk_format_name — фильтр устройств Ceph.
      • ceph_osd_disks_regexp — regex-фильтр для данных устройств.
      • ceph_osd_pool_default_size — количество реплик данных в кластере Ceph.
      • ceph_osd_pool_default_min_size — количество репликаций для отправки подтверждения операции ввода-вывода.
      • ceph_mon_hosts — расположение компонентов MON/MGR/MDS.

В разделе vars выполняется настройка различных переменных Платформы.

В этом разделе настраиваются как переменные, значения которых нужно подставить из Технического паспорта, так и переменные, значения которых нужно получить непосредственно на узлах Платформы. Информация обо всех переменных приведена в сопутствующих комментариях в файле minimal.yml. Наиболее сложные переменные описаны ниже.

Количество подсетей должно соответствовать количеству зон доступности.

 
vars:...  network_address_management: ["10.30.3.0/24"]  network_address_portal: ["10.30.5.0/27"]  network_address_cephexternal: ["10.30.10.0/26"]  network_address_cephinternal: ["10.30.11.0/26"]  network_address_octavia: ["10.254.0.0/16"]...

 
vars:...  network_address_management: ["10.30.3.0/24","10.20.3.0/24","10.10.3.0/24"]  network_address_portal: ["10.30.5.0/27","10.20.5.0/27","10.10.5.0/27"]  network_address_cephexternal: ["10.30.10.0/26","10.20.10.0/26","10.10.10.0/26"]  network_address_cephinternal: ["10.30.11.0/26","10.20.11.0/26","10.10.11.0/26"]  network_address_octavia: ["10.251.0.0/16","10.252.0.0/16","10.253.0.0/16"]...

Задайте способ подключения клиентских ресурсов к внешней сети (External Network). Для этого укажите нужное значение переменной external_network_variant:

• shared — одна или несколько общих внешних сетей на все проекты (#2, #8).
• per-project (провайдерские сети) — одна или несколько внешних сетей на каждый проект (#4, #5, #7).

Настройка внешних сетей выполняется после генерации Inventory (подробнее — в разделе Настройка внешних сетей Платформы).

В качестве хранилища образов ВМ для сервиса Glance могут использоваться:

1. Ceph (#2, #5, #8) — хранение образов в отдельных RBD на Ceph-кластере. Для включения заполните параметр glance_type_store значением rbd.

2. Cinder (#4) — хранение образов на СХД. Для включения заполните параметр glance_type_store значением cinder.

3. VK Object Storage или сторонний S3 (#7) — хранение образов в VK Object Storage или любом внешнем S3-сервисе. Для включения заполните параметры:

   • glance_type_store — укажите значение s3.
   • s3_schema — укажите значение http.
   • s3_host — IP-адрес узла logging в сети Management.
   • s3_port — укажите значение стандартного рабочего порта S3 (9000).
   • glance_s3_bucket — имя созданного в S3 бакета для образов Glance.
   • glance_s3_tmp_bucket — имя созданного в S3 бакета для временных образов Glance.
   • glance_s3_access_key — Access-ключ для доступа к S3 основного бакета хранения образов.
   • glance_s3_secret_key — Secret-ключ для доступа к S3 основного бакета хранения образов.
   • glance_s3_tmp_access_key — Access-ключ для доступа к S3 временного бакета хранения образов.
   • glance_s3_tmp_secret_key — Secret-ключ для доступа к S3 временного бакета хранения образов.

   Подробнее о работе с бакетами VK Object Storage — в документе Руководство администратора VK Object Storage. Подробнее о работе с бакетами стороннего S3 — в документации соответствующего сервиса.

Время жизни токена авторизации API указывается в параметре session_expire_period в секундах.

 
...session_expire_period: 28800...

Подробнее об изменении времени жизни токена и времени неактивности (бездействия) пользователя — в документе Руководство администратора VK Private Cloud в разделе Интерфейсы и инструменты → REST API → Настройка срока действия токена аутентификации.

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

 
...force_2fa_enabled: true...

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

 
...  keystone_ip_limiter_admin_ip_list_additional:    - 10.10.30.0/24    - 100.70.16.0/22...

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

 
...polkit_libvirt_enable: false...

В разделе networks выполняется настройка сетевой конфигурации Платформы: BGP, MTU и т.п.

В этом разделе настраиваются как переменные, значения которых нужно подставить из Технического паспорта, так и переменные, значения которых нужно получить непосредственно на узлах Платформы. Информация обо всех переменных приведена в сопутствующих комментариях в файле minimal.yml. Наиболее сложные переменные описаны ниже.

Словарь bgp_switches содержит список BGP-cоседей. Он заполняется согласно Техническому паспорту (раздел 5.2.1, пункт 3).

 
...  networks:    bgp_switches:      - name: vkrouter        as: 65431        ip: "10.30.3.22"...

 
...  networks:    bgp_switches:      - name: vkrouter-az1        as: 65431        ip: "10.30.3.22"        az: "AZ1"      - name: vkrouter-az2        as: 65431        ip: "10.30.3.22"        az: "AZ2"      - name: vkrouter-az3        as: 65431        ip: "10.30.3.22"        az: "AZ3"...

Для корректной установки Платформы в варианте Multi AZ нужно задать параметрам neutron_dhcp_multiaz и neutron_l3_multiaz значение true.

 
networks:...    neutron_dhcp_multiaz: true    neutron_l3_multiaz: true...

В разделе groups существующие серверы можно добавить в подгруппы и таким образом подключить к ним дополнительные компоненты для расширения функциональности Платформы. Пример: серверы Compute (вычислительные узлы) можно добавить в подгруппу highiops, чтобы преобразовать их в compute node High IOPS.

 
groups:  highiops:    az1:      - kcn002

 
groups:  highiops:    az1:      - dc1kcn002    az2:      - dc2kcn002    az3:      - dc3kcn002

В разделе host_templates указаны правила именования серверных ролей.

Имена формируются из отдельных блоков в соответствии с шаблоном:

 
{dc}{prefix}{role}{counter}{extra}{number}{suffix}

Особенности:

• Каждый блок шаблона генерируется отдельно и затем блоки объединяются в итоговое имя.
• Пустые блоки в генерации не участвуют.

В этом разделе описан пример структуры словаря host_templates для серверов с ролью controller node (управляющий узел). Шаблон используется для генерации имен узлов и назначения IP-адресов в различных сетях. Пример актуален и для других групп узлов.

 
host_templates:  controller:    name: {}    addresses: {}

В разделе name имя узла формируется из отдельных блоков, которые объединяются в итоговую строку. Пустые или неиспользуемые блоки в генерации не участвуют. Раздел name состоит из блоков:

• dc — используется для варианта Multi AZ и задает идентификатор зоны доступности.

  Параметры:

  • name — строковый префикс зоны. Если значение не задано, блок не используется.

  • start — начальное значение.

  • size — список с количеством узлов для каждой зоны доступности. Сумма элементов должна соответствовать количеству серверов в equipment.

  • digits — количество ведущих нулей. Пример:

    • digits: 1 → dc1,
    • digits: 2 → dc01,
    • digits: 3 → dc001.

• prefix — добавляет строковый префикс после блока dc.

• role — добавляет обозначение роли узла после блока prefix.

• counter — дополнительная нумерация узлов:

  • Генерирует только числовые значения.

  • По умолчанию отключен. Для включения нужно указать use: true.

  • Использует ту же логику, что и блок dc.

• extra — добавляет произвольную строку после блока counter.

• number — основная нумерация узлов. Параметры:

  • start — начальное значение;
  • size — список для нумерации;
  • digits — количество ведущих нулей.

• suffix — добавляет строку в конец имени узла.

• exceptions — позволяет заменить автоматически сгенерированные имена на заданные вручную. Поддерживается замена одного или нескольких имен.

В разделе addresses определяются правила выделения IP-адресов для различных сетей.

Общие параметры IP-адресации:

• network_name — название сети (подробнее — в разделе Раздел vars).

• start — стартовый индекс адреса в сети. Каждый элемент массива соответствует зоне доступности.

• range — альтернативный способ задания диапазонов IP-адресов. Поддерживаемые форматы:

  • 10.30.3.10-10.30.3.20 — явный диапазон;
  • 10.30.3.32/29 — подсеть;
  • .241-.2.31 — диапазон по последним октетам;
  • 11-15 — диапазон по номеру адреса;
  • 11- — от указанного адреса до конца сети.

  Для Multi AZ можно указать:

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

• Management;

• Additional Management;

• Private API Loopbacks;

• Public API Transport (Portal);

• Public API Loopbacks;

• Octavia (использует внутреннюю подсеть /16 и не участвует в маршрутизации).

 
host_templates:  controller:    name:      prefix: "spb99devctrl"      number:        start: 1        size: [3]        digits: 0

 
groups:  controller:    - spb99devctrl1    - spb99devctrl2    - spb99devctrl3

 
host_templates:  controller:    name:      prefix: "ekb99-iaas-ctl"      number:        start: 4        size: [3]        digits: 2

 
groups:  controller:    - ekb99-iaas-ctl04    - ekb99-iaas-ctl05    - ekb99-iaas-ctl06

В варианте Multi AZ использование блока {dc} является обязательным.

 
host_templates:  controller:    name:      dc:        name: "ekb99-iaas-ctl"        start: 1        size: [1, 1, 1]        digits: 1      number:        start: 1        size: [1, 1, 1]        digits: 2

 
groups:  controller:    - ekb99-iaas-ctl101    - ekb99-iaas-ctl201    - ekb99-iaas-ctl301

 
host_templates:    controller:      name:        dc:          name: "dc"          start: 1          size: [3,3,3]          digits: 1        number:          start: 1          size: [3,3,3]          digits: 3    network:      name:        dc:          name: "dc"          start: 1          size: [2,2,2]          digits: 1        number:          start: 1          size: [2,2,2]          digits: 3    compute:      name:        dc:          name: "dc"          start: 1          size: [2,2,2]          digits: 1        number:          start: 1          size: [2,2,2]          digits: 3    rs:      name:        dc:          name: "dc"          start: 1          size: [1,1,1]          digits: 1        number:          start: 1          size: [1,1,1]          digits: 3    ceph:      name:        dc:          name: "dc"          start: 1          size: [3,3,3]          digits: 1        number:          start: 1          size: [3,3,3]          digits: 3      addresses:        mon_address:          network_name: "network_address_cephexternal"          start: [20,20,20]        management_ip:          network_name: "network_address_management"          start: [60,60,60]

1. После заполнения файла minimal.yml запустите invgen:

    
   $ ./invgen-linux-amd64 generate

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

    
   $ ls /opt/vkcloud/inventory/vkcloud/ansible.cfg  group_vars  hosts.yml  host_vars  README.md  vkcloud.yml$ ls /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud                               vkcloud_galera_keycloak                 vkcloud_mcsvkcloud_audit                         vkcloud_galera_keystone                 vkcloud_mcs_breezevkcloud_az1_storage                   vkcloud_galera_maas                     vkcloud_mcs_duskvkcloud_barbican                      vkcloud_galera_magnum                   vkcloud_monitoring_frontendvkcloud_bff_stolon_cluster            vkcloud_galera_manila                   vkcloud_nbgpvkcloud_billingcore_stolon_cluster    vkcloud_galera_neutron                  vkcloud_networkvkcloud_ceph_osd                      vkcloud_galera_nova                     vkcloud_neutron_controllervkcloud_ch_cluster_cloudaudit         vkcloud_galera_octavia                  vkcloud_nova_controllervkcloud_ch_cluster_laas               vkcloud_galera_quotamanager             vkcloud_octaviavkcloud_ch_cluster_maas               vkcloud_galera_scrooge                  vkcloud_ost_kubevkcloud_ch_proxy                      vkcloud_galera_scroogearchive           vkcloud_privatedns_etcd_clustervkcloud_cinder                        vkcloud_galera_sdnbilling               vkcloud_private_haproxyvkcloud_cinder_backup                 vkcloud_galera_sdnprojectsapi           vkcloud_cinder_cephvkcloud_galera_trove                  vkcloud_public_haproxy                  vkcloud_clickhousevkcloud_galera_zabbix                 vkcloud_rabbitmq_persistent             vkcloud_cloudaudit_etcd_clustervkcloud_ghosts_privatedns_dataplane   vkcloud_rs                              vkcloud_cloudaudit_kafkavkcloud_glance                        vkcloud_redis                           vkcloud_computevkcloud_iam_etcd_cluster              vkcloud_scrooge_etcd_cluster            vkcloud_consulvkcloud_katana                        vkcloud_scst_iscsi                      vkcloud_control_planevkcloud_kube                          vkcloud_service_galera                  vkcloud_dhcpvkcloud_laas_etcd_cluster             vkcloud_servicesmanager_stolon_cluster  vkcloud_elk_kafkavkcloud_logstash                      vkcloud_stolon_cluster                  vkcloud_etcd_clustervkcloud_maas_etcd_cluster             vkcloud_syncservice_stolon_cluster      vkcloud_galera_barbicanvkcloud_maas_redis                    vkcloud_uncert_kube                     vkcloud_galera_billingaccountservicevkcloud_magnum_addons_stolon_cluster  vkcloud_victoriametrics_cloudmonitoring vkcloud_galera_cindervkcloud_magnum_etcd_cluster           vkcloud_xaas_kafka                      vkcloud_galera_evacuationvkcloud_magnumrapid_redis             vkcloud_xaas_stolon_cluster             vkcloud_galera_ghostsvkcloud_magnum_rapid_stolon_cluster   vkcloud_zabbix                          vkcloud_galera_glancevkcloud_manila_controller             vkcloud_zookeeper                       vkcloud_galera_karboiivkcloud_manila_share                                                       $ ls /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/addresses.yml           imageloader.yml           README.mdbgp.yml                 initial-install-vars.yml  test-stand-app-limits.ymlbox-builder.yml         INVENTORY.md              trove.ymlceph.yml                logging.yml               vars.ymlcommon.yml              manila.yml                vault.ymldeprecated.yml          memcached.yml             version_locks.ymlenabled-components.yml  networks.yml              versions.ymlfeature.yml             osimages.yml              yum-repos.ymlzabbix.yml              packages.yml              yum.ymliam.yml                 postdeploy.yml

   Чтобы узнать синтаксис команды invgen, выполните:

    
   $ ./invgen-linux-amd64 help

   Чтобы вывести описание определенной команды, выполните:

    
   $ ./invgen-linux-amd64 <КОМАНДА> --help

2. Удалите исполняемый файл Inventory-генератора:

    
   $ rm -rf invgen-*

Способ подключения клиентских ресурсов к внешней сети (External Network) через Floating IP-адрес ранее был задан в файле minimal.yml в переменной external_network_variant (подробнее — в разделе Способ подключения к внешней сети). В зависимости от значения переменной добавьте нужные сети:

• Добавление shared-сетей
• Добавление per-project-сетей

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

• /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/networks.yml

  Пример заполнения переменных в networks.yml

   
  external_networks_extend:  10.31.0.0/16:    type: vlan    project_id: '{{ breeze_katana_project }}'    network_name: external    shared: true    allocation_pools:      start: 10.31.1.0      end: 10.31.253.254    gateway_ip: '{{ (external_network_mode == ''bgp'')|ternary(''10.31.255.254'', ''10.31.0.22'') }}'    enable_dhcp: true

• /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/postdeploy.yml

  Шаблон заполнения переменных в postdeploy.yml

   
  external_networks_predefined:  shared:    # Список подключаемых сетей    - name: <НАЗВАНИЕ_СЕТИ>      external: true      shared: true      type: vlan      segmentation_id: <VLAN_ID>      subnet:        name: <НАЗВАНИЕ_ПОДСЕТИ>        dns_nameservers: [<DNS-СЕРВЕР>, <DNS-СЕРВЕР>]        gateway_ip: <МАРШРУТИЗАТОР>        cidr: <ПОДСЕТЬ>        allocation_pools:          start: <СТАРТ_ДИАПАЗОНА>          end: <ОКОНЧАНИЕ_ДИАПАЗОНА>        enable_dhcp: true

  Здесь:

  • <НАЗВАНИЕ_СЕТИ> — произвольное название сети. Допустимые символы: латинские буквы, цифры, подчеркивание и дефис.
  • external: true — сеть будет создана с флагом --external.
  • shared: true — видимость для прочих проектов. Сеть будет создана с флагом --shared.
  • type: vlan — тип подключения сети.
  • <VLAN_ID> — идентификатор VLAN создаваемой сети.
  • <НАЗВАНИЕ_ПОДСЕТИ> — произвольное название подсети. Допустимые символы: латинские буквы, цифры, подчеркивание и дефис.
  • <DNS-СЕРВЕР> — IP-адреса DNS-серверов.
  • <МАРШРУТИЗАТОР> — IP-адрес маршрутизатора по умолчанию.
  • <ПОДСЕТЬ> — CIDR подсети.
  • allocation_pools — диапазон IP-адресов, доступных для клиентских ресурсов. В диапазон включается вся подсеть, за исключением зарезервированных IP-адресов маршрутизаторов и серверов: Controller node, Compute node, Compute node High IOPS и Network.
  • <СТАРТ_ДИАПАЗОНА> — начальный IP-адрес диапазона.
  • <ОКОНЧАНИЕ_ДИАПАЗОНА> — конечный IP-адрес диапазона.
  • enable_dhcp: true — включение DHCP для подсети.

Для создания сетей per-project заполните переменные для проектов, пользователей и сетей в следующих файлах:

• /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/postdeploy.yml

  Шаблон заполнения переменных в postdeploy.yml

   
  prepare_user_project:  # Список проектов  <НАЗВАНИЕ_ПРОЕКТА>:    group_name: '<НАЗВАНИЕ_ГРУППЫ>'    username: '<ИМЯ_ПОЛЬЗОВАТЕЛЯ>'    password: '<ПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ>'    roles:      - <РОЛЬ>    sprut_is_enabled: false...external_networks_predefined:  per-project:    # Список подключаемых сетей    - name: <НАЗВАНИЕ_СЕТИ>      external: true      shared: true      type: vlan      segmentation_id: <VLAN_ID>      subnet:        name: <НАЗВАНИЕ_ПОДСЕТИ>        dns_nameservers: [<DNS-СЕРВЕР>, <DNS-СЕРВЕР>]        gateway_ip: <МАРШРУТИЗАТОР>        cidr: <ПОДСЕТЬ>        allocation_pools:          start: <СТАРТ_ДИАПАЗОНА>          end: <ОКОНЧАНИЕ_ДИАПАЗОНА>

  Здесь:

  • <НАЗВАНИЕ_ПРОЕКТА> — название создаваемого проекта.
  • <НАЗВАНИЕ_ГРУППЫ> — название создаваемой группы.
  • <ИМЯ_ПОЛЬЗОВАТЕЛЯ> — имя создаваемого пользователя.
  • <ПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ> — пароль создаваемого пользователя.
  • <РОЛЬ> — роль, которая будет назначена пользователю.
  • <НАЗВАНИЕ_СЕТИ> — произвольное название сети.
  • external: true — сеть будет создана с флагом --external.
  • shared: true — видимость для прочих проектов. Сеть будет создана с флагом --shared.
  • type: vlan — тип подключения сети.
  • <VLAN_ID> — идентификатор VLAN создаваемой сети.
  • <НАЗВАНИЕ_ПОДСЕТИ> — произвольное название подсети. Допустимые символы: латинские буквы, цифры, подчеркивание и дефис.
  • <DNS-СЕРВЕР> — IP-адреса DNS-серверов.
  • <МАРШРУТИЗАТОР> — IP-адрес маршрутизатора по умолчанию.
  • <ПОДСЕТЬ> — CIDR подсети.
  • allocation_pools — диапазон IP-адресов, доступных для клиентских ресурсов. В диапазон включается вся подсеть, за исключением зарезервированных IP-адресов маршрутизаторов и серверов: Controller node, Compute node, Compute node High IOPS и Network.
  • <СТАРТ_ДИАПАЗОНА> — начальный IP-адрес диапазона.
  • <ОКОНЧАНИЕ_ДИАПАЗОНА> — конечный IP-адрес диапазона.

• /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/networks.yml

  Шаблон заполнения переменных в networks.yml

   
  postdeploy_provider_network:    # Список подключаемых сетей    - name: <НАЗВАНИЕ_СЕТИ>      project: "<НАЗВАНИЕ_ПРОЕКТА>"      external: true      shared: true      type: vlan      segmentation_id: <VLAN_ID>      subnet:        name: <ПОДСЕТЬ>        dns_nameservers: [<DNS-СЕРВЕР>, <DNS-СЕРВЕР>]        gateway: <МАРШРУТИЗАТОР>        cidr: <ПОДСЕТЬ>        allocation_pools:          start: <СТАРТ_ДИАПАЗОНА>          end: <ОКОНЧАНИЕ_ДИАПАЗОНА>

  Здесь:

  • <НАЗВАНИЕ_СЕТИ> — произвольное название сети.
  • <НАЗВАНИЕ_ПРОЕКТА> — название проекта, для которого предоставляется эта сеть.
  • external: true — сеть будет создана с флагом --external.
  • shared: true — видимость для прочих проектов. Сеть будет создана с флагом --shared.
  • type: vlan — тип подключения сети.
  • <VLAN_ID> — идентификатор VLAN создаваемой сети.
  • <ПОДСЕТЬ> — CIDR подсети.
  • <DNS-СЕРВЕР> — IP-адреса DNS-серверов.
  • <МАРШРУТИЗАТОР> — IP-адрес маршрутизатора по умолчанию.
  • <ПОДСЕТЬ> — CIDR подсети.
  • allocation_pools — диапазон IP-адресов, доступных для клиентских ресурсов. В диапазон включается вся подсеть, за исключением зарезервированных IP-адресов маршрутизаторов и серверов: Controller node, Compute node, Compute node High IOPS и Network.
  • <СТАРТ_ДИАПАЗОНА> — начальный IP-адрес диапазона.
  • <ОКОНЧАНИЕ_ДИАПАЗОНА> — конечный IP-адрес диапазона.

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

Максимальное количество одновременных подключений к MariaDB задается параметром max_connections в файлах компонентов:

 
/opt/vkcloud/inventory/vkcloud/group_vars/vkcloud_galera_<КОМПОНЕНТ>/vars.yml

Здесь <КОМПОНЕНТ> — название компонента Платформы. Список компонентов приведен в таблице 1.

По умолчанию параметры max_connections для разных компонентов Платформы определены с помощью переменной galera_innodb_max_connections и профиля нагрузки galera_connection_profile.

 
# Выберите профиль нагрузки на соединения: heavy, regular или test. Подробнее в переменной galera_innodb_max_connectionsgalera_connection_profile: "{{ galera_connection_profile_override if galera_connection_profile_override | string | trim != '' else 'regular' }}"mysql:  # Калибровка Mysql. Название переменной должно соответствовать названию параметра в MySQL  innodb_io_capacity: 8000  innodb_buffer_pool_instances: 2  max_connections: "{{ galera_innodb_max_connections[galera_connection_profile] }}"  max_connect_errors: 4294967295  max_heap_table_size: 134217728  tmp_table_size: 134217728  innodb_read_io_threads: 16  innodb_buffer_pool_size: "{{ default_innodb_buffer_pool_size }}"  key_buffer_size: 134217728

Профили нагрузки заданы в файле /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/common.yml.

 
galera_innodb_max_connections:  regular: 50000  heavy: 5000000  test: 10000

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

Для инсталляции на ограниченных ресурсах и без пользовательского потока достаточно указать значение 1000 для всех компонентов.

При увеличении нагрузки на Платформу значения max_connections необходимо увеличить.

При необходимости измените размер буфера, выделяемого в оперативной памяти для каждой базы данных. Для этого в файле /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/common.yml измените значение переменной default_innodb_buffer_pool_size.

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

Увеличить значение в переменной innodb_buffer_pool_size можно в файле настроек для конкретной БД group_vars/vkcloud_galera_<БД>/vars.yml.

Рекомендации по заполнению переменных default_innodb_buffer_pool_size и innodb_buffer_pool_size:

• Для переменных default_innodb_buffer_pool_size и innodb_buffer_pool_size значение больше 7 ГБ является избыточным. Превышать его допустимо только в исключительных случаях.

• Переменные innodb_buffer_pool_size и default_innodb_buffer_pool_size поддерживают только числовые значения в байтах. Варианты вида 1G или 1024M не допускаются: в этом случае инсталлятор завершит работу корректно, но изменения не будут внесены.

Длительность хранения пользовательских логов от сервиса Cloud Logging настраивается в файле /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud_kube/laas-admin-api.yml в параметре helm_laas_admin_api_builtin_services_raw_content. Этот параметр содержит три вида клиентских ресурсов:

• IaaS-сервисы (id:Default).
• Контейнеры (id:Containers).
• DBaaS-сервисы (id:Databases).

Задайте длительность хранения логов в параметре ttl для каждого из ресурсов. Значение указывается в днях. Увеличение количества дней позволит дольше хранить логи, но при этом будет занимать больше места в ClickHouse-кластере.

Чтобы отправлять уведомления об инцидентах от сервиса Cloud Alerting, в файле /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud_kube/cloud-alerting.yml настройте параметры подключения к почтовому сервису:

• helm_cloud_alerting_smtp_host — узел SMTP-сервера.
• helm_cloud_alerting_smtp_port — порт SMTP-сервера.
• helm_cloud_alerting_smtp_user — имя пользователя для подключения к SMTP-серверу.
• helm_cloud_alerting_smtp_password — пароль для подключения к SMTP-серверу.
• helm_cloud_alerting_smtp_from_addr — электронная почта отправителя уведомлений.

По умолчанию пароль от пользователя root генерируется автоматически из 32 символов. Пароль содержится в файле /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/vault.yml в переменных:

• vault_root_password_plain_text — в открытом виде.
• vault_root_password — в закодированном виде.

 
$ grep vault_root_password  /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/vault.ymlvault_root_password_plain_text: XM8d4N61549P9XSJ64ctvault_root_password: $6$NQt7WcAu39s8eOyU$PJP7rb6MZ5p36suoQgU71MSBDXnF58AYaNZnlaDO3eKyJ./sv9Je/SDeLTZ/RSXAMUjtJIyC7o1v0cWYT3MWq

Оставьте сгенерированный пароль в качестве root-пароля либо поменяйте его на новый.

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

Чтобы поменять пароль на новый:

1. Зашифруйте новый пароль через Python:

    
   $ python3 -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'Password: *password*Confirm: *password*$6$AZAax7ZhzC3Mmv9A$KVc8C5odjXjz1A94ZvaYLpjSXh4hqZBlkpEHIZkhWveCJsrEaYYWpVHdqGaIezL/x3yaaOtXVEoveC6Iu0NXi1

2. Получившуюся строку внесите в переменную vault_root_password:

    
   $ vi  /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/vault.yml...vault_root_password: $6$AZAax7ZhzC3Mmv9A$KVc8C5odjXjz1A94ZvaYLpjSXh4hqZBlkpEHIZkhWveCJsrEaYYWpVHdqGaIezL/x3yaaOtXVEoveC6Iu0NXi1...

   При этом переменную vault_root_password_plain_text можно удалить, чтобы избежать путаницы в дальнейшем.

Подробнее о размещении данных с использованием CRUSH — в документе Руководство по проектированию VK Private Cloud в разделе Основные принципы проектирования новой инсталляции → Размещение данных при проектировании SDS Ceph.

Чтобы включить автоматическое формирование CRUSH-иерархии, включающей стойки (Rack), в файле minimal.yml в разделе vars заполните переменные:

• ceph_osd_build_crushmap — автоматическое построение CRUSH-иерархии: true — включено, false — отключено.

• ceph_osd_autodetect_weight — автоматическое вычисление весов OSD: true — включено, false — отключено. Если значение переменной false, вес всех созданных OSD по умолчанию — 1.

• ceph_clusters — описание спроектированной CRUSH-иерархии кластера Ceph в следующем виде:

   
  ceph_clusters:  ceph:    rack_01:      - csn001    rack_02:      - csn002    rack_03:      - csn003  ceph2:    rack_04:      - csn004    rack_05:      - csn005    rack_06:      - csn006  ceph3:    rack_07:      - csn007    rack_08:      - csn008    rack_09:      - csn009

  Здесь:

  • ceph, cephХ — названия кластеров.
  • rack_ХХ — названия стоек для размещения вычислительных узлов кластеров (Ceph-бакет с типом rack).
  • csnХХХ — названия вычислительных узлов кластеров.

Чтобы организовать окружение для подключения внешних СХД, выделите 3 управляющих узла для работы nvmebox и любое количество вычислительных узлов для доступа ВМ к внешнему СХД. Для этого:

1. В файле vkcloud.yml:

   1. В группу параметров vkcloud_cinder_nvmebox внесите управляющие узлы и определите уникальные значения параметров sanlock_host_id.

      Пример

       
      # NVMeBox Controllervkcloud_cinder:  children:    # ...    vkcloud_cinder_nvmebox:      hosts:         cpn001:            sanlock_host_id: 101         cpn002:            sanlock_host_id: 102         cpn003:            sanlock_host_id: 103

   2. В группу параметров vkcloud_nvmebox_agent внесите вычислительные узлы и определите уникальные значения параметров sanlock_host_id.

      Пример

       
      # NVMeBox Nodesvkcloud_nvmebox_agent:   hosts:      kcn001:         sanlock_host_id: 201      kcn002:         sanlock_host_id: 202# ...

2. На указанных в файле vkcloud.yml узлах подключите iSCSI-диски. Подробнее — в разделе Подключение iSCSI для NVMeBox.

3. В файле group_vars/vkcloud/nvmebox.yml заполните следующие параметры:

   • nvmebox_profile — произвольное имя профиля сервиса nvmebox. Для каждого кластера используется свое имя профиля. Рекомендуется использовать имя, описывающее СХД.

   • nvmebox_cluster_service_unit — произвольное имя сервиса nvmebox. Рекомендуется использовать имя, описывающее СХД.

   • nvmebox_cluster_vg_name — имя кластерной VG, которая будет создана автоматически при развертывании сервиса.

   • nvmebox_pool_reservation — доля емкости хранилища, резервируемая под служебные операции. Значение по умолчанию — 0.2, что соответствует 20% от емкости. Диапазон допустимых значений: 0–1.

     Резерв не учитывается в доступной емкости при создании и расширении дисков и остается свободным для служебных данных: снимков (snapshots) и других операций. Резерв вычисляется как доля от общей емкости, поэтому на больших СХД он может составлять значительный объем. В этом случае значение параметра можно снизить.

   • nvmebox_erase_on_create — очистка пространства на кластерной VG, занимаемого диском при его создании (команда blkdiscard). Значение по умолчанию — true.

     Очистка гарантирует, что на новом диске не окажется данных ранее удаленных дисков. Если СХД не поддерживает быстрое выполнение операции discard, создание больших дисков может занимать продолжительное время. Параметр можно отключить, но в этом случае данные ранее удаленных дисков могут быть доступны на новых.

   В них определяются технические данные о работе Платформы c iSCSI-дисками.

   Пример заполнения параметров

    
   nvmebox_profile: sharedlunnvmebox_cluster_service_unit: sharedlun-clusternvmebox_cluster_vg_name: slvg-0nvmebox_pool_reservation: 0.2nvmebox_erase_on_create: true

4. В файле /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/common.yml укажите основные настройки для внешней СХД:

    
   cinder_backends_available_by_type:   nvmebox-type1: "{{ nvmebox_profile }}"   nvmebox-type2: "sharedlun-hdd"

5. В случае использования Trove и Magnum укажите диски nvmebox-typeX:

   • В файле group_vars/vkcloud_kube/trove.yml:

      
     trove_volume_types:  - nvmebox-type1  - nvmebox-type2

   • В файле group_vars/vkcloud_kube/magnum.yml:

      
     magnum_volume_types:   - nvmebox-type1   - nvmebox-type2

6. Укажите квоты по умолчанию для внешней СХД в файле group_vars/vkcloud/quotas.yml:

    
   quota_templates:  # ...   - name: "infra"      quotas:         cinder:            # Квоты на количество виртуальных дисков во Внешнем СХД первого типа            volumes_nvmebox-type1: 3            # Квоты на суммарный объем виртуальных дисков во Внешнем СХД первого типа            gigabytes_nvmebox-type1: 100            volumes_nvmebox-type2: 6            gigabytes_nvmebox-type2: 200   # ...   - name: "infra+paas"      quotas:         cinder:            # Заполняется идентично с "infra"            volumes_nvmebox-type1: 3            gigabytes_nvmebox-type1: 100            volumes_nvmebox-type2: 6            gigabytes_nvmebox-type2: 200# ...openstack_quotas:   service:   # ...      volume_quotas:      # ...         # Аналогично с "quota_templates"         volumes_nvmebox-type1: 3         gigabytes_nvmebox-type1: 100         volumes_nvmebox-type2: 6         gigabytes_nvmebox-type2: 200

7. В файле group_vars/vkcloud_kube/mcs-admin-ui.yml укажите имена квот для внешних СХД на русском и английском языках:

    
   helm_superadmin_configuration_tpl:   # ...   regions:      # ...      info:        locale:          en:            regionName: Moscow            cinder_volumes_nvmebox-type1: External disk (DAS) 1            cinder_gigabytes_nvmebox-type1: External disk (DAS) 1            cinder_volumes_nvmebox-type2: External disk (DAS) 2            cinder_gigabytes_nvmebox-type2: External disk (DAS) 2          ru:            regionName: Москва            cinder_volumes_nvmebox-type1: Внешний диск (СХД) 1            cinder_gigabytes_nvmebox-type1: Размер внешнего диска (СХД) 1            cinder_volumes_nvmebox-type2: Внешний диск (СХД) 2            cinder_gigabytes_nvmebox-type2: Размер внешнего диска (СХД) 2

8. Включите счетчик квот в файле group_vars/vkcloud_kube/quota-manager.yml:

    
   helm_quota_manager_enabled_services_yaml:  cinder:      - volumes_nvmebox-type1      - gigabytes_nvmebox-type1      - volumes_nvmebox-type2      - gigabytes_nvmebox-type2

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

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

 
/opt/vkcloud/inventory/vkcloud/group_vars/vkcloud_compute/vars.yml

 
...  nova_force_config_drive: true...

IaC-код расположен в директории repos_mcs_distr_box-<ВЕРСИЯ_РЕЛИЗА>, которая ранее была распакована.

1. Перейдите в директорию repos_mcs_distr_box-<ВЕРСИЯ_РЕЛИЗА>:

    
   $ ls /opt/vkcloud/repos_mcs_distr_box-${RELEASE_NAME}/ansible-openstack  gitinfo.txt  invgen-version  mcs-ceph-deploy  terraform_manifests  upgrade

   Директория repos_mcs_distr_box-<ВЕРСИЯ_РЕЛИЗА> включает в себя следующие файлы и директории:

   • ansible-openstack/ — Ansible-плейбуки и роли для установки Платформы.
   • gitinfo.txt — техническая информация для разработки. Необходим на случай отладки.
   • invgen-version — версия Inventory-генератора под ваш релиз. Необходим на случай отладки.
   • mcs-ceph-deploy/ — вспомогательные инструменты для настройки Ceph.
   • terraform_manifests/ — примеры Terraform-манифестов для проверки работы IaC-составляющей облака.

2. Скопируйте директорию ansible-openstack/ в директорию /opt/vkcloud/inventory.

    
   $ cp -r /opt/vkcloud/repos_mcs_distr_box-${RELEASE_NAME}/ansible-openstack /opt/vkcloud/inventory/ansible-openstack

После выполнения всех шагов этого раздела проверьте содержимое директории inventory:

 
$ ls /opt/vkcloud/inventory/*/opt/vkcloud/inventory/ansible-openstack:library  playbooks  roles  tools/opt/vkcloud/inventory/tools:box.sh.d/opt/vkcloud/inventory/vkcloud:ansible.cfg  group_vars  hosts.yml  host_vars  README.md  vkcloud.yml

Директория должен содержать целевые IaC-инструменты для процесса установки Платформы и ее дальнейшего обслуживания:

• ansible-openstack — директория с Ansible-ролями и плейбуками.
• tools — настройки скрипта установки box.sh.
• vkcloud — inventory стенда.

Файл конфигурации Ansible (ansible.cfg) расположен в директории /opt/vkcloud/inventory/vkcloud. Настройте его для дальнейшего использования.

Настройте директорию, в которой будут храниться логи выполнения Ansible-плейбуков:

1. При необходимости измените директорию. Для этого укажите в параметре log_path путь до удобной директории. Пример:

    
   $ vi inventory/vkcloud/ansible.cfg +17...log_path = $HOME/ansible/ansible-openstack.log...

2. Создайте директорию, указанную в параметре log_path, даже если вы не меняли его значение. Пример:

    
   $ mkdir $HOME/ansible

Файл group_vars/vkcloud/vault.yml содержит пароли Платформы. При условии, что злоумышленники гарантированно не смогут его прочитать, вы можете оставить его в открытом виде. Иначе зашифруйте его. Это повысит безопасность хранения паролей, но усложнит администрирование Платформы.

Чтобы оставить файл group_vars/vkcloud/vault.yml открытым, удалите из файла ansible.cfg строку с параметром vault_identity_list:

 
$ sed -i '/vault_identity_list/d' /opt/vkcloud/inventory/vkcloud/ansible.cfg

Чтобы зашифровать файл /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/vault.yml:

1. Создайте файл с новым паролем для Ansible vault:

    
   $ echo "my-vault-secret-password" > ~/.ansible.vault-vkcloud

2. Зашифруйте файл /opt/vkcloud/inventory/vkcloud/group_vars/vkcloud/vault.yml:

    
   $ ansible-vault encrypt group_vars/vkcloud/vault.yml

   Пример зашифрованного содержимого файла

    
   $ head group_vars/vkcloud/vault.yml$ANSIBLE_VAULT;1.2;AES256;vkcloud356138323034633933393838643365306565613236613632353562636537386630663632303438366363386337356434373362303062633662313266396235310a356164626431393531333663633131623964336461313832633534353762353534326137313362393237366366666263643737366566303161326262313732350a3436663533363234336435353062333564343839333633316235393339643865336334303138396639366439616130306537626335303238373338343566396235623866343135626361663536626539613435643032383361356132346536353635386461383637343363623138346636323861393933623636323962326333666538386561383039633065343561306430306438666630636637326235373663333666363738343462613162306366343739643663666238396133663833326636633338646239373362376134353938646161396433633365313531663332353138303732

Чтобы внести изменения в зашифрованный файл, выполните команду:

 
$ ansible-vault edit group_vars/vkcloud/vault.yml

Откроется текстовый редактор с расшифрованным текстом. После сохранения и выхода из редактора файл снова зашифруется.