Moby: только время сборки -v опция

Ищу похожее решение.

Проблема

Недавно предприятие, на котором я работаю, включило прокси-сервер Zscaler с проверкой SSL, что подразумевает установку сертификатов и установку некоторых переменных среды во время сборки.

Временным решением было создать новый файл Dockerfile с установленными сертификатами и переменными среды. Но это не кажется разумным в долгосрочной перспективе.

Итак, моей первой мыслью было установить прозрачный прокси с HTTP и HTTPS, но опять же мне нужно передать сертификат во время сборки.

Идеальный сценарий — с одним и тем же файлом Dockerfile я мог бы создать свой образ на своем ноутбуке, дома и на предприятии.

Возможное решение

# Enterprise
$ docker build -v /etc/ssl:/etc/ssl -t myimage .

# Home
$ docker build -t myimage .

У меня немного другой вариант использования этой функции — кэширование пакетов, которые загружаются/обновляются менеджером пакетов ASP.Net 5 . Менеджер пакетов управляет своей собственной папкой кеша, поэтому в конечном итоге мне просто нужна папка, которую я могу повторно использовать между сборками.

То есть:

docker build -v /home/dokku/cache/dnx/packages:/opt/dnx/packages -t "dokku/aspnettest" .

@yngndrw то, что вы предлагаете, подойдет и мне, т. Е. Нам нужно монтировать дополнительные ресурсы во время сборки, которые не нужны во время выполнения, поскольку они были установлены в контейнере.

FWIW я видел где-то на этих страницах, что кто-то говорил что-то вроде (и я надеюсь, что перефразирую это правильно) «решите проблему компиляции на аналогичном хост-компьютере, а затем просто установите развертываемый артефакт или exe в контейнер».
Боюсь, это не так просто, ребята. Иногда мне нужно установить в /usr/bin, но мне также нужно отредактировать какой-то файл конфигурации. Я проверяю ОС, на которой я работаю, параметры ядра, которые мне нужно настроить, файлы, которые мне нужно создать, в зависимости от переменных или файлов сборки манифеста. Есть много зависимостей, которых просто не устраивает простая копия скомпилированного продукта.

Я повторяю то, что сказал, когда открывал вопрос: есть разница между файлом объявления манифеста и его процессом и временем выполнения артефакта.
Если мы действительно верим в инфраструктуру как код и, более того, в неизменяемую инфраструктуру, в то, что сам Docker продвигается дальше, и мне это нравится, кстати, то это нужно серьезно рассмотреть, ИМО (см. раздувание в посте 1).

Еще раз спасибо

Другой вариант использования, который действительно интересен, — это обновление программного обеспечения. В некоторых случаях, как в случае с FreeIPA, вам действительно следует протестировать копию производственных данных, чтобы убедиться, что все различные компоненты могут быть обновлены без ошибок. Вы по-прежнему хотите выполнить обновление в среде "сборки". Вы хотите, чтобы производственная копия данных находилась где-то еще, чтобы при перемещении новых обновленных версий контейнеров в рабочую среду они могли собрать точные данные, для которых вы выполнили обновление.

Другим примером может служить Satellite/Spacewalk, который часто меняет схему и даже изменяет базы данных с Oracle на Postgresql в версии 5.6 (IIRC).

Есть много, много сценариев, когда мне временно нужен доступ к данным при обновлении программного обеспечения в контейнерной сборке, особенно с распределенными/микросервисами....

По сути, теперь я вынужден выполнить обновление вручную, запустив обычный контейнер с монтированием привязки -v, а затем выполнив «фиксацию докера». Я не могу понять, почему такая же возможность недоступна при автоматической сборке Dockerfile?

Поддерживая @yngndrw , указывающего на кеширование: точно такие же рассуждения применимы ко многим популярным проектам, таким как Maven, npm, apt, rpm — использование общего кеша может значительно ускорить сборку, но не должно попадать в окончательный образ.

Я согласен с @stevenschlansker. Это может быть много требований к объему прикрепленного кеша или какие-то несколько гигабайт данных, которые должны быть представлены (в проанализированном состоянии) на финальном изображении, а не в виде необработанных данных.

Меня также укусило постоянное сопротивление расширению docker build для поддержки томов, которые могут использоваться docker run . Я не нашел мантру «независимых от хоста сборок» очень убедительной, так как кажется, что разработка и повторение образов Docker только усложняются и отнимают много времени, когда вам нужно повторно загружать весь репозиторий пакетов каждый раз, когда вы перестраиваете. изображение.

Моим первоначальным вариантом использования было желание кэшировать репозитории пакетов ОС, чтобы ускорить итерацию разработки. Обходной путь, который я использовал с некоторым успехом, похож на подход, предложенный @fatherlinux , который заключается в том, чтобы просто отказаться от борьбы с docker build и Dockerfile целом и начать с нуля, используя docker run в стандартном сценарии оболочки, за которым следует docker commit .

В качестве небольшого эксперимента я расширил свою технику до полноценной замены docker build , используя немного сценариев оболочки POSIX: dockerize .

Если кто-то хочет протестировать этот сценарий или общий подход, дайте мне знать, если он интересен или полезен (или работает ли он вообще для вас). Чтобы использовать, поместите скрипт где-нибудь в PATH и добавьте его как шебанг для вашего скрипта сборки (вещь #! ), затем установите соответствующие переменные среды перед второй строкой шебанга, отмечающей начало вашего скрипта установки Docker.

Переменные FROM , RUNDIR и VOLUME будут автоматически переданы в качестве аргументов в docker run .
Переменные TAG , EXPOSE и WORKDIR будут автоматически переданы в качестве аргументов в docker commit .

Все остальные переменные будут оцениваться в оболочке и передаваться в качестве аргументов среды в docker run , делая их доступными в вашем скрипте сборки.

Например, этот сценарий будет кэшировать и повторно использовать пакеты Alpine Linux между сборками (VOLUME монтирует домашний каталог в CACHE, который затем используется в качестве символической ссылки для кеша репозитория пакетов ОС в сценарии установки):

#!/usr/bin/env dockerize
FROM=alpine
TAG=${TAG:-wjordan/my-image}
WORKDIR=/var/cache/dockerize
CACHE=/var/cache/docker
EXPOSE=3001
VOLUME="${HOME}/.docker-cache:${CACHE} ${PWD}:${WORKDIR}:ro /tmp"
#!/bin/sh
ln -s ${CACHE}/apk /var/cache/apk
ln -s ${CACHE}/apk /etc/apk/cache
set -e
apk --update add gcc g++ make libc-dev python
[...etc etc build...]

Итак, после встречи с французским контингентом :) от Docker на MesoCon на прошлой неделе (это было приятно, ребята), я узнал, что у них есть такая же проблема, и они разработали хак, который копирует в новый тонкий образ то, что им нужно. .
Я бы сказал, что взломы приветствуются в корпоративном мире;) и этот запрос должен быть правильно обработан.
Спасибо, что выслушали, ребята...

Я также за добавление флага -v во время сборки, чтобы ускорить сборку за счет совместного использования каталога кеша между ними.

@yngndrw Я не понимаю, почему вы закрыли две связанные проблемы. Я прочитал ваш выпуск № 59 и не понимаю, как это связано с этим. В некоторых случаях контейнеры становятся чрезмерно раздутыми, когда они не нужны во время выполнения. Пожалуйста, прочитайте 1-й пост.
Надеюсь, я ничего здесь не упустил... так как это был долгий день :-o

@zrml Проблема https://github.com/aspnet/aspnet-docker/issues/59 была связана со встроенным поуровневым кэшированием, которое докер обеспечивает во время сборки для всех файлов докеров, но эта текущая проблема немного отличается, поскольку мы говорим об использовании томов хоста для обеспечения кэширования, специфичного для dockerfile, которое зависит от dockerfile, специально использующего том. Я закрыл вопрос https://github.com/aspnet/aspnet-docker/issues/59 , поскольку он не имеет прямого отношения к проекту/репозиторию aspnet-docker.

Другая проблема, о которой, я думаю, вы говорите, — это проблема https://github.com/progrium/dokku/issues/1231 , которая касалась процессов Dokku, явно отключающих встроенное кэширование уровня докеров. Майкл внес изменения в Dokku, чтобы можно было настраивать это поведение, и это решило проблему, связанную с проектом/репозиторием Dokku, так что эта проблема также была закрыта.

