tmux на проде после Screen
Почему перешли с Screen на tmux
Screen был нашим инструментом номер один ещё лет пять назад. Но после миграции кластера на новые серверы стало очевидно: screen теряет сессию при обрыве SSH, если не настроен hardstatus, а восстановление через screen -r иногда ловит race condition при одновременном подключении нескольких админов. tmux решает оба вопроса из коробки — сессия живёт в памяти сервера, привязана к сокету, и подключение к ней не зависит от состояния TCP-соединения.
Переход занял полдня: настроили общий конфиг, раздали ключбиндинги, проверили на staging. На продакшен ушли через неделю — после того как tmux прошёл через два инцидента, где screen бы потерял контекст.
Ключевые отличия от GNU Screen
Не повторяем историю Screen. Фокус — на том, что tmux даёт иначе.
Главное отличие — архитектура. tmux клиент-серверная модель с отдельным серверным процессом на каждую сессию. Screen тоже клиент-сервер, но его сессия привязана к терминалу хуже и чаще теряется при обрыве.
| Аспект | Screen | tmux |
|---|---|---|
| Восстановление сессии | screen -r (может упасть) | tmux attach -t <name> (стабильно) |
| Поддержка 256 цветов | Ограниченная | Полная, default-terminal "screen-256color" |
| Синхронизация ввода | Через multiuser + acladd | Через set -g allow-rename off + совместные сессии |
| Конфигурация | ~/.screenrc | ~/.tmux.conf |
| Состояние после обрыва | Часто теряется | Сессия жива, сокет на месте |
| Скриптование | screen -X | tmux send-keys, tmux split-window |
Ещё одно — tmux имеет нормальный copy-mode. В Screen приходилось мучиться с выделением текста через escape-последовательности. В tmux Ctrl+B [ — и вы в scrollback с поиском.
Когда tmux, когда нет
tmux не панацея. Есть сценарии, где он избыточен или даже вреден.
tmux имеет смысл, когда:
- несколько админов работают с одним сервером одновременно;
- сессии длительные (мониторинг, деплой, дебаг);
- нужен стабильный copy-mode и скроллбек;
- автоматизация через
tmuxCLI (CI/CD скрипты, которые шлют команды в сессию).
tmux не нужен, когда:
- один админ на один сервер, сессии короткие;
- система ограничена по памяти — tmux-сервер потребляет больше RAM, чем screen (хотя на современных машинах это нивелировано);
- используется контейнерная среда с ephemeral файловой системой — конфиг tmux не переживёт пересоздание контейнера без volume.
В Docker лучше использовать docker exec -it <container> bash вместо tmux внутри контейнера. tmux в контейнере имеет смысл только для stateful сервисов, где нужен persistent shell-доступ.
Базовые команды для продакшена
Стандартный префикс — Ctrl+B. Все команды после него.
Создание и подключение:
Управление окнами и панелями:
Работа с копией:
Скриптовый вызов (для автоматизации):
Сохранение сессии при перезагрузке сервера:
tmux не переживёт reboot. Если нужна живая сессия после перезагрузки — используйте tmux-resurrect плагин или скрипт в cron, который пересоздаёт сессии из файла состояния.
Минимальный ~/.tmux.conf для прода:
После правки конфига: tmux source-file ~/.tmux.conf.
Итог
tmux заменил Screen на проде не потому что «новее», а потому что его сессии не теряются при обрыве, копирование работает без костылей, а скриптование через CLI даёт предсказуемость при автоматизации. Минус — чуть больше потребление памяти и необходимость поддерживать единый конфиг на всех серверах. Для нашего стека из 12 прод-серверов с тремя админами на каждом это окупилось за первую неделю.