[devel-distro] Атомарный образ

[Дмитрий <dmitry@udalov.online>]

Здравствуйте, хотел бы обсудить реализацию атомарного образа для 
домашних систем.
Описание текущего состояния проекта: ссылка <https://atomic.alt-gnome.ru/>


Вступление
Компания ALT уже активно внедряет технологии атомарных образов в 
серверных решениях — ярким примером служит проект ALT Container OS. Эти 
образы ориентированы на массовое развертывание, эффективное 
администрирование серверов, минималистичный подход и решение 
узкоспециализированных задач.

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

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

Технологии
На сегодняшний день флагманом в сфере атомарных дистрибутивов я считаю 
решения от Red Hat. Поэтому как и ALT Container OS, я сосредоточился на 
технологиях, которые эта компания активно развивает.
Краеугольным камнем для реализации этой задачи стал *bootc* — 
инструмент, на котором сейчас сфокусирована Red Hat. Его ключевая 
философия заключается в возможности преобразования /*любого*/ 
дистрибутива в атомарный образ при соблюдении определённых технических 
условий.

Подготовка базового образа
За основу берётся OCI-контейнер 
<https://registry.altlinux.org/image/sisyphus%2Fbase/tag/latest> из 
реестра ALT Linux. Для приведения его к совместимости с *bootc* 
выполняется ряд доработок:

1. В образ добавляются все доступные пакеты из репозитория Sisyphus,
    чтобы обеспечить базовую функциональность.

2. Пакеты, отсутствующие в репозитории, собираются вручную с учётом
    зависимостей и специфики ALT Linux.

3. Форк проекта |bootupd| и исправление исходного кода для
    совместимости с ALT.

4. Подготавливаю файловую систему, а именно создаю символьные ссылки,
    переношу директории чтобы структура образа соответствовала
    требованиям *bootc*.

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

Установщик
Как оказалось готовых решений совместимых или хотя бы придерживающихся 
принципов совместимости с любым дистрибутивом для установки такого 
образа не существует, проекты привязаны к экосистеме других 
дистрибутивов, в частности bootc-image-builder который использует 
Anaconda установщик неразрывно связан с пакетным менеджером dnf.
Было принято решение сделать свой простенький установщик 
<https://github.com/SkyWar-design/atomic-actions/tree/main/models/installer> 
который бы потенциально мог установить любой bootc совместимый образ но 
в нашем случае полагающийся на готовый образ ALT.

Об изменении системы
Помимо разных вариантов установки программ многим юзерам может 
потребоваться установить пакеты напрямую с помощью встроенного пакетного 
менеджера или его аналогов. В данный момент единственный способ - это 
создание локального Dockerfile который наследует облачный образ и 
применяет в декларативном стиле какие-то команды, по сути любые, 
встроенный помощник системы atomic-actions прячет эту особенность за 
упрощенным вариантом взаимодействия с apt-get, но работает пока в весьма 
упрощенном виде. Теоретически можно попробовать интегрировать 
rpm-ostree, но насколько я знаю он слишком тесно связан с dnf и фокус 
разработки смещен в сторону dnf5 + bootc поэтому проект в будущем будет 
архивным.
Несмотря на кажущуюся абсурдность изменять систему через Dockerfile с 
философской точки зрения это намного удобнее чем спонтанные и хаотичные 
изменения которые привыкли совершать пользователи в системе так как 
любое изменение должно быть отражено и сохранено в файле, к тому же 
Dockerfile является легко переносимым и может быть повторно применен в 
другой аналогичной системе доступной пользователю или на его базе даже 
может быть сформирован образ в облаке.

О хорошем
Проект уже протестирован и работает не только в виртуальной машине но и 
на реальном устройстве, добавлена поддержка nvidia, разработчики из ALT 
Gnome Development поддержали меня и помогают в доработке дистрибутива 
разными маркетинговыми и административными способами.


О плохом
1. Обновления

Размер готового образа на базе gnome со всей пакетной базой сжимается до 
состояния 2.7гб. Это довольно много для того что бы позволить себе часто 
совершать обновления поэтому были предпринятые некоторые шаги для 
улучшения ситуации, а именно базовый образ был сжат до 1 слоя и назван 
например base, затем в облаке выполняется dist-upgrade который наследует 
base образ уже под названием latest итого мы получаем:
- base слой 2,7 гб который редко обновляется
- latest слой который наследует base и содержит в себе результат 
dist-upgrade, знимает от 20 до 150 мегабайт (зависит от обновлений)
Такой подход позволяет получать микро обновления без необходимости 
тянуть весь образ, но есть некоторые сомнения в правильности этого 
подхода, возможно dist-upgrade может изменить модули которые связаны с 
определенной версией ядра, но ядро у нас хранится в base слое и случится 
конфликт, если это произойдет то будет разумным перенести формирование 
ядра и других ключевых вещей в latest слой вместо base. Тут вопрос 
скорее к знатокам, мне не хватает знаний что бы предугадать такого рода 
проблемы, а протестировать такой вариант не представляется возможным.

2. Совместимость пакетов

Что касается обновлений, ostree как указано в этом коммите 
<https://github.com/ostreedev/ostree/pull/3166/commits/f81b9fa1666c62a024d5ca0bbe876321f72529c7> 
уже давно полностью игнорирует папку /var оставляя ее на совесть 
пользователя. Предполагается что идеально совместимая система - это 
система которая хранит себя в /usr.
Понятное дело что любая система далека от такой философии поэтому при 
установку *новых* пакетов которым требуется папка в /var нужно быть 
особенно аккуратными и либо создавать папку на стороне клиента с помощью 
tmpfiles.d или придумывать какие-то другие варианты решения проблемы, я 
хочу посмотреть как это делают другие дистрибутивы что бы найти 
оптимальный путь.