Возможно, все еще существует нерешенная проблема, связанная с Docker (например, почему Docker не обрабатывал встроенное кэширование слоев, как я ожидал в выпуске https://github.com/aspnet/aspnet-docker/issues/59), но У меня не было возможности выяснить, почему это так, и подтвердить, происходит ли это до сих пор. Если это все еще проблема, то для этого проекта/репозитория следует создать новую проблему, поскольку она отличается от текущей проблемы.

@yngndrw точно, поэтому мы согласны, что это другое и известное @docker.com, поэтому я снова открываю его, если вы не возражаете ... ну, я не могу. Вы не возражаете, пожалуйста?
Я хотел бы увидеть некоторые комментарии от наших коллег в SF, по крайней мере, прежде чем мы закроем его.

Кстати, @cpuguy83 попросил меня открыть пользовательский случай и объяснить все это из журнала № 3156.

@zrml Я не уверен, что следую — это https://github.com/aspnet/aspnet-docker/issues/59 , который вы хотите снова открыть? Это не проблема /aspnet/aspnet-docker, поэтому я не думаю, что правильно снова открывать эту проблему. Это действительно должна быть новая проблема в /docker/docker, но ее нужно будет проверить, и сначала потребуются воспроизводимые шаги.

нет, нет.. этот № 14080, который вы закрыли вчера.

Этот вопрос все еще открыт?

@yngndrw Кажется , я неправильно прочитал красный значок «закрыто». Извинения.

Полностью согласен, что время сборки -v было бы огромным подспорьем.

Кэширование сборки — один из вариантов использования.

Другим вариантом использования является использование ключей ssh ​​во время сборки для создания из частных репозиториев без их сохранения на уровне, что устраняет необходимость в хаках (хотя и хорошо спроектированных), таких как этот: https://github.com/dockito/vault

Я комментирую здесь, потому что это ад в корпоративном мире.
У нас есть перехватывающий SSL прокси, при этом я могу направлять трафик через него, куча проектов предполагает, что у них хорошие SSL соединения, поэтому они ужасно умирают.

Несмотря на то, что моя машина (и, следовательно, сборщик докеров) доверяет прокси-серверу, образы докеров — нет.
Хуже всего, что сейчас лучше всего использовать curl внутри контейнера, так что это болезненно, мне нужно изменить файлы Docker, чтобы они даже собирались. Я мог бы смонтировать сертификаты с опцией -v и быть счастливым.

Это сказано. Это не столько вина докера, сколько вина менеджеров пакетов, использующих https, когда они должны использовать систему, аналогичную тому, как работает apt-get. Поскольку это по-прежнему безопасно и проверяемо, а также может быть кэшировано HTTP-прокси.

@btrepp спасибо за еще один хороший вариант использования.

Я могу представить себе другую ситуацию.

Одна из вещей, которые я хотел бы сделать с моими файлами докеров, — это не отправлять инструменты сборки с «скомпилированным» файлом докеров. Нет причин, по которым приложению C нужен gcc, а приложению ruby ​​​​необходим упаковщик в образе, но в настоящее время используется сборка докера, пока есть это.

У меня была идея указать файл dockerfile, который запускает несколько команд docker при сборке внутри него. Псевдоподобные файлы докеров ниже.

Файл Docker, который создает другие

FROM dockerbuilder
RUN docker build -t docker/builder myapp/builder/Dockerfile
RUN docker run -v /app:/app builder
RUN docker build -t btrepp/myapplication myapp/Dockerfile

btrepp/myapplication dockerfile

FROM debian:jessie+sayrubyruntime
ADD . /app //(this is code thats been build using the builder dockerfile
ENTRYPOINT ["rails s"]

Здесь у нас есть временный контейнер, который выполняет всю связную установку/управление пакетами и любые сценарии сборки, но он создает файлы, необходимые контейнеру среды выполнения.

Затем контейнер времени выполнения просто добавляет результаты этого, то есть ему не нужно ничего, кроме установленного ruby. В случае, скажем, GCC или, что еще лучше, статической привязки go, нам может не понадобиться ничего, кроме основных файлов ОС для запуска.

Это сделало бы образы докеров очень легкими.

Проблема здесь в том, что временный контейнер сборщика исчезнет в конце, а это означает, что он будет очень дорогим без возможности загрузки своего рода кеша, мы будем хватать debian:jessie целую кучу раз.

Я видел, как люди используют определенные методы, подобные этому, но используют внешние http-серверы для добавления файлов сборки. Я бы предпочел, чтобы все это создавалось докером. Хотя, возможно, есть способ использовать образ докера, чтобы сделать это правильно. Использование run и, таким образом, возможность монтировать тома.

Вот еще один пример. Скажем, я хочу создать контейнер для systemtap, в котором есть все символы отладки для ядра (которые являются Yuuuuge). Мне нужно смонтировать базовый /lib/modules, чтобы команда yum знала, какие RPM устанавливать.

Кроме того, возможно, я бы предпочел, чтобы они жили где-то еще, кроме образа 1,5 ГБ (из символов отладки)

Я пошел писать Dockerfile, а потом понял, что это невозможно :-(

docker run --privileged -v /lib/modules:/lib/modules --tty=true --interactive=true rhel7/rhel-tools /bin/bash
yum --enablerepo=rhel-7-server-debug-rpms install kernel-debuginfo-$(uname -r) kernel-devel-$(uname -r)
docker ps -a
CONTAINER ID        IMAGE                     COMMAND             CREATED             STATUS                        PORTS               NAMES
52dac30dc495        rhel7/rhel-tools:latest   "/bin/bash"         34 minutes ago      Exited (0) 15 minutes ago                         dreamy_thompson
docker commit dreamy_thompson stap:latest

https://access.redhat.com/solutions/1420883

Я хотел бы повторить здесь свой вариант использования из #3949, так как эта ошибка была закрыта по другим причинам.

Я бы очень хотел использовать проприетарное программное обеспечение в песочнице в докере. Для меня незаконно размещать его где бы то ни было, и процесс загрузки невозможно (или юридически) автоматизировать. В общей сложности установщики занимают около 22 ГБ (и они становятся больше с каждым выпуском). Я думаю, что глупо ожидать, что это должно быть скопировано в образ докера во время сборки.

Есть новости в этой необходимой функции?
Спасибо

_ОПРОС ПОЛЬЗОВАТЕЛЯ_

_Лучший способ получить уведомление об изменениях в этом обсуждении — нажать кнопку «Подписаться» в правом верхнем углу._

Перечисленные ниже люди оценили ваше содержательное обсуждение случайным +1:

@вад

+1 за эту функцию!

Другим вариантом использования является использование ключей ssh ​​во время сборки для создания из частных репозиториев без их сохранения на уровне, что устраняет необходимость в хаках (хотя и хорошо спроектированных), таких как этот: https://github.com/dockito/vault

Это также наш вариант использования (в данном случае ключи ssh обрабатываются с помощью tmpfs на хосте).

Другой вариант использования для этого — локальный кеш каталога node_modules на сервере CI для сокращения времени сборки.
npm install работает очень медленно, и даже в текущем «наилучшем» случае, когда package.json ADD вводится в образ, npm install запускается, а затем запускается npm install. фактические исходники проекта добавлены и построены на изменениях package.json , все зависимости необходимо повторно загрузить заново.

См. npm/npm#8836, чтобы узнать об этом на стороне Node/npm.

Связанная с aspnet-docker проблема, связанная с медленным восстановлением пакетов и результирующим размером образа кэширования текущих пакетов на уровне. Было бы намного лучше использовать смонтированный том для кэширования пакета.
https://github.com/aspnet/aspnet-docker/issues/123

Это не проблема конкретного языка, она затронет многих людей, учитывая, что менеджеры пакетов теперь являются общепринятым стандартом.

ОП решил проблему с головой, поскольку «docker build -v» очень помог бы отделить процесс сборки от среды выполнения.

Я видел несколько проектов, которые теперь строят «гавани Малберри», которые затем используются для создания фактического докера, который затем выталкивается/распространяется. Это слишком сложно как с точки зрения администрирования, так и с точки зрения вычислительных ресурсов, что, в свою очередь, приводит к более медленной непрерывной интеграции и модульному тестированию, а также к менее продуктивному рабочему процессу разработки.

Я думал об этом, и другой вариант, который я могу придумать, — это возможность помечать слои как слои «src».

Что-то вроде тех слоев, которые доступны только во время сборки докера, но не извлекаются в результирующий файл изображения.

Таким образом, Docker может кэшировать более ранние слои/изображения, временные артефакты сборки, но они не требуются для использования окончательного образа.

Например.

FROM ubuntu
RUN apt-get install gcc
ADDPRIVATE . /tmp/src <--these can be cached by docker locally
RUNPRIVATE make     <-- basically these layers become scoped to the current build process/dockerfile
RUN make install <--result of this layer is required.

Конечно, это означает, что вам нужно знать, что вы делаете лучше, так как вы вполне можете пропустить важные файлы.

@yngndrw
Гораздо лучшим решением для таких ситуаций, как netcore, было бы для них не использовать HTTPS для управления пакетами, тогда тривиально настроить iptables + squid для прозрачного кэширующего прокси-сервера для сборок докеров. Мое личное мнение таково, что эти менеджеры пакетов должны настроить свои game, их ужасно использовать в корпоративной среде из-за отказа от ssl, тогда как такие вещи, как apt-get, работают отлично и уже кэшируются с помощью iptables + squid для docker.

Я также вижу недостаток использования томов времени сборки, файлы dockerfile не будут такими воспроизводимыми, и потребуется дополнительная настройка за пределами docker build -t btrepp/myapp . Это также затруднит автоматическую сборку на dockerhub.

@btrepp : мне нравится твое предложение. Я мог бы даже жить для своих вариантов использования с жестко закодированным (я знаю, что это вообще плохо) каталогом TMP, о котором Docker сообщает нам, чтобы они знали, когда они создают окончательный артефакт из всех слоев, которые они могут забыть / пропустить один смонтирован на /this_is_the_tmp_explosion_folder_that_will_be_removed_from_your_final_container_image
достаточно легко....

@btrepp Мне очень нравится твоя идея исходного слоя.

Однако в отношении менеджеров пакетов, не использующих SSL, я бы не согласился.

Если вы хотите кэшировать такие пакеты, то вам, вероятно, следует использовать (локальный) частный поток пакетов вместо этого, который отражает официальный источник. Возврат к HTTP кажется мне плохой идеей, особенно с учетом того, что многие менеджеры пакетов, похоже, не подписывают свои пакеты и поэтому полагаются на HTTPS.

Существует инструмент грамматики/рокера , который можно использовать, пока эта проблема еще не исправлена.

@yngndrw

Я хочу сказать, что локальный прокси-сервер и т. Д. - это проблема, которая давно решена. Менеджерам пакетов нужна только проверка, им не нужна конфиденциальность. Использование https — ленивый способ подтверждения, но он поставляется с вложением о конфиденциальности.

Нет никакой причины, по которой "super_awesome_ruby_lib" должен быть закрытым при извлечении через http(s). Для рубиновых драгоценных камней лучше всего иметь брелок. Или даже известный публичный ключ, и им подписывать пакеты. Примерно так работает apt-get и позволяет стандартным HTTP-прокси кэшировать вещи.

Что касается локального канала частных пакетов, докер даже сам не поддерживает это. Нет никакого способа отключить стандартный канал, и он _правильно_ теряет его, если сертификат https отсутствует в хранилище сертификатов. Я почти уверен, что докер всегда хочет, по крайней мере, проверять основной канал при извлечении изображений. Насколько я знаю, реализация Rocket/rkt собиралась использовать signing+http для получения образов контейнеров.

Если основной мотивацией для объемов времени сборки является просто кеширование пакетов, то я думаю, что следует оказать давление на менеджеров пакетов, чтобы они лучше поддерживали кеширование, а не ставили под угрозу некоторые из автоматизированных/чистых докеров в настоящее время.

Чтобы было ясно, я не выступаю за то, чтобы менеджеры пакетов переключались только на использование http и отбрасывали https. Им нужна проверка пакетов, чтобы предотвратить атаки «человек посередине». Что им не нужно, так это аспект конфиденциальности, использующий https в качестве предложения «безопасность поймать все кувалдой».

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

В этой теме также есть масса других примеров того, почему это необходимо. Слова «вы должны просто изменить то, как работают все инструменты, которые вы используете для создания своих приложений» не устранят проблему, а только оттолкнут пользователей.

(Я также категорически не согласен с привязкой Docker к общедоступному реестру — я бы предпочел запретить доступ к общедоступному реестру и разрешить использовать только наш внутренний. Но это совсем другая тема.)

Для меня мне также нужно docker build -v .

В нашем случае мы хотим создать образ, который состоит из предварительно настроенной установки соответствующего продукта, а размер установщика превышает 2 ГБ . Не имея возможности смонтировать хост-том, мы не можем собрать образ с помощью установщика, хотя мы уже загрузили его в хост-ОС, для чего мы можем использовать различные инструменты/протоколы, скажем, прокси с https cert/auth , или, может быть, даже бит торрент.

В качестве обходного пути мы должны использовать wget для повторной загрузки установщика во время docker build , что является очень ограниченной средой, гораздо менее удобной, более трудоемкой и подверженной ошибкам.

Кроме того, из-за гибкости вариантов установки/конфигурации продукта для нас гораздо более целесообразно поставлять образы с предустановленным продуктом, а не поставлять образ только с установщиком.

@thaJeztah есть шанс, что это произойдет?

Между прочим, это единственная причина, по которой я не использую (или не могу) использовать докер.

У нас есть патч в версиях Docker для Red Hat, который включает параметр -v. Но истинным решением этого было бы создание новых и разных способов создания образов контейнеров OCI, отличных от сборки докера.

@rhatdan RHEL или Fedora?

Мы также реализовали опцию -v сборки докера в нашей внутренней версии докера на сайте Resin.io. Вы можете найти разницу здесь https://github.com/resin-io/docker/commit/9d155107b06c7f96a8951cbbc18287eeab8f60cc

@rhatdan @petrosagg , можешь сделать пиар для этого?

@jeremyherbert патч находится в демоне докеров, который входит во все последние версии RHEL, CentOS и Fedora...

@graingert Мы отправили его в прошлом, и он был отклонен.

@rhatdan , у тебя есть ссылка на него?

@runcom У вас есть ссылка?

@thaJeztah , это то, что вы, ребята, отвергли бы?

Вот список существующих проблем, которые были закрыты или на которые не ответили:
https://github.com/docker/docker/issues/3949
https://github.com/docker/docker/issues/3156
https://github.com/docker/docker/issues/14251
https://github.com/docker/docker/issues/18603

Информацию об исправлениях Project Atomic, используемых в RHEL/CentOS/Fedora, можно найти по адресу:
http://www.projectatomic.io/blog/2016/08/docker-patches/

@daveisfera похоже, что они добавляют только тома R, а не тома RW, поэтому это не сработает для @yngndrw и моего варианта использования.

@graingert Зачем вам тома RW? Я понимаю только для чтения как обходной путь для определенных случаев.

Тестирование миграции схемы было бы одной из веских причин...

01.11.2016, 10:36, Брайан Гофф написал:

@graingert https://github.com/graingert Зачем вам тома RW?
Я понимаю только для чтения как обходной путь для определенных случаев.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/14080#issuecomment-257582035 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAHLZdp0D6fAtuNglajPBIwnpWGq3slOks5q5050gaJpZM4FIdOc.

Скотт Маккарти

Скотт. [email protected]

http://crunchtools.com

@отецлинукс

@ cpuguy83 Другим вариантом использования RW будет ccache .

@fatherlinux Я не уверен, что следую. Зачем тебе для этого том? Кроме того, почему это должно быть сделано на этапе сборки?

У меня немного другой вариант использования этой функции — кэширование пакетов, которые загружаются/обновляются менеджером пакетов ASP.Net 5. Менеджер пакетов управляет своей собственной папкой кеша, поэтому в конечном итоге мне просто нужна папка, которую я могу повторно использовать между сборками.

Я бы привязал mount, например:

docker build -v /home/jenkins/pythonapp/cache/pip:/root/.cache/pip  -t pythonapp .
docker build -v /home/jenkins/scalaapp/cache/ivy2:/root/.ivy2  -t scalaapp .

Потому что много раз приходится выполнять миграцию схемы, когда
программное обеспечение установлено. Если вы запускаете контейнеры только для чтения, вы должны
никогда не устанавливайте программное обеспечение в любое время, кроме как когда вы находитесь в
этап сборки.....

01.11.2016, 10:42, Брайан Гофф написал:

@fatherlinux https://github.com/fatherlinux Я не уверен, что следую.
Зачем тебе для этого том? Кроме того, почему это должно быть сделано во время
этап сборки?

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/14080#issuecomment-257583693 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAHLZfhBG8RUWtqPD-6RaLC7uoCNc-3nks5q50_TgaJpZM4FIdOc.

Скотт Маккарти

Скотт. [email protected]

http://crunchtools.com

@отецлинукс

Я знаю, что содержимое этих каталогов не приведет к тому, что сборка будет зависеть от хоста (отсутствие этих монтирований приведет к тому, что сборка будет работать в любом случае, просто медленнее)

NFS решила эту проблему 30 лет назад...

01.11.2016, 10:45, Томас Грейнджер написал:

Я знаю, что содержимое этих каталогов не остановит сборку
быть идемпотентным или зависимым от хоста (отсутствие этих креплений приведет к
сборка все равно работает)

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/14080#issuecomment-257584576 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAHLZS75Vq0BSEvUjI2oXORsS0el2mwOks5q51CQgaJpZM4FIdOc.

Скотт Маккарти

Скотт. [email protected]

http://crunchtools.com

@отецлинукс

NFS решила эту проблему 30 лет назад...

Не полезный комментарий

@graingert извините, это серьезно пошло не так. Я пытался ответить слишком быстро и не дал достаточного контекста. Если серьезно, мы рассматриваем NFS в сочетании с CRIO для решения некоторых из этих проблем.

И реестр изображений, и булды имеют много общего. То, о чем вы говорите, в основном проблема кэширования. NFS и особенно встроенное кэширование могут сделать сборку независимой от хоста и выполнять все кэширование за вас.

Следовательно, даже с параметром времени сборки -v сборка не обязательно должна быть привязана только к одному хосту. Возможно, это не зависит от масштаба Интернета, но этого вполне достаточно для многих людей, которые контролируют свою среду сборки на одном сайте или в одном месте.

@fatherlinux Я бы использовал кеширование gitlab или travis, чтобы взять каталог кеша и загрузить/выгрузить в S3

@graingert да, но это работает только с определенными типами данных / приложений, а также только на уровне корзины, а не на уровне метаданных и блоков posix. Для определенных типов интерфейсных и промежуточных приложений проблем нет. Для миграции схемы базы данных вам нужно заранее протестировать и иметь локальный кеш для скорости, и обычно он должен быть posix.

Представьте, что у меня есть кластер MySQL Galera с 1 ТБ данных, и я хочу выполнить обновление, и все они находятся в контейнерах. Контейнерная/организованная многоузловая, сегментированная Galera действительно удобна. Я не хочу вручную тестировать миграцию схемы при каждом обновлении.

Я хочу сделать снимок тома данных (pv в мире Kube), выставить его на сервер сборки, а затем протестировать обновление и миграцию схемы. Если все работает правильно и тесты пройдены, мы создаем производственные контейнеры и позволяем миграции схемы происходить в производственной среде....

@graingert извините, забыл добавить, а затем удалите снимок, который использовался при тестовом прогоне ... Я не хочу организовывать сборку и тестирование отдельно, хотя это было бы возможно ...

@fatherlinux Я думаю, что это ортогональный вариант использования ...

@graingert бесполезный комментарий. Ортогонально чему? Ортогонально запросу -v во время сборки, о чем я понял этот разговор?

Я вижу несколько разных применений этого флага.

• кеш, разделяемый между серверами сборки докеров
• ADD-подобное ключевое слово, которое применяется только «во время сборки» одного Dockerfile. Например, ДОБАВЬТЕ большой файл, а затем исключите его из изображений.
• ADD+RUN как ключевое слово, которое игнорирует все выходные данные. Например, ДОБАВЬТЕ большой файл, затем ЗАПУСТИТЕ шаг и игнорируйте любые изменения в изображении - ДОБАВЬТЕ + ЗАПУСТИТЕ за один шаг, затем пропустите слой.

Последние два варианта использования могут быть решены более четко с помощью двух новых ключевых слов.

BUILDCONSTFILE <path>

Будет запускать COPY <path> перед каждым RUN и удалять <path> из образа после.

TEST <cmd> WITH <paths>

Что бы КОПИРОВАТЬ пути, запустить команду, затем со статусом выхода 0 продолжить сборку из родительского образа, в противном случае сборка остановится.

Лично я думаю, что TEST ... WITH лучше обрабатывается на другом этапе CI, который проверяет ваш контейнер в целом.

Позвольте мне предварить следующее: я _думаю_, что могу добавить --mount в сборку ("-v", вероятно, не так много). Не уверен на 100% в реализации, в том, как обрабатывается (или не обрабатывается) кеширование и т. д.

Для проекта докера мы создаем образ построителя.
По сути, в нем есть все, что нам нужно, он копирует код, но на самом деле не создает докер.
У нас есть Makefile , который организует это. Таким образом, make build создает образ, make binary создает двоичный файл с build в качестве зависимости и т. д.

Создание двоичного файла запускает образ сборки и выполняет сборку, благодаря чему мы можем монтировать то, что нам нужно, включая кэши пакетов для инкрементных сборок.
Большая часть этого довольно прямолинейна и легко организована.
Таким образом, сегодня, безусловно, есть способы справиться с этим случаем, просто докер не может справиться с этим на 100% (и это не обязательно плохо), и вам придется заставить это работать с вашей системой CI.

@ cpuguy83 Я думаю, что это подойдет для большинства моих вариантов использования. Я так понимаю, вы имеете в виду --mount только для чтения? и -v для чтения/записи?

@ cpuguy83 мы также в основном создаем образы-конструкторы, которые, ИМХО, становятся все более и более распространенным шаблоном ...

Службы роя @fatherlinux , и теперь (для 1.13) docker run поддерживает --mount , что намного точнее и гибче: https://docs.docker.com/engine/reference/commandline/service_create/# /add -bind-mounts-or-volumes

Похоже, в документах отсутствует 3-й тип монтирования, tmpfs .

Ааа, очень круто, спасибо...

01.11.2016, 14:20, Брайан Гофф написал:

@fatherlinux https://github.com/fatherlinux сервисы роя и сейчас
(для 1.13) |запуск докера| поддерживает |--mount| что гораздо точнее
и гибкий:
https://docs.docker.com/engine/reference/commandline/service_create/#/add -bind-mounts-or-volumes

Похоже, в документах отсутствует 3-й тип монтирования, |tmpfs|.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/14080#issuecomment-257648598 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAHLZXv_VBfVi4WUAjVijE-SKR0ErRC4ks5q54L2gaJpZM4FIdOc.

Скотт Маккарти

Скотт. [email protected]

http://crunchtools.com

@отецлинукс

@ cpuguy83 мы также часто используем шаблон построителя, и нам нужно кэширование, которое не сохраняется в изображении, а также выдерживает аннулирование слоя.

Мы создаем образы Yocto, и у нас есть общий кеш sstate в хранилище NFS. Еще один вариант использования — npm cache, так что вы можете аннулировать весь слой RUN npm install , но пересчитывать его быстрее из-за кешированных пакетов.

В качестве возможного компромисса, основанного на сообщении @graingert , нельзя ли иметь необязательный хэш вашего огромного файла в файле докеров, а затем докер проверяет это при запуске сборки? Тогда не было бы проблем с детерминированными сборками, и для человека, который занимается сборкой, было бы очевидно, что у него нет необходимых зависимостей, а не просто в какой-то момент взорвался со странной ошибкой. То же самое касается ssh-ключей и т. д., которые в любом случае необходимо распространять с файлом докер-файла.

Я также думаю, что любая идея, требующая _копирования_ огромного файла, далеко не идеальна. Размеры файлов, которые мне интересны, составляют порядка 10-40 ГБ, и даже с хорошим ssd копирование займет как минимум минуту или две. Это моя проблема с директивой ADD уже в докере; Я не хочу ДОБАВЛЯТЬ 30 ГБ к моему образу каждый раз, когда он создается, и мне приходится иметь дело со всем этим дополнительным свободным пространством, а также с необходимостью сжимать изображения.

Это не сработает для того, для чего мы это используем. У нас есть том, содержащий кэши sstate из системы сборки yocto, которая является RW с привязкой в ​​сборке, потому что любой промах кэша будет рассчитан во время сборки и сохранен в sstate для будущих. Наши каталоги также занимают около 30 ГБ, поэтому даже вычисление хеша займет некоторое время.

Я никогда не понимал концепцию детерминированной сборки. Есть способы выстрелить себе в ногу даже с сегодняшней семантикой. Например, вы можете curl что-то с внутреннего IP. Внезапно этот Dockerfile не работает везде и зависит от хоста. Но есть законные случаи, почему вы хотели бы это сделать. Например, локальный кэш HTTP.

Итак, поскольку сборки в любом случае не являются детерминированными, и поскольку сегодня можно эмулировать смонтированный привязкой том по сети, почему бы не предоставить собственный способ сделать это с соответствующими предупреждениями, если это необходимо?

@petrosagg @zrml @thaJeztah Мы знаем следующее:

• Если порыться в #7115 #3156, то можно найти длинный список вопросов, которым уже много лет обсуждают эту же проблему
• Большинство из них были закрыты либо по причинам воспроизводимости (или по старому комментарию Dockerfile syntax is frozen , а затем, после добавления инструкции HEALTHCHECK , зависание было удалено, но проблемы остались закрытыми)
• Эта проблема на протяжении многих лет мешала многим командам иметь хорошее удобство использования/производительность контейнеров при ежедневной разработке. Как сказал @btrepp , это ад
• Люди, занимающиеся докером, знают об этой проблеме, но это приведет к классу « О, моя сборка докера сломалась! » проблемы из-за общего кеша, что не очень хорошо
• Но переход от дискового кеша к сетевому кешу, похоже, никоим образом не повышает надежность сборки, действует просто как прославленный кеш-через-http, и было обнаружено, что он ухудшает ситуацию (загрузка Интернета для каждой сборки, HTTPS, размер файлов, перегрузка диска при создании контейнеров, кэширование слоев, сложная оркестровка сборки и т. д.)

Учитывая все, что мы знаем, я думаю, что это, скорее всего, будет закрыто либо как Dupe, либо как WontFix. Кажется, не имеет значения, какие варианты использования мы даем. Обновление: я рад ошибиться здесь. Предложение выглядит открытым :)

Наша компания перешла на независимую среду выполнения контейнеров, и вскоре ей также придется перейти на независимый опыт создания образов. Но это неподходящее место для обсуждения этого, потому что негатив не помогает. Это должен быть отдельный пост.

@rdsubподелитесь ссылкой, когда закончите?

@rdsub имеет хорошее резюме. Не похоже, что эта ветка будет закрыта из-за дублирования/несправления, поскольку @cpuguy83 считает, что он не против добавления --mount во время сборки, которая охватывает большинство вариантов использования.

Что я хотел бы знать, так это то, что текущее предложение:

1. не изменяет синтаксис Dockerfile
2. не делает сборки более зависимыми от хоста, чем они в настоящее время

Какие контраргументы остались относительно этой идеи? Если их нет, возможно, нам следует начать обсуждение деталей реализации механизма --mount .

Чтобы подтвердить аргумент о том, что сборки уже зависят от хоста и невоспроизводимы, я привожу список фрагментов Dockerfile с этим свойством:

# Install different software depending on the kernel version of the host
RUN wget http://example.com/$(uname -r)/some_resource

# example.intranet is only accessible from specific hosts
RUN wget http://example.intranet/some_resource

# get something from localhost
RUN wget http://localhost/some_resource

# gcc will enable optimizations supported by the host's CPU
RUN gcc -march=native .....

# node:latest changes as time goes by
FROM node

# ubuntu package lists change as time goes by
RUN apt-get update

# install different software depending on the docker storage driver
RUN if [ $(mount | head -n 1 | awk '{print $5}') == "zfs" ]; then .....; fi

Честно говоря, если мы просто добавим --mount и позволим пользователю обрабатывать аннулирование кеша ( --no-cache ), я думаю, все будет в порядке. Мы можем захотеть рассмотреть более детальное управление кешем из CLI, чем все или ничего, но это отдельная тема.

Мой вариант использования

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

Условия

1. У CircleCI есть ключи ssh для загрузки всех внутренних зависимостей во время сборки.
2. GitHub размещает внутренние зависимости, а другие загружаются из образа во время сборки.

Опции

1. Используйте --build-arg для передачи токена во время сборки (настоятельно не рекомендуется). Это очень привлекательный и простой вариант, поскольку он «просто работает» без каких-либо дополнительных действий.
2. Загрузите все зависимости и добавьте их в контекст сборки. К сожалению, ADD и COPY выполняются в отдельных слоях, поэтому я застрял с данными из предыдущих слоев.

Размер некоторых моих изображений в некоторых случаях увеличился более чем в два раза, но общий размер пока приемлем. Я думаю, что был PR (я не могу его найти) для удаления аргументов времени сборки из истории сборки, но это было неприемлемо из-за проблем с кешированием irrc.
Я буду рад услышать о любых других обходных путях, используемых там.

@misakwa мы, вероятно, будем поддерживать секреты в сборке 1.14.

Очень приятно слышать @cpuguy83. Буду следить когда выйдет. Это определенно упростит некоторые из моих рабочих процессов.

мы, вероятно, будем поддерживать секреты в сборке 1.14.

Будет ли он также работать для отображения во время сборки других типов томов, таких как, например, yarn-cache ?

Кстати, есть интересный способ создания производственных образов с помощью docker-compose, я нашел его работающим и довольно эффективным:

Итак, у вас есть файл компоновки docker-compose.build.yml примерно так:

services: 
  my-app:
    image: mhart/alpine-node:7.1.0
    container_name: my-app-build-container # to have fixed name
    volumes:
    - ${YARN_CACHE}:/root/.cache/yarn # attach yarn cache from host
    - ${HOME}/.ssh:/.ssh:ro    # attach secrets
    - ./:/source
    environment: # set any vars you need
     TEST_VAR: "some value"    
    ports:
    - "3000"
    working_dir: /app/my-app # set needed correct working dir even if if doesn't exist in container while build type
    command: sh /source/my-app.docker.build.sh # build script

1) вы создаете контейнер, используя docker compose:

$ docker-compose -f docker-compose.build.yml up --force-recreate my-app

он создает контейнер и запускает скрипт сборки оболочки my-app.docker.build.sh , я не использую Dockerfile и делаю все в скрипте сборки:

• установить необходимые пакеты ОС
• скопируйте необходимый исходный код (из сопоставленной папки /source )
• установить зависимости
• сборка/компиляция/тестирование при необходимости
• удалить пакеты и прочее, которые не нужны для работы целевой среды (чтобы уменьшить размер конечного изображения)

Затем вы создаете образ из контейнера, заменяя CMD тем, что его нужно запустить в целевой среде:

docker commit -c "CMD npm run serve" my-app-build-container my-app-build-image:tag

Итак, ваш образ готов, используется внешний кэш пряжи и внешние секретные ключи, которые доступны только во время сборки.

@whitecolor да, это работает :) за исключением одного: docker build действительно эффективно загружает контекст сборки. К сожалению, смонтированные исходные тома не работают с удаленными демонами докеров (например, докер-машина в облаке для ноутбуков с низким энергопотреблением/с пропускной способностью). Для этого нам нужно выполнить громоздкую серию docker run , docker cp , docker run и т. д., а затем сделать снимок конечного изображения, но это действительно хакерский подход.

Это действительно помогает официально включить это в сборку докеров, а также использовать слои и контекст сборки 😄

@rdsubhas Да, вы правы

@whitecolor Это действительно простое и эффективное решение. Я просто сократил 30-40-минутную сборку проекта до 5 минут. Я с нетерпением жду возможности использовать функцию --mount on build, но на данный момент это решение действительно разблокирует мой конвейер.

Это комментарий, который я оставил для вопроса № 17745, который, как я понял, был закрыт, но не был помечен как дубликат. Кажется, я ошибался в последнем пункте: я признаю, что привык к таким системам, как Bugzilla, которые явно помечают что-то как «РАЗРЕШЕННЫЙ ДУБЛИКАТ» и отображают это в верхней части описания ошибки. Я не телепат. (Так что мои извинения @graingert , я мало что знал, поэтому нет необходимости кричать на меня шрифтом 20pt - это было чрезмерно.)

В моем случае это было бы полезно в системах Debian: монтировать /var/cache/apt как том, чтобы вам не приходилось повторно загружать одни и те же файлы .deb снова и снова. (По-настоящему «безлимитной» интернет-квоты просто не существует, особенно здесь, в Австралии, а если бы и была, то время на ожидание загрузки тратится впустую.)

Или другой сценарий: вы выполняете сборку, но она также создает отчеты о тестировании, такие как списки сбоев и отчеты о покрытии кода, которые вам не нужно поставлять с образом, но которые являются полезными артефактами. Они могут быть записаны в том, когда сервер CI создает образ, который сервер CI собирает и размещает.

Или сегодня вечером я делаю несколько образов на основе Gentoo для себя, я хотел бы смонтировать /usr/portage с хоста. Для Dockerfile нетрудно понять: «Эй, /usr/portage (в контейнере) пуст, без проблем, я просто возьму это» при работе без смонтированного тома, ИЛИ, он просто использует том как есть, экономя время на получение новой копии.

Добавление этих умных функций является тривиальным оператором if в сценарии оболочки Bourne… ЕСЛИ базовая логика для монтирования тома присутствует в первую очередь. Прямо сейчас для моих образов Gentoo мне приходится тянуть /usr/portage каждый раз, когда я делаю сборку (к счастью, зеркало находится в моей локальной сети), а это означает, что ждать завершения этого шага нужно несколько минут.

Так много причин, почему это стоящее предложение, и я сомневаюсь, что вложенные сборки, предложенные в #7115, помогут в вышеупомянутых случаях.

У @whitecolor есть интересный подход, но если я сделаю это, я мог бы также использовать Makefile , полностью внешний по отношению к системе Docker, для достижения сборки.

@sjlongland Я не кричал на тебя, я заполнял большое уведомление «РАЗРЕШЕННЫЙ Дубликат»

Я использую docker и docker-compose для создания нескольких контейнеров для нашей инфраструктуры. Контейнеры представляют собой микросервисы, в основном написанные на nodeJS, но есть один микросервис, написанный на Java с использованием фреймворка maven.
Каждый раз, когда мы пересобираем java-контейнер, из Maven загружаются десятки зависимостей; это занимает несколько минут. Затем код строится примерно за 15 секунд.

Это очень уродливо и очень сильно влияет на нашу стратегию CI.

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

Я понимаю, что есть проблемы с безопасностью, потому что я могу вмешаться в зависимости и внедрить туда неприятный код; ИМХО, это можно легко обойти, запретив публикацию образов со сборочными томами в docker-hub или docker-store.
Чтобы выразить это по-другому, должно быть различие между корпоративным и личным использованием докера.

@stepps проверьте https://pypi.python.org/pypi/shipwright вместо docker-compose

Я некоторое время слежу за этой темой, ищу хорошее решение для себя. Для гибкого создания минимальных контейнеров с минимальными усилиями мне очень нравится https://github.com/edannenberg/gentoo-bb от @edannenberg.

• Он отделяет зависимости времени сборки от зависимостей времени выполнения.
• Сборки выполняются в контейнерах и являются изолированными, чистыми и воспроизводимыми.
• Обрабатывает зависимости между изображениями и порядком сборки

Он основан на использовании портежей Gentoo и emerge, поэтому @sjlongland вам может понравиться это для ваших образов на основе Gentoo. Dist-файлы и двоичные пакеты кэшируются, поэтому их не нужно загружать или собирать заново, что ускоряет перестроение. Он имеет крючки для легкой настройки процесса сборки. Установка стороннего программного обеспечения проста, например, использование git для клонирования репозитория, а затем его сборки, сохраняя только сборку в финальном образе. Он шаблонизирует Dockerfile.

Простой пример для figlet : -

build.conf:

IMAGE_PARENT="gentoobb/glibc"

Dockerfile.template:

FROM ${IMAGE_PARENT}
ADD rootfs.tar /
USER figlet
CMD ["gentoo-bb"]
ENTRYPOINT ["figlet"]

build.sh

PACKAGES="app-misc/figlet"

configure_rootfs_build() {
        useradd figlet
}

Мне нравится решение @whitecolor , оно простое, используя только технологию Docker, а затем простой сценарий оболочки или что-то еще, что вы хотите использовать. Я использую gentoo-bb, так как он более совершенен. Shipwright выглядит хорошо с более ориентированными на разработчиков функциями, такими как работа с ветвями. https://github.com/grammarly/rocker тоже кажется интересным. Спасибо, что поделились со всеми.

Просто еще один голос добавился к этой куче. Наша очень сложная среда разработки была бы намного проще, если бы мы могли монтировать локальные тома при сборке.

Обходной путь — запустить во время сборки http-сервер, который предоставляет локальные файлы, а затем использовать curl/wget и т. д., чтобы получить файлы в сборку докера. Но я бы очень хотел, чтобы такие хаки были ненужными.

Другой вариант использования. Я хочу создать образы докеров для создания проприетарной ОС, которая имеет 10 разных версий. Размер установочного носителя составляет> 80 ГБ, поэтому я не могу просто скопировать его в среду сборки докера. Связное крепление было бы намного предпочтительнее.

Еще один: мой проект использует файлы Dockerfile в репозитории для сборки из исходников в контейнере. В настоящее время мы получаем еще один клон git в контейнере с github. Есть мелкие клоны и все такое, но все же...

Итак, я только что протестировал [1] на хосте сборки rhel7, и сборка Red Hat демона докера ДЕЙСТВИТЕЛЬНО имеет параметр -v для сборки. Я не тестировал CentOS/Fedora, но можно предположить, что в Fedora/CentOS он тоже есть. Это стоит протестировать. Кроме того, подписки RHEL Developer теперь бесплатны [2]:

@fatherlinux В Fedora также доступен `docker build -v'.

@fatherlinux Версия CentOS 7 включает его.

+1 Я думаю, что это было бы очень полезно добавить в официальный докер.

Только что обновился как на Centos, так и на linuxmint (сейчас работает 17.03.1-ce). Я что-то здесь упустил? Я не вижу вариант -v

На мяте

$ docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --build-arg list             Set build-time variables (default [])
      --cache-from stringSlice     Images to consider as cache sources
      --cgroup-parent string       Optional parent cgroup for the container
      --compress                   Compress the build context using gzip
      --cpu-period int             Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int             CPU shares (relative weight)
      --cpuset-cpus string         CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string         MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust      Skip image verification (default true)
  -f, --file string                Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                   Always remove intermediate containers
      --help                       Print usage
      --isolation string           Container isolation technology
      --label list                 Set metadata for an image (default [])
  -m, --memory string              Memory limit
      --memory-swap string         Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string             Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                   Do not use cache when building the image
      --pull                       Always attempt to pull a newer version of the image
  -q, --quiet                      Suppress the build output and print image ID on success
      --rm                         Remove intermediate containers after a successful build (default true)
      --security-opt stringSlice   Security options
      --shm-size string            Size of /dev/shm, default value is 64MB
  -t, --tag list                   Name and optionally a tag in the 'name:tag' format (default [])
      --ulimit ulimit              Ulimit options (default [])
$ cat /etc/lsb-release 
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=18
DISTRIB_CODENAME=sarah
DISTRIB_DESCRIPTION="Linux Mint 18 Sarah"
$ docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64
 Experimental: false

На центос 7

# docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --build-arg list             Set build-time variables (default [])
      --cache-from stringSlice     Images to consider as cache sources
      --cgroup-parent string       Optional parent cgroup for the container
      --compress                   Compress the build context using gzip
      --cpu-period int             Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int             CPU shares (relative weight)
      --cpuset-cpus string         CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string         MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust      Skip image verification (default true)
  -f, --file string                Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                   Always remove intermediate containers
      --help                       Print usage
      --isolation string           Container isolation technology
      --label list                 Set metadata for an image (default [])
  -m, --memory string              Memory limit
      --memory-swap string         Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string             Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                   Do not use cache when building the image
      --pull                       Always attempt to pull a newer version of the image
  -q, --quiet                      Suppress the build output and print image ID on success
      --rm                         Remove intermediate containers after a successful build (default true)
      --security-opt stringSlice   Security options
      --shm-size string            Size of /dev/shm, default value is 64MB
  -t, --tag list                   Name and optionally a tag in the 'name:tag' format (default [])
      --ulimit ulimit              Ulimit options (default [])
# docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:05:44 2017
 OS/Arch:      linux/amd64
# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core) 

@wilfriedroset В CentOS 7 неофициальные пакеты Docker предоставляют эту возможность. Я думаю, что это часть репозитория EPEL.

спасибо @nathanjackson. У нас есть ETA для этой функции в официальном выпуске?

@wilfriedroset Насколько я знаю , ETA НЕТ, потому что было решено (несколько раз), что эта функция НЕ ДОЛЖНА быть в официальном докере, чтобы сохранить «переносимость сборки». ака позволяет вашим файлам Docker работать где угодно, включая службу сборки Docker.

По моему опыту, клиенты действительно хотят ограниченной переносимости сборки. Они хотят настроить среду/ферму сборки и обеспечить возможность повторной сборки сборок в этой среде. Опция сборки -v никак не препятствует этому.

Например, если вы используете монтирование NFS, просто убедитесь, что все серверы сборки имеют это монтирование в своих fstabs, и ваша сборка будет завершена без проблем в любом месте фермы.

На RHEL 7.3
````
[ root@rhel7 ~] # сборка докера --help

Использование: сборка докеров [ОПЦИИ] ПУТЬ | URL-адрес | -

Создайте образ из Dockerfile

Опции:
--build-arg value Установить переменные времени сборки (по умолчанию [])
--cgroup-parent строка Необязательная родительская cgroup для контейнера
--cpu-period int Ограничить период CPU CFS (Completely Fair Scheduler)
--cpu-quota int Ограничить квоту CPU CFS (Completely Fair Scheduler)
-c, --cpu-shares int доли ЦП (относительный вес)
--cpuset-cpus строка ЦП, на которых разрешено выполнение (0-3, 0,1)
--cpuset-mems строка MEM, в которой разрешено выполнение (0-3, 0,1)
--disable-content-trust Пропустить проверку изображения (по умолчанию true)
-f, --file string Имя Dockerfile (по умолчанию «PATH/Dockerfile»)
--force-rm Всегда удалять промежуточные контейнеры
--help Распечатать использование
--isolation string Технология изоляции контейнеров
--label value Установить метаданные для изображения (по умолчанию [])
-m, --memory string Лимит памяти
--memory-swap string Лимит свопа, равный объему памяти плюс своп: '-1' для включения неограниченного свопа
--no-cache Не использовать кеш при сборке образа
--pull Всегда пытаться получить более новую версию образа
-q, --quiet Подавить вывод сборки и распечатать идентификатор изображения в случае успеха
--rm Удалить промежуточные контейнеры после успешной сборки (по умолчанию true)
--shm-size string Размер /dev/shm, значение по умолчанию 64 МБ.
-t, --tag значение Имя и, необязательно, тег в формате ' имя:тег ' (по умолчанию [])
--ulimit значение Ulimit опции (по умолчанию [])
-v, --volume значение Задать монтирование привязки во время сборки (по умолчанию [])
```

Другой вариант использования в проектах узлов построения CI — совместное использование кэша yarn CI при создании всех образов.

+1: снова и снова устанавливать node_modules действительно ужасно, особенно для микросервисов nodejs
Я пытаюсь решить эту проблему с помощью nfs, я думаю, что «повторяемость» не является веской причиной для того, чтобы не реализовывать эту функцию...

Кажется, что это будет еще более важно, когда #31257 и #32063 объединены.

Взгляните на # 32507

@fatherlinux , не могли бы вы объяснить, как работает переносимость сборки, когда вы можете иметь команды COPY в Dockerfile? У меня есть проблема, когда я хочу избежать количества копий большого файла (из соображений сложности времени) и ищу вариант только для чтения во время сборки, чтобы поделиться файлом с контейнером.

@arunmk См. https://github.com/moby/moby/issues/32507

@arunmk @cpuguy83 точно. Идея состоит в том, что вы действительно не хотите КОПИРОВАТЬ данные в контейнер при сборке. Это может сделать его очень большим. Мы просто хотим, чтобы данные были доступны во время сборки. Как указано выше, вы можете выполнить монтирование с привязкой -v в версии демона докера Red Hat, которая позволяет вам иметь доступные данные, но прямо сейчас она доступна только для чтения (обожгла меня на прошлой неделе).

Итак, если вам это нужно сегодня, проверьте Fedora, CentOS или RHEL, и вы можете смонтировать копию данных только для чтения во время сборки...

И, если вам нужна переносимость в сборочной ферме, я бы предложил NFS или что-то в этом роде....

Если вы не хотите копировать его, а просто хотите, чтобы он был в конечном образе, вы можете использовать многоэтапные сборки для решения этой проблемы.

Надуманный пример:

FROM fatImage AS build
COPY bigData /data
RUN some_stoff /data

FROM tinyImage
COPY --from=build /data/result

Спасибо за разъяснение @fatherlinux
@ cpuguy83 спасибо за подробности. Позвольте мне добавить больше деталей к моей проблеме, которая может быть необычной: у меня есть система сборки, которая генерирует файл размером 3,3 ГБ. Это добавляется к RPM, который встроен в контейнер докеров. Таким образом, создаются две копии: одна из системы сборки в док-контейнер, другая из док-контейнера в RPM. Теперь я не могу избежать второй копии. Я думал избежать первой копии, но похоже, что это тоже невозможно, даже с многоэтапными сборками.
Я могу понять, что если бы большой файл использовался повторно, многоэтапная копия уменьшила бы количество копий до «1». Я использую его один раз и хотел уменьшить число до «0». Я правильно понимаю, что это невозможно?

@arunmk Неважно, что нужно будет скопировать в экземпляр сборки с клиента.

@ cpuguy83 спасибо за разъяснение. Похоже, сейчас мне придется взять на себя накладные расходы. Это чтобы иметь атомарность?

@отецлинукс

Я попробовал то, что вы сказали, используя -v на RHEL7, чтобы попытаться смонтировать каталог только для чтения во время сборки, но получил эту ошибку:

Тома не поддерживаются в сборке докеров. Пожалуйста, используйте только привязные крепления.

Это будет работать только с пакетом docker от RHEL, а не с пакетом Docker. Патч не был принят восходящим потоком.

@отецлинукс

Я попробовал то, что вы сказали, используя -v на RHEL7, чтобы попытаться смонтировать каталог только для чтения во время сборки, но получил эту ошибку:

Тома не поддерживаются в сборке докеров. Пожалуйста, используйте только привязные крепления.

@fcntl

вам нужно использовать привязки, как сказано в ошибке, вы, вероятно, использовали -v /something , а не /hostsomething:/containersomething

@thebigb и, возможно, другие, мы создали инфраструктуру, позволяющую использовать ccache во время сборки докеров. мы опубликовали его на https://github.com/WebHare/ccache-memcached-server , если он вам поможет, хотя в идеале решение этой проблемы, вероятно, устарело бы.

Я как раз собирался добавить, вариант использования, для которого мне это действительно нужно, — это ccache. Я хотел бы иметь возможность монтировать свой кеш ccache во время сборки образа докера - нет смысла в том, чтобы он находился в самом образе. @unilynx Я посмотрю на ваш обходной путь - хорошее время!

Используйте другой голос.

Мой пример использования: в настоящее время я использую команду рокера MOUNT для совместного использования каталогов /root/.cache и /var/cache/apk .

По какой-то причине у меня очень (очень, очень) медленный сетевой доступ к пакетам apk и пакетам pip. Любая перестройка сделает процесс невероятно трудоемким. Эта функция MOUNT во время сборки значительно упрощает работу.

@embray @roxma взгляните на https://github.com/moby/moby/issues/32507 , если это подходит для вашего варианта использования; обратная связь приветствуется

С введением многоэтапных сборок я считаю, что необходимость указывать монтирование тома для локального кэша Maven имеет решающее значение.

@ gim913 Вы не участвуете в любом сообществе таким образом. Если вы хотите внести свой вклад, просмотрите существующие предложения, связанные здесь, чтобы узнать, решает ли какое-либо из них ваш вариант использования.

@ gim913 gim913 На данном этапе интеграции докера в различные дистрибутивы изменение среды (т.е. полное удаление докера) кажется гораздо более разрушительным, чем изменение вашей «ОС» (я полагаю, вы имеете в виду переход с другого дистрибутива Linux на сборку RedHat, которая, по-видимому, включает -в?)

Не проще ли просто взять версию докера от RedHat? Возможно, кто-то здесь может указать вам на соответствующие патчи/форки/коммиты, чтобы получить опцию «-v» в сборке.

@unilynx вот так

Я просматривал несколько примеров, в которых использовался wget, и попал сюда... мой вариант использования аналогичен... Я хочу разархивировать большой архив и просто запустить его. Я не хочу засорять файл докера с tarball или тратить время на выполнение wget с локального веб-сервера. Монтирование, которое вы можете сделать с помощью docker compose, кажется разумным во время сборки. Пожалуйста, объедините изменение Puneeth, если оно выглядит нормально :-)

Я предварительно компилирую колеса Python и хочу установить их в контейнер, не копируя их и не создавая слой, который мне действительно не нужен, или мне нужно как-то пытаться его раздавить. День 1, а я уже ищу rocker 😢 😢 😢

Это было бы легко добавить и чрезвычайно полезно (или команду mount, см. снова rocker ). Сколько времени тратится (в сообществе) на написание сценариев для этой или подобных отсутствующих функций?

Сборка @awbacker Multi-stag довольно хорошо решает эту проблему, когда вы можете сделать что-то вроде

FROM something AS my_wheels
RUN compile_all_the_things

FROM something
COPY --from my_wheels /wherever
RUN do_stuff_with_wheels

Первая часть запускается только в том случае, если что-то изменилось. Кэш для него также может использоваться совместно с другими сборками/файлами докеров.
Это делает всю конструкцию автономной.

Также есть предложение, позволяющее RUN --mount , где спецификация монтирования говорила бы ему монтировать объект из цели сборки my_wheels , а не копировать его.

Как и в случае с @kenyee , это может монтировать что-то из контекста сборки, который в 17.07-experimental отправляется только постепенно по мере необходимости.

@ cpuguy83 cpuguy83 На практике это не работает - по крайней мере, для сборок Gradle Java. У меня есть базовый образ Docker с предварительно кэшированными файлами Gradle Jar, но сборка Gradle вашего исходного кода запускает загрузку всех ваших зависимостей в кеш.

@cpuguy83 multi-stage не позволяет удалить скопированные колеса из полученного изображения, о чем говорит @awbacker . Таким образом, содержимое папки /wherever будет кэшировано, а размер изображения будет увеличен.

