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

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

В данный момент я считаю что самое важное влияние которое оказывают 
мейнтейнеры и пакетная база в репозитории на такой образ - это 
следование следующим декларативам:

https://www.freedesktop.org/software/systemd/man/latest/systemd-sysusers.html

https://www.freedesktop.org/software/systemd/man/latest/systemd-tmpfiles-setup.service.html

А ALT в данный момент очень мало пакетов собраны с учетом этих правил. 
Вероятно мне придется проверять каждый пакет которые будет добавлен в 
систему после ее установки и описывать эти правила вручную. Но если все 
пакеты будут собраны с использованием этих правил - переключением между 
образами и обновление будут тривиальной задачей, необходимые юзеры и 
папки буду созданы автоматически и для самовоспроизведения и корректной 
работы единственным важным обновлением будут папки /usr и /etc

31.01.2025 18:29, Дмитрий пишет:
> Если я правильно понял вопрос о мейнтейнерах, то для них, по сути, 
> ничего не меняется, когда система на основе |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
>>
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro