комплект для сборки
0.17.0
BuildKit — это набор инструментов для преобразования исходного кода для создания артефактов эффективным, выразительным и воспроизводимым образом.
Ключевые особенности:
Автоматический сбор мусора
Расширяемые форматы интерфейса
Параллельное разрешение зависимостей
Эффективное кэширование инструкций
Импорт/экспорт кэша сборки
Вложенные вызовы заданий сборки
Распределяемые рабочие
Несколько выходных форматов
Подключаемая архитектура
Выполнение без root-прав
Прочтите предложение от moby/moby#32925.
Вводная запись в блоге https://blog.mobyproject.org/introducing-buildkit-17e056cc5317.
Присоединяйтесь к каналу #buildkit в сообществе Docker Slack.
Примечание
Если вы посещаете этот репозиторий для использования функций Dockerfile, доступных только в BuildKit, таких как RUN --mount=type=(bind|cache|tmpfs|secret|ssh) , обратитесь к справочнику по Dockerfile.
Примечание
docker build по умолчанию использует Buildx и BuildKit, начиная с Docker Engine 23.0. Вам не нужно читать этот документ, если вы не хотите использовать полнофункциональную автономную версию BuildKit.
Используется
Быстрый старт
Изображение/Реестр
Локальный каталог
Докер-архив
Архив OCI
хранилище изображений контейнера
Создание Dockerfile с помощью buildctl
Создание Dockerfile с использованием внешнего интерфейса
Настройка Linux
Настройка Windows
Настройка macOS
Сборка из исходного кода
Изучение права бакалавра права
Изучение файлов Dockerfile
Выход
Кэш
Встроенное (объедините изображение и кеш)
Реестр (отправьте изображение и кеш отдельно)
Локальный каталог
Кэш действий GitHub (экспериментальный)
Кэш S3 (экспериментальный)
Кэш хранилища BLOB-объектов Azure (экспериментальный)
Сбор мусора
Экспортировать кэш
Согласованное хеширование
Метаданные
Активация системного сокета
Предоставить BuildKit как службу TCP
Балансировка нагрузки
Контейнеризация BuildKit
Подман
Нердктл
Кубернетес
Без демонов
Поддержка OpenTelemetry
Запуск BuildKit без root-прав
Создание мультиплатформенных образов
Элементы управления выводом цвета
Количество строк журнала (для активных шагов в режиме tty)
Настройка buildctl
Содействие
BuildKit используется в следующих проектах:
Moby & Docker ( DOCKER_BUILDKIT=1 docker build )
изображение
Облако OpenFaaS
интерфейс сборки контейнера
Tekton Pipelines (ранее Knative Build Templates)
инструмент сборки Sanic
ваб
Рио
Ким
МешочекКонтейнер
Докер сборка
Октето Облако
Земные файлы
Гитпод
Кинжал
окружение
Депо
Пространство имен
Уникрафт
ДевЗеро
дакк
Информацию о развертываниях Kubernetes см. в examples/kubernetes .
BuildKit состоит из демона buildkitd и клиента buildctl . Хотя клиент buildctl доступен для Linux, macOS и Windows, демон buildkitd в настоящее время доступен только для Linux и *Windows.
Последние двоичные файлы BuildKit доступны здесь для Linux, macOS и Windows.
Для демона buildkitd необходимо установить следующие компоненты:
бежать или бежать
Containerd (если вы хотите использовать работникаContainerd)
Запуск демона buildkitd : вам необходимо запустить buildkitd от имени пользователя root на хосте.
$ sudo buildkitd
Чтобы запустить buildkitd от имени пользователя без полномочий root, см. docs/rootless.md .
Демон buildkitd поддерживает два рабочих сервера: OCI (runc) иContainerd.
По умолчанию используется исполнитель OCI (runc). Вы можете установить --oci-worker=false --containerd-worker=true чтобы использовать работникаContainerd.
Мы открыты для добавления дополнительных бэкэндов.
Чтобы запустить демон buildkitd с использованием активации сокета systemd, вы можете установить файлы модулей buildkit systemd. См. Активацию сокета Systemd.
Демон buildkitd по умолчанию прослушивает API gRPC в /run/buildkit/buildkitd.sock , но вы также можете использовать TCP-сокеты. См. раздел «Предоставление BuildKit как службы TCP».
См. инструкции и примечания по адресу docs/windows.md .
Формула Homebrew (неофициальная) доступна для macOS.
$ Brew установить сборку
Формула Homebrew не содержит демона ( buildkitd ).
Например, Lima можно использовать для запуска демона внутри виртуальной машины Linux.
заварить установку limalimactl start template://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"
Чтобы собрать BuildKit из исходного кода, см. .github/CONTRIBUTING.md .
Справочную информацию о buildctl см. в этом документе.
Сборки BuildKit основаны на двоичном промежуточном формате, называемом LLB, который используется для определения графа зависимостей для процессов, выполняющих часть вашей сборки. tl;dr: LLB для Dockerfile — это то же самое, что LLVM IR для C.
Маршалируется как сообщения Protobuf
Одновременно исполняемый файл
Эффективное кэширование
Независимость от поставщика (т. е. языки, не относящиеся к Dockerfile, могут быть легко реализованы)
См. solver/pb/ops.proto для определения формата и см. ./examples/README.md для примеров приложений LLB.
В настоящее время для LLB реализованы следующие языки высокого уровня:
Dockerfile (см. «Изучение Dockerfiles»).
Сборочные пакеты
Мокерфайл
Гокерфайл
блдр (Pkgfile)
HLB
Файл Земли (Земной)
Грузовой причал (Ржавчина)
Никс
мопи (Питон)
энвд (жаворонок)
ворвань
Бас
kraft.yaml (Уникрафт)
r2d4/llb (шлюз JSON)
(откройте PR, чтобы добавить свой язык)
Интерфейсы — это компоненты, которые работают внутри BuildKit и преобразуют любое определение сборки в LLB. Существует специальный интерфейс под названием шлюз ( gateway.v0 ), который позволяет использовать любое изображение в качестве интерфейса.
Во время разработки интерфейс Dockerfile ( dockerfile.v0 ) также является частью репозитория BuildKit. В будущем это будет удалено, и Dockerfiles можно будет создавать с использованием внешнего образа.
buildctl сборка buildctl
--frontend=dockerfile.v0
--локальный контекст=.
--local dockerfile=.# сборка orbuildctl
--frontend=dockerfile.v0
--локальный контекст=.
--local dockerfile=.
--opt цель=foo
--opt build-arg:foo=bar --local предоставляет сборщику локальные исходные файлы от клиента. context и dockerfile — это имена, которые интерфейс Dockerfile ищет в контексте сборки и расположении Dockerfile.
Если Dockerfile имеет другое имя файла, его можно указать с помощью --opt filename=./Dockerfile-alternative .
Внешние версии интерфейса Dockerfile передаются на https://hub.docker.com/r/docker/dockerfile-upstream и https://hub.docker.com/r/docker/dockerfile и могут использоваться с интерфейсом шлюза. . Исходный код внешнего интерфейса в настоящее время находится в ./frontend/dockerfile/cmd/dockerfile-frontend , но в будущем он будет перемещен из этого репозитория (#163). Для автоматической сборки из основной ветки этого репозитория можно использовать образ docker/dockerfile-upstream:master или docker/dockerfile-upstream:master-labs .
сборка buildctl
--интерфейсный шлюз.v0
--opt source=docker/dockerfile
--локальный контекст=.
--local dockerfile=.
сборка buildctl
--интерфейсный шлюз.v0
--opt source=docker/dockerfile
--opt context=https://github.com/moby/moby.git
--opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.orgПо умолчанию результат сборки и промежуточный кеш остаются только внутри BuildKit. Для получения результата необходимо указать выходные данные.
buildctl build ... --output type=image,name=docker.io/username/image,push=true
Чтобы экспортировать образ в несколько реестров:
buildctl build ... --output type=image,"name=docker.io/username/image,docker.io/username2/image2",push=true
Чтобы экспортировать встраиваемый кэш вместе с изображением и отправить их вместе в реестр, для импорта кэша требуется тип registry , вы должны указать --export-cache type=inline и --import-cache type=registry,ref=... . Чтобы экспортировать кеш напрямую в локальную систему, вы должны указать --export-cache type=local . Подробности в Экспортном кэше.
построитьctl построить... --output type=image,name=docker.io/username/image,push=true --export-cache тип=встроенный --import-cache type=registry,ref=docker.io/username/image
Ключи, поддерживаемые выводом изображения:
name= : укажите имя(я) изображения.
push=true : нажать после создания изображения
push-by-digest=true : отправить безымянное изображение
registry.insecure=true : перейти в небезопасный реестр HTTP.
oci-mediatypes=true : использовать медиатипы OCI в конфигурации JSON вместо Docker.
unpack=true : распаковать образ после создания (для использования с контейнером)
dangling-name-prefix= : имя изображения с prefix@ , используется для анонимных изображений.
name-canonical=true : добавить дополнительное каноническое имя name@
compression= : выберите тип сжатия для вновь созданных и кэшированных слоев, gzip — значение по умолчанию. estargz следует использовать с oci-mediatypes=true .
compression-level= : уровень сжатия для gzip, estargz (0-9) и zstd (0-22)
rewrite-timestamp=true : перезаписать временные метки файла на значение SOURCE_DATE_EPOCH . См. docs/build-repro.md чтобы узнать, как указать значение SOURCE_DATE_EPOCH .
force-compression=true : принудительно применить опцию compression ко всем слоям (включая уже существующие слои)
store=true : сохраняет изображения результатов в хранилище изображений работника (например, контейнера), а также гарантирует, что изображение содержит все большие двоичные объекты в хранилище контента (по умолчанию true ). Игнорируется, если у работника нет хранилища изображений (например, работник OCI).
annotation. : прикрепите аннотацию с соответствующим key и value к построенному изображению.
Используя расширенный синтаксис, annotation- , annotation[ и оба в сочетании с annotation- позволяет точно указать, куда прикреплять аннотацию.
manifest (по умолчанию), manifest-descriptor , index и index-descriptor
platform , см. docs/multi-platform.md .
Дополнительную информацию см. docs/annotations.md .
Если требуются учетные данные, buildctl попытается прочитать файл конфигурации Docker $DOCKER_CONFIG/config.json . $DOCKER_CONFIG по умолчанию равен ~/.docker .
Локальный клиент скопирует файлы непосредственно на клиент. Это полезно, если BuildKit используется для создания чего-то другого, кроме образов контейнеров.
buildctl build ... --output type=local,dest=path/to/output-dir
Для экспорта определенных файлов используйте многоэтапные сборки с нуля и копируйте необходимые файлы на этот этап с помощью COPY --from .
... С нуля как testresultCOPY --from=builder /usr/src/app/testresult.xml . ...
buildctl build ... --opt target=testresult --output type=local,dest=path/to/output-dir
При многоплатформенной сборке в целевом каталоге будет создана подпапка, соответствующая каждой целевой платформе:
FROM busybox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROM ScratchCOPY --from=build /out /
$ buildctl построить
--frontend dockerfile.v0
--opt платформа=linux/amd64,linux/arm64
--output type=local,dest=./bin/release
$дерево ./bin
./бин/
└── выпуск
├── linux_amd64
│ └── привет-linux-amd64
└── linux_arm64
└── привет-linux-arm64 Вы можете установить platform-split=false , чтобы объединить файлы со всех платформ в один каталог:
$ buildctl построить
--frontend dockerfile.v0
--opt платформа=linux/amd64,linux/arm64
--output type=local,dest=./bin/release,platform-split=false
$дерево ./bin
./бин/
└── выпуск
├── привет-linux-amd64
└── привет-linux-arm64Экспортер Tar аналогичен локальному экспортеру, но передает файлы через архив.
buildctl build ... --output type=tar,dest=out.tar buildctl build ... --output type=tar > out.tar
# экспортированный архив также совместим со сборкой OCI specbuildctl ... --output type=docker,name=myimage | загрузка докера
buildctl build ... --output type=oci,dest=path/to/output.tar buildctl build ... --output type=oci > output.tar
Необходимо использовать работникаContainerd.
buildctl build ... --output type=image,name=docker.io/username/image ctr --namespace=изображения buildkit ls
Чтобы изменить пространство имен контейнера, вам необходимо изменить worker.containerd.namespace в /etc/buildkit/buildkitd.toml .
Чтобы показать локальный кеш сборки ( /var/lib/buildkit ):
buildctl du -v
Чтобы очистить локальный кеш сборки:
buildctl чернослив
См ./docs/buildkitd.toml.md .
BuildKit поддерживает следующие экспортеры кэша:
inline : встроить кеш в образ и вместе отправить их в реестр.
registry : поместите образ и кеш отдельно
local : экспорт в локальный каталог
gha : экспорт в кеш действий GitHub
В большинстве случаев вы захотите использовать inline экспортер кэша. Однако обратите внимание, что средство экспорта inline кэша поддерживает только режим min кэша. Чтобы включить режим max кэша, отправьте образ и кэш отдельно с помощью средства экспорта кэша registry .
Как inline экспортеры, так и экспортеры registry хранят кеш в реестре. Для импорта кеша в обоих случаях достаточно type=registry , поскольку указание формата кеша не требуется.
построитьctl построить... --output type=image,name=docker.io/username/image,push=true --export-cache тип=встроенный --import-cache type=registry,ref=docker.io/username/image
Обратите внимание, что встроенный кеш не импортируется, если не указан --import-cache type=registry,ref=...
Встроенный кэш встраивает метаданные кэша в конфигурацию изображения. Слои изображения останутся нетронутыми по сравнению с изображением без информации из кэша.
BuildKit, интегрированный в Docker ( DOCKER_BUILDKIT=1 docker build ), и docker buildx требуют указания --build-arg BUILDKIT_INLINE_CACHE=1 чтобы включить экспортер inline кэша. Однако для автономного buildctl НЕ требуется --opt build-arg:BUILDKIT_INLINE_CACHE=1 , и build-arg просто игнорируется.
построитьctl построить... --output type=image,name=localhost:5000/myrepo:image,push=true --export-cache type=registry,ref=localhost:5000/myrepo:buildcache --import-cache type=registry,ref=localhost:5000/myrepo:buildcache
--export-cache параметры:
type=registry
mode= : укажите слои кэша для экспорта (по умолчанию: min )
min : экспортировать только слои полученного изображения.
max : экспортировать все слои всех промежуточных шагов
ref= : укажите ссылку на репозиторий для хранения кеша, например docker.io/user/image:tag
image-manifest= : экспортировать ли манифест кэша как OCI-совместимый манифест изображения, а не список/индекс манифеста (по умолчанию: false , необходимо использовать с oci-mediatypes=true )
oci-mediatypes= : использовать ли медиатипы OCI в экспортируемых манифестах (по умолчанию: true , начиная с BuildKit v0.8 )
compression= : выберите тип сжатия для вновь созданных и кэшированных слоев, gzip — значение по умолчанию. estargz и zstd следует использовать с oci-mediatypes=true
compression-level= : выберите уровень сжатия для gzip, estargz (0-9) и zstd (0-22).
force-compression=true : принудительно применить параметр compression ко всем слоям.
ignore-error= : указывает, игнорируется ли ошибка в случае сбоя экспорта кэша (по умолчанию: false )
--import-cache параметры:
type=registry
ref= : укажите ссылку на репозиторий, из которого нужно получить кеш, например docker.io/user/image:tag
buildctl build ... --export-cache type=local,dest=path/to/output-dir buildctl build ... --import-cache type=local,src=path/to/input-dir
Структура каталога соответствует спецификации изображений OCI v1.0.
--export-cache параметры:
type=local
mode= : укажите слои кэша для экспорта (по умолчанию: min )
min : экспортировать только слои полученного изображения.
max : экспортировать все слои всех промежуточных шагов
dest= : каталог назначения для экспортера кэша.
tag= : укажите пользовательский тег изображения для записи в локальный индекс (по умолчанию: latest )
image-manifest= : экспортировать ли манифест кэша как OCI-совместимый манифест изображения, а не список/индекс манифеста (по умолчанию: false , необходимо использовать с oci-mediatypes=true )
oci-mediatypes= : использовать ли медиатипы OCI в экспортируемых манифестах (по умолчанию true , начиная с BuildKit v0.8 )
compression= : выберите тип сжатия для вновь созданных и кэшированных слоев, gzip — значение по умолчанию. estargz и zstd следует использовать с oci-mediatypes=true .
compression-level= : уровень сжатия для gzip, estargz (0-9) и zstd (0-22)
force-compression=true : принудительно применить параметр compression ко всем слоям.
ignore-error= : указывает, игнорируется ли ошибка в случае сбоя экспорта кэша (по умолчанию: false )
--import-cache параметры:
type=local
src= : исходный каталог для импортера кеша
tag= : укажите пользовательский тег изображения для чтения из локального индекса (по умолчанию: latest )
digest=sha256: : укажите явный дайджест списка манифестов для импорта.
построитьctl построить... --output type=image,name=docker.io/username/image,push=true --export-cache type=gha --import-cache тип=гха
Кэш действий GitHub сохраняет метаданные и слои кэша в службе кэша GitHub. В настоящее время этот кеш имеет ограничение по размеру в 10 ГБ, которое используется разными кешами в репозитории. Если вы превысите этот предел, GitHub сохранит ваш кеш, но начнет удалять его до тех пор, пока общий размер не станет меньше 10 ГБ. Слишком частая переработка кешей может привести к общему замедлению времени выполнения.
Аналогично использованию действий/кеша, кеши распределяются по ветвям, при этом ветки по умолчанию и целевые ветки доступны для каждой ветки.
Следующие атрибуты необходимы для аутентификации с помощью API службы GitHub Actions Cache:
url : URL-адрес сервера кэширования (по умолчанию $ACTIONS_CACHE_URL ).
token : токен доступа (по умолчанию $ACTIONS_RUNTIME_TOKEN )
Этот тип кеша можно использовать с действием Docker Build Push Action, где url и token будут установлены автоматически. Чтобы использовать этот бэкэнд на этапе встроенного run , вам необходимо включить mad-max/ghaction-github-runtime в свой рабочий процесс, чтобы предоставить доступ к среде выполнения.
--export-cache параметры:
type=gha
mode= : укажите слои кэша для экспорта (по умолчанию: min )
min : экспортировать только слои полученного изображения.
max : экспортировать все слои всех промежуточных шагов
scope= : к какому объекту кэша области принадлежит ( buildkit по умолчанию)
ignore-error= : указывает, игнорируется ли ошибка в случае сбоя экспорта кэша (по умолчанию: false )
timeout= : устанавливает продолжительность таймаута для экспорта кэша (по умолчанию: 10m ).
--import-cache параметры:
type=gha
scope= : к какому объекту кэша области принадлежит ( buildkit по умолчанию)
timeout= : устанавливает продолжительность тайм-аута для импорта кэша (по умолчанию: 10m ).
построитьctl построить... --output type=image,name=docker.io/username/image,push=true --export-cache type=s3,region=eu-west-1,bucket=my_bucket,name=my_image --import-cache type=s3,region=eu-west-1,bucket=my_bucket,name=my_image
Обязательны следующие атрибуты:
bucket : корзина AWS S3 (по умолчанию: $AWS_BUCKET )
region : регион AWS (по умолчанию: $AWS_REGION )
Места хранения:
blobs: s3:// , по умолчанию: s3://
манифесты: s3:// , по умолчанию: s3://
Конфигурация S3:
blobs_prefix : глобальный префикс для хранения/чтения больших двоичных объектов на s3 (по умолчанию: blobs/ )
manifests_prefix : глобальный префикс для хранения/чтения манифестов на s3 (по умолчанию: manifests/ )
endpoint_url : укажите конкретную конечную точку S3 (по умолчанию: пусто)
use_path_style : если установлено значение true , имя сегмента помещается в URL-адрес, а не в имя хоста (по умолчанию: false ).
Аутентификация AWS:
Самый простой способ — использовать профиль экземпляра IAM. Другие варианты:
Любая система, использующая переменные среды/файлы конфигурации, поддерживаемые AWS Go SDK. Конфигурация должна быть доступна для демона buildkit, а не для клиента.
Используя следующие атрибуты:
access_key_id : Идентификатор ключа доступа
secret_access_key : Секретный ключ доступа
session_token : токен сеанса
--export-cache параметры:
type=s3
mode= : укажите слои кэша для экспорта (по умолчанию: min )
min : экспортировать только слои полученного изображения.
max : экспортировать все слои всех промежуточных шагов
prefix= : установить глобальный префикс для хранения/чтения файлов на s3 (по умолчанию: пусто)
name= : укажите имя используемого манифеста ( buildkit по умолчанию).
Одновременно можно указать несколько имен манифеста, разделенных ; . Стандартный вариант использования — использовать git sha1 в качестве имени и имя ветки в качестве дубликата и загружать оба с помощью двух команд import-cache .
ignore-error= : указывает, игнорируется ли ошибка в случае сбоя экспорта кэша (по умолчанию: false )
touch_refresh=24h : вместо повторной загрузки, если они не были изменены, файлы больших двоичных объектов будут «затрагиваться» на s3 каждый touch_refresh , по умолчанию — 24 часа. Благодаря этому в корзине S3 можно установить политику истечения срока действия для автоматической очистки ненужных файлов. Файлы манифестов систематически переписываются, трогать их нет необходимости.
upload_parallelism=4 : этот параметр изменяет количество слоев, загружаемых параллельно в s3. Каждый отдельный слой загружается в 5 потоков с помощью менеджера загрузки, предоставляемого AWS SDK.
--import-cache параметры:
type=s3
prefix= : установить глобальный префикс для хранения/чтения файлов на s3 (по умолчанию: пусто)
blobs_prefix= : установить глобальный префикс для хранения/чтения больших двоичных объектов на s3 (по умолчанию: blobs/ )
manifests_prefix= : установить глобальный префикс для хранения/чтения манифестов на s3 (по умолчанию: manifests/ )
name= : имя используемого манифеста ( buildkit по умолчанию).
построитьctl построить... --output type=image,name=docker.io/username/image,push=true --export-cache type=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image --import-cache type=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image
Обязательны следующие атрибуты:
account_url : URL-адрес учетной записи хранилища BLOB-объектов Azure (по умолчанию: $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL ).
Места хранения:
blobs:
манифесты:
Конфигурация хранилища BLOB-объектов Azure:
container : имя контейнера хранилища BLOB-объектов Azure (по умолчанию: buildkit-cache или $BUILDKIT_AZURE_STORAGE_CONTAINER , если установлено).
blobs_prefix : глобальный префикс для хранения или чтения больших двоичных объектов в контейнере хранилища BLOB-объектов Azure ( blobs/ ).
manifests_prefix : глобальный префикс для хранения и чтения больших двоичных объектов в контейнере хранилища BLOB-объектов Azure ( manifests/ ).
Аутентификация хранилища BLOB-объектов Azure:
Для аутентификации в хранилище BLOB-объектов Azure поддерживаются два варианта:
Любая система, использующая переменные среды, поддерживаемые пакетом Azure SDK для Go. Конфигурация должна быть доступна для демона buildkit, а не для клиента.
Секретный ключ доступа: с помощью атрибута secret_access_key укажите основной или дополнительный ключ учетной записи для вашей учетной записи хранилища BLOB-объектов Azure. Ключи учетной записи хранилища BLOB-объектов Azure.
Примечание
Имя учетной записи также можно указать с помощью атрибута account_name (или $BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME ), если оно не является частью хоста URL-адреса учетной записи.
--export-cache параметры:
type=azblob
mode= : укажите слои кэша для экспорта (по умолчанию: min )
min : экспортировать только слои полученного изображения.
max : экспортировать все слои всех промежуточных шагов
prefix= : установите глобальный префикс для хранения/чтения файлов в контейнере хранилища BLOB-объектов Azure (
name= : укажите имя используемого манифеста (по умолчанию: buildkit ).
Одновременно можно указать несколько имен манифеста, разделенных ; . Стандартный вариант использования — использовать git sha1 в качестве имени и имя ветки в качестве дубликата и загружать оба с помощью двух команд import-cache .
ignore-error= : указывает, игнорируется ли ошибка в случае сбоя экспорта кэша (по умолчанию: false )
--import-cache параметры:
type=azblob
prefix= : установите глобальный префикс для хранения/чтения файлов в контейнере хранилища BLOB-объектов Azure (
blobs_prefix= : установите глобальный префикс для хранения или чтения больших двоичных объектов в контейнере хранилища BLOB-объектов Azure ( blobs/ ).
manifests_prefix= : установите глобальный префикс для хранения/чтения манифестов в контейнере хранилища BLOB-объектов Azure ( manifests/ ).
name= : имя используемого манифеста (по умолчанию: buildkit )
Если у вас есть несколько экземпляров демона BuildKit, но вы не хотите использовать реестр для совместного использования кэша в кластере, рассмотрите возможность балансировки нагрузки на стороне клиента с использованием согласованного хеширования.
См ./examples/kubernetes/consistenthash .
Чтобы вывести метаданные сборки, такие как дайджест изображения, передайте флаг --metadata-file . Метаданные будут записаны в виде объекта JSON в указанный файл. Каталог указанного файла должен уже существовать и быть доступен для записи.
buildctl build ... --metadata-file метаданные.json
jq '.' метаданные.json
{ "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "containerimage.descriptor": {"annotations": { "config.digest": "sha256:2937f6 6a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "org.opencontainers.image.created": " 2022-02-08T21:28:03Z"},"дайджест": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3","mediaType": "application/vnd.oci.image.manifest.v1+json"," размер": 506
}, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"} В системах на базе Systemd вы можете общаться с демоном через активацию сокета Systemd, используя buildkitd --addr fd:// . Вы можете найти примеры использования активации сокета Systemd с BuildKit и Systemd в ./examples/systemd .
Демон buildkitd может прослушивать API gRPC в сокете TCP.
Настоятельно рекомендуется создать сертификаты TLS как для демона, так и для клиента (mTLS). Включение TCP без mTLS опасно, поскольку контейнеры-исполнители (также известные как контейнеры Dockerfile RUN ) также могут вызывать API BuildKit.
buildkitd --addr TCP://0.0.0.0:1234 --tlscacert /путь/к/ca.pem --tlscert /путь/к/cert.pem --tlskey /путь/к/key.pem
сборкаctl --addr TCP://example.com:1234 --tlscacert /путь/к/ca.pem --tlscert /путь/к/clientcert.pem --tlskey /путь/к/clientkey.pem строить ...
buildctl build может быть вызван против демонов buildkitd со случайной балансировкой нагрузки.
См. также раздел «Последовательное хеширование для балансировки нагрузки на стороне клиента».
BuildKit также можно использовать, запустив демон buildkitd внутри контейнера Docker и получив к нему удаленный доступ.
Мы предоставляем образы контейнеров как moby/buildkit :
moby/buildkit:latest : создан на основе последней регулярной версии.
moby/buildkit:rootless : то же, что и latest , но запускается от имени непривилегированного пользователя, см. docs/rootless.md
moby/buildkit:master : собран из ветки master
moby/buildkit:master-rootless : то же, что и master, но запускается от имени непривилегированного пользователя, см. docs/rootless.md
Чтобы запустить демон в контейнере:
docker run -d --name buildkitd --privileged moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd buildctl построить --help
Чтобы подключиться к демону BuildKit, работающему в контейнере Podman, используйте podman-container:// вместо docker-container:// .
podman run -d --name buildkitd --privileged moby/buildkit:latest buildctl --addr=podman-container://buildkitd build --frontend dockerfile.v0 --local context=. --local dockerfile=. --output type=oci | подман загрузить фу
sudo не требуется.
Чтобы подключиться к демону BuildKit, работающему в контейнере Nerdctl, используйте nerdctl-container:// вместо docker-container:// .
nerdctl run -d --name buildkitd --privileged moby/buildkit:latest buildctl --addr=nerdctl-container://buildkitd build --frontend dockerfile.v0 --local context=. --local dockerfile=. --output type=oci | нердктл нагрузка
sudo не требуется.
Информацию о развертываниях Kubernetes см. в examples/kubernetes .
Чтобы запустить клиент и эфемерный демон в одном контейнере («режим без демона»):
запуск докера
-это
--rm
--привилегированный
-v /путь/к/каталогу:/tmp/work
--entrypoint buildctl-daemonless.sh
moby/buildkit:мастер
строить
--frontend dockerfile.v0
--local context=/tmp/work
--local dockerfile=/tmp/workили
запуск докера
-это
--rm
--security-opt seccomp=неограниченный
--security-opt apparmor=не ограничено
-e BUILDKITD_FLAGS=--oci-worker-no-process-песочница
-v /путь/к/каталогу:/tmp/work
--entrypoint buildctl-daemonless.sh
moby/buildkit:master-rootless
строить
--внешний интерфейс
dockerfile.v0
--local context=/tmp/work
--local dockerfile=/tmp/work BuildKit поддерживает OpenTelemetry для API buildkitd gRPC и команд buildctl. Чтобы записать трассировку в Jaeger, установите для переменной среды JAEGER_TRACE адрес сбора.
docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latestexport JAEGER_TRACE=0.0.0.0:6831# перезапустите buildkitd и buildctl, чтобы они знали JAEGER_TRACE# любая команда buildctl должна быть прослежена до http:/ /127.0.0.1:16686/
В Windows, если вы запускаете Jaeger вне контейнера
jaeger-all-in-one.exe, установите переменную средыsetx -m JAEGER_TRACE "0.0.0.0:6831", перезапуститеbuildkitdв новом терминале, и трассировки будут собираются автоматически.
Пожалуйста, обратитесь к docs/rootless.md .
Пожалуйста, обратитесь к docs/multi-platform.md .
buildctl buildctl поддерживает изменение цветов, используемых для вывода информации на терминал. Вы можете установить для переменной среды BUILDKIT_COLORS что-то вроде run=green:warning=yellow:error=red:cancel=255,165,0 чтобы установить цвета, которые вы хотите использовать. Установка NO_COLOR любого значения отключит любой цветной вывод, как рекомендовано no-color.org.
Об ошибках синтаксического анализа будет сообщено, но они будут проигнорированы. Это приведет к тому, что значения цвета по умолчанию будут использоваться там, где это необходимо.
Список предопределенных цветов.
Вы можете изменить количество строк журнала, отображаемых для активных шагов в режиме tty, задав для BUILDKIT_TTY_LOG_LINES число (по умолчанию: 6).
Хотите внести свой вклад в BuildKit? Потрясающий! Информацию о вкладе в этот проект вы можете найти на сайте CONTRIBUTING.md.