@BryanHunt Значит, частью вашего процесса сборки является загрузка файлов? Наверняка Gradle должен предоставить способ их кэширования без прохождения и фактического создания?

@ cpuguy83 Да, deps загружаются как часть сборки. В основном то же, что и Maven. Для справки: https://github.com/gradle/gradle/issues/1049

был ли где-то пиар для билд маунтов?

@graingert Здесь

👍 для этого. В Lunar Way мы хотим выполнить полный процесс «сборка -> тестирование -> сборка производственного образа» в одной сборке Docker, чтобы удалить зависимости сборки и тестирования с сервера CI. С многоэтапными сборками мы можем это сделать, но мы не можем получить результаты тестирования из промежуточного контейнера в процессе сборки. Поэтому мы должны сделать это в два этапа прямо сейчас — с отдельным файлом Dockerfile для сборки тестового образа, его запуска, а затем перейти только к этапу сборки рабочего образа, если тесты пройдут успешно.

Параметр -v в сборке докера позволит нам сохранить результаты теста в папке, смонтированной с сервера CI, и устранит необходимость в текущем двухэтапном процессе.

@tbflw По умолчанию сборка Docker не удаляет промежуточные контейнеры после неудачной сборки. Поэтому, если тест не пройден, вы можете получить результаты теста от них.

Пожалуйста , нам тоже очень-очень нужна эта функция! Прибегать к другим инструментам, таким как рокер или ветвящийся докер со специальными патчами, намного уродливее, чем нарушать евангельское понятие «мобильности сборки».

@BryanHunt @stepps @yngndrw другие тоже @awhitford
Один из способов кэширования зависимостей сборки — заставить вашу сборку работать, как пример многоэтапной сборки go в документации или python onbuild Dockerfile .
Вот пример, который я сделал, который, кажется, работает для maven. Скопирую сюда.

FROM maven
WORKDIR /usr/src/app
# /root/.m2 is a volume :(
ENV MAVEN_OPTS=-Dmaven.repo.local=../m2repo/
COPY pom.xml .
# v2.8 doesn't work :(
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

