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

В этом руководстве описано, как создать файл динамического инвентаря с использованием плагина tarantool.enterprise.generator. В файле динамического инвентаря для плагина задаются параметры кластера Tarantool или продуктов на его основе, серверов, а также компонентов кластера. Плагин входит в поставку Ansible Tarantool Enterprise. Чтобы использовать данный плагин вне коллекции АТЕ, включите его в файле конфигурации Ansible (файл ansible.cfg):

 
[inventory]enable_plugins = tarantool.enterprise.generator

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

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

• plugin: плагин, используемый для генерации инвентаря (tarantool.enterprise.generator).
• cluster_name: имя кластера, которое будет использоваться как родительская группа для всех сгенерированных хостов.
• product: название продукта. Возможные значения: tarantool, TCS, TCF, TQE, cartridge, CDC. Для генерации инвентаря для 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-.*"

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

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

В начале инвентаря добавьте строку с подключением плагина динамического инвентаря ATE:

 
plugin: tarantool.enterprise.generator

Придумайте имя кластера Tarantool, а затем укажите желаемый продукт — tarantool, TCS, TCF, TQE, cartridge или CDC:

 
cluster_name: my_cluster_nameproduct: tarantool

В секции constants укажите глобальные переменные, которые будут применяться ко всем хостам:

 
constants:  cartridge_app_name: my_app_name  tarantool_etcd_host: "{{ tarantool_etcd_host }}"  tarantool_config_global:    credentials:      users:        client:          password: 'secret'          roles: [super]        replicator:          password: 'secret'          roles: [replication]        storage:          password: 'secret'          roles: [sharding]    roles_cfg:      my-role:        variable_1: 10    iproto:      advertise:        peer:          login: replicator        sharding:          login: storage        client: 'unix/:{{ cartridge_run_dir }}/{% raw %}{{ instance_name }}{% endraw %}.iproto'      listen:        - uri: unix/:/app/tarantool/kvee/run/{% raw %}{{ instance_name }}{% endraw %}.iproto

В секции servers укажите список серверов и их параметры:

 
servers:  - name: 'vm_1'    host: '{{ tarantool_ansible_host }}'    user: '{{ super_user }}'  - name: 'vm_2'    host: '{{ tarantool_ansible_host }}'    advertise_host: '127.0.0.1'    port: 2201    zone: 'DC5'    user: '{{ super_user }}'    port_starts:      iproto: 3401      http: 9091

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

 
components:  - name: storage    replicasets: 2    replicas: 2    config:      replicaset:        memtx:          memory: 512000000      group:        app:          module: storage          cfg:            space_name: super-duper-space        sharding:          roles: [storage]        memtx:          memory: 1000241024        roles:          - roles.my-role  - name: router    replicasets: 2    replicas: 1    config:      replicaset:      group:        app:          module: router        sharding:          roles: [router]        roles:          - roles.another-role

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

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

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

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

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

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

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

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

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

Эти режимы взаимоисключающие. Если scaling не задан, создаётся по одному экземпляру Gateway и Destination на направление (поведение по умолчанию).

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

Все 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 разворачиваются без сохранения состояния для leader election: на каждый шард приходится ровно один экземпляр, и распределённая блокировка (storage/storage_params в конфигурации TCF) не генерируется — она не нужна, когда конкурировать за роль активного обработчика не с кем. Это справедливо и для масштабирования через scaling (Масштабирование репликаторов): count и shards_per_instance распределяют шарды между несколькими экземплярами без пересечений, так что конкурировать всё равно не с кем.

Блокировка нужна только тогда, когда на один и тот же shard назначено больше одного экземпляра 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-конфигурации целевого кластера направления.

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

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

Если в константах кластера задан параметр tarantool_iproto_ssl_params с transport: ssl, генератор автоматически заполняет переменные для 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, значения которых копируются из 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 для задания очередей. Генератор автоматически заполнит секцию advertise_uri для экземпляров хранилища и роутера соответственно. Если требуется задать свои собственные параметры подключения, их можно указать в поле connections.

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

