Перейти к содержимому

tmux на проде после Screen

Почему перешли с Screen на tmux

Screen был нашим инструментом номер один ещё лет пять назад. Но после миграции кластера на новые серверы стало очевидно: screen теряет сессию при обрыве SSH, если не настроен hardstatus, а восстановление через screen -r иногда ловит race condition при одновременном подключении нескольких админов. tmux решает оба вопроса из коробки — сессия живёт в памяти сервера, привязана к сокету, и подключение к ней не зависит от состояния TCP-соединения.

Переход занял полдня: настроили общий конфиг, раздали ключбиндинги, проверили на staging. На продакшен ушли через неделю — после того как tmux прошёл через два инцидента, где screen бы потерял контекст.

Ключевые отличия от GNU Screen

Примечание

Не повторяем историю Screen. Фокус — на том, что tmux даёт иначе.

Главное отличие — архитектура. tmux клиент-серверная модель с отдельным серверным процессом на каждую сессию. Screen тоже клиент-сервер, но его сессия привязана к терминалу хуже и чаще теряется при обрыве.

АспектScreentmux
Восстановление сессииscreen -r (может упасть)tmux attach -t <name> (стабильно)
Поддержка 256 цветовОграниченнаяПолная, default-terminal "screen-256color"
Синхронизация вводаЧерез multiuser + acladdЧерез set -g allow-rename off + совместные сессии
Конфигурация~/.screenrc~/.tmux.conf
Состояние после обрываЧасто теряетсяСессия жива, сокет на месте
Скриптованиеscreen -Xtmux send-keys, tmux split-window

Ещё одно — tmux имеет нормальный copy-mode. В Screen приходилось мучиться с выделением текста через escape-последовательности. В tmux Ctrl+B [ — и вы в scrollback с поиском.

Когда tmux, когда нет

Предупреждение

tmux не панацея. Есть сценарии, где он избыточен или даже вреден.

tmux имеет смысл, когда:

  • несколько админов работают с одним сервером одновременно;
  • сессии длительные (мониторинг, деплой, дебаг);
  • нужен стабильный copy-mode и скроллбек;
  • автоматизация через tmux CLI (CI/CD скрипты, которые шлют команды в сессию).

tmux не нужен, когда:

  • один админ на один сервер, сессии короткие;
  • система ограничена по памяти — tmux-сервер потребляет больше RAM, чем screen (хотя на современных машинах это нивелировано);
  • используется контейнерная среда с ephemeral файловой системой — конфиг tmux не переживёт пересоздание контейнера без volume.
Подсказка

В Docker лучше использовать docker exec -it <container> bash вместо tmux внутри контейнера. tmux в контейнере имеет смысл только для stateful сервисов, где нужен persistent shell-доступ.

Базовые команды для продакшена

Стандартный префикс — Ctrl+B. Все команды после него.

Создание и подключение:

tmux new -s prod-db
tmux attach -t prod-db
tmux list-sessions

Управление окнами и панелями:

Ctrl+B c          # новое окно
Ctrl+B &          # закрыть окно
Ctrl+B %          # разделить панели вертикально
Ctrl+B "          # разделить панели горизонтально
Ctrl+B o          # переключить между панелями
Ctrl+B z          # полноэкранный режим текущей панели

Работа с копией:

Ctrl+B [          # войти в copy-mode
Space             # начать выделение
Enter             # скопировать
Ctrl+B ]          # вставить буфер обмена

Скриптовый вызов (для автоматизации):

tmux send-keys -t prod-db "systemctl restart api" C-m
tmux split-window -t prod-db -h "tail -f /var/log/api.log"

Сохранение сессии при перезагрузке сервера:

Предупреждение

tmux не переживёт reboot. Если нужна живая сессия после перезагрузки — используйте tmux-resurrect плагин или скрипт в cron, который пересоздаёт сессии из файла состояния.

Минимальный ~/.tmux.conf для прода:

set -g default-terminal "screen-256color"
set -g base-index 1
set -g pane-base-index 1
set -g allow-rename off
set -g set-titles on
set -g set-titles-string "#S:#I.#P #W"
set -g status-keys vi
set -g mouse on
bind -n M-1 select-pane -t 0
bind -n M-2 select-pane -t 1
bind -n M-3 select-pane -t 2

После правки конфига: tmux source-file ~/.tmux.conf.

Итог

tmux заменил Screen на проде не потому что «новее», а потому что его сессии не теряются при обрыве, копирование работает без костылей, а скриптование через CLI даёт предсказуемость при автоматизации. Минус — чуть больше потребление памяти и необходимость поддерживать единый конфиг на всех серверах. Для нашего стека из 12 прод-серверов с тремя админами на каждом это окупилось за первую неделю.