Описание работы генератора

Файл инвентаря для генератора написан в формате YAML и состоит из нескольких основных секций:

• plugin: название используемого инвентарного плагина;
• cluster_name: имя кластера;
• product: название продукта -- например tarantool, TCS, TCF, TQE, CDC, tdb_redis (Tarantool DB RESP);
• constants: глобальные переменные и настройки;
• servers: список серверов и их параметры;
• components: список компонентов кластера и их параметры;
• changes: список изменений для кластера.

• plugin: плагин, используемый для генерации инвентаря (tarantool.enterprise.generator).
• cluster_name: имя кластера, которое будет использоваться как родительская группа для всех сгенерированных хостов.
• product: название продукта. Возможные значения: tarantool, TCS, TCF, TQE, CDC, tdb_redis (Tarantool DB RESP). Для генерации инвентаря для Tarantool DB укажите tarantool в качестве названия продукта.

Секция constants содержит глобальные переменные, применяемые ко всем хостам. Для Tarantool 3.x здесь указывается переменная tarantool_config_global. Некоторые переменные можно посмотреть в соответствующем разделе документации.

Секция servers содержит список физических серверов и виртуальных машин, на которых будут распределены компоненты кластера. Каждый сервер содержит данные поля:

• name (опционально): имя сервера. Значение по умолчанию: экранированное поле host;
• host: хост сервера;
• advertise_host (опционально): адрес для advertise_uri. Значение по умолчанию: host;
• port (опционально): порт для подключения к серверу. Значение по умолчанию: 22;
• user: пользователь для подключения к серверу;
• zone (опционально): зона, к которой относится сервер;
• port_starts (опционально): стартовые порты для генерации. Значение по умолчанию: "iproto": 3301, "http": 8081 (для TCS -- "http_tcs": 7777).

Секция components описывает компоненты кластера, их конфигурацию, а также количество наборов реплик и экземпляров в них:

• name: имя компонента;
• replicasets: количество наборов реплик;
• replicas: количество узлов в каждом наборе реплик;
• config: конфигурация компонента;
• servers (опционально): список серверов, на которых будут размещаться экземпляры данного компонента. Экземпляры распределяются между указанными серверами по round-robin. Если не указано, используется глобальная стратегия распределения (distribution_strategy). Каждый элемент списка может быть строкой (имя сервера) или словарём с полями:
  • name (обязательно): имя сервера;
  • max_instances (опционально): максимальное количество экземпляров данного компонента на этом сервере. Если не указано, лимит не ограничен.

Пример привязки компонента к серверам:

 
components:  - name: storage    replicasets: 2    replicas: 2    servers: [vm_1, vm_2]    config:      replicaset:        memtx:          memory: 512000000      group:        sharding:          roles: [storage]  - name: router    replicasets: 1    replicas: 1    servers: [vm_3]    config:      group:        sharding:          roles: [router]

В данном примере все экземпляры storage будут размещены только на vm_1 и vm_2 (по round-robin), а экземпляры router — только на vm_3.

Привязка с ограничением количества экземпляров на сервер:

Для каждого сервера в списке можно указать max_instances — максимальное количество экземпляров данного компонента на этом сервере:

 
components:  - name: storage    replicasets: 2    replicas: 3    servers:      - name: vm_1        max_instances: 4      - name: vm_2        max_instances: 2    config:      replicaset:        memtx:          memory: 512000000      group:        sharding:          roles: [storage]

В этом примере на vm_1 будет размещено максимум 4 экземпляра storage, а на vm_2 — максимум 2. При необходимости создать 6 экземпляров (2 replicasets × 3 replicas) распределение будет следующим:

• vm_1: 4 экземпляра
• vm_2: 2 экземпляра

Если сумма max_instances всех серверов меньше требуемого количества экземпляров, генератор выдаст ошибку.

Секция changes содержит список изменений, которые будут применены после создания топологии кластера. Возможные типы изменений:

• set_variables: задаёт переменные для экземпляров;
• remove_instances: удаляет экземпляр из инвентаря;
• add_replicas: добавляет реплики в существующие наборы реплик;
• add_servers: добавляет серверы в кластер;
• remove_servers: удаляет серверы из кластера;
• change_components: изменяет количество наборов реплик и реплик компонента;
• relocate_instances: переносит экземпляры с одного сервера на другой.

 
changes:  - type: set_variables # тип изменения    hosts: # Хост или группа хостов      - kvee-app-r001-s01      - ROUTERS    values: # Переменные, задаваемые для узлов      expelled: true      config:        http_port: 101010301        vinyl_cache: 1        vinyl_memory: 2  - type: add_servers    servers:      - name: vm_3        host: vm3.example.com        user: root        zone: DC2  - type: add_replicas    replicaset_name:      - storage-r01      - storage-r02    replicas: 1  - type: remove_instances    hosts:      - storage-r02-i01      - storage-r02-i02  - type: remove_servers    servers:      - vm_2

Тип изменения add_replicas позволяет добавить реплики в существующие наборы реплик. Новые экземпляры распределяются по серверам согласно distribution_strategy. Создание новых наборов реплик через эту команду не поддерживается.

Для TCF поддержано точечное добавление реплик в существующие наборы реплик gateway-* и destination-* в режиме add-only (без ребаланса шардов), начиная с версии ATE 1.21.0.

• replicaset_name: список имён существующих наборов реплик (обязательно);
• replicas: количество реплик для добавления в каждый набор реплик (опционально, по умолчанию 1, минимум 1);
• servers (опционально): список серверов, на которых будут размещены добавляемые реплики. Каждый элемент может быть строкой (имя сервера) или словарём с полями name и max_instances (аналогично секции components). Если указано, экземпляры распределяются между указанными серверами по round-robin, игнорируя глобальную стратегию распределения и привязку компонента. Если не указано, используется привязка компонента (servers в секции components) или глобальная стратегия распределения.

Добавление реплики в существующие наборы реплик:

 
changes:  - type: add_replicas    replicaset_name:      - storage-r01      - storage-r02    replicas: 1

Добавление реплики на определённые серверы:

 
changes:  - type: add_replicas    replicaset_name: [storage-r01]    replicas: 1    servers: [vm_1]

Добавление реплики с ограничением количества на сервер:

 
changes:  - type: add_replicas    replicaset_name: [storage-r01]    replicas: 3    servers:      - name: vm_1        max_instances: 2      - name: vm_2        max_instances: 1

В этом примере 3 новые реплики будут распределены так: 2 на vm_1 и 1 на vm_2. Лимит max_instances учитывает все экземпляры данного компонента на сервере, включая уже существующие.

Тип изменения change_components позволяет изменить топологию компонента: увеличить количество наборов реплик и/или реплик. Уменьшение количества наборов реплик и реплик не поддерживается — для удаления используйте remove_instances.

• component_name: имя компонента (обязательно);
• replicasets (опционально): целевое количество наборов реплик. Должно быть не меньше текущего. Если не указано, количество наборов реплик не меняется;
• replicas (опционально): целевое количество реплик в каждом наборе реплик. Должно быть не меньше 1. Если не указано, берётся значение из секции components;
• servers (опционально): список серверов, на которых будут размещены новые экземпляры. Каждый элемент может быть строкой (имя сервера) или словарём с полями name и max_instances (аналогично секции components). Если указано, новые экземпляры распределяются между указанными серверами по round-robin. Если не указано, используется привязка компонента (servers в секции components) или глобальная стратегия распределения.

Должно быть указано хотя бы одно из полей: replicasets или replicas.

Увеличение количества наборов реплик:

 
changes:  - type: change_components    component_name: storage    replicasets: 4

В этом примере количество наборов реплик компонента storage будет увеличено до 4. Количество реплик в новых наборах реплик берётся из секции components.

Увеличение количества реплик:

 
changes:  - type: change_components    component_name: storage    replicas: 4

В этом примере каждый набор реплик компонента storage будет дополнен репликами до 4. Наборы реплик, в которых уже есть 4 или более реплик, не изменяются.

Изменение топологии с размещением на определённых серверах:

 
changes:  - type: change_components    component_name: storage    replicasets: 4    replicas: 2    servers: [vm_1, vm_2]

В этом примере новые наборы реплик и отдельные реплики будут размещены только на серверах vm_1 и vm_2 по round-robin, игнорируя привязку компонента из секции components. Существующие наборы реплик, в которых уже достаточно реплик, не изменяются.

Изменение топологии с ограничением количества на сервер:

 
changes:  - type: change_components    component_name: storage    replicasets: 4    replicas: 2    servers:      - name: vm_1        max_instances: 3      - name: vm_2        max_instances: 3

Лимит max_instances учитывает все экземпляры данного компонента на сервере, включая уже существующие. Если все указанные серверы достигли лимита, генератор выдаст ошибку.

Тип изменения add_servers позволяет добавить серверы в кластер динамически. Добавленные серверы участвуют в распределении экземпляров при последующих операциях add_replicas.

• servers: список серверов для добавления (обязательно);
  • name (опционально): имя сервера;
  • host (обязательно): хост сервера;
  • user (обязательно): пользователь для подключения;
  • zone (опционально): зона, к которой относится сервер.

Добавление сервера в кластер:

 
changes:  - type: add_servers    servers:      - name: vm_3        host: vm3.example.com        user: root        zone: DC2

Тип изменения remove_servers позволяет удалить серверы из кластера. Сервер может быть удалён только если на нём нет экземпляров — перед удалением необходимо использовать remove_instances для удаления всех экземпляров с данного сервера.

• servers: список имён серверов для удаления (обязательно).

Удаление сервера из кластера:

 
changes:  - type: remove_instances    hosts:      - storage-r02-i01      - storage-r02-i02  - type: remove_servers    servers:      - vm_2

Тип изменения relocate_instances переносит экземпляры с одного сервера на другой. Генератор автоматически добавляет новые реплики на целевой сервер, формирует план миграции (relocate_plan) и, при необходимости, удаляет старые экземпляры из инвентаря.

Поля:

• from_server (обязательно): имя сервера-источника;
• to_server (обязательно): имя целевого сервера или словарь с конфигурацией нового сервера (поля host и user обязательны, name опционален). Если сервер ещё не описан в секции servers, он будет добавлен автоматически;
• old_instances (опционально): список имён экземпляров-источников на from_server. Если не указан, генератор автоматически собирает все экземпляры с from_server;
• old_instances_pattern (опционально): регулярное выражение для выборки экземпляров-источников на from_server. Например, ^storage-.* перенесёт только storage;
• state (опционально, по умолчанию active): active — генератор добавляет новые реплики на to_server и формирует план миграции (relocate_plan) для плейбука; completed — финализирует миграцию (удаляет старые экземпляры и пустой сервер-источник из инвентаря).

Перенос всех экземпляров с сервера (авто-сбор):

При замене сервера целиком укажите только from_server и to_server — генератор сам соберёт все экземпляры и создаст новые реплики:

 
changes:  - type: relocate_instances    from_server: vm_1    to_server: vm_2

Точечный перенос конкретных экземпляров:

 
changes:  - type: relocate_instances    from_server: vm_1    to_server: vm_2    old_instances:      - storage-r01-i01      - router-r01-i01

Перенос по шаблону (например, только storage):

 
changes:  - type: relocate_instances    from_server: vm_1    to_server: vm_2    old_instances_pattern: "^storage-.*"

После успешного выполнения плейбука playbooks/relocate_instances.yml финализируйте инвентарь — добавьте state: completed в блок relocate_instances:

 
changes:  - type: relocate_instances    from_server: vm_1    to_server: vm_2    state: completed

Tarantool 3.x позволяет задавать параметры конфигурации на различных уровнях (scope) — например для всех узлов кластера или отдельного набора реплик. Вы можете задать конфигурацию для группы и набора реплик в секции config.

TCS имеет обязательные компоненты scheduler (для TCS 0.x) и coordinator, а также компонент storage, который может иметь произвольное имя.

Для установки TCS версии 1.x укажите переменную tcs_v1_support: true и заполните инвентарь в соответствии с документацией TCS (без компонента scheduler).

В инвентаре TCF есть две обязательные секции:

• cluster_1 и cluster_2 - описание первого и второго кластера;
• tcf (опциональная) - переменные для компонентов Gateway и Destination;