Поддерживаемые типы 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 — параметры sink-коннектора (подключение к целевому кластеру, топик, режимы вставки/удаления);
• cdc_source_connector_params — параметры source-коннектора (подключение к исходному кластеру, репликация, spaces, топик). replication.id генерируется автоматически из имени экземпляра, если в конфиге присутствует секция replication (для source-коннекторов без репликации от 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-обработчик на каждый шард source-кластера, заданного в source_cluster_name. Для каждого сгенерированного обработчика автоматически проставляются уникальные connect.targets (все экземпляры своего шарда, через запятую), replication.id (по тем же правилам, что описаны выше), worker.id, worker.tag, offset.storage.connection.id, cdc_worker_port, offset.storage.file.name и sink.task.id. Значения *.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. Имя source-кластера (значение его cluster_name), из инвентаря которого берётся список шардов. Source-кластер описывается в отдельном 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-обработчиков с разной конфигурацией.

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

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

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

• servers — список серверов TCM (dict). Каждый entry содержит:
  • 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). Генератор преобразует ключи в имена переменных: api_token → tcm_feature_api_token и т.д.;
• tcm_tbcs_static_config: добавляет кластер Tarantool-based Configuration Storage (TbCS) в TCM как static-кластер на этапе начальной загрузки (см. ниже). По умолчанию (секция не задана или enabled: false) кластер TbCS в TCM не добавляется вообще.

Все ключи секции tcm:, кроме servers и tcm_tbcs_static_config, становятся переменными хостов TCM как есть. Благодаря этому через tcm: задаются переменные роли cluster_manager, которых нет среди полей генератора: подключение к etcd (tcm_etcd_*), TLS etcd и веб-интерфейса (tcm_etcd_tls_*, tcm_http_tls_*), логирование (tcm_log_*), auditlog (tcm_initial_settings_auditlog_*), хранилище (tcm_storage_*), пути к бинарнику и конфигурации и т. д. Полный список — в разделе Переменные TCM.

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

Пример — etcd с TLS и HTTPS веб-интерфейса:

 
tcm:  servers:    - name: vm_tcm      host: '{{ tarantool_ansible_host }}'      user: admin  tcm_etcd_host: etcd  tcm_etcd_schema: https  tcm_etcd_tls_enabled: true  tcm_etcd_tls_ca_file: /certs/rootCA.crt  tcm_http_tls_enabled: true  tcm_http_tls_cert_file: /certs/server.crt  tcm_http_tls_key_file: /certs/server.key

Из этого генератор создаст хост tcm (группа cluster-manager) с соответствующими переменными, а роль cluster_manager запишет их в /app/tarantool/cluster-manager/conf.d/tcm.yml:

 
storage:  etcd:    endpoints: ["https://etcd:2379"]    tls:      enabled: true      trusted-ca-file: /certs/rootCA.crthttp:  tls:    enabled: true    cert-file: /certs/server.crt    key-file: /certs/server.key

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

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

HTTPS для веб-интерфейса и API самого TCM включается переменными tcm_http_tls_*, заданными как общие ключи секции tcm:. Сертификат и ключ — серверные; проверка клиентских сертификатов (mTLS) для этого подключения не поддерживается, параметра ca-file у секции http.tls нет. При включённом HTTPS рекомендуется установить tcm_http_websession_cookie_secure: true; плейбуку tcm_add_tbcs при этом нужен tcm_api_scheme: https (по умолчанию http) — иначе он обратится к API по http и не подключится.

 
tcm:  servers:    - name: vm_tcm      host: '{{ tarantool_ansible_host }}'      port: 2201      user: admin      tcm_host: 0.0.0.0      tcm_port: 8080  tcm_http_tls_enabled: true  tcm_http_tls_cert_file: "/certs/server.crt"  tcm_http_tls_key_file: "/certs/server.key"  tcm_http_tls_min: "1.2"  tcm_http_tls_max: "1.3"  tcm_http_websession_cookie_secure: true  tcm_api_scheme: https

Полное описание переменных tcm_http_* — в разделе HTTP API и веб-интерфейс.

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]

