Было бы здорово организовать сборку docker образов. - все необходимое для сборки размещать в git.altlinux.org/people/$USER/containers/foo - собирать образ на основе Dockerfile. Хотя бы для архитектур x86_64 и aarch64. существующие утилиты для сборки образов: - BuildKit https://github.com/moby/buildkit - buildah https://github.com/containers/buildah - Docker - Выгружать полученный образ на какой-либо реестр образов(hub.docker.com, quay.io). Предлагаю организовать свой сервер реестра образов.
Для того, чтобы сборочница могла собирать docker-образы на основе Dockerfile, необходимо, чтобы используемый для сборки инструмент мог работать внутри hasher'а и, как следствие, быть непривилегированным и не требовать unprivileged userns. Поскольку ни один из существующих инструментов не обладает таким свойством, придётся либо разработать такой инструмент, либо разработать другую сборочницу, которая не будет основана на безопасной воспроизводимой сборке с помощью hasher.
Или, как вариант, можно использовать vm-run, если научиться забирать из него результаты сборки.
(In reply to Anton Farygin from comment #2) > Или, как вариант, можно использовать vm-run, если научиться забирать из него > результаты сборки. И заранее ограничить множество поддерживаемых архитектур теми, где работает vm-run.
да, конечно. Но это, возможно, будет проще чем переписывать hasher или инструменты сборки образов. А можно каким-то образом репозиторий с пакетами сделать доступным внутри hasher ?
(In reply to Anton Farygin from comment #4) > А можно каким-то образом репозиторий с пакетами сделать доступным внутри > hasher ? Во время обычной сборки пакетов вряд ли, а вообще да, поскольку hasher поддерживает монтирование.
если во время сборки docker образов получится смонтировать внутрь hasher используемый репозиторий, то задача выглядит решаемой через vm-run. Понятно, что количество платформ будет ограничено наличием /dev/kvm, но я подозреваю что те платформы, на которых /dev/kvm нету, не очень нужно поддерживать в docker образах.
(Ответ для Dmitry V. Levin на комментарий #3) > (In reply to Anton Farygin from comment #2) > > Или, как вариант, можно использовать vm-run, если научиться забирать из него > > результаты сборки. > > И заранее ограничить множество поддерживаемых архитектур теми, где работает > vm-run. Что мы теряем? e2k до выхода e2kv6 riscv64 пока, хотя движение есть mipsel мертв Что ещё?
Эти "теряемые" архитектуры отстутствуют на сборочнице, поэтому мы их не теряем до тех пор, пока они не будут интегрированы в основной girar.
(In reply to AEN from comment #7) > (Ответ для Dmitry V. Levin на комментарий #3) > > (In reply to Anton Farygin from comment #2) > > > Или, как вариант, можно использовать vm-run, если научиться забирать из него > > > результаты сборки. > > > > И заранее ограничить множество поддерживаемых архитектур теми, где работает > > vm-run. > > Что мы теряем? > e2k до выхода e2kv6 > riscv64 пока, хотя движение есть > mipsel мертв > > Что ещё? armv7, но, видимо, 32-битные архитектуры не интересны.
(Ответ для Dmitry V. Levin на комментарий #9) > (In reply to AEN from comment #7) > > (Ответ для Dmitry V. Levin на комментарий #3) > > > (In reply to Anton Farygin from comment #2) > > > > Или, как вариант, можно использовать vm-run, если научиться забирать из него > > > > результаты сборки. > > > > > > И заранее ограничить множество поддерживаемых архитектур теми, где работает > > > vm-run. > > > > Что мы теряем? > > e2k до выхода e2kv6 > > riscv64 пока, хотя движение есть > > mipsel мертв > > > > Что ещё? > > armv7, но, видимо, 32-битные архитектуры не интересны. Насколько я понимаю, зависит от железки. То есть решается вне общей процедуры.
Дима, Глеб, делаем? Ключевой элемент плана 2022.
