Неизменяемые дистрибутивы Linux на сервере: обзор

Что такое неизменяемый дистрибутив Linux

Неизменяемый дистрибутив Linux поставляет операционную систему в виде единого образа, поэтому вы заменяете систему целиком вместо внесения изменений «на лету». В работающей системе нет перезаписи файлов в apt upgrade под /usr. Вы собираете или загружаете новый образ, машина подготавливает его параллельно с текущим, а при следующей перезагрузке происходит переключение на новый образ. Предыдущий образ остаётся на диске, поэтому откат неудачного обновления выполняется простой перезагрузкой.

Термин «неизменяемый» (immutable) несколько преувеличен. Ничто физически не мешает пользователю root записывать данные на диск. Эти системы монтируют системные директории в режиме «только для чтения» и передают право владения ими образу. Постоянные данные хранятся в /var. Конфигурация, специфичная для конкретной машины, находится в /etc. Всё, что находится в /usr, принадлежит образу, поэтому два сервера, использующие один и тот же тег образа, содержат идентичные системные файлы.

Наиболее понятные названия для этих двух моделей предлагает Red Hat: package mode (пакетный режим) и image mode (режим образа). Package mode — это работающая система плюс менеджер пакетов, который вносит в неё изменения. Image mode — это этап сборки, выполняемый в другом месте, в результате которого создаётся артефакт, а единственная задача сервера — загрузить тот артефакт, на который вы его направили. Всё, что описано ниже, вытекает из этого единственного различия.

Почему система только для чтения важнее на сервере

Сервер, проработавший два года, обладает историей, которую никто не фиксировал. make install, сделанный в спешке вечером. Сторонний репозиторий, добавленный ради одного пакета. Файл конфигурации, измененный во время аварии и не возвращенный в систему управления конфигурациями. Это называется «дрейфом конфигурации» (configuration drift), и именно поэтому пересборка «того же самого» сервера по заметкам так часто приводит к появлению системы, которая ведет себя иначе. Заметки содержат намерения. Диск содержит истину.

Режим образа устраняет место, где скапливается дрейф. /usr доступна только для чтения во время выполнения, поэтому ручная установка либо сразу завершается ошибкой, либо записывается как слой, который можно вывести одной командой. Это делает различия между двумя машинами видимыми, а не археологическими. Это та же проблема, которую стандартный чек-лист обслуживания Linux-сервера решает с помощью дисциплины, но здесь она решается на уровне файловой системы.

Откат — это перезагрузка, и в этом вся суть

Сбой, для которого создана эта модель, — это тот, который мы уже описывали: VPS, который не загружается после обновления ядра. В пакетном режиме вы восстанавливаетесь через консоль спасения (rescue console) провайдера. Вы монтируете диск, выполняете chroot и вручную удаляете пакет ядра. Это работает, потому что загрузчик сохраняет старые ядра, но версионируется только ядро. Обновление glibc и изменения в systemd, пришедшие в той же транзакции, уже применены, и нет единой команды, которая могла бы откатить их все вместе.

В режиме образа единицей является вся система. На хосте bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback меняет порядок в загрузчике обратно на предыдущую запись — это тот образ, который вы использовали час назад, включая ядро и пространство пользователя. Ничего не скачивается и не пересобирается, так как старый образ не покидал диск.

Fedora CoreOS делает то же самое под другими названиями:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r

Сначала остановите Zincati. Zincati — это агент, который поддерживает Fedora CoreOS в актуальном состоянии, поэтому, если оставить его запущенным, он подготовит обновление, от которого вы только что отказались. -r перезагружает систему после подготовки отката. Чтобы развертывание, которому вы доверяете, не было удалено сборщиком мусора:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status выводит список развертываний в порядке, в котором их предложит загрузчик, отмечает текущее работающее точкой и показывает Pinned: yes для того, которое вы закрепили.

Talos выполняет это одним вызовом API с вашей рабочей станции:

talosctl rollback --nodes 10.20.30.40

Flatcar хранит два раздела /usr и переключается между ними. Каждый слот имеет приоритет и счетчик попыток в таблице разделов, поэтому слот, который не загружается успешно, исчерпывает попытки, и загрузчик выбирает другой. Проверьте, в каком слоте вы находитесь и был ли он помечен как исправный:

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

Исправный работающий слот выводит строку, содержащую priority=1 tries=0 successful=1. Отсутствие такой строки означает, что текущий слот не был подтвержден — это состояние, в котором машина находится между обновлением и первой успешной загрузкой.

Чем заменить «установку пакетов»: bootc и Containerfile

bootc — это инструмент, который обобщает данный подход. Он позиционируется как средство для транзакционных обновлений операционной системы «на месте» с использованием образов OCI (Open Container Initiative) и является проектом CNCF Sandbox. Ваш сервер превращается в Containerfile. По состоянию на август 2026 года базовым образом Fedora является quay.io/fedora/fedora-bootc:44, а базовым образом CentOS Stream — quay.io/centos-bootc/centos-bootc:stream10.

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

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

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

Затем на сервере:

sudo bootc upgrade --check
sudo bootc upgrade --apply

bootc upgrade опрашивает источник образа и ставит новый образ в очередь на следующую загрузку. --check проверяет наличие обновлений, не внося никаких изменений. --apply выполняет перезагрузку в новый образ. bootc switch registry.example.com/edge/web:next переключает машину на другой образ, сохраняя при этом /etc и /var; именно так можно перевести сервер между потоками образов без его переустановки.

Для автоматических обновлений включите таймер, поставляемый в составе проекта:

sudo systemctl enable --now bootc-fetch-apply-updates.timer

Это ответ image-mode на автоматические обновления в Ubuntu и на dnf-automatic в Rocky и Alma. Разница заключается в том, что именно попадает в систему. Таймер в пакетном режиме применяет любые версии, которые оказались в репозитории на текущую ночь, поэтому итоговый набор пакетов на каждой машине будет немного отличаться. Таймер в режиме образа применяет один конкретный артефакт, который вы уже протестировали при загрузке в другом месте.

Из этого Containerfile вытекают два правила сборки. Данные для записи должны находиться в /var, поэтому для программного обеспечения, которое требует записи в собственный каталог установки, необходимо создать символическую ссылку или добавить параметр BindPaths= в systemd на этапе сборки. А /etc при обновлении объединяется методом трехстороннего слияния: это означает, что файл, который вы не изменяли, получит новую версию из образа, а файл, который вы редактировали локально, будет сохранен.

Если вам нужен инструмент на работающей системе для разовой сессии отладки:

sudo bootc usr-overlay
sudo dnf -y install strace

Это добавляет временный оверлей для записи поверх /usr, который удаляется при следующей перезагрузке. Это нужно для анализа проблемы, а не для её исправления. Таким способом нельзя изменить ядро, и всё, что вы установите, по замыслу исчезнет после перезагрузки.

Fedora CoreOS: подготовка один раз, обновления навсегда

В Fedora CoreOS нет интерактивного установщика. Вы создаете YAML-файл для Butane, транслируете его в JSON-файл Ignition и передаете его машине при первой загрузке:

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

Ignition выполняется в initramfs только при первой загрузке. Это ключевой момент для тех, кто переходит с cloud-init. Если в конфигурации не указан SSH-ключ, машина загрузится без возможности доступа, и исправить это можно будет только повторной установкой с нуля. Протестируйте конфигурацию на тестовой машине, прежде чем применять её к важному серверу.

Установка на диск из live-окружения:

sudo coreos-installer install /dev/sda \
    --ignition-url https://example.com/example.ign

Обновления по умолчанию автоматические. Вы управляете временем, но не самим фактом их наличия. Создайте TOML-файл в /etc/zincati/config.d/55-updates-strategy.toml, чтобы выбрать периодическую стратегию:

[updates]
strategy = "periodic"