FROM openjdk
COPY --from=0 /usr/src/app/target/*.jar ./

Его необходимо настроить так, чтобы он загружал зависимости, прежде чем копировать остальную часть кодовой базы. Также убедитесь, что место, где хранятся ваши артефакты , не находится в VOLUME .

@sixcorners Это не работает для Gradle

@BryanHunt Этот файл Docker или этот подход не работает для Gradle? cpuguy83 спросил, есть ли способ загрузить зависимости без фактического выполнения сборки. Вы связались с задачей разрешения зависимостей. Не могли бы вы просто добавить файл build.gradle и запустить эту задачу?

@sixcorners Когда у вас много модулей, вам нужно реплицировать структуру каталогов вместе с файлами сборки и файлами свойств. Я полагаю, что это можно сделать, но я вижу, что это очень подвержено ошибкам.

Многоэтапность от @sixcorners — интересный трюк, и я видел, как он используется для разных менеджеров пакетов (например, npm, composer).

Однако существует проблема: всякий раз, когда список зависимостей изменяется COPY pom.xml в изображении этапа 0, слой удаляется, и, таким образом, весь кеш исчезает. Это означало, что всякий раз, когда разработчик что-либо меняет в pom (комментарий, зависимость 1 КБ), весь кеш должен быть загружен снова.

Для машин CI, создающих образ, а затем запускающих тесты с зависимостями, которые постоянно меняются, то есть тысячи и тысячи пакетов, которые необходимо повторно загружать (либо с прокси-сервера, либо из upsrea), что делает перестроение довольно медленным. Кэш на основе локальных файлов, смонтированный как том, намного быстрее.

Это также проблема, когда разработчики повторяют сборку образа, особенно если они используют медленное соединение. Хотя можно настроить локальный экземпляр Nexus и http_proxy к нему, но это имеет другие побочные эффекты (например, направление любого http-запроса через Nexus).

Многоэтапный — хороший обходной путь, но он не идеален.

Решение, которое мы собираемся попробовать, состоит в том, чтобы создать образ, создав наши общие библиотеки и сохранив кеш зависимостей. Затем этот образ станет нашим образом сборки для наших приложений. Это не идеально, но мы думаем, что стоит попробовать.

Однако существует проблема: всякий раз, когда список зависимостей изменяется, COPY pom.xml в образе этапа 0 приводит к тому, что слой отключается, и, таким образом, весь кеш исчезает. Это означало, что всякий раз, когда разработчик что-либо меняет в pom (комментарий, зависимость 1 КБ), весь кеш должен быть загружен снова.

@hashar обратите внимание, что функция COPY --from не ограничивается этапами сборки; из ссылки Dockerfile :

Опционально COPY принимает флаг --from=<name|index> , который можно использовать для установки исходного местоположения на предыдущую стадию сборки (созданную с помощью FROM .. AS <name> ), которая будет использоваться вместо отправленного контекста сборки пользователем. Флаг также принимает числовой индекс, присвоенный всем предыдущим этапам сборки, начатым с помощью инструкции FROM . _ В случае, если этап сборки с указанным именем не может быть найден, вместо него делается попытка использовать образ с таким же именем. _

Это позволяет вам _создать_ образ для ваших зависимостей, пометить его и использовать для копирования ваших зависимостей. Например:

FROM maven
WORKDIR /usr/src/app
# /root/.m2 is a volume :(
ENV MAVEN_OPTS=-Dmaven.repo.local=../m2repo/
COPY pom.xml .
# v2.8 doesn't work :(
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

docker build -t dependencies:1.0.0 .

И укажите использование изображения dependencies:1.0.0 для ваших зависимостей;

FROM openjdk
COPY --from=dependencies:1.0.0 /usr/src/app/target/*.jar ./

Или (просто очень простой пример для тестирования);

$ mkdir example && cd example
$ touch dep-one.jar dep-two.jar dep-three.jar

$ docker build -t dependencies:1.0.0 . -f -<<'EOF'
FROM scratch
COPY . /usr/src/app/target/
EOF

$ docker build -t myimage -<<'EOF'
FROM busybox
RUN mkdir /foo
COPY --from=dependencies:1.0.0 /usr/src/app/target/*.jar /foo/
RUN ls -la /foo/
EOF

В выводе сборки вы увидите:

Step 4/4 : RUN ls -la /foo/
 ---> Running in 012a8dbef91d
total 8
drwxr-xr-x    1 root     root          4096 Oct  7 13:27 .
drwxr-xr-x    1 root     root          4096 Oct  7 13:27 ..
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-one.jar
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-three.jar
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-two.jar
 ---> 71fc7f4b8802

Я не знаю, упоминал ли кто-нибудь об этом варианте использования (я кратко просмотрел страницу), но установка сокета аутентификации SSH в контейнер сборки значительно упростила бы использование зависимостей, развернутых через частные репозитории git. Будет меньше необходимости в шаблонах внутри Dockerfile в отношении копирования ключей на неокончательных этапах сборки и т. д.

buildkit имеет встроенную поддержку git
https://github.com/moby/buildkit

Решение.
Создайте сценарий bash (~/bin/docker-compose или подобный):

#!/bin/bash

trap 'kill $(jobs -p)' EXIT
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &

/usr/bin/docker-compose $@

И в Dockerfile с помощью socat:

...
ENV SSH_AUTH_SOCK /tmp/auth.sock
...
  && apk add --no-cache socat openssh \
  && /bin/sh -c "socat -v UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:172.22.1.11:56789 &> /dev/null &" \
  && bundle install \
...
or any other ssh commands will works

Затем запустите docker-compose build

Чтобы добавить еще один вариант использования в кучу. Я использую Docker для Windows для создания файловой системы для сборки встроенной системы Linux в одном контейнере, и я хотел бы поделиться ею с другими контейнерами на этапе их сборки. Я взаимодействую с этим контейнером, меняю конфигурацию, перестраиваю и т. д., поэтому выполнение сборки в Dockerfile и использование многоэтапных сборок не очень подходят, так как я потеряю добавочные сборки. Я хочу кэшировать свои предыдущие артефакты сборки, так как для чистой сборки требуется около 1,5 часов. Из-за того, как Windows работает с символическими ссылками, я не могу выполнить сборку в томе, смонтированном на хосте, поэтому я использую именованные тома. В идеале я хотел бы использовать эти именованные тома на этапах сборки других моих образов; так как на данный момент мне нужно создать tar вывода сборки (около 4 ГБ), а затем сделать копию докера, чтобы сделать ее доступной на хосте Windows для последующих сборок.

В случае python, когда мы pip install package , он и его зависимости загружаются в папку кеша, а затем устанавливаются в пакеты сайта.
В качестве хорошей практики мы используем pip --no-cache-dir install package , чтобы не хранить мусор/кеш в текущем слое. Но для лучшей практики желательно поместить папку кэша вне контекста сборки. поэтому время сборки -v поможет.
некоторые пользователи, упомянутые выше, используют COPY . /somewhere/in/container/ , это нормально для пользовательского приложения или файлов, но не для кеша. потому что COPY создает еще один слой как свой собственный, и удаление кешей в более поздних слоях не будет полезным. другой плохой побочный эффект заключается в том, что если кеш изменился, когда мы используем COPY, контекст изменился, и следующие слои станут недействительными и будут принудительно перестроены.

@wtayyeb Если у вас есть Dockerfile, который запускается pip install ... только при изменении файла требований, то время сборки -v не кажется таким важным, поскольку требования меняются не так часто, как приложения при сборке.

@wtayyeb Вы можете использовать многоэтапный Dockerfile, чтобы иметь как кеш, так и компактный образ. То есть используйте образ установщика для установки python в какой-либо каталог, а затем для вашего окончательного образа используйте COPY --from для передачи только необходимых файлов python без каких-либо артефактов установки или даже самого pip.

@manishtomar , спасибо, да и нет! В чистом случае все зависимости загружаются снова, собираются и преобразуются в колеса и кэшируются, а затем устанавливаются в среду назначения. Так что, если кто-то поместит туда требования, это будет разовая работа. Но если обновляется одна крошечная зависимость, все зависимости должны быть повторно загружены, перестроены, перекручены и повторно кэшированы, чтобы их можно было использовать.
При использовании CI для создания и тестирования ваших библиотек и приложений в матрице из нескольких заданий умножьте вышеуказанную работу на количество одновременных заданий на вашем сервере CI, и вы получите повышение iowait до более чем 3 с и среднюю нагрузку выше 15 даже с твердотельными накопителями. (эти цифры реальны для 2 одновременных сборок и приложения с ~ 20 зависимостями) Я думаю, что pip cache делает это правильно, избегая повторной загрузки, повторной сборки и повторного запуска готовых пакетов. а без bind -v мы теряем время и ресурсы сервера.

@ibukanov , спасибо. Я использую многоэтапный Dockerfile для создания пакетов приложений и использую их позже. Это помогло бы, если бы у меня был только один файл Dockerfile и я хотел бы собрать его несколько раз, но что, если бы было несколько файлов Dockerfile, и каждый из них собирался для версии python (на данный момент 2.7,3.6), а также имел несколько c-расширений, которые необходимо построить для выбранного базового образа? как насчет абзаца выше?

@thaJeztah Ваше предложение отличное, и оно сэкономит нам некоторое время, однако в случае кэшей сборки мы действительно не хотим копировать что-либо из другого изображения.
Почему мы не можем получить доступ к другому изображению без его копирования?

@thedrow мой пример был с функциями, которые есть в настоящее время; взгляните на предложение RUN --mount (https://github.com/moby/moby/issues/32507), которое может быть ближе к вашему варианту использования.

Читая вышеприведенную ветку, я вижу большое количество людей, пытающихся найти кладжи, чтобы исправить пробел в базовой функциональности в процессе сборки докера. Я не вижу веских аргументов в пользу переносимости без обязательного смешения монтирования хоста с монтированием образа — аргументы, которые откровенно обманчивы и ленивы.

Я также являюсь пользователем контейнера gentoo и был перенаправлен с https://github.com/moby/moby/issues/3156 , что является вполне допустимым вариантом использования этой отсутствующей функциональности.

Все, что мне действительно нужно, — это возможность монтировать содержимое другого образа во время сборки, чтобы не раздувать мои образы.

@kbaegis звучит как точное совпадение с функцией, предложенной в https://github.com/moby/moby/issues/32507 .

Конечно. Этот был нереализованным P3 в отставании только один год, а не 3 года.

Похоже, что https://github.com/projectatomic/buildah на самом деле довольно быстро превзойдет сборку докеров по этой базовой функциональности. Думаю, я просто переключу свой конвейер, как только это произойдет.

@kbaegis , что вы пришли сюда, чтобы добавить к этому обсуждению? Вы описали вариант использования, который _точно_ соответствует другому предложению;

Все, что мне действительно нужно, — это возможность монтировать содержимое другого образа во время сборки, чтобы не раздувать мои образы.

Это с открытым исходным кодом, вещи не появляются волшебным образом.

Что я хочу добавить к обсуждению?

Вкратце, что я ухожу от этого набора инструментов. Я уверен, что это ценная информация для команды разработчиков, так как я уверен, что я не одинок.

Ледяная скорость и низкий приоритет для поддержки этого варианта использования (и любого надежного обходного пути, обеспечивающего эту функциональность) вынудили меня использовать другие инструменты, и я отказываюсь от этого конвейера сборки из-за отсутствия функциональности.

У меня есть (перефразировать, я уверен) вариант использования, который нужно добавить. #32507 может подойти лучше.

Я создаю образ докера для некоторых конвейеров биоинформатики. Для некоторых инструментов требуется наличие некоторых баз данных до их компиляции/установки (пожалуйста, не спрашивайте, это не мой код ). Эти базы данных весят как минимум 30 ГБ.

Во время выполнения я, конечно, намереваюсь, чтобы эти базы данных были смонтированы томами -v . К сожалению, я не могу сделать это в процессе сборки, не «запекая» их, что приводит к довольно неприличному размеру изображения.

@draeath взгляните на https://github.com/grammarly/rocker . Он уже поддерживает прекрасную инструкцию MOUNT.

@draeath также, проверьте Buildah, он поддерживает монтирование по умолчанию, потому что он настроен больше как инструмент программирования. Также поддерживает монтирование с Dockerfile:

https://github.com/projectatomic/buildah

Спасибо обоим @fatherlinux и @lig - это поможет мне выполнить мою задачу. Я все еще думаю, что мне не нужно отклоняться от проекта, чтобы сделать это, и все равно хотелось бы увидеть это и # 32507 реализованным;)

Я пришел сюда через поиск в Google, чтобы попросить ту же функцию, тома во время «сборки докера», а не во время «запуска докера».

У нас есть встроенная система, которая содержит процессор. Производитель предоставляет инструменты для создания образа системы и последующего переноса образа в ЦП. Этот инструментарий принадлежит мне третьей стороной, и я не могу его изменить. Производитель также вряд ли будет переделывать его по моей просьбе.

Я хочу создать образ докера, который сначала выполняет «сборку образа прошивки», а затем имеет возможность создавать контейнеры, которые просто передают образ прошивки на свежие готовые печатные платы. Dockerfile может выглядеть так:
----------[ Отрежь здесь ]----------
FROM base-image как строитель
КОПИРОВАТЬ источник
RUN build-src

ИЗ базового образа в качестве прошивальщика
КОПИРОВАТЬ --from=Builder build-artifacts
RUN cpu-build-and-flash --build-only
----------[ Отрежь здесь ]----------
К сожалению, шаг cpu-build-and-flash требует доступа к целевому устройству через шину USB, даже если он не собирается передавать образ прошивки на устройство. Таким образом, мне нужно взять «-v /dev/usb/bus:/dev/usb/bus» из команды «docker run» и вместо этого использовать его в сборке.

Понятно, что сейчас это невозможно.

Обходной путь, который я использую, заключается в том, чтобы вручную создать мигающий образ с помощью «контейнера докеров», зафиксировав контейнер в образе. Я бы предпочел просто установить шину USB во время сборки.

Обновление для всех, кто заинтересован: недавно я успешно перестроил всю свою трубу с помощью buildah. В настоящее время у меня есть два конвейера сборки, работающих параллельно, и конвейер oci/buildah генерирует образы меньшего размера (в моем случае, в частности, удаление /usr/portage, маскируя его другим монтированием).

И, наконец, эта функция здесь: https://github.com/docker/docker-py/issues/1498 .

Но мне нужны тома RW для кеша сборки

Сб, 28 апр 2018, 17:29 Коренберг Марк, уведомления@github.com написал:

И, наконец, эта функция здесь: docker/docker-py#1498.
https://github.com/docker/docker-py/issues/1498

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/14080#issuecomment-385188262 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAZQTJodLCCzyDdPFtNiIUZ_z85YvLWbks5ttJjagaJpZM4FIdOc
.

Я также хотел бы видеть эту функцию (с возможностью записи), чтобы файл результатов модульного теста можно было экспортировать во время многоэтапного процесса сборки в конвейере CI. Чтобы соответствовать духу переносимости сборки, если ключ -v не был предоставлен, файл просто был бы записан внутри тестового образа на этом этапе.

Идеальная цель состоит в том, чтобы один раз собрать, один раз протестировать и по-прежнему иметь файл результатов, переданный хост-системе, даже в случае (и особенно в случае), когда тесты не пройдут, остановив сборку.

Да, пожалуйста. Весь день.

Не совсем актуально, но мы переносим часть нашей инфраструктуры развертывания, и нам нужен способ копировать файлы из образа после сборки. Следующее помогло:

docker build -t x .
ID=$(docker create x)
docker cp $ID:/package.deb .
docker rm $ID

Он должен был быть уже добавлен, когда был представлен многоэтапный файл докера. В конце концов, все столкнутся с этой проблемой, как только они начнут запускать модульные тесты как этап в многоэтапном файле докера, особенно в случае конвейеров сборки CI. Мы также сталкиваемся с этой проблемой, когда нам приходится публиковать отчеты о модульных тестах в VSTS. Уже применяя обходной путь, упомянутый @hoffa . Но в конце концов это обходной путь и усложняет ситуацию.

Должны ли мы сделать другую проблему для людей, которым нужны тома времени сборки для кэша сборки?

@ajbouh Да, наверное, на https://github.com/moby/buildkit/issues

См. https://github.com/moby/moby/issues/32507#issuecomment -391685221

В среду, 23 мая 2018 г., 19:22 Акихиро Суда, [email protected] написал:

@ajbouh https://github.com/ajbouh Да, наверное, в
https://github.com/moby/buildkit/issues

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/14080#issuecomment-391566368 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAAcnSqNoVc4j34ElECy53gIfPecQFKfks5t1hlkgaJpZM4FIdOc
.

Хотя вы не можете добавлять тома во время сборки, вы можете добавлять хосты, поэтому теперь я создаю все свои образы докеров с чем-то вроде --add-host yum-mirror:$MIRROR_IP , который обслуживает зеркало yum, которое мои образы сборки затем обнаруживают с помощью оболочки вокруг ням. Удобно, когда мой проект меняет зависимости много раз в день, а я не в сети или с плохим соединением (часть проекта включает в себя обновление и очистку его многочисленных зависимостей).

Меня бесит сопротивление Докера решению этой проблемы.

Недавно была объединена экспериментальная поддержка buildkit, с возможностью RUN --mount=<opts> <command> .

ссылка на примечание @cpuguy83 : https://github.com/moby/buildkit/pull/442

@glensc @cpuguy83 Когда можно ожидать релиза этой объединенной функции?

+1

RUN --mount не поддерживает объем, поэтому такие вещи, как https://github.com/avsm/docker-ssh-agent-forward , остаются невозможными во время сборки, какое решение для этого?

@peter-edge https://github.com/moby/buildkit/pull/655

docker build --secret наконец доступен в Docker 18.09 https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

Можем ли мы закрыть этот вопрос?

Насколько я могу судить, --secret нельзя использовать для кэширования.

@AkihiroSuda RUN --mount в целом выглядит как что-то, что может подойти для решения этой проблемы.

Да, я полагаю, что RUN --mount=type=cache (для объема кеша) и --mount=type=secret с docker build --secret (для секретного тома) почти покрывают проблему.

@AkihiroSuda , так что было бы неплохо увидеть рабочий пример, решающий исходную проблему.

@AkihiroSuda Из статьи (https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066) я видел 2 варианта использования mount во время сборки: Secret и SSH

[Секрет]

docker build --secret id=mysite.key,src=path/to/mysite.key .
RUN --mount=type=secret,id=mysite.key,required <command-to-run>

[SSH]

RUN --mount=type=ssh git clone [email protected]:myorg/myproject.git myproject

Есть 2 других варианта использования (которые я помню), которые не объясняются, как использовать ни в статье, ни в этом выпуске:

1) [Кэш] RUN --mount=type=cache
2) Тома в целом (например, для монтирования SSL-сертификатов или в случае больших томов, которые должны использоваться при сборке, но не включаться в сгенерированный образ и т. д.)

После того, как вариант использования монтирует рабочее пространство yarn перед запуском webpack

Вы все это можете..

RUN --mount=type=cache,from=<some image>,source=<path in from image>,target=<target>

Вы также можете заменить from=<some image> на from=<some build stage>

Вот надуманный пример:

# syntax=docker/dockerfile:1.0.0-experimental
FROM busybox as hello
RUN  echo hello > /hello.txt

FROM scratch
RUN --mount=type=cache,from=busybox,source=/bin,target=/bin --mount=type=cache,from=hello,source=/hello.txt,target=/tmp/hello.txt echo /tmp/hello.txt

Вот некоторая документация по этому поводу: https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md

Я согласен с @AkihiroSuda , это должно обрабатывать все случаи ... но, пожалуйста, сообщите нам, если это не так.

@AkihiroSuda @cpuguy83 : К сожалению, текущая реализация (сборка в докере 18.09) имеет проблемы с частными реестрами. На данный момент эти новые функции нельзя использовать, если вам нужно получать изображения через частный реестр. Смотрите мои тесты на https://github.com/moby/moby/issues/38303.

Я думаю, что это также будет использоваться для артефактов Jenkins, поэтому, например, если я создаю образ Docker и компилирую что-то внутри, я хочу получить некоторые артефакты, такие как вывод junit pytest

Это было бы очень полезно. Я действительно предпочел бы не добавлять --experimental для поддержки RUN --mount=type=cache /user/.cache/pip pip install (чтобы сэкономить массу пропускной способности индекса пакетов).

buildah bud ( buildah build-using-dockerfile ) имеет вариант --volume / -v :
https://github.com/containers/buildah/blob/master/docs/buildah-bud.md

buildah может запускать сборки без полномочий root без сокета докера.

Потому что загрузка пакетов из сети более воспроизводима?

Не нужно добавлять "--experimental", только "DOCKER_BUILDKIT=1" на клиенте.

Да, сетевые сборки более воспроизводимы, поскольку весь контекст находится в Dockerfile. Если вам нужно монтировать контекст с хоста, чтобы сборка работала, это плохой опыт.

Обратите внимание, что вы также можете смонтировать образ в сборку.

Да, сетевые сборки более воспроизводимы, поскольку весь контекст находится в Dockerfile.

Конечно, наличие RUN apt-get update в Dockerfile гарантирует, что у вас есть все шаги, необходимые для создания образа. Однако это невозможно воспроизвести, поскольку дополнительный контекст загружается от третьего лица. Единственная разница с монтированием заключается в том, что все внешние контексты действительно определены в Dockerfile.

Если вам нужно монтировать контекст с хоста, чтобы сборка работала, это плохой опыт.

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

Что я в конечном итоге делаю, так это многоэтапную сборку. Одно изображение, получающее контекст из сети, которое, таким образом, действует как снимок удаленного контекста. Затем отметьте, что с какой-то произвольной версией дата работает нормально. Например:

RUN apt-get update

docker build -t aptupdate-20190417

И на самом изображении:

FROM aptupdate-20190417
FROM somebaseimage

COPY --from=aptupdate-20190417 /var/apt /var/apt

Повторите с другим удаленным контекстом, и вы более или менее получите что-то воспроизводимое.

Или короче: Dockerfile, который зависит от доступа к сети, вероятно, не воспроизводим. Крепление может сделать его невоспроизводимым, но поможет воспроизвести некоторые варианты использования. Но я предполагаю, что в Dockerfile должны быть все шаги, необходимые для фактического создания образа, хотя, по моему опыту, большинство из них пишут свои собственные инструменты для инструментального создания образов.

Я имею в виду, RUN --mount=type=cache как раз для этого.
Или вы даже можете смонтировать из другого образа из реестра, и он будет загружен.

Ваши команды apt можно сделать (относительно) воспроизводимыми, закрепив то, что вы хотите получить.
Но если вы действительно хотите контролировать все биты, то почему вы используете apt в своей сборке? Хранение этого на хосте сборки невоспроизводимо и легко ломается от хоста к хосту.
Хранение его в реестре неплохо, если не считать потенциального сбоя сети... что, конечно, является справедливой критикой.

-v на buildah и форк redhat был явно отклонен здесь, потому что он слишком широкий... не сказать, что он бесполезен, но он легко ломается от хоста к хосту, что противоречит дизайну docker build .
Между тем причина, по которой RH добавил его (или, точнее, почему они решили работать над этим), заключалась в том, чтобы иметь возможность монтировать учетные данные RHEL в среду сборки.

Да, сетевые сборки более воспроизводимы, поскольку весь контекст находится в Dockerfile. Если вам нужно монтировать контекст с хоста, чтобы сборка работала, это плохой опыт.

Я категорически не согласен. Сеть может быть отключена или скомпрометирована; в этом случае локальный кеш предотвращает сбой всей сборки, когда Интернет не работает.

Я мог бы указать volumes: один раз в моем файле docker-compose.yml; но вместо этого нужно сделать DOCKER_BUILDKIT=1 и добавить RUN --mount=type=cache в файлы Dockerfiles, управляемые вверх по течению? Почему?

Со сборками CI мы говорим о нетривиальном количестве ненужных повторных загрузок от десятков до тысяч пакетов (десятки или сотни раз в день), которые могут быть просто кэшированы при монтировании тома (в сборке, которая работает без полномочий root без возможность запуска привилегированных контейнеров с собственными томами на хосте).

Индексы пакетов во многих случаях щедро поддерживаются за счет пожертвований. Тратить эти деньги на пропускную способность, чтобы удовлетворить какое-то ложное представление о воспроизводимости, основанное на ложном убеждении, что удаленные ресурсы являются более воспроизводимым кешем компонентов сборки, ужасно неприятно.

Пожалуйста, просто добавьте --volume , чтобы мой docker-compose.yml работал.

Пожалуйста, просто добавьте --volume, чтобы мой docker-compose.yml работал.

Заставить вашу «докер-композицию» просто работать — это наоборот.
docker-compose потребители этого проекта, а не наоборот.

docker-compose взаимодействует с сокетом докера. docker-compose YAML — это консолидированный способ хранения параметров контейнера (которые можно преобразовать в определения модулей k8s (которые в некоторой степени поддерживает podman)). Как мне указать DOCKER_BUILDKIT=1 воспроизводимым образом? Я мог бы воспроизвести build_volumes: в файле docker-compose.yml.

Когда я — в моем скрипте сборки CI, который запускается n раз в день — создаю образ, например, вызывая docker-compose build (например, с помощью ansible) или packer (вместо buildah и podman), я иметь несколько целей:

• Экономьте ресурсы / Не тратьте ресурсы впустую
  
  
  
  • Не перезагружайте постоянно ОС и пакеты для каждого языка.
  
  
  • Сохраните ресурсы полосы пропускания моей организации в файле package index.
  
  
• Гарантия доступности
  
  
  
  • Он должен / должен работать в автономном режиме
  
  
  • Он должен зависеть от как можно меньшего количества компонентов
  
  
• Обеспечение целостности сборки
  
  
  
  • Возможность воссоздать одно и то же изображение с теми же параметрами
  
  
  • Изолируйте вариации / Создавайте воспроизводимые сборки
  
  
  • Мы не контролируем удаленные ресурсы, такие как индексы пакетов.
  
  
  • Мы не контролируем сетевой путь
    
    
    
    
    
    • DNSSEC и DNS через HTTPS, вероятно, реализованы неправильно.
    
    
    
  
  
  • Мы можем быть забанены и довольно ограничены в скорости
  
  
  • Мы должны использовать подписанные контрольные суммы для проверки подписанных ресурсов.
    
    
    
    
    
    • Авторизация для доступа и подписи ключами где-то делегирована
    
    
    
    • Переменные ENViron доступны для всех процессов в пространстве имен контейнера.
    
    
    
    • Монтирование тома во время сборки — это один из способов обмена ключами, необходимыми только во время сборки (без их утечки в кеш образа).
    
    
    
  
  
• Держите сборки быстро
  
  
  
  • Кэшировать и запоминать частые операции.
  
  
  • Кэши добавляют точки отказа, потенциальную дисперсию и риск невоспроизводимости.
    
    
    
    
    
    • Кэш прокси-сервера HTTP(S!)
    
    
    
    • Кэш прикладного уровня по сети
    
    
    
    • Кэш локальной файловой системы
    
    
    
  
  
  • Реализовать тупой, очищаемый кэш без внешних зависимостей.
    
    
    
    
    
    • Кэш локальной файловой системы
    
    
    
  
  

Если мне нужно очистить том кеша, я могу очистить том кеша.

0. Статус-кво

RUN pip install app && rm -rf /root/.cache

• Возможно сегодня
• O(n_builds): использование пропускной способности
• Не будет работать в автономном режиме: зависит от сети
• Более медленные перестройки

А. Копии

COPY . /app/src/app
COPY .cache/pip /app/.cache/pip
RUN pip install /app/src/app \
    && rm -rf /app/.cache/pip

• Возможно сегодня
• ~O(1) пропускная способность индекса пакета
• O(n): при каждой сборке (* ONBUILD )
  
  
  
  • Копирует кеш
  
  
  • Разархивирует пакеты
  
  
  • Удаляет кеш
  
  
• Работает в автономном режиме
• Более медленные перестройки

B. Разветвите и измените каждый файл Dockerfile из восходящего потока, чтобы добавить RUN --mount=type=cache и установить переменную среды.

# Fork by copying to modify every pip install line
RUN --mount=type=cache /app/.cache/pip pip install /app/src/pip

$ DOCKER_BUILDKIT=1 docker build . [...]

• Возможно сегодня
• Это уже приводит к невоспроизводимости: есть параметр extra-Dockerfile, extra-docker-compose.yml, который вносит дисперсию в вывод: именованный встроенный образ.
• Документы: как очистить кеш --mount=type=cache (?)
• ~O(1) пропускная способность индекса пакета
• Работает в автономном режиме
• Быстрое восстановление

C. Укажите том, который монтируется во время сборки.

С.1. билдах

$ buildah bud -v .cache/pip:/app/.cache.pip

• Возможно сегодня
• Также вводит невоспроизводимость
• Документы: как очистить кеш
• ~O(1) пропускная способность индекса пакета
• Работает в автономном режиме
• Быстрое восстановление

С.2. докер (что запрашивает эта проблема)

C.2.1 интерфейс командной строки докера

$ docker build -v .cache/pip:/app/.cache.pip

• Сегодня невозможно
• Также вводит невоспроизводимость
• Документы: как очистить кеш
• ~O(1) пропускная способность индекса пакета
• Будет работать в автономном режиме
• Быстрое восстановление

C.2.2 создание докера

services:
  app:
    image: imgname:latest
    build: .
    build_volumes:  # "build_volumes" ?
    - ./.cache/pip:/app/.cache/pip

$ docker-compose build

• Сегодня невозможно
• Также вводит невоспроизводимость
• Документы: как очистить кеш
• Потребуется пересмотр схемы docker-compose.
• ~O(1) пропускная способность индекса пакета
• Будет работать в автономном режиме
• Быстрое восстановление

...

• КОПИРОВАТЬ || REMOTE_FETCH || читать()
  
  
  
  • Какие из них наиболее воспроизводимы?
  
  

:point_up: Просто напоминание. Вы можете закрепить загруженный файл, проверив его контрольную сумму. Некоторые менеджеры пакетов, такие как pip, также поддерживают это.

@westurner Спасибо за подробное объяснение.

Я думаю, что следующее будет похоже на ваш случай B, но вы можете очистить кеш, и он будет похож на ваш случай C2 (я думаю, что вы просите):

_docker-compose.yml:_

services:
  my-cache:
    build: ./my-cache
    image: local/my-cache

  my-image:
    build: ./my-image

_мой-кэш/Dockerfile:_

FROM python

RUN pip install app

_my-image/Dockerfile:_

FROM my-repo/my-image

RUN --mount=target=/export,type=bind,from=local/my-cache

RUN pip install /app/src/app

(https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run---mounttypecache)

Вы можете создать изображение кеша с помощью:

docker-compose build my-cache

Команда RUN --mount=target=/export,type=bind,from=local/my-cache должна быть привязана к изображению. Если вы хотите обновить кеш, вы можете удалить и перестроить образ кеша.

Если это все еще использует кеш в RUN --mount... , вы можете использовать файл .env с версией, включите версию в image: local/my-cache:$MY_VERSION и from=local/my-cache:$MY_VERSION (она должна быть включен в качестве аргумента сборки).

Вы можете включить сервис my-cache в другой файл docker-compose , если не хотите, чтобы он находился в том же файле, что и ваши основные сервисы.

Вам все равно нужно будет использовать DOCKER_BUILDKIT=1 (как в вашем случае B, но я думаю, что это не будет необходимо в будущих версиях), и это все равно не будет воспроизводимо (но ваш случай C2 тоже).

Какой штраф вы видите, если он не воспроизводим? Если вы поместите образ кеша local/my-cache в концентратор докеров (с другим именем репо) или в частный реестр и будете использовать версии для каждой сборки (это создаст другой кеш), при этом одна и та же версия всегда будет иметь один и тот же кеш, разве это не сделает его воспроизводимым ? Вам даже не нужно включать службу в файл docker-compose и вызывать команду сборки. (Докер-хаб должен быть доступен из сети, но я полагаю, что то же самое для других ваших образов, и после того, как вы загрузите один раз, он больше не понадобится, если только вы не создадите новую версию с новым кешем)

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: я не тестировал приведенный выше код.

@Yajo Поддержка контрольной суммы в pip изначально была реализована в «peep», а затем объединена в pip. Вы можете добавить известные хорошие хэши как фрагменты URL-адресов в записи файла требований pip. (В этом году в проекте PyPA выделено финансирование для улучшения безопасности; поддержка TUF (The Update Framework; точно так же, как Docker Notary) в PyPI запланирована на конец этого года.) Правильная загрузка pip и PyPI (с ключами и доверием) в образах докеров вероятно, будет темой позже в этом году.
(изменить; немного OT, но для заинтересованных) https://discuss.python.org/t/pypi-security-work-multifactor-auth-progress-help-needed/1042/

@lucasbasquerotto Спасибо за вашу помощь. Это значительно сложнее, чем просто указать --volume во время сборки. А именно, кажется, требуется:

• Указание DOCKER_BUILDKIT=1 в оболочке оболочки docker build
• Изменение любой/каждой вышестоящей инструкции RUN Dockerfile с помощью (редактировать) RUN --mount=type=cache и аргументов
• Доступ для чтения/записи к другому образу? Изменчивость! Или указанный кеш заморожен с вероятно устаревшими версиями?

Если я могу КОПИРОВАТЬ файлы с хоста или указать параметры времени сборки, которые не хранятся где-либо еще, я не вижу, как монтирование тома во время сборки становится менее воспроизводимым?

КОПИРОВАТЬ || REMOTE_FETCH || читать()

• Какие из них наиболее воспроизводимы?

@вестернер

Указание DOCKER_BUILDKIT=1 в окружении оболочки сборки докеров

Если вы используете docker-compose , как я видел в других ваших сообщениях, и если вы запускаете его из контейнера, например:

$ sudo curl -L --fail https://github.com/docker/compose/releases/download/1.24.0/run.sh -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose

Затем вы можете отредактировать загруженный файл в /usr/local/bin/docker-compose , чтобы использовать эту переменную env. Меняться от:

exec docker run --rm $DOCKER_RUN_OPTIONS $DOCKER_ADDR $COMPOSE_OPTIONS $VOLUMES -w "$(pwd)" $IMAGE "$@"

к

DOCKER_BUILDKIT=1
exec docker run --rm $DOCKER_RUN_OPTIONS $DOCKER_ADDR $COMPOSE_OPTIONS $VOLUMES -w "$(pwd)" --env DOCKER_BUILDKIT=$DOCKER_BUILDKIT $IMAGE "$@"

Это очень простое изменение, и оно прозрачно для тех, кто запускает команду.

_(Если вы не работаете как контейнер, вышеизложенное не применяется)_

Изменение любой/каждой инструкции RUN восходящего файла Dockerfile с помощью RUN --cache и args

В случае, который я выставил, это было бы RUN --mount=type=bind... , но в любом случае необходимость изменить Dockerfile также плохая ИМО. Вариант -v действительно был бы намного лучше и прозрачнее .

Доступ для чтения/записи к другому образу? Изменчивость! Или указанный кеш заморожен с вероятно устаревшими версиями?

Когда вы привязываете образ, он, вероятно, создаст контейнер (или как бы там ни было имя с реплицированной файловой системой), и изменения, сделанные там во время сборки, не должны изменить исходный образ (это не имело бы смысла). Таким образом, если вы строите с использованием образа кеша с именем my-repo/my-cache:my-version в сборке, в следующей сборке он будет точно таким же (неизменяемость). Если вы хотите использовать более свежий кеш, вы можете создать новый образ с новой версией и использовать его, например my-repo/my-cache:my-new-version .

Какие из них наиболее воспроизводимы?

Я считаю воспроизводимым то, что будет точно таким же, даже если вы запустите его на другой машине. В этом смысле, если вы поместите образ в (безопасный и надежный) реестр докеров и никогда не измените этот образ, я бы счел его воспроизводимым (если у вас есть опасения по поводу подключения к Интернету, вы можете использовать частный реестр и получить к нему доступ внутри VPN или что-то в этом роде (сам никогда не пользовался частным реестром)).

Если команда COPY копирует кеш вашей машины, я не считаю ее воспроизводимой, потому что если вы запустите pip install (или apt-get или что-то еще) на другой машине в другое время, можете ли вы гарантировать что содержимое кеша будет одинаковым? Возможно, это может быть проблемой для вас. Возможно, нет.

С другой стороны, если у вас есть файлы, которыми вы владеете, в каком-то надежном месте, которым вы «владеете» (например, в корзине S3), загрузите эти файлы на свой компьютер и скопируйте эти файлы с помощью команды COPY, после чего вы сможете воспроизвести их из другого машина с теми же результатами (при условии, что файлы не изменились, а другая машина идентична предыдущей). Так что я бы считал это воспроизводимым. Это зависит от того, откуда поступают эти файлы и насколько вы их контролируете.

По правде говоря, я не считаю что-либо воспроизводимым на 100% во всех случаях (в конце концов, железо может дать сбой), но чем надежнее, тем лучше. Когда я говорю о воспроизводимости некоторого процесса, я в основном имею в виду, что его содержимое и результат одинаковы, и это будет включать в себя что-то, загруженное из сети, при условии, что содержимое не меняется с течением времени (я не рассматриваю возможность сетевого провал в данном случае).

Есть какая-то сетевая ошибка Docker, которая делает go mod download ненадежным внутри контейнера (по крайней мере, для приложений нашего размера), поэтому просто запускать его каждый раз, чтобы снова загрузить все мои GOPATH/pkg/mod не просто расточительно, а сломано. 🤷‍♀

Я мог бы избежать большого количества ненужного копирования файлов, если бы мог использовать --volume !

@kevincantu RUN --mount=type=cache должен покрывать ваш вариант использования

Для этого требуется хотя бы одна успешная загрузка модулей из сборки докера, и в этом конкретном случае я еще никогда такого не видел.

https://github.com/moby/moby/issues/14080#issuecomment -484314314 от @westurner — довольно хороший обзор, но я не смог заставить buildkit работать:

$ sudo docker -v
Docker version 19.03.1, build 74b1e89

$ sudo DOCKER_BUILDKIT=1 docker build .
Ä+Ü Building 0.1s (2/2) FINISHED                                                                                                                
 => ÄinternalÜ load build definition from Dockerfile                                                                                       0.0s
 => => transferring dockerfile: 407B                                                                                                       0.0s
 => ÄinternalÜ load .dockerignore                                                                                                          0.0s
 => => transferring context: 2B                                                                                                            0.0s
failed to create LLB definition: Dockerfile parse error line 8: Unknown flag: mount

Мои Dockerfile начинаются с # syntax=docker/dockerfile:experimental .

Я действительно хотел бы использовать его через docker-compose . Пробовал ENV DOCKER_BUILDKIT 1 в Dockerfile , а также передавать его из docker-compose.yml через ARG DOCKER_BUILDKIT , но все равно:

$ sudo docker-compose up --build
Building web
ERROR: Dockerfile parse error line 10: Unknown flag: mount

@lucasbasquerotto Как то, что вы предложили в https://github.com/moby/moby/issues/14080#issuecomment -484639378, будет переведено в установленную версию docker-compose?

Наконец, я даже не уверен, будет ли это охватывать мой вариант использования, возможно, некоторые из вас могут сказать мне, следует ли мне продолжать это. Я хочу использовать кэш времени сборки для локальной разработки, который сохраняется между сборками, чтобы при обновлении зависимостей приходилось загружать только новые. Поэтому я бы добавил RUN --mount=type=cache,target=/deps к Dockerfile и установил кеш менеджера зависимостей на /deps .

для создания докеров см. https://github.com/docker/compose/pull/6865 , который будет в предстоящем выпуске-кандидате компоновки

У меня есть еще один вариант использования... Я хочу создать контейнеры для руки на хосте x86_64 с настроенным binfmt. Для этого требуется, чтобы у меня был эмулятор статического процессора qemu для конкретной архитектуры в /usr/bin .

Мое текущее решение состоит в том, чтобы добавить qemu-arm-static в контейнер в виде файла, например:

FROM arm32v7/alpine:3.10
COPY qemu-arm-static /usr/bin/qemu-arm-static
RUN apk update && apk upgrade
RUN apk add alpine-sdk cmake
...

Более простым решением было бы монтировать мой файл только при необходимости внутри контейнера, например:
docker build -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static -t test:arm32v7 .
Это очень хорошо работает для запуска докеров, но мне не хватает этой функциональности для создания контейнеров.

Есть ли другое решение, как я могу собрать ARM-контейнер на хостах x86_64, или мы можем разрешить тома во время сборки, по крайней мере, в этом случае?

Последние ядра @jneuhauser позволяют статически загружать эти двоичные файлы, поэтому нет необходимости настраивать их каждый раз. Этого можно добиться, например, запустив образ linuxkit/binfmt в привилегированном режиме один раз после загрузки.

последние ядра позволяют статически загружать эти двоичные файлы, поэтому нет необходимости настраивать их каждый раз.

@alehaa Разве вам все еще не нужен статический двоичный файл эмулятора qemu внутри контейнера?

@cybe Это больше не требуется, если используется флаг F (что делает пакет linuxkit/binfmt ). Вы можете найти больше информации об этом здесь .

Может ли кто-нибудь предоставить рабочую настройку для опробования buildkit? Я не могу заставить его работать на Ubuntu. Моя установка выглядит следующим образом:

cat /etc/docker/daemon.json

{
  "experimental": true
}

Dockerfile

# syntax=docker/dockerfile:experimental

FROM ruby:2.6.3

RUN --mount=type=cache,target=/bundle/vendor

sudo docker -v

Докер версии 19.03.1, сборка 74b1e89

DOCKER_BUILDKIT=1 sudo docker build .

Ответ об ошибке от демона: строка ошибки синтаксического анализа Dockerfile 12: Неизвестный флаг: монтирование

sudo не несет с собой env vars, если вы не скажете ему sudo -E или не объявите переменную в sudo.

Я написал несколько слов об этой функции и создал несколько минимальных примеров, показывающих, как кэшировать

• bundler зависимости с использованием docker
• NPM зависимости с использованием docker-compose

Изменить: см. ниже

@cpuguy83 спасибо!

@thisismydesign извините, что испортил вам впечатление, но вы не можете --cache node_modules , его не будет в финальном изображении, поэтому ваше приложение не работает.

@glensc Черт, ты прав .. есть ли способ сделать кеш времени сборки частью окончательного изображения?

Честно говоря, я думал, что это будет рассмотрено для функции, рекламируемой как

позволяет контейнеру сборки кэшировать каталоги для компиляторов и менеджеров пакетов.

Вместо этого вы должны иметь возможность отображать ~/.npm… https://docs.npmjs.com/files/folders.html#cache

@thisismydesign

Однако вы можете использовать другое изображение в качестве кеша, либо создав его в своем Dockerfile, либо буквальное изображение, хранящееся где-то в реестре, и используйте COPY --from

FROM example/my_node_modules:latest AS node_modules

FROM nodejs AS build
COPY --from=/node_modules node_modules 
...

Это просто пример, который вы можете использовать для разных целей.

Тьфу, я ненавижу поднимать этот вопрос и вмешиваться сюда (тоже привет, друзья)

но у нас есть вариант использования для этого.

Есть ли хорошее место, где я могу принять участие, или звонок или список, к которому я могу присоединиться, чтобы получить здесь дайджест?

Кроме того, если нам нужно, чтобы кто-то вложил в это ресурсы, у меня есть 1 kris nova и небольшая команда, которую я, вероятно, смогу убедить взглянуть на это.

TLDR Могу ли я закодировать это, пожалуйста? Есть ли кто-нибудь, с кем я могу поговорить об этом?

_TLDR_ Могу ли я закодировать это, пожалуйста? Есть ли кто-нибудь, с кем я могу поговорить об этом?

Я не могу говорить за Docker, но у меня сложилось впечатление, что они не открыты для добавления монтирования томов в сборки (и что им, вероятно, следует закрыть эту проблему).

Многие варианты использования buildtime -v теперь покрываются buildkit. По крайней мере, это решило это для меня.

Тогда я проверю buildkit - у меня также есть хакерский bash, который выполняет свою работу, если кому-то интересно.

спасибо @unilynx

+1 к @unilynx при закрытии этой проблемы, buildkit также решил для меня проблемы с объемом времени сборки.

Бьюсь об заклад, если кто-то сбросит несколько ссылок и пример, мы сможем убедить наших друзей нажать блестящую кнопку закрытия.

(мне бы они тоже пригодились)

Вариант использования кэширования не решен для меня и многих других, поскольку объемы времени сборки с помощью buildkit отсутствуют в финальном образе.

Таким образом, я смог вытащить все свои артефакты сборки из временного тома, используемого в момент времени build , и снова восстановить образ с предыдущим кешем, используя этот bash, о котором я упоминал выше.

Я смог перестроить свой образ поверх самого себя, так что файловая система наложения захватила лишь небольшую дельту.

Я даже смог повторно использовать том для других образов во время сборки.

другие люди не в состоянии сделать это?

(кеш) маунты находятся в "экспериментальном" интерфейсе; описано в https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md (собирается отправиться на встречу, но я могу привести более подробные примеры)

спасибо @thaJeztah LMK , если я могу чем-то помочь :)

https://github.com/moby/moby/issues/14080#issuecomment-547662701

@thisismydesign извините, что испортил вам впечатление, но вы не можете --cache node_modules , его не будет в финальном изображении, поэтому ваше приложение не работает.

@thaJeztah Я не верю, что проблема выше решена. Хотелось бы взглянуть на некоторые примеры, где можно кэшировать, например, npm install во время сборки, что также позволит результирующему образу использовать кэшированную установку.

@kris-nova Я не решил эту проблему, но опять же, я не собираюсь использовать скрипты bash. Возможно, нам нужна новая проблема, но это довольно распространенный вариант использования, который, насколько мне известно, еще не решен.

@thaJeztah Вот несколько примеров использования монтирования кэша, показывающих, как окончательный образ не будет содержать монтирование, и здесь он не охватывает многие случаи использования кэширования во время сборки:

• https://github.com/c-hive/basics/tree/558fbd91d45e56e574ebb05fb8645268d5b01974/docker-build-cache
• https://github.com/c-hive/basics/tree/558fbd91d45e56e574ebb05fb8645268d5b01974/docker-compose-build-cache

Для npm: нельзя ли использовать монтирование кеша для каталога кеша npm (см. https://docs.npmjs.com/cli-commands/cache.html, обычно ~/.npm )?

@ankon Это может сработать, спасибо, я попробую. Другой вариант использования, в котором я не уверен, — это Bundler и Ruby.

Поэтому я думаю (еще не проверял), что для Bundler вы можете, по крайней мере, избавиться от сетевой зависимости, используя том сборки в $BUNDLE_PATH , а затем во время сборки

bundle install
bundle package
bundle install --standalone --local

В основном это означает, что у вас есть кешированный каталог установки пакетов, оттуда вы упаковываете драгоценные камни в ./vendor/cache и переустанавливаете в ./bundle . Но это не экономит время на установку и сборку драгоценных камней, это может фактически увеличить шаг сборки.

Если вы хотите сохранить кешированные данные в образ, скопируйте их в образ из кеша.

Спасибо, однако, это все же скорее обходной путь, потому что

• вам нужно сделать дополнительную копию
• Я предполагаю, что у вас должны быть разные каталоги между средами сборки и запуска (вы не можете использовать каталог, в который вы смонтировали том во время сборки, верно?), поэтому он требует дополнительной настройки.

Я не знаю, сколько усилий потребуется, чтобы просто иметь встроенную опцию для монтирования того же тома в окончательный образ, но я почти уверен, что это облегчило бы использование. Это всего лишь 2 примера из скриптовых языков, где способ использования этого кеша был для меня неочевиден. Я вполне могу представить, что это всплывет и в других контекстах.

@thisismydesign Похоже, вы хотите иметь возможность совместно использовать кеш между сборкой и запуском?

buildkit — это решение только для Linux, что мы делаем в Windows?

@thisismydesign Я не уверен, почему вы ожидаете, что монтирование (кэш) останется в финальном изображении. Я не ожидал этого, и я не хочу иметь ~ 1 ГБ в моем образе только из-за использования монтирования кэша загрузки.

buildkit — это решение только для Linux, что мы делаем в Windows?

Вы можете использовать buildkit в Windows.

https://docs.docker.com/develop/develop-images/build_enhancements/

Возможно, вам будет проще установить настройку демона через Docker для пользовательского интерфейса Windows, а не задавать переменную среды перед выполнением.

@nigelgbanks вверху вашей ссылки:

Only supported for building Linux containers

О, извините, я просто предположил, что вы создавали контейнеры Linux в Windows.

@thisismydesign Похоже, вы хотите иметь возможность совместно использовать кеш между сборкой и запуском?

Это решило бы мой вариант использования кэширования, да.

Упрощение этой задачи может сэкономить миллионы повторных загрузок пакетов в CI.
строит в год.

Поддерживают ли какие-либо службы CI экспериментальные функции сборочного комплекта?

В субботу, 13 июня 2020 г., 14:08 Чаба Апаги, уведомления@github.com написал:

@thisismydesign https://github.com/thisismydesign Похоже на то, что
вы хотите иметь возможность совместно использовать кеш между сборкой и запуском?

Это решило бы мой вариант использования кэширования, да.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/14080#issuecomment-643657987 или
отписаться
https://github.com/notifications/unsubscribe-auth/AAAMNS6IEQDCO5F3LNHJK5TRWO6AJANCNFSM4BJB2OOA
.

Поддерживают ли какие-либо службы CI экспериментальные функции сборочного комплекта?

Должны ли они явно поддерживать это? Я использую gitlab-ci с buildkit, и он просто работает. В конце концов, это просто другой способ вызова «сборки докера».

Конечно, если вы не принесете свои собственные бегуны в gitlab, шансы получить попадание в кеш во время сборки в любом случае невелики.

Копирование с именованного этапа многоэтапной сборки — еще одно решение.

FROM golang:1.7.3 AS builder
COPY --from=builder

Но тогда локализация образа контейнера по-прежнему остается в основном нерешенной проблемой для планирования заданий CI.

Бегуны должны быть более липкими и делиться (промежуточными) изображениями в общей файловой системе, чтобы свести к минимуму ненужные запросы к (постоянно недофинансируемым) репозиториям пакетов.

Я только что попробовал buildkit , но это лишь незначительно улучшает мой рабочий процесс, которому на 100% поможет «реальный» объем или привязка монтирования к хосту.

Я использую docker build для кросс-компиляции старых версий glibc , которые затем должны быть частью новых контейнеров сборки, предоставляющих эти glibc для сборки и ссылки на них.

Теперь повторная загрузка исходников glibc решается привязкой монтирования (от buildkit ), архив доступен только для чтения, без проблем. Но у меня нет возможности получить доступ к каталогу сборки для анализа после неудачных сборок, так как контейнер взрывается по ошибке. (Если я перезапускаю его, чтобы получить к нему доступ, он перезапускает сборку, так что это не помогает).

Кроме того, я не понимаю, почему я должен прыгать через обручи, такие как создание нового контейнера из старого, только для того, чтобы избавиться от моего каталога сборки, где, если бы каталог сборки был бы монтированием в первую очередь, это было бы так легко. (Просто сделайте make install после сборки, и у меня будет чистый контейнер без каталога сборки и без загруженных исходников).

Так что я по-прежнему считаю, что это очень правильный запрос на добавление функции, который значительно облегчит нашу жизнь. Тот факт, что функция может быть использована не по назначению и может нарушить работу других функций, не означает, что ее следует избегать любой ценой. Просто считайте это дополнительным использованием более мощного инструмента.

Но у меня нет доступа к каталогу сборки для анализа после неудачных сборок.

Звучит как запрос функции для buildkit. Это определенно известная недостающая деталь.

Это можно было бы сделать сегодня, имея цель для извлечения «каталога сборки». Вы бы просто запустили это после неудачного запуска, все по-прежнему должно быть кэшировано, просто нужен последний шаг, чтобы получить данные.
Поймите, что это немного обходной путь.

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

Можете ли вы объяснить больше, что вы хотите / ожидаете здесь?

Можете ли вы объяснить больше, что вы хотите / ожидаете здесь?

В данном случае это просто желание убить 2 зайцев одним выстрелом:

• иметь простой способ доступа к промежуточным результатам от хоста (здесь «создать анализ каталогов»)
• убедитесь, что это место для хранения не загрязняет вновь созданный образ

Поскольку этот и все другие случаи, когда контейнер сборки (а также «сборка контейнера») должен сделать сборку как можно более безболезненной, можно было бы решить гораздо более элегантно, просто предоставив функциональность -v , у меня есть трудно понять сопротивление, чтобы обеспечить эту функцию. Помимо «кэш-осведомленной» функциональности buildkit , которую, по-видимому, предлагает buildkit, я могу рассматривать ее только как запутанный и громоздкий способ достижения именно этой функциональности, и то лишь частично. (И во многих случаях, когда кэширование является основной целью, она также может быть решена с помощью -v за счет необходимости привязывать смонтированный том к определенному контейнеру, пока он работает, но кеш с buildkit имеет те же ограничения.)

Можете ли вы объяснить больше, что вы хотите / ожидаете здесь?

Я использую многоэтапный процесс сборки, в котором сама среда сборки контейнеризирована, а конечным результатом является образ, содержащий только приложение и среду выполнения (без инструментов сборки).

Я бы хотел, чтобы промежуточный контейнер сборки Docker каким-то образом выводил файлы результатов модульного теста и покрытия кода в хост-систему в событиях как успешной сборки, так и неудачной сборки, без необходимости передавать их в выходной образ сборки. для извлечения (поскольку весь процесс сборки сокращается, если модульные тесты не проходят на более раннем этапе, поэтому в этой ситуации не будет выходного изображения, и именно тогда нам больше всего нужны результаты модульного теста) . Я полагаю, что если хост-том можно подключить к процессу сборки Docker, то внутренние тестовые команды могут направить свой вывод в смонтированную папку.

@mcattle
Действительно очень похоже на (одну из функций), которые мне нужны.
После перехода на buildah несколько дней назад я получил все необходимые функции и даже больше. Отладка моего билд-контейнера была бы совершенно невозможна без возможности гибкого входа в вышедший контейнер и ссылки на хост. Теперь я счастливый турист. (Извините, что разорвал вечеринку с «конкурентом», я бы с радостью удалил этот комментарий, если бы обиделся, но это было настолько эффективное решение для вариантов использования, представленных в этой теме, что я подумал, что должен упомянуть его) .

Нет ничего обидного в том, чтобы сказать, что другой инструмент лучше соответствует вашим потребностям.

Если что-то работает для вас, это замечательно.

Недостатки как сборщика v1 в Docker, так и сборщика buildkit довольно хорошо понятны в этом контексте, и рассматривается, как их устранить, желательно без необходимости прибегать к привязке монтирования от клиента.
Уведомления [email protected] написал:
«@мкэттл
Действительно очень похоже на (одну из функций), которые мне нужны.
С момента перехода на buildah несколько дней назад я получил все необходимые функции и даже больше. Отладка моего билд-контейнера была бы совершенно невозможна без возможности гибкого входа в вышедший контейнер и ссылки на хост. Теперь я счастливый турист. (Извините, что разорвал вечеринку с «конкурентом», я бы с радостью удалил этот комментарий, если бы это было оскорблением, но это было настолько эффективное решение для вариантов использования, представленных в этой теме, что я подумал, что должен упомянуть его) ».

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отмените подписку.

без необходимости прибегать к привязке монтирования от клиента.

Здесь я объясню, почему параметр -v во время сборки не прибегает к воспроизводимости и не жертвует ею больше, чем зависимость от сетевых ресурсов во время сборки.

https://github.com/moby/moby/issues/14080#issuecomment -484314314:

КОПИРОВАТЬ || REMOTE_FETCH || читать()

• Какие из них наиболее воспроизводимы?

Я собираюсь использовать buildah для времени сборки -v (и cgroupsv2).

@mcattle У меня было такое же требование. Я решил это с помощью маркировки .

Я собираюсь использовать buildah для времени сборки -v (и cgroupsv2).

Я серьезно подумываю о переходе с Ubuntu (у которого есть только докер) на Fedora (который заменил докер на podman/buildah) на нашем сервере сборки из-за поддержки «-v».

Кстати. Podman также поддерживает режим без рута, и до сих пор он казался полностью совместимым с Docker (за исключением различий в воздействии --user/USER и кэшировании изображений, которые возникают из-за использования режима без рута вместо запуска от имени пользователя root, как это делает демон Docker).

PS. в то время как cgroups v2 необходим для работы без root, поддержка этого больше касается времени выполнения контейнера, чем докера. Если вы используете CRun вместо RunC (как это делает Fedora), у вас будет поддержка cgroups v2. У RunC есть некоторая поддержка v2 и rootless в Git, но у меня были некоторые проблемы при тестировании его на Fedora (31) несколько месяцев назад.

РЕДАКТИРОВАТЬ: Ubuntu имеет podman/buildah/etc в Groovy, но не в последней версии 20.04 LTS, я думаю, что он импортирован из нестабильного Debian. Он не был перенесен в LTS, по крайней мере, пока. В то время как я думаю, что в Fedora с 2018 года.

@eero-t, возможно, вы могли бы описать свой вариант использования и то, чего не хватает в параметрах, которые в настоящее время предоставляет BuildKit, но которые не предназначены для них.