Администрирование через официальный TCM (Tarantool Cluster Manager)

[denis_tnt]

Что такое TCM и зачем он нужен

Tarantool Cluster Manager (TCM) - официальная веб-админка для кластеров Tarantool, входящая в Enterprise Edition. Это standalone-приложение, написанное на Go и поставляемое как готовый исполняемый файл для Linux прямо в дистрибутиве Tarantool EE. Один процесс TCM поднимает HTTP-сервер (по умолчанию http://127.0.0.1:8080) и даёт графический интерфейс для конфигурирования, управления и мониторинга кластеров.

Ключевое ограничение, которое надо понять сразу: TCM работает ТОЛЬКО с кластерами Tarantool EE 3.0+, которые используют централизованное хранилище конфигурации - etcd или Tarantool-based config storage. Это не случайно. TCM не правит файлы yaml на узлах и не лезет руками в каждый инстанс. Когда вы редактируете конфигурацию в редакторе TCM и нажимаете Apply, TCM публикует новую версию в централизованное хранилище, а инстансы сами подхватывают её через механизм config-reload. Поэтому без etcd (или tarantool config storage) TCM конфигурацию применять некуда.

TCM - это окно в централизованную конфигурацию, а не агент на каждом узле. Он меняет источник правды (etcd), а кластер реагирует сам. Если у вас классический box.cfg без centralized config - TCM вам не подойдёт, это инструмент декларативного трека 3.x.

Как это устроено внутри: stateless + backend store

Главная архитектурная идея TCM - он stateless. Сам процесс TCM не хранит свои данные внутри себя. Всё, что вы создаёте в UI (пользователи TCM, роли, подключения к кластерам, настройки, записи аудита), сохраняется в отдельное хранилище - backend store. Backend store - это тоже etcd или Tarantool, работающий независимо от TCM.

Из этого вытекают важные следствия для администратора:

• Любое число инстансов TCM можно подключить к одному backend store - они дублируют друг друга (горизонтальное масштабирование, HA админки).
• Если остановить все инстансы TCM, данные останутся в store. Поднимаете новый процесс - продолжаете с того же места.
• Backend store может быть тем же etcd-кластером, что вы используете как config storage. По умолчанию данные TCM лежат под префиксом /tcm.

Не путайте два разных хранилища, хотя физически это может быть один и тот же etcd:

Код: Выделить всё

+---------------------------+--------------------------------+
| Хранилище                 | Что в нём лежит                |
+---------------------------+--------------------------------+
| backend store (storage.*) | сущности самого TCM:           |
|                           | юзеры/роли/подключения/аудит   |
|                           | префикс по умолчанию: /tcm     |
+---------------------------+--------------------------------+
| config storage кластера   | YAML-конфиг кластера Tarantool |
|                           | префикс задаёте вы, напр.      |
|                           | /cluster1, /default            |
+---------------------------+--------------------------------+

Безопасность тоже встроена в TCM. У него своя role-based access control: создаёте пользователей TCM, назначаете роли с правами (например, admin конкретного кластера или только чтение данных). Поддерживается LDAP. Пароли, которыми TCM подключается к Tarantool и etcd, шифруются ключом шифрования TCM - не храните этот ключ как попало, без него зашифрованные подключения не расшифровать.


Архитектура TCM: stateless UI, backend store, config storage и кластер

Запуск, конфигурация, первый вход

TCM конфигурируется тремя способами с понятным приоритетом (от высшего к низшему): аргументы командной строки -> переменные окружения TCM_* -> YAML-файл. Параметры именуются полным путём от группы: http.host, http.tls.enabled и т.д. Параметры имеют типы Go (а не Lua, как конфиг Tarantool!) - int, bool, string, time.Duration (например 10s, 4h30m25s).

Сгенерировать шаблон полного конфига со всеми значениями по умолчанию:

Код: Выделить всё

$ tcm generate-config > tcm.example.yml

Запуск с YAML-файлом:

Код: Выделить всё

$ tcm -c=config.yml

Запуск через переменные окружения (имя = TCM_ + путь в верхнем регистре, разделители -> подчёркивания):

Код: Выделить всё

$ export TCM_HTTP_HOST=0.0.0.0
$ export TCM_HTTP_PORT=8888
$ tcm

Минимальный фрагмент конфига с подключением backend store к etcd:

Код: Выделить всё

# tcm.yaml
http:
  host: 127.0.0.1
  port: 8080
storage:
  provider: etcd          # либо tarantool
  etcd:
    endpoints:
      - http://127.0.0.1:2379
    prefix: /tcm           # где TCM держит свои данные

Первый вход. После bootstrap логиньтесь как admin. Начальный пароль TCM генерирует и печатает в лог при старте, строкой вида:

Код: Выделить всё

WRN Generated super admin credentials login=admin password=jS9PsdkEJBYNhdMtSswMlxDR1vdbfc1N

Сразу после входа настройте password policy и смените пароль admin на странице User settings.

Что доступно в интерфейсе

Страницы сгруппированы в навигации: Cluster (работа с выбранным кластером), Clusters (все подключения), Users (доступ), Tools (обслуживание TCM), Settings. Главная страница кластера - Stateboard: топология, память, версии Tarantool, переход на страницу инстанса. На странице инстанса есть вкладки Details/State (вывод box.info, box.cfg), SQL и Terminal (интерактивная консоль Lua/SQL), Logs, Slabs (визуализация box.slab.stats()), Users, Funcs, Metrics.

Частые заблуждения и грабли

• TCM не нужен Tarantool-кластеру для работы. Подключение и отключение кластера в TCM никак не влияет на сам кластер - он продолжает работать. TCM это лишь окно наблюдения и управления.
• TCM это не Cartridge UI. Старый веб-интерфейс Cartridge - для legacy-стека Cartridge. TCM - для декларативной конфигурации 3.x через etcd. Это разные миры.
• Один etcd, но два префикса. Частая путаница: backend store TCM (/tcm) и config storage кластера (/cluster1) могут жить в одном etcd, но это разные деревья ключей. Перепутали префикс - TCM не видит конфиг кластера.
• Потеря начального пароля. Пароль admin генерируется один раз и пишется только в лог старта. Не сохранили - придётся пересоздавать через initial-settings или сбрасывать store.
• initial-settings применяются только при первом старте. Секция initial-settings.clusters создаёт сущности один раз. Поправили её и перезапустили TCM - изменения не применятся. Дальше правьте через UI.
• guest по умолчанию. К инстансам Tarantool TCM по умолчанию ходит под пользователем guest. В проде заведите отдельного пользователя с нужными правами и шифрованием iproto.
• Tuples нужен CRUD. Кластерный просмотр данных на вкладке Tuples работает только для шардированных кластеров на модуле CRUD, и с TCM 1.6.0 вкладка по умолчанию выключена (включается feature.tuples: True).

Мини-лаба

Задание (теоретическое, без поднятия кластера): сгенерируйте шаблон конфигурации TCM и найдите в нём ключевые секции.

• Выполните: tcm generate-config > tcm.example.yml
• Откройте файл и найдите три вещи: (1) секцию http (host/port веб-интерфейса), (2) секцию storage (provider и endpoints backend store), (3) секцию initial-settings (как задать начальные кластеры и пользователей).
• Ответьте письменно: если поменять storage.etcd.prefix с /tcm на /tcm-staging, что произойдёт с пользователями и подключениями, которые вы создали ранее?

Ожидаемый вывод по последнему пункту: новый префикс - это новое пустое дерево в etcd, поэтому TCM стартует как чистый, со сгенерированным новым паролем admin; старые сущности останутся под /tcm и станут невидимы, пока не вернёте префикс.

Контрольные вопросы

• Почему TCM называют stateless и где на самом деле хранятся его пользователи, роли и подключения?
• Чем backend store отличается от config storage кластера, и могут ли они физически совпадать?
• Что происходит в etcd, когда вы редактируете конфигурацию кластера в редакторе TCM и нажимаете Apply - и как изменения доходят до инстансов?
• Каков приоритет источников конфигурации TCM (CLI / env / YAML) и где взять начальный пароль admin?