По умолчанию генератор создаёт по одному экземпляру Gateway и Destination на каждое направление репликации (A→B и B→A). С помощью параметра scaling можно увеличить количество репликаторов и автоматически распределить шарды между ними (см. раздел "Масштабирование репликаторов" ниже).

Начиная с TCF 0.11.0 поддерживается запуск нескольких экземпляров Gateway и Destination на каждом направлении репликации. Это позволяет распределить нагрузку по репликации между несколькими процессами.

Масштабирование настраивается через параметр scaling в секции tcf. Поддерживаются два режима:

• count — точное количество репликаторов каждого типа на направление;
• shards_per_instance — один репликатор на каждые N шардов (наборов реплик хранилищ). Количество вычисляется как ⌈общее_число_шардов / N⌉.

При одновременном указании count и shards_per_instance используется count. Если scaling не задан, создаётся по одному экземпляру Gateway и Destination на направление (поведение по умолчанию).

Шарды распределяются между репликаторами равномерно по round-robin. Например, 6 шардов на 4 Gateway дадут распределение: [r01, r05], [r02, r06], [r03], [r04].

Все Destination одного направления получают одинаковый tcf_gateway_clusters — они подключаются ко всем Gateway этого направления. Различаются у них только tcf_destination_shards.

При масштабировании генератор автоматически заполняет следующие переменные (если они не заданы вручную в tcf):

• tcf_gateway_alias — уникальный псевдоним для каждого Gateway (формат: gateway-{src}-{dst}-{N:02d});
• tcf_destination_alias — уникальный псевдоним для каждого Destination (формат: destination-{src}-{dst}-{N:02d});
• tcf_gateway_metrics_labels — метки для метрик Gateway (содержат tcf_cluster, direction, component, instance);
• tcf_destination_metrics_labels — метки для метрик Destination;
• tcf_destination_shards — список шардов, закреплённых за данным Destination;
• tcf_gateway_clusters — описание подключения ко всем Gateway направления (для Destination);
• tcf_gateway_storage_uris — список URI storage-экземпляров, которые читает данный Gateway.

Если какая-либо из этих переменных задана вручную в секции tcf, автогенерация для неё пропускается — используется пользовательское значение.

По умолчанию Gateway и Destination разворачиваются без сохранения состояния для выбора лидера: на каждый шард приходится ровно один экземпляр, и распределённая блокировка (storage/storage_params в конфигурации TCF) не генерируется — она не нужна, когда конкурировать за роль активного обработчика не с кем. Это справедливо и для масштабирования через scaling (Масштабирование репликаторов): count и shards_per_instance распределяют шарды между несколькими экземплярами без пересечений, так что конкурировать всё равно не с кем.

Блокировка нужна только тогда, когда на один и тот же шард назначено больше одного экземпляра Gateway или Destination, то есть после того, как к уже существующему Gateway- или Destination-набору реплик добавлена ещё одна реплика через секцию changes с type: add_replicas. Без блокировки каждый экземпляр будет считать себя единственным активным, что приведёт либо к зависанию соединения с etcd (Destination), либо к отказу в обслуживании с ошибкой gateway is not the pool master (Gateway).

Автогенерация storage/storage_params включается явно, через флаг в секции tcf (не в constants отдельных кластеров), и должна сопровождаться самим добавлением реплики через changes:

 
tcf:  tcf_gateway_ha_enabled: true  tcf_destination_ha_enabled: truechanges:  - type: add_replicas    replicaset_name:      - gateway-tarantooldb-tarantooldb-2-r01    replicas: 1    servers: [vm_2]  - type: add_replicas    replicaset_name:      - destination-tarantooldb-tarantooldb-2-r01    replicas: 1    servers: [vm_4]

• tcf_gateway_ha_enabled — включает автогенерацию tcf_gateway_storage, tcf_gateway_storage_endpoints, tcf_gateway_storage_user, tcf_gateway_storage_password, tcf_gateway_storage_prefix для всех экземпляров Gateway. Источник — etcd-конфигурация кластера-источника направления;
• tcf_destination_ha_enabled — аналогично, для tcf_destination_storage*, на основе etcd- или TbCS-конфигурации целевого кластера направления.

