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=1738330168; bh=H+wiLUdZGQ54xZ0Y9RVKRuBqIDtR4eZIeDgli96WmyA=; h=In-Reply-To:Reply-To:Date:References:To:From:Subject:Message-ID; b=ExdJxJpfo5HKyouQJbwzJwG0slh3EPTAeuw0x1AZkR+kqJu+LfiUG5oxNKA2JoXaT sfeYhzV+IOWYeWlGdWDv2onJOMJW9qumuGCf3jziF6nxFlSCisOEZhGQybJDMkRCdk axIK+0/5eh98qxcGmqecSd5PrZ/FKCvIB9cwqgjE= Authentication-Results: mail-nwsmtp-smtp-production-main-10.sas.yp-c.yandex.net; dkim=pass header.i=@udalov.online Message-ID: <956286cc-0e9c-4cb2-8f06-e9b600a20c4f@udalov.online> Date: Fri, 31 Jan 2025 19:29:26 +0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: =?UTF-8?B?0JTQvNC40YLRgNC40Lk=?= To: =?UTF-8?B?0JXQstCz0LXQvdC40Lkg0KHQuNC90LXQu9GM0L3QuNC60L7Qsg==?= , Distributions development References: <14B322BC-80D3-4CD1-AE0B-80241A4ED46B@basealt.ru> Content-Language: en-US, ru-RU In-Reply-To: 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 13:29:32 -0000 Archived-At: List-Archive: В данный момент я считаю что самое важное влияние которое оказывают мейнтейнеры и пакетная база в репозитории на такой образ - это следование следующим декларативам: 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, "Дмитрий" >> пишет: >> >>     Здравствуйте, хотел бы обсудить реализацию атомарного образа для >>     домашних систем. Описание текущего состояния проекта: ссылка >>     Вступление Компания 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 >> > _______________________________________________ > devel-distro mailing list > devel-distro@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel-distro