Привет, Хабр. Меня зовут Кирилл Балашов, я инженер‑программист компании РЕД СОФТ. Мы в РЕД СОФТ изучили подходы к иммутабельным, или же неизменяемым операционным системам, сравнили полностью иммутабельную модель и гибридную, и выбрали гибрид для неизменяемого варианта РЕД ОС 8. Сегодня я расскажу, почему такая операционка удобнее для решения определённого круга enterprise‑задач и покажу, как она работает.
Проблема дрейфа конфигурации
У классических Linux‑дистрибутивов есть проблема: со временем накапливается «дрейф конфигурации»: недокументированные изменения, ручные правки, расходящиеся версии пакетов на разных серверах. Когда вы разворачиваете сотни однотипных узлов, такая вариативность становится критичной: усложняется обновление, диагностика и обеспечение безопасности. Перед нами стояла задача изучить существующие подходы к решению этой проблемы и создать иммутабельную версию операционной системы, которая гарантирует воспроизводимость и автоматически поддерживает заданное состояние.
Так мы открыли для себя неизменяемые операционные системы. В таких системах корневая файловая система монтируется только для чтения. Вместо императивных скриптов, описывающих последовательность действий, здесь работает декларативная модель: администратор один раз описывает желаемое состояние, а встроенные механизмы непрерывно приводят реальную систему к этому эталону, устраняя отклонения.
Как индустрия пришла к иммутабельности
Эволюция проходила в две волны.
Единый образ + фоновый агент
Сначала появились минималистичные серверные операционные системы на базе единого образа с фоновым агентом обновлений: новый образ загружался на неиспользуемый раздел диска, и после перезагрузки система переключалась на него. Главным принципом того времени было «всё — контейнер», то есть даже системные сервисы предлагалось запускать в изолированных окружениях, чтобы отделить их от хоста.
Специализированные платформы
Затем возникли специализированные платформы, которые довели этот подход до логического завершения: полный отказ от традиционного пакетного менеджера, использование монолитных образов, постоянный интерактивный доступ отсутствует. Примеры этого направления — Talos Linux и Bottlerocket OS.
В основе развития лежал поиск решения для трёх фундаментальных задач:
Атомарное управление файловой системой: системы перешли от привычных пакетных менеджеров к механизмам, которые либо хранят деревья фиксаций на основе жёстких ссылок, либо полностью заменяют системный раздел по схеме с двумя чередующимися разделами. В любом случае текущее развёртывание всегда монтируется только для чтения, а новое готовится заранее и применяется после перезагрузки.
Централизованное декларативное конфигурирование и обновление: вместо императивных скриптов администратор описывает «что должно быть» в документе формата YAML или JSON; начальная настройка выполняется однократно при старте, а фоновый агент обновлений периодически опрашивает удалённый сервер, загружает новый снимок системы и после перезагрузки атомарно переключает на него. Это обеспечивает регулярную актуализацию без вмешательства человека.
Максимальное сокращение кодовой базы самого хоста: компоненты собираются статически, целостность проверяется цифровыми подписями, а постоянный удалённый доступ через SSH полностью исключается, что резко уменьшает поверхность для атак.
В результате индустрия пришла к двум параллельно сосуществующим архитектурам, которые рассмотрим подробно далее.
Обзор архитектур
Полностью иммутабельная операционная система
Схема слоёв:
Базовый слой — это монолитное ядро, собранное статически и включающее минимум компонентов; здесь нет командной оболочки, пакетного менеджера и утилит для изменения системы.
Пользовательский слой содержит только критически важные данные — логи, образы контейнеров, конфигурацию кластера; всё остальное живёт в оперативной памяти и исчезает при перезагрузке.
Она создана для работы в качестве ноды под управлением оркестраторов контейнеров, прежде всего Kubernetes. Все компоненты — сетевые плагины, агенты, среда выполнения — поставляются как образы и управляются статическими подами. Постоянный интерактивный доступ на уровне ядра отсутствует, а сам образ пересобирается CI/CD‑конвейером при любом изменении конфигурации.
Гибридная модель
Схема слоёв:
Базовый слой — неизменяемый образ в формате OSTree.
Над ним располагается слой локальных приложений: сюда можно «наслаивать» дополнительные пакеты, драйверы, агенты мониторинга через механизмы типа rpm‑ostree, не пересобирая всю систему.
Верхний пользовательский слой — это постоянные разделы вроде
/var,/optи/srv, где хранятся системные конфигурации, состояние приложений и все данные, которые должны пережить обновления.
Гибридная модель предлагает компромисс. Берётся базовый образ, монтируется как неизменяемый нижний слой, поверх которого располагается слой локально установленных rpm‑пакетов. Также монтируемый в дерево OSTree в режиме только для чтения, позволяющий локально изменять состав неизменяемого образа без его полной пересборки. Сервисы выносятся в контейнеры, а управление конфигурацией и дополнительными компонентами идёт через технологии слоёных атомарных обновлений. После настройки постоянный SSH‑доступ обычно отключается, вместо него может использоваться Ansible с временным подключением.
Сравнение архитектур
Критерий | Полностью иммутабельная | Гибридная |
Идентичность узлов | Максимальная | Высокая, но есть вариативность из‑за доустановки пакетов |
Скорость развёртывания | Очень высокая | Высокая |
Сложность CI/CD | Любое изменение — пересборка образа | Сложность ниже, так как пакеты можно доустановить через rpm‑ostree |
Диагностика и отладка | Сложно, особенно на «голом железе» | Сохранены привычные инструменты |
Поверхность атаки | Минимальна | Чуть шире (временный SSH и перезаписываемый слой) |
Установка доп. компонентов | Только пересборка образа целиком | Штатно через rpm‑ostree |
Совместимость с оборудованием | Только с тем, что заложено в образ | Драйверы и модули ядра |
Целевая среда | Облако, Kubernetes | Облако + «железо» + legacy |
На каком варианте остановить выбор?
Сложность сборочного конвейера у полностью иммутабельной модели высокая — любое изменение требует пересборки образа. У гибридной модели она ниже, так как за счёт установки пакетов нет необходимости пересобирать образ при каждом изменении системы.
Возможности диагностики и отладки в полностью иммутабельной системе отсутствуют, в гибридной же они сохранены.
По минимальной поверхности атаки полностью иммутабельная ОС лидирует. У гибридной поверхность атаки больше из‑за возможности включать SSH, а также локально изменять конфигурационные файлы в
/etc.Установка дополнительных компонентов в первом случае — только через пересборку образа, во втором — штатно через rpm‑ostree.
Таким образом, если ваша главная цель — безопасность и абсолютная идентичность, выбирайте полностью иммутабельную модель. Если же нужны гибкость, совместимость и возможность администрирования привычными методами — гибридная модель это ваш вариант.
Именно гибридная модель была выбрана для реализации неизменяемого варианта РЕД ОС 8.
Неизменяемый вариант РЕД ОС 8
В основе неизменяемой РЕД ОС 8 — корневая файловая система только для чтения и атомарные обновления на базе rpm‑ostree. Перезаписываемые разделы сохраняют состояние приложений, логи, конфигурации и данные между обновлениями. Система спроектирована так, чтобы обеспечивать повторяемость узлов и при этом давать возможность запускать необходимые сервисы не только в контейнерах, но и в виде дополнительного слоя с пакетами.
Механизм гибридного обновления
На практике начальная конфигурация описывается в Ignition‑файле. Пример — минимальный файл ignition, создающий при установке РЕД ОС 8 Core пользователя «redos» с паролем «qqqwww» (прописывается в виде HASH) с предоставлением пользователю прав администрирования системы:
{ "ignition": { "version": "3.2.0" }, "passwd": { "users": [ { "name": "redos", "gecos": "RED OS Core Admin", "passwordHash": "$2a$10$2mgLNA3h4NbJYQpePh.Fe0hhEsblwjr.YBE.Vyq200lkqjViKj7xG", "groups": [ "adm", "sudo", "systemd-journal", "wheel" ] } ] } }
Когда приходит обновление, агент загружает новый снимок OSTree, проверяет его цифровую подпись, и после перезагрузки система атомарно переключается на новую версию; все пользовательские данные и настройки при этом полностью сохраняются.
Кому и для чего нужна неизменяемая РЕД ОС 8
Прежде всего, администраторам с классическими навыками не придётся переучиваться: они получат знакомые утилиты и привычную структуру каталогов.
Парк разнородного оборудования с разными драйверами и модулями ядра — среда, в которой можно доустанавливать специфические пакеты через rpm‑ostree без пересборки всего образа.
Задачи оркестрации и контейнеризации — родная стихия для такой операционки: всё заточено под Kubernetes, но без жёсткой привязки.
Конвейеры CI/CD требуют воспроизводимых чистых окружений, а атомарные обновления и контейнеризация здесь идеально ложатся в процессы.
Информационные системы высокой надёжности — серверы КИИ, АСУ ТП, standalone‑серверы, гипервизоры — получают декларативное описание, атомарные обновления с возможностью отката и сохранение всех критичных данных. И даже любители экспериментировать на «боевых» серверах, хоть это и не рекомендуется, получают спасительный откат к последнему стабильному состоянию.
Заключение
Итогом нашей работы стал выбор гибридной модели для неизменяемого варианта РЕД ОС 8. Мы реализовали атомарные обновления, возможность доустановки пакетов и сохранение состояния. В планах — расширение совместимости с разнородным оборудованием и развитие средств централизованного управления парком узлов.
Кто уже использует иммутабельные операционные системы в проде на «голом железе» (не в облаке)? Какие подводные камни встретили? Буду рад обсуждению в комментариях.