Как и остальные переменные этого раздела, они не применяются, если соответствующие tcf_gateway_storage/tcf_destination_storage заданы в tcf вручную — в этом случае используется пользовательское значение независимо от флага.

Флаг без добавленной реплики (и наоборот, реплика без флага) не имеют смысла: в первом случае блокировка будет сгенерирована для единственного экземпляра, во втором — несколько экземпляров одного шарда будут работать без согласования между собой.

Если в константах кластера задан параметр tarantool_iproto_ssl_params с transport: ssl или transport: tls, генератор автоматически заполняет переменные для TLS-подключений репликаторов к экземплярам Tarantool по протоколу iproto:

• tcf_gateway_iproto_ssl_opts — параметры TLS для подключения Gateway к экземплярам хранилищ кластера-источника;
• tcf_destination_iproto_ssl_opts — параметры TLS для подключения Destination к роутерам целевого кластера.

Обе переменные содержат ключи ssl_cert_file, ssl_key_file, ssl_ca_file и ssl_ciphers (если значение не задано в tarantool_iproto_ssl_params, используется пустая строка), значения которых копируются из tarantool_iproto_ssl_params соответствующего кластера. В конфигурации репликаторов эти параметры попадают в секцию ssl_opts с полями key_file, cert_file, ca_file.

Если переменные заданы вручную в секции tcf, автогенерация не выполняется.

TQE имеет обязательный компонент, который должен содержать строку grpc_server (например grpc_server_consumer, grpc_server_producer). У компонента, содержащего строку grpc_server, достаточно указать словарь очередей для публикации и подписки - это можно сделать в секции инвентаря producer/consumer для задания очередей. Генератор автоматически заполнит подключения connections для очередей (в новом режиме — в секциях producer/consumer, в старом — publisher/consumer): для публикации — адресами роутеров, для подписки — адресами экземпляров хранилища. Если требуется задать свои собственные параметры подключения, их можно указать в поле connections.

CDC (Change Data Capture) — продукт для репликации данных между различными источниками и приёмниками. Инвентарь для генератора, описывающий кластер CDC, генерирует хосты с параметрами обработчиков CDC, включая конфигурацию исходных и целевых коннекторов.

Поддерживаемые типы offset storage (cdc_offset_params.storage.type):

• tqe — хранение контрольных точек в Tarantool Queue Enterprise;
• file — хранение контрольных точек в файле;
• kafka — хранение контрольных точек в Kafka.

Примеры инвентарей для наиболее употребимых конфигураций CDC (TDB → TQE → PostgreSQL, TDB → PostgreSQL) приведены в разделе Change Data Capture.

В секции config каждого компонента укажите следующие переменные:

• cdc_worker_params — параметры обработчика (shutdown timeout и др.). worker.id генерируется автоматически из имени экземпляра;
• cdc_sink_connector_params — параметры целевого коннектора (подключение к целевому кластеру, топик, режимы вставки/удаления);
• cdc_source_connector_params — параметры исходного коннектора (подключение к исходному кластеру, репликация, spaces, топик). replication.id генерируется автоматически из имени экземпляра, если в конфигурации присутствует секция replication (для исходных коннекторов без репликации от Tarantool, например TQESourceConnector, секция не создаётся и не добавляется);
• начиная с CDC 0.12.0 параметр group.id у TarantoolConnector переименован в replication.id (без обратной совместимости — group.id не читается коннектором 0.12.0+); при обновлении CDC до 0.12.0 конфигурации с ручным group.id нужно переименовать вручную, таблица соответствия старых и новых имён — в release notes CDC 0.12.0.
• shard_per_worker — при значении true компонент трактуется как шаблон: вместо ручного описания одного компонента на шард, генератор автоматически разворачивает его в отдельный исходный CDC-обработчик на каждый шард исходного кластера, заданного в source_cluster_name. Для каждого сгенерированного обработчика автоматически проставляются уникальные connect.targets (все экземпляры своего шарда, через запятую), replication.id (по тем же правилам, что описаны выше), worker.id, worker.tag, offset.storage.connection.id, cdc_worker_port, offset.storage.file.name и ключ task.id в cdc_sink_connector_params. Значения *.id полей, заданные вручную, не перезаписываются (уникальность между обработчиками при этом не проверяется генератором, совпадающие значения приведут к конфликту в кластере). connect.targets генерируется заново при каждом запуске независимо от ручного значения; cdc_worker_port увеличивается на индекс обработчика относительно заданного вручную порта, а offset.storage.file.name дополняется суффиксом с именем обработчика. worker.id генерируется только при наличии секции cdc_worker_params, offset.storage.connection.id - только при наличии cdc_offset_params. При использовании этого параметра требуется указывать секцию cdc_source_connector_params в конфигурации компонента, без неё генератор вернёт ошибку;
• source_cluster_name — параметр обязателен при флаге shard_per_worker: true. Имя исходного кластера (значение его cluster_name), из инвентаря которого берётся список шардов. Исходный кластер описывается в отдельном inventory-файле, который должен быть указан раньше CDC-файла в списке --inventory, генератор ищет его по имени среди уже обработанных в текущем запуске кластеров, при нарушении порядка или опечатке в имени возвращается понятная ошибка;
• shards_per_instance — опциональный параметр при флаге shard_per_worker: true (по умолчанию 1): число шардов, обслуживаемых одним CDC-обработчиком. При значении больше 1, шарды группируются последовательно и распределяются по обработчикам.
• cdc_offset_params — параметры хранения контрольных точек (flush, storage type/address/queue). storage.connection.id генерируется автоматически;
• cdc_throttle_params — параметры троттлинга (максимальный rps).

Опциональные переменные:

• cdc_log_params — параметры журналирования. Если не заданы, генерируется автоматически: file.name: /app/cdc/logs/<имя_экземпляра>.log;
• cdc_group — системная группа для сервиса CDC (по умолчанию: tarantool);
• cdc_user — системный пользователь для сервиса CDC (по умолчанию: tarantool);
• cdc_file_mode — права доступа к файлам (по умолчанию: 0755).

Количество компонентов и их имена задаются произвольно, что позволяет развернуть несколько CDC-обработчиков с разной конфигурацией.

Вместо ручного описания отдельного компонента на каждый шард исходного кластера можно указать один компонент-шаблон с shard_per_worker: true — генератор сам создаст по одному исходному CDC-обработчику на каждый шард.

Секция tcm: позволяет сгенерировать инвентарь для Tarantool Cluster Manager из того же файла инвентаря для генератора, что и продуктовый кластер.

Поля секции tcm::

• servers — список серверов TCM (dict). Каждый элемент содержит:
  • name (обязательный): имя сервера;
  • host (опциональный): хост для SSH-подключения;
  • port (опциональный): SSH-порт (по умолчанию: 22);
  • user (обязательный, если сервер не из servers:): пользователь для подключения;
  • tcm_host (опциональный): адрес, на котором TCM слушает HTTP. По умолчанию: host;
  • tcm_port (опциональный): HTTP-порт TCM. По умолчанию: 8080.
• tcm_bootstrap_password: начальный пароль администратора;
• tcm_bootstrap_api_token: начальный API-токен;
• tcm_features: словарь флагов (ttgraph, api_token, tqe, column_store, tuples, tcf);
• tcm_tbcs_static_config: добавляет кластер Tarantool-based Config Storage (TbCS) в TCM как static-кластер на этапе начальной загрузки (см. ниже). По умолчанию (секция не задана или enabled: false) кластер TbCS в TCM не добавляется вообще.

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

• Если name совпадает с сервером из servers: кластера того же файла, что и секция tcm:, — TCM размещается на этом же сервере, а данные для SSH-подключения берутся из этого сервера. Поиск сервера по имени выполняется только внутри файла с секцией tcm:: сервер из другого файла по имени не находится. Однако это не мешает для любого сервера TCM явно указать полные креды (host, user, при необходимости port) — тогда он будет создан как отдельный сервер TCM;
• Если name не найден в servers: кластера этого файла — создаётся новый сервер TCM. В этом случае обязательно укажите host и user, иначе Ansible не сможет подключиться по SSH;
• tcm_initial_clusters генерируется автоматически из кластеров текущего файла;
• При использовании нескольких файлов инвентаря для генератора (например, --inventory file1.yml --inventory file2.yml) секцию tcm: нужно указать ровно в одном файле; указание tcm: более чем в одном файле — ошибка генерации. Кластеры из всех файлов аккумулируются в tcm_initial_clusters автоматически.
• Имя кластера в tcm_initial_clusters используется как уникальный ключ: генератор накапливает по нему данные конкретного кластера. Поэтому два разных кластера с одинаковым именем (tcm_cluster_display_name или cluster_name) вызывают ошибку генерации — задайте им разные имена.

