Атомарность на серверах Linux. Да или нет?

Обсуждая с коллегами атомарные дистрибутивы очень часто можно услышать мнение, что мол да, десктопные туда уверенно идут и скоро придут, но вот серверные…

Серверные системы представляются как надежный оплот пакетной базы, где каждый админ, как тот суслик, сам себе агроном и сам себе собирает по кирпичикам нужную систему.

На самом деле это давно не так, ну разве только вы админ локалхоста. В корпоративных средах давно важна унификация и поддержка. Точнее снижение затрат на последнюю.

Любая собранная руками система накладывает дополнительные требования по своей поддержке и увеличивает суммарную стоимость владения.

К тому же сервер сегодня – это не сервер вчера, времена, когда одна система выполняла кучу различных ролей, канули в прошлое. Сегодня ведущую роль играет виртуализация и контейнеризация. И неписанным стандартом стало правило: одна роль – одна виртуалка (контейнер).

Таким образом типичный современный железный сервер будет с большой вероятностью иметь роль гипервизора. Либо еще что-то нишевое и специфическое: роутер, дисковое хранилище и т.д. со своей нишевой сборкой: OPNsense, TrueNAS и т.д. и т.п.

А все остальное – виртуалки или контейнеры, скорее всего последнее. Контейнеры экономичны, производительны, удобны и не несут ничего лишнего, тогда как виртуалка – это полноценная ОС со всем «фаршем».

Но так или иначе мы приходим к тому, что базовая система на физическом сервере должна обеспечить нам возможность запуска KVM, LXC, Docker. А остальное нас сильно не волнует. Точнее даже будет лучше, если вообще не будет волновать.

И мы снова приходим к атомарной системе. Чем плох атомарный гипервизор? Да ничем, наоборот даже лучше, что никакие шаловливые ручки не наставят в него левых пакетов и он не «скопытится» на очередном обновлении.

Тоже самое давно напрашивается в отношении OPNsense, TrueNAS и подобных, там давно никто не лазит под капот. Скажем та же RouterOS давно себе является атомарной. Мы просто загружаем новый образ системы и никого это не напрягает и не ущемляет.

Если завтра атомарным станет Proxmox – кому станет от этого хуже? Да никому, кроме полутора землекопов, которые пытаются из пакетов натянуть сову на глобус, типа установки на mdadm или еще чего-нибудь разработчиками нерекомендуемого и неподдерживаемого.

А так вышло обновление, прочитали отзывы, если все хорошо – обновляемся, нет – ждем следующего релиза.

И нет никаких конфликтов зависимостей, левых репозиториев и установленных через make install непотребств, которые могут взять и сломать все на ровном месте.

Вы всегда знаете, что у вас под капотом образ 123.45.6 и он работает именно так, как написано. Еще есть образ 123.45.7, но там есть траблы, поэтому подождем 123.46.0 где их не только исправят, но и новых «ништияков» подкинут.

А как же то, что мое приложение требует… Как-как? Берем контейнер с нужным окружением и пусть дальше требует, получите и распишитесь. Работаем, радуемся, никому не мешаем. Надо обновить? Просто заменили контейнер. Проблемы? Убили контейнер, создали новый из шаблона.

Это прекрасно представлено в парадигме Docker, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.

С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.

Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.

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

Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.