Примеры инвентарей

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

Статический инвентарь — это вручную созданный текстовый файл со списком хостов, групп и переменных.

Динамический инвентарь — это файл для Ansible-плагина (например, генератора), который на основе данных динамически формирует список хостов, групп и переменных.

Сценарии для приложений и продуктов на основе Tarantool 3.x Enterprise Edition приведены в разделе Tarantool 3.x. Пример инвентаря для централизованного хранилища конфигурации на основе Tarantool приведен в разделе Tarantool-based Configuration Storage.

Сценарии для приложений и продуктов на основе Tarantool Cartridge приведены в разделе Tarantool Cartridge.

Централизованное хранилище конфигурации на основе Tarantool, TbCS (Tarantool-based Configuration Storage), используется с кластерами на основе Tarantool 3.x. Подробная информация о таком типе хранилища приведена в документации Tarantool: Централизованное хранилище конфигурации.

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

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

Сценарии для работы с TCM приведены в разделе Tarantool Cluster Manager.

Все примеры ниже, кроме раздела «Динамический инвентарь с TCM», приведены для статического инвентаря.

В примере ниже TCM подключается к собственному etcd по TLS с проверкой сертификата сервера (tcm_etcd_tls_ca_file) и клиентским сертификатом (tcm_etcd_tls_cert_file/tcm_etcd_tls_key_file — требуется, если на etcd включён --client-cert-auth). TLS для подключения TCM к etcd управляемого кластера настраивается независимо — блоком tls в etcd-connection записи кластера, а TLS к экземплярам кластера (iproto) — блоком ssl в tarantool-connection записи кластера.

Обратите внимание на различие имён: для etcd используется блок tls и ключ trusted-ca-file, для Tarantool-подключений (TbCS, iproto) — блок ssl и ключ ca-file. Провайдер собственного хранилища TCM и провайдер хранилища кластера независимы: например, TCM может хранить своё состояние в TbCS (пример с TbCS), а конфигурация кластера — в etcd, как в примере ниже.

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

В примере ниже TCM подключается к собственному хранилищу на TbCS по TLS: транспорт ssl (tcm_tarantool_ssl_transport: ssl), клиентский сертификат (tcm_tarantool_ssl_cert_file/ tcm_tarantool_ssl_key_file) и CA для проверки сертификата сервера TbCS (tcm_tarantool_ssl_ca_file). У секции storage.tarantool.ssl нет ключа enabled — TLS включается транспортом. TLS для подключения TCM к TbCS управляемого кластера настраивается независимо — блоком ssl в tarantool-connection внутри storage-connection записи кластера, а TLS к экземплярам кластера (iproto) — блоком ssl во втором tarantool-connection записи кластера.

Имена ключей различаются по провайдерам: для Tarantool-подключений (TbCS, iproto) — блок ssl с ключом ca-file, для etcd — блок tls с ключом trusted-ca-file.

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

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

Кластер TbCS — это само хранилище конфигурации, у него нет внешнего провайдера (etcd/tarantool), из которого TCM мог бы читать его конфигурацию. Чтобы добавить TbCS в TCM при начальной загрузке, в tcm_initial_clusters используется запись с провайдером static: снимок конфигурации фиксируется в static-connection.config, а подключение к экземплярам задаётся в tarantool-connection. Результат аналогичен кнопке «Add TCS cluster» в веб-интерфейсе. Доступно с версии TCM 1.11 и выше.

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

В динамическом инвентаре такой снимок собирает генератор из секции tcm_tbcs_static_config (см. Static-импорт TbCS при начальной загрузке). Чтобы добавить static-кластер TbCS в уже запущенный TCM, используйте плейбук tarantool.enterprise.tcm_add_tbcs (см. сценарий добавления кластера TbCS в TCM).

В динамическом инвентаре TLS задаётся в двух местах. Подключение TCM к собственному etcd — переменными tcm_etcd_tls_* общими ключами секции tcm:. TLS для записей initial_clusters генератор выводит из constants: управляемого кластера: tarantool_config_etcd_ssl_* — для хранилища конфигурации на etcd, tarantool_iproto_ssl_params — для подключения к экземплярам кластера по iproto. Подробнее о генерации TLS-блоков и вариант с TbCS — в разделе Автоматическая генерация TLS в initial_clusters.

Генератор сформирует в tcm_initial_clusters блок etcd-connection.tls (с ключом trusted-ca-file) из tarantool_config_etcd_ssl_* и блок tarantool-connection.ssl (с ключом ca-file) из tarantool_iproto_ssl_params. Для хранилища конфигурации на TbCS TLS задаётся в params конечных точек tarantool_config_storage_endpoints, а собственное хранилище TCM на TbCS — переменными tcm_tarantool_ssl_* в секции tcm: (tcm_storage_provider: tarantool).

