tt CLI глубоко: разработка, сборка, запуск

Рейтинг: 57.8% · 13 голосов
Исчерпывающий курс по Tarantool 3.x: модель данных, движки memtx и vinyl, Lua и файберы, транзакции и MVCC, SQL, конфигурация (box.cfg и декларативная 3.x), репликация и Raft, шардирование vshard, эксплуатация, безопасность. 47 уроков со схемами.
Ответить
Аватара пользователя
denis_tnt
Сообщения: 47
Зарегистрирован: 11 май 2026, 05:31

tt CLI глубоко: разработка, сборка, запуск

Сообщение denis_tnt »

Оглавление курса (47)
  1. Что такое Tarantool: in-memory СУБД и сервер приложений
  2. Архитектура изнутри: процесс, потоки, event-loop
  3. Установка и первый запуск: tt CLI, пакеты, Docker
  4. Интерактив: консоль, admin-консоль, первые команды
  5. Спейсы и кортежи: форматы, типы данных
  6. Типы индексов и их применимость
  7. Движки хранения: memtx vs vinyl
  8. DDL: схема, создание спейсов и индексов, миграции
  9. DML и выборки: insert/update/upsert, итераторы
  10. Персистентность: WAL, снапшоты, recovery
  11. Внутренности memtx: аллокаторы slab/arena, память
  12. Внутренности vinyl: LSM, компакция, тюнинг
  13. Lua и LuaJIT в Tarantool: box, модули, rocks
  14. Файберы: кооперативная многозадачность, каналы
  15. Транзакции: ACID, изоляция, MVCC
  16. Хранимые процедуры, модули, организация приложения
  17. net.box: удалённые вызовы, async
  18. Пулы соединений, балансировка, реконнект
  19. Ошибки и диагностика: box.error, pcall
  20. Типы и сериализация: MsgPack, decimal, datetime, uuid
  21. SQL в Tarantool: возможности и связь с box
  22. SQL: таблицы, JOIN, подзапросы, представления
  23. SQL: подготовленные выражения, транзакции, Lua-интероп
  24. Классическая конфигурация box.cfg (legacy 1.x/2.x)
  25. Декларативная конфигурация 3.x: config.yaml, иерархия
  26. Роли и приложения в 3.x
  27. Централизованная конфигурация: etcd / config storage
  28. tt CLI глубоко: разработка, сборка, запуск (вы здесь)
  29. Cartridge (официальный legacy) и миграция на 3.x
  30. Репликация: replicaset, топологии
  31. Механика репликации: WAL-стриминг, vclock
  32. Синхронная репликация и выборы лидера (Raft)
  33. Жизненный цикл узла: bootstrap, join, rejoin
  34. vshard: router/storage, виртуальные бакеты
  35. Решардинг и rebalancing бакетов
  36. Запросы поверх шардов: map-reduce, crud
  37. Мониторинг: метрики, Prometheus, Grafana
  38. Логирование и аудит
  39. Бэкапы и восстановление
  40. Безопасность: аутентификация, RBAC, TLS
  41. Производительность: профилирование, тюнинг
  42. Обновления: схема, rolling upgrade
  43. Деплой в продакшен: Docker, топология (официальные паттерны)
  44. Администрирование через официальный TCM (Tarantool Cluster Manager)
  45. Коннекторы: Python, Go, Java
  46. Ключевые модули (rocks): crud, metrics, queue, expirationd
  47. Capstone: шардированный отказоустойчивый кластер
Обзор: что такое tt и зачем он нужен

tt - это официальная единая консольная утилита Tarantool, написанная на Go. Она заменила устаревший tarantoolctl и закрывает весь жизненный цикл приложения: установку нужной версии ядра, генерацию каркаса из шаблона, сборку зависимостей, фоновый запуск инстансов, подключение к консоли, проверку статуса, остановку и упаковку. Ключевая идея урока: tt - это не просто запускалка процессов, а менеджер окружения (environment). Понимание того, что такое окружение и как tt раскладывает по нему файлы, объясняет почти всё поведение команд.

В этом уроке мы пройдём минимальный рабочий цикл: init -> create -> build -> start -> connect -> status -> stop, и разберём, что происходит под капотом на каждом шаге.

Механика: окружение, конфиг и раскладка файлов

Сердце tt - конфигурационный файл tt.yaml. Его создаёт команда . Корень окружения (environment root) - это директория, где лежит tt.yaml. Когда вы запускаете любую команду, tt ищет tt.yaml от текущей директории вверх до корня файловой системы; если не нашёл - берёт системный из /etc/tarantool. Это так называемый default launch mode. Есть ещё system (-S, всегда /etc/tarantool) и local (-L DIR, искусственно заданный корень). Из-за поиска вверх по дереву можно случайно подцепить чужой tt.yaml родительской директории - это первая типичная путаница.

Внутри tt.yaml несколько секций. Самые важные:
  • env.instances_enabled - директория, где лежат приложения (по умолчанию instances.enabled). Только то, что здесь, tt считает enabled и видит командами start, status, stop.
  • env.bin_dir (bin) - сюда ставятся бинарники tarantool и tt при tt install.
  • app.run_dir / log_dir / wal_dir / vinyl_dir / memtx_dir - пути для рантайм-артефактов: сокеты и pid, логи, .xlog, .vylog, .snap. По умолчанию var/run, var/log, var/lib.
Важно: в tt 2.0 раскладка изменилась. Теперь app.*_dir отсчитываются НЕ от корня окружения, а от директории приложения внутри instances.enabled. То есть логи лежат в instances.enabled/myapp/var/log/<instance_name>/, а не в общем var у корня. Многие гайды из эпохи tt 1.x вводят в заблуждение.
Приложение - это директория внутри instances.enabled. Для Tarantool 3.x в ней должны быть два файла: config.yaml (декларативная конфигурация: топология, имена инстансов, их роли) и instances.yml (список инстансов, которые поднимать в этом окружении). Можно положить и .lua-файлы с прикладным кодом. Имя директории = имя приложения (то, что вы пишете в tt start app).

Изображение
Рабочий цикл tt: init, create, build, start, connect

Команды и примеры

Шаг 0. Создать окружение

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

tt init
# создаст tt.yaml и каркас директорий:
#   bin/  include/  distfiles/  instances.enabled/  modules/  templates/
Шаг 1. Создать приложение из шаблона

tt create инстанцирует приложение из шаблона. Встроенные шаблоны для 3.x: single_instance (один инстанс) и vshard_cluster (шардированный кластер). Шаблон cartridge оставлен только для устаревшего Tarantool 2.x.

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

tt create single_instance --name myapp
# -s / --non-interactive   - не спрашивать переменные интерактивно
# --var name=value         - задать переменную шаблона
# -f / --force             - перезаписать существующую директорию
# -dst PATH                - куда создавать (по умолчанию ./<name>)
Шаблон - это набор файлов плюс манифест MANIFEST.yaml (секции description, vars, pre-hook/post-hook, include). Файлы с расширением .tt.template проходят подстановку переменных в синтаксисе Go-шаблонов: {{.name}}, {{.user_name}}, после чего расширение .tt.template снимается. Переменная name есть всегда и берётся из --name.

Шаг 2. Собрать приложение

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

tt build [PATH] [--spec app-scm-1.rockspec]
tt build по сути делает tt rocks make: читает .rockspec в директории приложения и тянет зависимости в локальную поддиректорию .rocks. Если rockspec несколько - укажите нужный через --spec. До и после сборки tt выполняет скрипты tt.pre-build и tt.post-build, если они есть (имена cartridge.pre-build / cartridge.post-build тоже распознаются для совместимости). pre-build удобен, чтобы собрать закрытые или submodule-rocks; post-build - чтобы вычистить артефакты сборки из пакета. Если у приложения нет внешних зависимостей и rockspec, шаг build можно пропустить.

Шаг 3. Запустить

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

tt start myapp            # все инстансы приложения по instances.yml
tt start myapp:router     # только инстанс router
tt start                  # все enabled-приложения окружения
tt start -i myapp         # интерактивно: логи в stdout, Ctrl+C останавливает
По умолчанию tt start запускает процессы tarantool в фоне и навешивает на каждый свой watchdog-процесс. Именно watchdog потом отвечает на tt status и принимает остановку через tt stop (SIGTERM идёт в watchdog, а тот корректно гасит инстанс). Поэтому нельзя включать фоновый режим средствами самого Tarantool (process.background: true в config.yaml или box.cfg.background) - тогда tt потеряет контроль над процессом и не сможет ни статус узнать, ни остановить.

Шаг 4. Подключиться

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

tt connect myapp                 # локально, по имени инстанса, без пароля
tt connect myapp:master          # конкретный инстанс
tt connect 192.168.1.10:3301 -u user -p pass   # удалённо, по URI
tt connect myapp -l sql          # язык консоли: lua (по умолчанию) или sql
tt connect myapp -f script.lua   # выполнить скрипт, не входя в консоль
Локальное подключение по имени идёт через unix-сокет из run_dir и не требует аутентификации. Удалённое по URI - требует, и без логина/пароля вы попадаете под пользователем guest. В консоли доступен модуль box:

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

myapp:instance001> box.info.ro
---
- false
...
myapp:instance001> box.space._space:count()
Статус и остановка

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

tt status myapp
# INSTANCE   STATUS   PID   MODE  CONFIG  BOX      UPSTREAM
# колонки: имя | running/not running | pid | RW/RO |
#          состояние config.info() | состояние box.info() | upstream репликации

tt stop myapp           # остановить всё приложение
tt restart myapp:i1     # перезапуск (спросит подтверждение)
tt clean myapp          # удалить артефакты: логи, снапшоты, xlog
Частые заблуждения и грабли
  • Приложение не видно командами. tt видит только то, что лежит (или симлинкнуто) в instances.enabled. Создали в другом месте через -dst и забыли симлинк - tt start app скажет, что приложения нет.
  • Не тот tt.yaml. Поиск конфига идёт вверх по дереву. Запускаете из вложенной папки - можете подцепить родительский или системный конфиг. Проверяйте через tt cfg dump или флаг -c.
  • Фоновый режим дважды. tt уже запускает в фоне через watchdog. Включать background внутри Tarantool нельзя - сломаете status и stop.
  • build не нужен всем. tt build - это про LuaRocks-зависимости. Чистому single_instance без rockspec он не требуется; вызов на пустом приложении просто ничего полезного не сделает.
  • config.yaml против box.cfg. В 3.x конфигурация декларативная (config.yaml). Старый путь через init.lua с box.cfg считается legacy; tt его ещё поддерживает, но документация для него - в ветке 2.11.
  • Остаточный pid/сокет. При жёстком убийстве процесса в run_dir могут остаться tt.pid и сокет; tt stop ругнётся, что не может stat pid-файл - это значит инстанс уже мёртв.
Мини-лаба
Задание. Соберите полный цикл с нуля в пустой директории:
1) tt init;
2) tt create single_instance --name lab --non-interactive;
3) tt start lab;
4) tt status lab - убедитесь, что STATUS = RUNNING и запомните PID;
5) tt connect lab и выполните box.info.uptime и box.cfg.memtx_memory;
6) выйдите (Ctrl+D), сделайте tt stop lab и снова tt status lab - статус должен смениться.
Бонус: найдите в файловой системе путь к unix-сокету и pid-файлу инстанса (подсказка: instances.enabled/lab/var/run/<instance>/).
Контрольные вопросы
  • Где физически лежат логи, snapshot и pid-файл инстанса myapp в default launch mode, и от чего отсчитываются эти пути в tt 2.0+?
  • Почему нельзя включать background средствами Tarantool, если приложение запускается через tt start? Какую роль играет watchdog?
  • Чем локальное подключение tt connect myapp по имени отличается от подключения по URI в плане аутентификации, и под каким пользователем вы окажетесь без логина?
  • Что именно делает tt build под капотом, куда складывает результат и в каком случае этот шаг можно пропустить?
👍2 ❤️4 🔥 😄 🤔1
Ответить
← Предыдущая глава
Централизованная конфигурация: etcd / config storage
Следующая глава →
Cartridge (официальный legacy) и миграция на 3.x

Все главы курса «Tarantool: in-memory СУБД и сервер приложений с нуля до продакшена»

Поделиться темой: ✈ Telegram VK

Вернуться в «Tarantool: СУБД и сервер приложений»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость