Миф: LTS-версия — всегда правильный выбор

MAATRIX

«Бери LTS, не ошибёшься» — совет, который звучит на каждом форуме и в каждом чате про серверы. В нём есть здравое зерно: длинная поддержка действительно снижает риски. Но на практике LTS — это не универсальный «безопасный режим», а компромисс с конкретной ценой: свежесть пакетов и библиотек вы меняете на стабильность и предсказуемость. Иногда это выгодная сделка, иногда — нет, и разница решается не убеждениями, а характером конкретного проекта.

Что на самом деле означает LTS

LTS (Long Term Support) — это ветка релиза, для которой производитель обязуется дольше обычного выпускать патчи безопасности и критические исправления, не меняя при этом основную функциональность. Это касается и дистрибутивов (Ubuntu LTS, Debian stable), и рантаймов (Node.js LTS-ветки), и фреймворков, и отдельных СУБД, которые публикуют «поддерживаемые» мажорные версии на несколько лет вперёд.

Ключевое слово — «не меняя функциональность». LTS-ветка замораживается на определённом наборе версий пакетов и получает только backport-патчи: исправления багов и уязвимостей переносятся в старый код, а не притягиваются новые фичи апстрима. Это осознанная инженерная политика, а не «более качественная» версия того же самого — обычный (non-LTS/current/edge) релиз ничем не хуже по качеству кода, он просто живёт по другим правилам обновлений.

Отсюда и вытекает главная ошибка мифа: люди воспринимают LTS как «стабильнее» в смысле «меньше багов», хотя на самом деле речь про «медленнее меняется». Это разные вещи, и вторая не гарантирует первую.

Где LTS — действительно правильный выбор

Есть классы задач, где длинный цикл поддержки почти всегда перевешивает всё остальное:

• Продакшн-инфраструктура с долгим жизненным циклом. Сервер, который будет крутиться 3-5 лет без пересборки с нуля: почтовый сервер, DNS, внутренний git, панель управления. Здесь ценность в том, что security-патчи приходят регулярно, а API системы не меняется у вас под ногами каждые полгода.
• Регулируемые и критичные системы. Биллинг, медицинские и финансовые системы, инфраструктура с аудитом — там, где любое непредсказуемое изменение поведения нужно обосновывать перед комплаенсом, а не «само подтянулось при обновлении».
• Команды без выделенного DevOps-ресурса. Если обновлять сервер будет один человек раз в квартал между другими задачами, LTS с длинным окном поддержки прощает более редкие апдейты без риска остаться на дистрибутиве без патчей безопасности.
• Проекты, где обвязка (мониторинг, бэкапы, деплой) уже отлажена под конкретные версии. Каждое обновление major-версии — это риск сломать скрипты, cron-задачи, интеграции. LTS даёт больше времени между такими рисковыми событиями.
• Базовый слой инфраструктуры на сервере, который вы не хотите трогать вообще — ядро ОС, systemd, базовые системные библиотеки. Разработка приложения может идти своим темпом поверх стабильной базы.

Если ваш профиль — «поставил, настроил, хочу, чтобы работало и получало патчи безопасности без сюрпризов» — LTS почти всегда правильный ответ. Собственно поэтому большинство наших гайдов по установке в блоге по умолчанию ориентированы на LTS-релизы вроде Ubuntu 24.04 — это разумный дефолт для типового продакшена.

Скрытая цена: устаревшие зависимости

Проблема начинается там, где ваш проект не изолирован от версии системных пакетов. LTS-дистрибутив фиксирует версии на момент релиза и потом годами только патчит уязвимости — не поднимает мажорные версии. Это значит:

• Системный Python, Node.js, PHP, PostgreSQL или Redis из репозиториев LTS-дистрибутива может на момент вашего запуска быть уже год-два как не «последней стабильной» версией апстрима.
• Новые возможности языка или фреймворка, которые вышли позже точки заморозки ветки, просто не поедут через системный пакетный менеджер — их нет в репозитории вообще.
• Часть современных инструментов разработки (новые версии линтеров, сборщиков, CI-раннеров) требуют более новых системных библиотек (glibc, OpenSSL, libc++), которых в LTS-репозитории попросту нет — и обновить их отдельно от всей системы бывает больно или невозможно без риска что-то сломать.
• Пакеты из PPA/сторонних репозиториев, собранные под non-LTS окружение, иногда вообще отказываются ставиться на LTS из-за несовпадения версий системных зависимостей.

Здесь важно разделить два случая. Если вы ставите приложение через Docker с собственным образом — вы уже не зависите от системных версий пакетов, у вас своя изоляция, и «LTS хоста vs версия внутри контейнера» — разные истории: чем выше изоляция, тем меньше вы завязаны на системные пакеты хоста.

Но если вы ставите зависимости системным пакетным менеджером (apt install python3-pip, apt install nodejs) — вот тут LTS начинает диктовать вам, на каких версиях вы работаете, а не наоборот.

Когда LTS тормозит разработку, а не помогает