В рамках этой стратегии вы добавляете по одному окну обслуживания на каждую запись в массиве таблиц. Каждое окно начинается с имени updates.periodic.window в двойных квадратных скобках в качестве заголовка, за которым следуют три ключа:

• days, список дней недели, например "Sat" и "Sun".
• start_time, время начала окна, записанное как "22:30".
• length_minutes, длительность окна, например 60.

Это время указано в UTC. Чтобы полностью остановить обновления, выполните sudo systemctl disable --now zincati.service и примите на себя ответственность за график установки патчей.

Для экстренных случаев предусмотрено наслоение пакетов (package layering):

sudo rpm-ostree install --allow-inactive vim
sudo systemctl reboot

Эта команда создает новое развертывание с добавленным пакетом, изменения вступают в силу только после перезагрузки. Последствия проявятся позже. Ваш набор слоев применяется поверх каждого нового базового образа, поэтому пакет, исчезнувший из репозитория в день обновления, приведет к сбою этого обновления. Официальная документация Fedora рекомендует использовать контейнеры для любых значимых задач, а для случаев, когда действительно необходимо изменить ОС — образы bootc.

Flatcar Container Linux: отсутствие пакетного менеджера

Flatcar — это продолжение CoreOS Container Linux и наиболее строгий вариант среди дистрибутивов общего назначения. В системе нет пакетного менеджера, на который можно было бы положиться. Всё, что вы запускаете, работает в контейнерах. Для подготовки системы используется Ignition, как и в Fedora CoreOS. Обновления выполняются через два раздела A/B /usr, описанных выше, под управлением update_engine, при этом locksmithd определяет время перезагрузки.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT означает, что пассивный раздел уже содержит новый образ и требуется только перезагрузка. Стратегия перезагрузки по умолчанию — reboot с пятиминутной задержкой, поэтому отдельный VPS в продакшене перезагрузится по собственному расписанию, если вы не укажете иное. Настройте окно обслуживания в /etc/flatcar/update.conf:

REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

REBOOT_STRATEGY=off оставляет решение о перезагрузке за вами. SERVER=disabled в том же файле полностью отключает проверку обновлений. Для кластера REBOOT_STRATEGY=etcd-lock в сочетании с locksmithctl set-max 4 ограничивает количество узлов, которые могут перезагружаться одновременно, чтобы обновление не вывело из строя весь парк серверов целиком.

Talos Linux: отсутствие shell, SSH и консоли

Talos — самая узкоспециализированная из четырех систем, ее назначение предельно ясно. Она предназначена для работы узлов Kubernetes. В ней отсутствуют SSH-демон, shell и возможность входа через консоль. Любая операция выполняется через gRPC API с помощью talosctl с вашей рабочей станции на основе конфигурации машины, которая хранится в git.

talosctl upgrade --nodes 10.20.30.40 \
  --image ghcr.io/siderolabs/installer:v1.10.6

Замените тег на версию, на которую вы переходите. Обновление использует схему A-B, сохраняющую предыдущее ядро и образ ОС, поэтому в случае сбоя загрузки новой версии Talos автоматически выполнит откат без вмешательства администратора. Отладка выглядит иначе из-за отсутствия shell: вместо journalctl на самом узле используются talosctl logs и talosctl dmesg.

Если ваша рабочая нагрузка не связана с Kubernetes, Talos вам не подходит. Если же связана, Talos устраняет целый класс инцидентов, так как ситуация, когда «кто-то зашел на узел и что-то изменил», становится невозможной.

От чего на самом деле отказывается арендатор VPS

Установка пакетов «на лету» в работающей системе. Это самый важный момент. sudo apt install htop в 2 часа ночи во время инцидента недоступен. В bootc вы получаете временный оверлей, который исчезает после перезагрузки. В Fedora CoreOS вы получаете послойное развертывание, требующее перезагрузки. В Flatcar и Talos вы не получаете ничего.

Конвейер сборки, которого у вас раньше не было. Добавление пакета означает редактирование Containerfile, сборку образа, отправку его в реестр и обновление серверов. Это дешево, если конвейер уже существует. Но это реальная работа, если его нужно создавать с нуля. Кроме того, требуется реестр, доступный серверам, а это еще один сервис для обслуживания или еще один счет к оплате.

Модули ядра. Ядро поставляется в составе образа, поэтому модуль, скомпилированный для текущего ядра, не сохранится после следующего обновления. Сторонние модули и пакеты DKMS (dynamic kernel module support) должны быть встроены в образ и скомпилированы для ядра этого образа. Любой компонент, требующий модуль, отсутствующий в базовом образе, превращается из проблемы установки в проблему сборки.

Агенты вендоров и провайдеров. Агенты мониторинга и резервного копирования обычно поставляются как .deb или .rpm со скриптом установки, который записывает данные в /usr и активирует юнит. В системе с файловой системой только для чтения этот скрипт завершится ошибкой. Некоторые вендоры публикуют контейнер или описывают процедуру установки в режиме образа. Многие этого не делают. Проверьте это до того, как принять решение, потому что парк серверов, который вы не можете отслеживать, хуже, чем парк с конфигурационным дрейфом.

Сам образ. Почти ни одна панель управления VPS не предлагает Fedora CoreOS, Flatcar или Talos наряду с Ubuntu и Debian. Вы предоставляете диск самостоятельно, о чем пойдет речь в следующем разделе.

Развертывание системы на арендованном VPS

Сначала убедитесь в двух вещах: у вас есть внеполосный (out-of-band) доступ к консоли (VNC или последовательный порт) и возможность загрузки в rescue-систему. Без консоли сервер, который не загрузился, превращается в тикет в техподдержку вместо пятиминутного исправления.

Если провайдер поддерживает пользовательские образы, загрузите raw или qcow2 образ от поставщика, и задача будет решена. В противном случае запишите образ на диск самостоятельно из rescue-системы. Flatcar поставляет готовый скрипт для этой цели, который работает из любого дистрибутива Linux:

curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.json

Запускайте этот скрипт только из rescue-системы, а не из той ОС, которую вы заменяете, так как скрипт переразмечает целевой диск в процессе работы. Требуется не менее 8 GB свободного места на устройстве, а rescue-окружение должно содержать bash, bzip2 или lbzip2, lsblk, wget, udevadm, gpg и gawk. Ваш ignition.json должен содержать SSH-ключ, иначе в установленную систему невозможно будет войти.

Fedora CoreOS имеет аналогичный принцип работы, а её установщик запускается в виде контейнера:

sudo podman run --pull=always --privileged --rm \
    -v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release \
    install /dev/vdb -i config.ign

Перед запуском проверьте имя устройства с помощью lsblk. Запись на неверное устройство уничтожит все данные на нем, и система не запросит подтверждение.

bootc предлагает единственный путь, позволяющий обойтись без rescue-режима, так как он преобразует работающую систему Linux на месте:

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
             --pid=host --security-opt label=type:unconfined_t \
             quay.io/fedora/fedora-bootc:44 \
             bootc install to-existing-root

Перед запуском ознакомьтесь с документацией к используемому базовому образу и протестируйте процесс на сервере, который не жалко удалить. После перезагрузки машина будет работать на базе образа, а прежний набор пакетов будет удален.

Кому стоит использовать неизменяемые серверы, а кому нет

Этот подход подходит вам, если вы относитесь к серверам как к «скоту». Множество машин, созданных по одному шаблону. CI-раннеры (continuous integration), которые живут один час. Узлы k3s или Kubernetes, которые проще заменить, чем чинить. Любые сценарии, где на поломку сервера есть готовый ответ: «удалить и создать новый». Это также полезно, когда нужно доказать аудитору, что именно запущено на машине, так как ответом будет хеш образа, а не список установленных пакетов.

Этот подход не подходит, если у вас один VPS, который вы обслуживаете вручную, на нем запущены три сервиса, вы устанавливаете ПО по мере необходимости и у вас нет конвейера сборки. Режим работы с образами не избавляет от работы. Он переносит её с сервера на этап сборки и требует наличия реестра и конвейера. Если у вас есть инфраструктура для такой работы, вы получаете идентичные серверы и возможность отката через перезагрузку. Если её нет, вы добавляете лишние сложности в систему, которая работала нормально, и усложняете себе жизнь при возникновении проблем в 2 часа ночи.

Скучный средний вариант всё ещё работает: обычный дистрибутив с автоматическими обновлениями безопасности плюс процедура пересборки, которую вы реально тестировали. Выбор базовой системы — это отдельное решение, описанное в выборе ОС для вашего VPS. Режим работы с образами — это лишь новый виток очень старого спора о том, как программное обеспечение должно попадать на машину, и история дистрибутивов Linux по большей части состоит из повторения этого спора.

FAQ

Является ли неизменяемый (immutable) дистрибутив Linux действительно неизменяемым?

Нет, и само название вводит в заблуждение. Пользователь root по-прежнему может записывать данные на диск. На самом деле происходит следующее: /usr монтируется в режиме только для чтения во время выполнения и полностью заменяется при обновлении образа, в то время как /etc и /var остаются доступными для записи и сохраняются после обновлений. Изменения, которые вы вносите в /usr, либо отклоняются в момент попытки записи, либо отбрасываются при следующем обновлении, поэтому на практике системные директории меняются только при смене самого образа.

Могу ли я запустить Fedora CoreOS или Flatcar на VPS, где они не предлагаются?

Обычно да, если провайдер предоставляет систему восстановления (rescue system) и доступ к консоли. Вы загружаетесь в режиме восстановления, записываете образ диска дистрибутива на блочное устройство и перезагружаетесь. Скрипт flatcar-install от Flatcar позволяет сделать это из любого Linux, а Fedora CoreOS поставляет coreos-installer в виде контейнера, который можно запустить аналогичным образом. Оба варианта требуют наличия файла Ignition с вашим SSH-ключом, так как в них отсутствует запрос пароля при первой загрузке. Без доступа к консоли не пытайтесь это делать: если машина не загрузится, у вас не будет возможности выяснить причину.

Как установить пакет на неизменяемый сервер?

Вы добавляете его в образ и разворачиваете заново. В bootc это строка RUN dnf -y install ... в Containerfile, пересборка, отправка в реестр и выполнение sudo bootc upgrade --apply на целевой машине. В Fedora CoreOS вы можете добавить пакет через sudo rpm-ostree install и перезагрузиться, но при этом пакет будет переустанавливаться при каждом последующем обновлении. В Flatcar и Talos нет пакетного менеджера, поэтому решение — использовать контейнер. Для разовых задач отладки на хосте bootc команда sudo bootc usr-overlay предоставляет временную область /usr, доступную для записи, которая исчезает после следующей перезагрузки.

Исправляет ли образ системы VPS, который не загружается после обновления ядра?

Это превращает процесс восстановления из работы с консолью в обычную перезагрузку. Предыдущий образ, включающий ядро и пользовательское пространство, остается на диске, поэтому sudo bootc rollback или sudo rpm-ostree rollback -r позволят вам вернуться к нему. Talos и Flatcar идут дальше и выполняют откат автоматически, если новая версия не загружается, так как запись в загрузчике становится основной только после одной успешной загрузки. Это не предотвращает неудачные обновления, но делает их отмену дешевой и быстрой.

Какой неизменяемый дистрибутив выбрать для сервера?

Выбирайте bootc, если вам нужен Linux-сервер общего назначения, который вы собираете как образ контейнера и можете установить на имеющееся оборудование. Выбирайте Fedora CoreOS, если вам нужна та же модель, но с готовой сборкой и автоматическими обновлениями «из коробки». Выбирайте Flatcar, если вам нужен минималистичный хост для контейнеров с A/B-схемой обновлений и без пакетного менеджера, чтобы избежать соблазна вносить изменения вручную. Выбирайте Talos только в том случае, если машина будет узлом Kubernetes, так как в нем нет оболочки (shell) и он не предназначен для запуска чего-либо другого.