openSUSE MicroOS: атомарная система для серверов

openSUSE MicroOS — это серверная система, у которой корень смонтирован только для чтения, обновления применяются атомарно через снапшоты btrfs, а приложения живут в контейнерах. Идея не новая, но именно в 2026 году она стала практичной: появились удобные расширения systemd-sysext, установщик научился шифровать диск через TPM2, а экосистема контейнеров закрывает почти все бытовые задачи. Разберём, как MicroOS устроен, как им пользоваться каждый день и в каких случаях он только добавит работы.

Место в семействе openSUSE

У openSUSE три близких, но разных продукта. Tumbleweed — обычный rolling-дистрибутив с изменяемой корневой системой. Leap Micro — стабильная ветка на кодовой базе SUSE Linux Enterprise Micro с фиксированными выпусками, её выбирают там, где важна предсказуемость. MicroOS — rolling-система для контейнерных хостов: та же идея атомарных обновлений, но пакеты обновляются непрерывно. В 2026 году MicroOS остаётся площадкой для Podman, k3s, edge-устройств и небольших серверов, где не хочется заниматься ручным сопровождением.

Как устроена атомарность

Корень смонтирован только для чтения. Каталог /etc входит в снапшот, /var вынесен в отдельный субтом и переживает откат. Обновление выполняется в новом снапшоте btrfs: пакеты ставятся, конфигурация меняется, а текущая система всё это время работает. Если операция завершилась успешно, следующая загрузка идёт с нового снапшота; если нет — остаётся прежний. Откат — это загрузка предыдущего снапшота, а не восстановление из архива.

Практическое следствие: изменения, сделанные в обход transactional-update, либо не сохранятся, либо приведут к ошибке read-only file system. Привычка править файлы в /etc напрямую здесь не работает.

Установка и первый запуск

Для серверов берут self-install ISO или готовый образ для виртуальной машины. В инсталляторе YaST с августа 2025 года поддерживается полнодисковое шифрование с привязкой к TPM2 и измеряемой загрузкой — удобно для машин, которые стоят в необслуживаемом помещении. Первичную настройку облачных и edge-образов делают через combustion: на конфигурационном носителе лежит скрипт, который выполняется при первом старте и создаёт пользователей, сети и ключи.

Требования скромные: от 1 ГБ памяти, от 5 ГБ под корень и от 5 ГБ под /var. На практике под /var стоит отдать десятки гигабайт, если планируются контейнеры и их образы. Под swap лучше выделить отдельный раздел или файл на /var.

Повседневные операции

sudo transactional-update pkg install nginx
sudo systemctl reboot
sudo transactional-update shell
sudo snapper list
sudo transactional-update rollback

Установка пакета не меняет работающую систему: создаётся снапшот, в нём выполняется zypper, а результат применяется после перезагрузки. Команда transactional-update shell открывает оболочку внутри нового снапшота — там можно выполнить несколько действий подряд, а при выходе изменения фиксируются одной транзакцией. Если что-то пошло не так, rollback возвращает предыдущее состояние, а номер снапшота можно указать явно.

Обновления и перезагрузки

systemctl status transactional-update.timer
sudo transactional-update dup
sudo rebootmgrctl get-strategy
sudo rebootmgrctl set-strategy best-effort

По умолчанию обновления ставятся таймером, но перезагрузка не происходит в произвольный момент. Стратегиями управляет rebootmgr: можно разрешить перезагрузку в заданное окно, отложить её или запретить. Для сервера с обслуживанием ночью это удобнее, чем ручной reboot после каждого обновления ядра.

health-checker и автоматический откат

health-checker запускается systemd при загрузке и проверяет, что критичные сервисы поднялись. Плагины лежат в /usr/libexec/health-checker и /usr/local/libexec/health-checker; каждый получает аргумент check и возвращает ноль или единицу. На systemd-boot и grub2-bls работает Automatic Boot Assessment: у нового снапшота три попытки, а успешная проверка помечает загрузку рабочей через systemd-bless-boot.

systemctl status health-checker.service
ls /usr/libexec/health-checker/
systemctl status systemd-bless-boot.service
journalctl -u health-checker --no-pager

Если проверка не прошла, система перезагружается в следующий доступный снапшот, то есть откатывается автоматически. Свои проверки добавляют скриптом в /usr/local/libexec/health-checker: он должен убедиться, что сервис активен и данные на месте.

Контейнеры вместо пакетов

Идеология MicroOS проста: базовый слой остаётся минимальным, приложения живут в контейнерах. Podman работает без демона и по умолчанию rootless, а systemd умеет запускать контейнеры через quadlet-юниты. Это даёт изоляцию и независимые обновления: новый образ можно поднять и погасить старый без перезагрузки хоста.

podman run -d --name web -p 8080:80 nginx:alpine
podman ps
systemctl --user status
podman auto-update --dry-run

Для инструментов, которых нет в базе, удобен toolbox или distrobox — контейнер с привычным пакетным менеджером и обычной оболочкой.

sysext: расширения без перезагрузки

В 2026 году в MicroOS появился удобный менеджер системных расширений sysextmgrcli: он работает с образами systemd-sysext и позволяет добавлять утилиты, не трогая базовый слой. Образы хранятся в /var/lib/sysext-store, а ссылки на них — в /etc/extensions, поэтому при откате снапшота расширения откатываются вместе с системой.

sysextmgrcli list
sudo sysextmgrcli install git
sudo systemd-sysext merge
systemd-sysext status

Для отладки есть готовые образы debug, gcc и git. Это не замена пакетному менеджеру: расширения не содержат зависимостей и не регистрируются в базе RPM, зато позволяют быстро получить strace или gdb и так же быстро убрать их.

Диагностика

sudo btrfs filesystem usage /
df -h /var
sudo journalctl -u transactional-update --since today
sudo transactional-update cleanup

Типичные проблемы: закончилось место на /var из-за старых образов контейнеров; обновление применилось, но перезагрузка не выполнена, и сервис работает по-старому; снапшоты копятся и занимают диск. Чистка старых снапшотов освобождает место, но удалять текущий и предыдущий не стоит — именно они дают возможность отката.

Когда MicroOS не подходит

• Нужны сторонние RPM-пакеты с проприетарными драйверами и сложной установкой.
• Администраторы привыкли править /etc и ставить софт через zypper без перезагрузок.
• Меньше 20 ГБ свободного места суммарно под корень и /var.
• Требуется тонкая настройка ядра под конкретное железо.

Чек-лист

• Понятно, что базовая система обновляется только через transactional-update.
• Настроен rebootmgr и окно обслуживания.
• health-checker проверяет ваши сервисы, а не только базовые.
• Данные и контейнеры лежат на /var или отдельном томе.
• Есть внешняя резервная копия конфигурации.

Итог

MicroOS — это не ещё один серверный дистрибутив, а другой способ эксплуатации: неизменяемая база, атомарные обновления, контейнеры как основной формат приложений и откат одним перезапуском. Он хорошо ложится на однотипные хосты, edge-устройства и фермы контейнеров, где важна воспроизводимость. Цена — дисциплина: все изменения через transactional-update, внимание к /var и привычка проверять, что обновление действительно применилось. Если это приемлемо, MicroOS заметно снижает вероятность ситуации, когда сервер сломался после обновления.