Обратная сторона того же механизма: если ваш проект активно использует новые возможности языка, фреймворка или инструментария, LTS-окружение может стать не подушкой безопасности, а тормозом.

Типичные сценарии:

• Стартап или продукт в активной разработке. Команда хочет фичи нового мажорного релиза фреймворка — улучшенную производительность, новый синтаксис, исправленные баги, которых в старой ветке никогда не будет, потому что LTS их принципиально не бэкпортит.
• ML/AI-инфраструктура. Библиотеки экосистемы (CUDA-тулкиты, фреймворки инференса, драйверы) обновляются быстро, и «стабильная» LTS-версия системных библиотек нередко просто не совместима с последними релизами таких инструментов — приходится либо собирать всё руками из исходников, либо переезжать на более новый дистрибутив, либо городить контейнеры поверх контейнеров.
• Фронтенд- и тулинг-цепочки. Свежие версии сборщиков и рантаймов JS нередко требуют более новых системных библиотек, чем есть в LTS-репозитории — тянуть их вручную поверх старой системы означает получить неофициальную, никем не тестируемую конфигурацию.
• Проекты, которые сами по себе недолговечны. Если сервису жить полгода-год до пересмотра архитектуры, «пять лет поддержки» не работает как аргумент — вы просто не доживёте до момента, когда это преимущество проявится, а вот с устаревшими версиями зависимостей столкнётесь сразу.
• Команды, которые сами являются источником обновлений. Если вы разрабатываете библиотеку или инструмент и должны тестировать его на актуальных версиях экосистемы, сидеть на LTS означает тестировать не на том окружении, в котором реально будут работать ваши пользователи.

В таких случаях уместнее current/non-LTS ветка — она получает новые версии пакетов раньше и чаще, ценой более короткого окна поддержки и, как следствие, более частых обновлений системы. Это осознанный trade-off в обратную сторону: вы платите временем на более частые апдейты, но получаете актуальный тулинг.

Показательный смежный миф разобран в статье Миф: обновления ломают больше, чем чинят — там же видно, что регулярные небольшие обновления обычно безопаснее, чем редкие большие скачки версий, к которым как раз приводит долгое сидение на устаревшей LTS-ветке без апдейтов внутри неё.

Как выбрать: рабочий чек-лист

Вместо того чтобы решать вопрос лозунгом «LTS — это святое» или «LTS — для тех, кто боится нового», честнее пройтись по конкретным критериям своего проекта.

Если большинство ответов в левой колонке — берите LTS не задумываясь, это правильный дефолт. Если большинство в правой — non-LTS или регулярно обновляемая ветка сэкономит вам время на обходные пути вокруг устаревших пакетов.

Отдельный совет: не путайте выбор ОС и выбор версий внутри приложения. Можно поставить Ubuntu LTS как базу (стабильное ядро, systemd, сеть, SSH) и при этом гонять внутри Docker-контейнеров самые свежие версии рантайма и библиотек — так вы получаете обе стороны компромисса одновременно. Про выбор дистрибутива для базового слоя есть отдельный разбор: Ubuntu или Debian — что выбрать для сервера.

Как жить с LTS, если выбрали именно её

Если решили, что LTS — ваш случай, несколько практик снижают её главный минус — устаревание версий:

• Не ставьте зависимости системным пакетным менеджером, если версия критична. Для Python используйте venv/pyenv, для Node.js — nvm, для PHP — репозитории вроде ondrej/php с явным указанием версии, для баз данных — официальные репозитории проекта, а не системные. Так вы получаете стабильную базовую ОС и актуальные версии рантайма отдельно.
• Docker как страховка от заморозки экосистемы. Контейнер с нужной версией рантайма и библиотек не зависит от того, что лежит в apt-репозитории хоста. Хост может быть на LTS пять лет, а внутри контейнеров — версии, которые вы обновляете по своему графику.
• Следите за EOL-датами явно, не полагаясь на память. Заведите себе напоминание или тикет за несколько месяцев до конца поддержки конкретной LTS-ветки — переезд на новую major-версию лучше планировать заранее, а не разбираться в панике, когда патчи безопасности перестали приходить.
• Не путайте «LTS ОС» с «LTS всего, что на ней стоит». Ubuntu LTS не означает, что установленная вами через сторонний репозиторий версия СУБД тоже LTS — у неё может быть собственный, гораздо более короткий, цикл поддержки, за которым надо следить отдельно.
• Тестируйте major-апгрейды на staging-окружении, а не на проде напрямую — тема отдельного разбора в статье Обновление мажорной версии базы на проде: даже внутри LTS рано или поздно наступает момент перехода на следующую поддерживаемую ветку, и делать это нужно предсказуемо.
• Держите список пакетов, поставленных не из системного репозитория, в документации проекта — через полгода-год будет не очевидно, что PostgreSQL или Node.js стоят из стороннего PPA, а не системные, и это важно знать при следующем major-апгрейде ОС.

Всё это — не отказ от идеи LTS, а способ убрать её главный недостаток, оставив главное преимущество: предсказуемые, редкие и хорошо протестированные security-патчи на уровне базовой системы.

Частые вопросы