From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.1 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udalov.online; s=mail; t=1738326569; bh=dCETvgOt1piy5sfydVjUPBZo8tKuaAWPTqBHvecJZ8A=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=dy1nlETXw7WhxSOtRdvhFawHlKzv4zrMSLF3uVp0psjHSc89sFBSBmorLCUGBhC4x 1JD38fsjTd68g2+jjCI3ymc/3XkpcE0fxdUlCZvlCrso+VUXdAon+R1oR9ovQd+q2m fueb8OZoT1+4wtaQoI1y5HoMVW0WyotKUarcOBGs= Authentication-Results: mail-nwsmtp-smtp-production-main-54.iva.yp-c.yandex.net; dkim=pass header.i=@udalov.online Message-ID: Date: Fri, 31 Jan 2025 18:29:28 +0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: =?UTF-8?B?0JXQstCz0LXQvdC40Lkg0KHQuNC90LXQu9GM0L3QuNC60L7Qsg==?= , Distributions development References: <14B322BC-80D3-4CD1-AE0B-80241A4ED46B@basealt.ru> Content-Language: en-US, ru-RU From: =?UTF-8?B?0JTQvNC40YLRgNC40Lk=?= In-Reply-To: <14B322BC-80D3-4CD1-AE0B-80241A4ED46B@basealt.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel-distro] =?utf-8?b?0JDRgtC+0LzQsNGA0L3Ri9C5INC+0LHRgNCw0Lc=?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2025 12:29:34 -0000 Archived-At: List-Archive: Если я правильно понял вопрос о мейнтейнерах, то для них, по сути, ничего не меняется, когда система на основе |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, "Дмитрий" > пишет: > > Здравствуйте, хотел бы обсудить реализацию атомарного образа для > домашних систем. Описание текущего состояния проекта: ссылка > Вступление Компания ALT уже активно > внедряет технологии атомарных образов в серверных решениях — ярким > примером служит проект ALT Container OS. Эти образы ориентированы > на массовое развертывание, эффективное администрирование серверов, > минималистичный подход и решение узкоспециализированных задач. Как > разработчик, я организовал рабочую среду на домашнем компьютере с > использованием контейнеров: это позволяет изолировать окружения, > гибко настраивать их и легко переносить конфигурации между > системами. Атомарные образы (их особенности и нюансы опустим для > краткости) стали для меня ключевым инструментом. Сейчас я > рассматриваю переход на ALT Linux, однако столкнулся с вопросом > создания кастомного атомарного образа для домашней системы, > который соответствовал бы моим потребностям для повседневного > использования. Технологии На сегодняшний день флагманом в сфере > атомарных дистрибутивов я считаю решения от Red Hat. Поэтому как и > ALT Container OS, я сосредоточился на технологиях, которые эта > компания активно развивает. Краеугольным камнем для реализации > этой задачи стал *bootc* — инструмент, на котором сейчас > сфокусирована Red Hat. Его ключевая философия заключается в > возможности преобразования /*любого*/ дистрибутива в атомарный > образ при соблюдении определённых технических условий. Подготовка > базового образа За основу берётся OCI-контейнер > > из реестра ALT Linux. Для приведения его к совместимости с *bootc* > выполняется ряд доработок: 1. В образ добавляются все доступные > пакеты из репозитория Sisyphus,    чтобы обеспечить базовую > функциональность. 2. Пакеты, отсутствующие в репозитории, > собираются вручную с учётом    зависимостей и специфики ALT Linux. > 3. Форк проекта |bootupd| и исправление исходного кода для    > совместимости с ALT. 4. Подготавливаю файловую систему, а именно > создаю символьные ссылки,    переношу директории чтобы структура > образа соответствовала    требованиям *bootc*. Полученный и > подготовленный образ является bootc совместимым и может быть > использован как для установки так и для обновлений системы. > Установщик Как оказалось готовых решений совместимых или хотя бы > придерживающихся принципов совместимости с любым дистрибутивом для > установки такого образа не существует, проекты привязаны к > экосистеме других дистрибутивов, в частности bootc-image-builder > который использует Anaconda установщик неразрывно связан с > пакетным менеджером dnf. Было принято решение сделать свой > простенький установщик > > который бы потенциально мог установить любой 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 как указано в этом коммите > > уже давно полностью игнорирует папку /var оставляя ее на совесть > пользователя. Предполагается что идеально совместимая система - > это система которая хранит себя в /usr. Понятное дело что любая > система далека от такой философии поэтому при установку *новых* > пакетов которым требуется папка в /var нужно быть особенно > аккуратными и либо создавать папку на стороне клиента с помощью > tmpfiles.d или придумывать какие-то другие варианты решения > проблемы, я хочу посмотреть как это делают другие дистрибутивы что > бы найти оптимальный путь. > ------------------------------------------------------------------------ > devel-distro mailing list devel-distro@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel-distro >