TCM подключается к экземплярам управляемого кластера по iproto: это блок tarantool-connection в tcm_initial_clusters. Имя пользователя задаётся в constants: управляемого кластера переменной tcm_tarantool_connection_username (по умолчанию client; пустое значение тоже приводит к client). Пароль генератор всегда берёт из tarantool_config_global.credentials.users[<username>].password этого же кластера. Если выбранный пользователь или его пароль отсутствуют в конфигурации, генератор подставляет пустую строку: он не создаёт пользователя и не проверяет возможность аутентификации. Пустой пароль может быть намеренным, например для guest.

 
constants:  tcm_tarantool_connection_username: tcm_admin  tarantool_config_global:    credentials:      users:        tcm_admin:          password: "secret"          roles: [super]

Переменная применяется к автоматически формируемым записям управляемых кластеров. Для static-записи самого кластера TbCS действуют отдельные tcm_tbcs_static_config.username / password и прежние значения по умолчанию.

Это подключение не зависит от tarantool_tt_connect_username / tarantool_tt_connect_password: они задают пользователя для команд tt CLI и могут иметь другие полномочия.

TLS для tcm_initial_clusters задаётся в constants:. Ниже приведены примеры для всех вариантов хранения конфигурации управляемого кластера.

• TLS включается, если первая конечная точка из tarantool_config_storage_endpoints использует схему https;
• cert-file, key-file, trusted-ca-file берутся из tarantool_etcd_ssl_cert_file, tarantool_etcd_ssl_key_file, tarantool_etcd_ssl_ca_file (общие переменные, также используемые экземплярами Tarantool);
• insecure-skip-verify и skip-client-san-verify управляются переменными tcm_cluster_etcd_tls_skip_verify и tcm_cluster_etcd_tls_skip_san_verify соответственно (только для TCM, не влияют на Tarantool);
• Jinja2-выражения в значениях переменных (например, {{ tarantool_etcd_ssl_ca_path }}/rootCA.crt) разрешаются автоматически на этапе генерации инвентаря.

Кластер с конфигурацией в etcd

 
constants:  tarantool_config_storage: etcd  tarantool_config_storage_endpoints:    - https://etcd-1.example:2379  tarantool_etcd_ssl_cert_file: /etc/tarantool/certs/client.crt  tarantool_etcd_ssl_key_file: /etc/tarantool/certs/client.key  tarantool_etcd_ssl_ca_file: /etc/tarantool/certs/ca.crt

ATE создаст storage-connection.etcd-connection.tls с ключом trusted-ca-file.

Кластер с конфигурацией в TbCS

 
constants:  tarantool_config_storage: tarantool  tarantool_config_storage_endpoints:    - uri: config-storage-1.example:4401      login: config-storage      password: <password>      params:        transport: ssl        ssl_cert_file: /etc/tarantool/certs/client.crt        ssl_key_file: /etc/tarantool/certs/client.key        ssl_ca_file: /etc/tarantool/certs/ca.crt

ATE создаст storage-connection.tarantool-connection.ssl для подключения к TbCS. Источник TLS — params конечных точек tarantool_config_storage_endpoints; В этом SSL-блоке используется ключ ca-file.

TLS к экземплярам управляемого кластера

Этот блок не зависит от провайдера хранилища конфигурации: добавьте его к любому из примеров выше, если TCM подключается к экземплярам кластера по iproto с TLS.

 
constants:  tarantool_iproto_ssl_params:    transport: ssl    ssl_cert_file: /etc/tarantool/certs/client.crt    ssl_key_file: /etc/tarantool/certs/client.key    ssl_ca_file: /etc/tarantool/certs/ca.crt

ATE создаст tarantool-connection.ssl с ключом ca-file. Этот блок относится только к подключению TCM c экземплярами управляемого кластера и не влияет на подключение TCM к TbCS (storage-connection.tarantool-connection.ssl): источники TLS независимы. TLS для TbCS задаётся только в params соответствующих конечных точек tarantool_config_storage_endpoints (см. пример выше).

Правило для CA: trusted-ca-file используется только в etcd-connection.tls; во всех Tarantool SSL-блоках используется ca-file. Ключи не взаимозаменяемы: начиная с версии 1.11 TCM валидирует конфигурацию по json-схеме (additionalProperties: false) и не запускается при некорректных ключах, выдывая ошибку следующего вида: initial-settings/clusters/0/tarantool-connection/ssl [additionalProperties] Additional property 'trusted-ca-file' does not match the schema.

Подробнее о переменных TLS для initial_clusters — в разделе Переменные генератора инвентаря.

Кластер TbCS (is_config_storage: true) — это само хранилище конфигурации, поэтому у него нет внешнего хранилища, из которого TCM мог бы читать его конфигурацию (провайдеры etcd или tarantool). По умолчанию он вообще не попадает в tcm_initial_clusters. Чтобы добавить его в initial-settings.clusters как static-кластер с зафиксированным снимком конфигурации, включите tcm_tbcs_static_config с enabled: true. Таким образом получаем результат аналогичный кнопке «Add TCS cluster» в Web UI (TCM >= 1.11), но снимок ATE строит иначе: UI запрашивает действующую конфигурацию API-методом (только Tarantool 3.8.0+), а при начальной загрузке (bootstrap) снимок собирает генератор из инвентаря кластера TbCS (см. ниже) — без iproto-подключения к TbCS и без требования Tarantool 3.8.0.

Обычные кластеры, которые хранят свою конфигурацию в TbCS (tarantool_config_storage: tarantool), это не затрагивает: они по-прежнему добавляются как кластеры с провайдером tarantool (storage-connection.provider: tarantool) и конечными точками TbCS.

Поля tcm_tbcs_static_config:

• enabled (опциональный, по умолчанию false): включает генерацию static-записи и добавление кластера TbCS в TCM;
• cluster (опциональный): cluster_name (или tcm_cluster_display_name) кластера TbCS. Если не задан, выбирается кластер с is_config_storage: true;
• name (опциональный): отображаемое имя кластера в TCM. По умолчанию — tcm_cluster_display_name или cluster_name;
• description (опциональный): описание кластера в TCM. По умолчанию — Tarantool-based Config Storage cluster (TbCS) added by ATE at bootstrap;
• id (опциональный): фиксированный ID кластера в TCM. По умолчанию — tcm_cluster_id или генерируется TCM;
• username, password (опциональные): учётные данные tarantool-connection. По умолчанию берутся из tcm_etcd_username / tcm_etcd_password (учётные данные storage-подключения TCM) при tcm_storage_provider: tarantool; в остальных случаях задайте их явно;
• ssl (опциональный): блок TLS для tarantool-connection (ключи enabled, key-file, cert-file, ca-file). Если не задан, выводится из tarantool_iproto_ssl_params.

Снимок конфигурации строится генератором из инвентаря кластера TbCS: дерево groups → replicasets → instances с адресами подключения (iproto.advertise.client, иначе iproto.listen). Глобальные секции (credentials, roles_cfg и т. п.) в снимок не попадают: TCM хранит учётные данные подключения в блоке tarantool-connection. Поэтому static-импорт не зависит от порядка развёртывания и не требует, чтобы TbCS был доступен по RPC.

Чтобы добавить static-кластер TbCS в уже запущенный TCM (вне начальной загрузки), используйте плейбук tarantool.enterprise.tcm_add_tbcs (см. сценарий добавления кластера TbCS в TCM): он читает отрендеренную конфигурацию с хоста хранилища конфигурации (или переменную tcm_tbcs_static_config_content) и добавляет кластер через мутацию cluster.add.

• Написание инвентаря — руководство по написанию инвентаря;
• Примеры инвентарей — готовые аннотированные примеры инвентарей по продуктам;
• Переменные окружения — справочник переменных коллекции.