Вариант предыдущего примера с хранилищем конфигурации на TbCS. TLS к TbCS управляемого кластера задаётся в params конечных точек tarantool_config_storage_endpoints в constants: (генератор создаст storage-connection.tarantool-connection.ssl), а TLS собственного хранилища TCM на TbCS — переменными tcm_tarantool_ssl_* в секции tcm: (tcm_storage_provider: tarantool; TLS включается транспортом, ключа enabled у секции storage.tarantool.ssl нет).

Генератор сформирует в tcm_initial_clusters блок storage-connection.tarantool-connection.ssl (с ключом ca-file) из params первой TLS-точки tarantool_config_storage_endpoints и блок tarantool-connection.ssl для iproto-подключения из tarantool_iproto_ssl_params. SSL-блок един для всех конечных точек TbCS; учётные данные TCM берутся из tarantool_config_storage_username/ tarantool_config_storage_password (login/password внутри точки используются экземплярами, а не TCM). Подробности — в разделе Автоматическая генерация TLS в initial_clusters.

Информация о настройке TCF и сценарии для работы с этим продуктом приведены в разделе Tarantool Clusters Federation.

Топология репликаторов данных между кластерами (Gateway и Destination) формируется автоматически на основе описания кластеров в инвентаре. Указывать её вручную необязательно — автоматическая настройка покрывает типовые случаи. При необходимости топологию можно задать вручную.

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

Информация о настройке TCS и сценарии для работы с этим продуктом приведены в разделе Tarantool Column Store.

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

Не работает для версии TCS 1.1 и выше

Информация о настройке Tarantool DB и сценарии для работы с этим продуктом приведены в разделе Tarantool DataBase.

Tarantool DB (RESP) начиная с версии 2.1.0 Sentinel является отдельной ролью tdb_redis_sentinel (на базе встроенного stateboard) и больше не переопределяет failover-координатор; порт Sentinel задаётся настройкой port роли tdb_redis_sentinel (старая sentinel_port роли tdb_redis_role удалена).

Роль tdb_redis_sentinel работает на базе Tarantool-based Configuration Storage (читает config.storage), поэтому кластер TDB RESP обязан использовать его (не etcd) как централизованное хранилище конфигурации. Пример ниже предполагает, что TbCS уже развёрнут.

Начиная с версии 2.1.0 в состав дистрибутива TDB RESP входят штатные роли Tarantool для экспорта метрик — roles.httpd и roles.metrics-export. Эти роли не применяются автоматически: чтобы включить экспорт метрик, добавьте обе роли в список roles кластерной конфигурации и задайте адрес и порт HTTP-сервера (параметр roles_cfg.roles.httpd.default.listen; в динамическом инвентаре генератор назначает порт каждому экземпляру автоматически). Метрики доступны по адресу http://<хост>:<порт>/metrics/prometheus в формате Prometheus. Примеры ниже показывают конфигурацию с включённым экспортером метрик.

В модели с отдельными узлами экземпляры Sentinel и Redis разворачиваются в разных наборах реплик. На наборе реплик хранения укажите roles: ["tdb_redis_role"], а для Sentinel выделите отдельный набор реплик с roles: ["tdb_redis_sentinel"] и нужным числом экземпляров (рекомендуется 3 — для кворума). Поскольку роль tdb_redis_sentinel читает состояние экземпляров из stateboard, ей не обязательно работать на тех же узлах, что и Redis.

Тот же кластер в модели с отдельными узлами можно описать динамическим инвентарём генератора. Для этого укажите product: tdb_redis. Роли задаются так же, как в статическом инвентаре: на наборе реплик хранения — tdb_redis_role, на наборе реплик Sentinel — tdb_redis_sentinel. Порт каждой роли генератор назначает автоматически (по умолчанию 6379 для Redis и 26379 для Sentinel); при необходимости начало диапазона можно изменить через port_starts.redis и port_starts.sentinel на уровне сервера или компонента.

Роли метрик включаются так же, как в статическом инвентаре: добавьте roles.httpd и roles.metrics-export в config.replicaset.roles. Порт HTTP-сервера roles.httpd генератор назначает каждому экземпляру автоматически (по умолчанию начиная с 8081); начало диапазона можно изменить через port_starts.http на уровне сервера или компонента. Явно задавать roles_cfg.roles.httpd.default.listen не нужно: значение уровня набора реплик будет переопределено сгенерированным портом экземпляра. Настройки экспортера — путь и формат endpoint'а — задаются в config.replicaset.roles_cfg.roles.metrics-export и применяются ко всем экземплярам набора реплик одинаково.

В co-located-модели роли задаются не в config.replicaset.roles, а в tarantool_config_global.roles секции constants.

В этом примере все экземпляры размещаются на единственном сервере, поэтому генератор назначит им порты HTTP-сервера 8081–8085: экземпляры storage получат 8081–8082, экземпляры sentinel — 8083–8085.

Сценарии для работы с TDG приведены в разделе Tarantool Data Grid.

Сценарии для работы с TQE приведены в разделе Tarantool Queue Enterprise (MQ).

Сценарии для работы с Tarantool CDC приведены в разделе Tarantool Change Data Capture.

Для использования динамического инвентаря укажите product: CDC и задайте параметры CDC-воркера в секции config компонента.

Ниже приведён пример инвентарей для топологии TDB (5 шардов) → TQE (3 шарда) → PostgreSQL. Для развертывания этой топологии необходимо три отдельных файла динамического инвентаря, которые комбинируются при запуске через несколько ключей --inventory:

 
ansible-playbook -i inventory_tdb_source.yml -i inventory_tqe.yml -i inventory_cdc.yml playbooks/cdc_install.yml

Стандартный инвентарь Tarantool DB, используемый в качестве источника данных для CDC. Для корректной работы репликации CDC необходимо включить расширенный формат WAL (wal.ext.old: true, wal.ext.new: true).

Инвентарь TQE для использования с CDC. gRPC-сервер TQE используется обработчиком CDC для подключения к очереди.

Конфигурация ниже актуальна для CDC 0.12.0+.

Для топологии через TQE используются два обработчика CDC:

1. Source-обработчик — читает данные из TDB (TarantoolConnector) и записывает в очередь TQE (TQESinkConnector);
2. Sink-обработчик — читает данные из очереди TQE (TQESourceConnector) и записывает в PostgreSQL (JdbcSinkConnector).

Оба обработчика хранят контрольные точки в TQE (storage.type: tqe).

В примере ниже для топологии TDB (5 шардов) → TQE (3 шарда) → PostgreSQL используются пять source-воркеров CDC (по одному на каждый шард TDB) и один sink-воркер CDC.

Параметры, общие для любого инвентаря CDC:

• В параметре cdc_worker_port каждого воркера укажите уникальный порт сервера для подключения приложения, чтобы избежать конфликтов при запуске нескольких обработчиков на одном сервере.
• В параметре cdc_source_connector_params.connect.targets укажите адрес узла соответствующего replicaset'а TDB-источника.
• В параметре cdc_source_connector_params.replication.id укажите уникальный идентификатор репликации для каждого воркера.
• В параметре cdc_sink_connector_params.connection.url укажите JDBC-URL приёмника PostgreSQL.
• Для корректного обнаружения плагинов (TQESinkConnector, TQESourceConnector, JdbcSinkConnector) укажите cdc_source_connector_package_name: "" и cdc_sink_connector_package_name: "" — это заставит сканер плагинов искать во всех подкаталогах бандла. Требуется бандл tarantool-cdc-jar-bundle версии 0.11.0 и выше (содержит debezium-connector-jdbc).
• Если spaces.include не указан, CDC реплицирует все пространства источника. Укажите список пространств для выборочной репликации.

Специфично для топологии через TQE:

• В параметре cdc_sink_connector_params.target source-обработчика укажите адрес gRPC-сервера TQE (совпадает с grpc_host:grpc_port из инвентаря TQE).
• В параметре cdc_source_connector_params.target sink-обработчика укажите тот же адрес gRPC-сервера TQE.
• И source-, и sink-обработчики хранят контрольные точки в TQE (storage.type: tqe).

Ниже приведён пример инвентарей для топологии TDB (5 шардов) → PostgreSQL (без TQE). Для развертывания этой топологии необходимо два отдельных файла динамического инвентаря:

 
ansible-playbook -i inventory_tdb_source.yml -i inventory_cdc.yml playbooks/cdc_install.yml

Инвентарь TDB-источника аналогичен инвентарю из предыдущего примера (TDB → TQE → PostgreSQL: динамический инвентарь).

Обработчик CDC читает данные из TDB через source-коннектор (TarantoolConnector), записывает в PostgreSQL через sink-коннектор (JdbcSinkConnector) и хранит контрольные точки в файле (storage.type: file).

Общие параметры CDC (cdc_worker_port, connect.targets, replication.id, connection.url, пакеты плагинов, spaces.include) описаны в предыдущем разделе (TDB → TQE → PostgreSQL: динамический инвентарь).

Специфично для топологии без TQE:

• cdc_sink_connector_params каждого воркера должен использовать JdbcSinkConnector для прямой записи в PostgreSQL.
• В параметре cdc_offset_params.storage.file.name укажите путь к файлу контрольных точек на целевом сервере. Путь должен быть доступен для записи пользователю, от имени которого запускается CDC (cdc_user).