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

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

Если я правильно понял вопрос о мейнтейнерах, то для них, по сути, 
ничего не меняется, когда система на основе |bootc| находится в режиме 
контейнера с системой можно работать как угодно, используя любые 
пакетные менеджеры, будь то |apt-get|, |epm| или другие.

В частности, используется пакетная база Sisyphus со всеми её 
особенностями. Когда система запускается на хостовой машине, появляются 
некоторые нюансы в работе с ней, но в процессе внесения изменений мы 
снова оказываемся в контейнерной среде, где можем применять любые 
встроенные механизмы установки пакетов локально.

Однако, под "чистым" использованием системы следует понимать минимизацию 
установки пакетов непосредственно в саму систему. Вместо этого 
рекомендуется опираться на контейнерные установщики, такие как 
|flatpak|, |brew|, |distrobox| и подобные. Это скорее рекомендация, чем 
строгая необходимость, но такой подход помогает сохранить систему более 
предсказуемой и управляемой.

Так же благодаря особенностям сборки, мы можем гибко настраивать образ: 
добавлять аргументы в загрузку ядра (nvidia), изменять любые 
конфигурации в /etc (не затронутые пользователем) и многое другое. Это 
позволяет создавать готовые образы, адаптированные под различные цели и 
устройства.

По сути главное что меняется -  это доставка пакетов: вместо 
традиционного подхода используется OCI-контейнер с его слоями и 
особенностями. Кроме того, мы получаем дополнительные преимущества, 
такие как хранение всех изменений в виде |ostree| коммитов с 
возможностью "путешествовать" по ним на этапе загрузки через |GRUB|. 
Либо путешествовать на разные состояния образа в облаке, так как в в OCI 
лежит образ целиком или даже в перспективе перемещаться между любыми 
bootc-совместимыми образами на основе ALT (/var куда переместился home и 
другие папки не затрагиваются)

Делюсь ссылками:

1. Концептуальная составляющей такого рода системы
https://0pointer.net/blog/fitting-everything-together.html

2. Об используемых технологиях и перспективах
https://containers.github.io/bootable/

3. В частности документация bootc
https://containers.github.io/bootc/

4. Так же у Red Hat полно документации разной
https://developers.redhat.com/articles/2024/09/24/bootc-getting-started-bootable-containers#

31.01.2025 17:10, Евгений Синельников пишет:
> Дмитрий,
>
> спасибо за подробное описание, внятное изложение и полезные ссылки.
>
> Думаю, эту историю нужно "переварить". Хотелось бы понять и осмыслить 
> куда мы движемся и общий прогресс вместе с нами куда движется.
>
> В каком смысле оказывается, в этом случае, существенной роль 
> сопровождающего пакетной базы - то есть, мэйнтейнера?
>
> Как не разорваться между этими мирами - пакетным и контейнерным?
>
> По уму, кроме таких артефактов, как gear-репозитрии, rpm-пакеты, 
> apt-репозитории и iso-образы, уже имеются docker/podman, flatpak (и 
> др.) образы...
>
> А тут мы получаем еще образы, и тоже через генерацию докерных чрутов, 
> при этом rpm-базу зачем-то им выпиливаем...
>
> https://github.com/alt-gnome/alt-atomic
>
> Хотя, в целом, понятно зачем -  используем генерацию docker-образов 
> вместо оригинальной.
>
> В общем, спасибо, интересная тема. Но концептуальные детали нужно 
> вычитывать. Видимо, из первоисточников. Какие посоветуете?
>
> PS: схема доверенной сборки контейнеров на сборочнице у нас, кстати, 
> прорабатывалась. Как для iso-образов, так и для docker-контейнеров. 
> Нужны добровольцы для развития и отладки этой истории. Особенно, и в 
> первую очередь, в рамках сообщества.
>
>
>
> 31 января 2025 г. 14:30:37 GMT+04:00, "Дмитрий" <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 или придумывать какие-то другие варианты решения
>     проблемы, я хочу посмотреть как это делают другие дистрибутивы что
>     бы найти оптимальный путь.
>     ------------------------------------------------------------------------
>     devel-distro mailing list devel-distro@lists.altlinux.org
>     https://lists.altlinux.org/mailman/listinfo/devel-distro
>