Результат: генератор читает constants: и формирует переменную хоста tcm_initial_clusters на хостах TCM (tcm, tcm-2, ...), а роль cluster_manager запишет её в /app/tarantool/cluster-manager/conf.d/tcm.yml в initial-settings.clusters. Для примера выше в переменных хоста tcm (видно через ansible-inventory --host tcm) появится запись вида:

 
tcm_initial_clusters:  - name: my-app    storage-connection: # ...    tarantool-connection:      username: tcm_admin      password: secret

а в tcm.yml — фрагмент:

 
initial-settings:  clusters:    - name: my-app      storage-connection: # ...      tarantool-connection:        username: tcm_admin        password: secret

Ключ roles: [super] из tarantool_config_global сюда не попадает: генератор читает только password, а права пользователя настраиваются на стороне Tarantool отдельно.

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

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

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

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

 
constants:  tarantool_config_storage: etcd  tarantool_etcd_schema_definition: https  tarantool_config_etcd_endpoints:    - https://etcd-1.example:2379  tarantool_config_etcd_ssl_cert_file: /etc/tarantool/certs/client.crt  tarantool_config_etcd_ssl_key_file: /etc/tarantool/certs/client.key  tarantool_config_etcd_ssl_ca_file: /etc/tarantool/certs/ca.crt

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

 
tcm_initial_clusters:  - name: my-app    storage-connection:      provider: etcd      etcd-connection:        endpoints:          - https://etcd-1.example:2379        prefix: /tarantool/my-app        username: ""        password: ""        tls:          enabled: true          cert-file: /etc/tarantool/certs/client.crt          key-file: /etc/tarantool/certs/client.key          trusted-ca-file: /etc/tarantool/certs/ca.crt          insecure-skip-verify: false    tarantool-connection: # ...

Кластер с конфигурацией в 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    - uri: config-storage-2.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. В host var tcm_initial_clusters появится запись вида:

 
tcm_initial_clusters:  - name: my-app    storage-connection:      provider: tarantool      tarantool-connection:        endpoints:          - config-storage-1.example:4401          - config-storage-2.example:4401        username: ""        password: ""        prefix: /tarantool/my-app        ssl:          enabled: true          key-file: /etc/tarantool/certs/client.key          cert-file: /etc/tarantool/certs/client.crt          ca-file: /etc/tarantool/certs/ca.crt    tarantool-connection: # ...

Специфика генератора: ssl-блок один на всё подключение — он строится из params первой конечной точки с transport: ssl и применяется ко всем конечным точкам, поэтому TLS-параметры (ssl_cert_file/ssl_key_file/ssl_ca_file) у всех конечных точек должны совпадать. Учётные данные тоже едины для всех конечных точек: login и password внутри конечной точки используются самими экземплярами для подключения к TbCS, но не для подключения TCM. Учётные данные TCM берутся из tarantool_config_storage_username / tarantool_config_storage_password (по умолчанию — пустые строки); задайте их в constants:, если TbCS требует аутентификацию.

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 (см. пример выше).

Результат в tcm_initial_clusters:

 
tcm_initial_clusters:  - name: my-app    storage-connection: # ...    tarantool-connection:      username: client      password: ""      ssl:        enabled: true        key-file: /etc/tarantool/certs/client.key        cert-file: /etc/tarantool/certs/client.crt        ca-file: /etc/tarantool/certs/ca.crt

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

{alert} Секция tcm: и секция constants: настраивают разные подключения TCM к etcd:

• tcm_etcd_tls_* в секции tcm: — подключение TCM к собственному etcd (хранилище состояния TCM);
• tarantool_config_etcd_ssl_* и tcm_cluster_etcd_tls_* в секции constants: — используются для настройки подключения TCM к etcd-хранилищу конфигурации управляемого кластера (блок etcd-connection.tls в initial_clusters).

Если TCM и кластер используют один и тот же etcd, значения переменных могут совпадать, но это разные подключения с независимыми настройками TLS. {/alert}

Подробнее о переменных TLS для initial_clusters — в разделе Подключение TCM к etcd управляемого кластера.

Добавлено в версии 1.22.0

Кластер 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.

Чтобы посмотреть топологию, используйте следующую команду:

 
ansible-inventory -i path/to/config.yml --graph

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

 
ansible-inventory -i path/to/config.yml --list