Bausatz
0.17.0
BuildKit ist ein Toolkit zum Konvertieren von Quellcode, um Artefakte auf effiziente, ausdrucksstarke und wiederholbare Weise zu erstellen.
Hauptmerkmale:
Automatische Müllsammlung
Erweiterbare Frontend-Formate
Gleichzeitige Abhängigkeitsauflösung
Effizientes Befehls-Caching
Build-Cache-Import/Export
Verschachtelte Build-Job-Aufrufe
Verteilbare Arbeitskräfte
Mehrere Ausgabeformate
Steckbare Architektur
Ausführung ohne Root-Rechte
Lesen Sie den Vorschlag von moby/moby#32925
Einführender Blogbeitrag https://blog.mobyproject.org/introducing-buildkit-17e056cc5317
Treten Sie #buildkit -Kanal auf Docker Community Slack bei
Notiz
Wenn Sie dieses Repo besuchen, um nur BuildKit-basierte Dockerfile-Funktionen wie RUN --mount=type=(bind|cache|tmpfs|secret|ssh) zu verwenden, lesen Sie bitte die Dockerfile-Referenz.
Notiz
docker build verwendet seit Docker Engine 23.0 standardmäßig Buildx und BuildKit. Sie müssen dieses Dokument nicht lesen, es sei denn, Sie möchten die voll funktionsfähige Standalone-Version von BuildKit verwenden.
Verwendet von
Schnellstart
Bild/Registrierung
Lokales Verzeichnis
Docker-Tarball
OCI-Tarball
Containerd-Image-Store
Erstellen einer Docker-Datei mit buildctl
Erstellen einer Docker-Datei mit einem externen Frontend
Linux-Setup
Windows-Setup
macOS-Setup
Aus dem Quellcode erstellen
LLB erkunden
Dockerfiles erkunden
Ausgabe
Cache
Inline (Bild und Cache zusammenschieben)
Registry (Image und Cache separat übertragen)
Lokales Verzeichnis
GitHub-Aktionscache (experimentell)
S3-Cache (experimentell)
Azure Blob Storage-Cache (experimentell)
Müllabfuhr
Cache exportieren
Konsistentes Hashing
Metadaten
Aktivierung des Systemd-Sockets
Stellen Sie BuildKit als TCP-Dienst bereit
Lastausgleich
Containerisierung von BuildKit
Podman
Nerdctl
Kubernetes
Dämonenlos
OpenTelemetry-Unterstützung
BuildKit ohne Root-Rechte ausführen
Erstellen von Multiplattform-Images
Steuerelemente für die Farbausgabe
Anzahl der Protokollzeilen (für aktive Schritte im TTY-Modus)
buildctl konfigurieren
Mitwirken
BuildKit wird von folgenden Projekten verwendet:
Moby & Docker ( DOCKER_BUILDKIT=1 docker build )
Bild
OpenFaaS-Cloud
Container-Build-Schnittstelle
Tekton Pipelines (ehemals Knative Build Templates)
das Sanic-Build-Tool
vab
Rio
Kim
BeutelContainer
Docker buildx
Okteto Cloud
Irdische Erddateien
Gitpod
Dolch
envd
Depot
Namensraum
Unikraft
DevZero
dacc
Informationen zu Kubernetes-Bereitstellungen finden Sie examples/kubernetes .
BuildKit besteht aus dem buildkitd -Daemon und dem buildctl Client. Während der buildctl -Client für Linux, macOS und Windows verfügbar ist, ist der buildkitd Daemon derzeit nur für Linux und *Windows verfügbar.
Die neuesten Binärdateien von BuildKit sind hier für Linux, macOS und Windows verfügbar.
Der buildkitd -Daemon erfordert die Installation der folgenden Komponenten:
runc oder crun
containerd (wenn Sie den Containerd-Worker verwenden möchten)
Starten des buildkitd -Daemons: Sie müssen buildkitd als Root-Benutzer auf dem Host ausführen.
$ sudo buildkitd
Informationen zum Ausführen buildkitd als Nicht-Root-Benutzer finden Sie unter docs/rootless.md .
Der Buildkitd-Daemon unterstützt zwei Worker-Backends: OCI (runc) und Containerd.
Standardmäßig wird der OCI-Worker (runc) verwendet. Sie können --oci-worker=false --containerd-worker=true festlegen, um den Containerd-Worker zu verwenden.
Wir sind offen für das Hinzufügen weiterer Backends.
Um den Buildkitd-Daemon mithilfe der Systemd-Socket-Aktivierung zu starten, können Sie die Buildkit-Systemd-Einheitsdateien installieren. Siehe Systemd-Socket-Aktivierung
Der buildkitd-Daemon überwacht standardmäßig die gRPC-API auf /run/buildkit/buildkitd.sock , Sie können aber auch TCP-Sockets verwenden. Siehe BuildKit als TCP-Dienst verfügbar machen.
Anweisungen und Hinweise finden Sie unter docs/windows.md .
Die Homebrew-Formel (inoffiziell) ist für macOS verfügbar.
$ brew Buildkit installieren
Die Homebrew-Formel enthält nicht den Daemon ( buildkitd ).
Lima kann beispielsweise zum Starten des Daemons innerhalb einer Linux-VM verwendet werden.
brew install limalimactl start template://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"
Informationen zum Erstellen von BuildKit aus dem Quellcode finden Sie unter .github/CONTRIBUTING.md .
Eine buildctl Referenz finden Sie in diesem Dokument.
BuildKit-Builds basieren auf einem binären Zwischenformat namens LLB, das zum Definieren des Abhängigkeitsdiagramms für Prozesse verwendet wird, die einen Teil Ihres Builds ausführen. tl;dr: LLB ist für Dockerfile das, was LLVM IR für C ist.
Als Protobuf-Nachrichten gemarshallt
Gleichzeitig ausführbar
Effizient zwischenspeicherbar
Herstellerneutral (d. h. Nicht-Dockerfile-Sprachen können problemlos implementiert werden)
Siehe solver/pb/ops.proto für die Formatdefinition und siehe ./examples/README.md für Beispiel-LLB-Anwendungen.
Derzeit sind für LLB folgende Hochsprachen implementiert:
Dockerfile (siehe Erkunden von Dockerfiles)
Buildpacks
Mockerfile
Gocker-Datei
bldr (Paketdatei)
HLB
Earthfile (Irdisch)
Frachtkai (Rost)
Nix
mopy (Python)
envd (starlark)
Speck
Bass
kraft.yaml (Unikraft)
r2d4/llb (JSON-Gateway)
(öffnen Sie eine PR, um Ihre eigene Sprache hinzuzufügen)
Frontends sind Komponenten, die in BuildKit ausgeführt werden und jede Build-Definition in LLB konvertieren. Es gibt ein spezielles Frontend namens Gateway ( gateway.v0 ), das die Verwendung jedes beliebigen Bildes als Frontend ermöglicht.
Während der Entwicklung ist das Dockerfile-Frontend ( dockerfile.v0 ) auch Teil des BuildKit-Repositorys. In Zukunft wird dies ausgezogen und Dockerfiles können mithilfe eines externen Images erstellt werden.
buildctl buildctl build
--frontend=dockerfile.v0
--local context=.
--local dockerfile=.# orbuildctl build
--frontend=dockerfile.v0
--local context=.
--local dockerfile=.
--opt target=foo
--opt build-arg:foo=bar --local stellt dem Builder lokale Quelldateien vom Client zur Verfügung. context und dockerfile sind die Namen, nach denen das Dockerfile-Frontend nach Build-Kontext und Dockerfile-Speicherort sucht.
Wenn die Docker-Datei einen anderen Dateinamen hat, kann dieser mit --opt filename=./Dockerfile-alternative angegeben werden.
Externe Versionen des Dockerfile-Frontends werden an https://hub.docker.com/r/docker/dockerfile-upstream und https://hub.docker.com/r/docker/dockerfile gepusht und können mit dem Gateway-Frontend verwendet werden . Die Quelle für das externe Frontend befindet sich derzeit in ./frontend/dockerfile/cmd/dockerfile-frontend , wird aber in Zukunft aus diesem Repository verschoben (#163). Für den automatischen Build aus dem Master-Zweig dieses Repositorys kann das Image docker/dockerfile-upstream:master oder docker/dockerfile-upstream:master-labs verwendet werden.
buildctl build
--frontend Gateway.v0
--opt source=docker/dockerfile
--local context=.
--local dockerfile=.
buildctl build
--frontend Gateway.v0
--opt source=docker/dockerfile
--opt context=https://github.com/moby/moby.git
--opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.orgStandardmäßig verbleiben das Build-Ergebnis und der Zwischencache nur intern in BuildKit. Um das Ergebnis abzurufen, muss eine Ausgabe angegeben werden.
buildctl build ... --output type=image,name=docker.io/username/image,push=true
So exportieren Sie das Bild in mehrere Register:
buildctl build ... --output type=image,"name=docker.io/username/image,docker.io/username2/image2",push=true
Um die Cache-Einbettung mit dem Bild zu exportieren und sie zusammen in die Registrierung zu übertragen, ist der Typ registry erforderlich. Zum Importieren des Caches sollten Sie --export-cache type=inline und --import-cache type=registry,ref=... angeben. . Um den Cache direkt in einen lokalen Cache zu exportieren, sollten Sie --export-cache type=local angeben. Details im Export-Cache.
buildctl build ... --output type=image,name=docker.io/username/image,push=true --export-cache Typ=inline --import-cache type=registry,ref=docker.io/username/image
Von der Bildausgabe unterstützte Schlüssel:
name= : Bildnamen angeben
push=true : Push nach dem Erstellen des Bildes
push-by-digest=true : unbenanntes Bild übertragen
registry.insecure=true : Push an unsichere HTTP-Registrierung
oci-mediatypes=true : OCI-Medientypen im Konfigurations-JSON anstelle von Docker verwenden
unpack=true : Bild nach der Erstellung entpacken (zur Verwendung mit Containerd)
dangling-name-prefix= : Benennen Sie das Bild mit prefix@ , wird für anonyme Bilder verwendet
name-canonical=true : Fügen Sie den zusätzlichen kanonischen Namen name@ hinzu
compression= : Wählen Sie den Komprimierungstyp für neu erstellte und zwischengespeicherte Ebenen. gzip ist der Standardwert. estargz sollte mit oci-mediatypes=true verwendet werden.
compression-level= : Komprimierungsstufe für gzip, estargz (0-9) und zstd (0-22)
rewrite-timestamp=true : Schreiben Sie die Zeitstempel der Datei auf den Wert SOURCE_DATE_EPOCH um. Informationen zum Angeben des SOURCE_DATE_EPOCH Werts finden Sie unter docs/build-repro.md .
force-compression=true : compression zwangsweise auf alle Ebenen anwenden (einschließlich bereits vorhandener Ebenen)
store=true : Speichern Sie die Ergebnisbilder im Bildspeicher des Workers (z. B. Containerd) und stellen Sie sicher, dass das Bild alle Blobs im Inhaltsspeicher enthält (Standard: true ). Wird ignoriert, wenn der Worker keinen Bildspeicher hat (z. B. OCI-Worker).
annotation. : Fügen Sie dem erstellten Bild eine Anmerkung mit dem entsprechenden key und value hinzu
Unter Verwendung der erweiterten Syntaxen annotation- , annotation[ und beide kombiniert mit annotation- ermöglicht die genaue Konfiguration, wo die Anmerkung angehängt werden soll.
manifest (Standard), manifest-descriptor , index oder index-descriptor
platform übergeben wird, siehe docs/multi-platform.md .
Weitere Informationen finden Sie unter docs/annotations.md .
Wenn Anmeldeinformationen erforderlich sind, versucht buildctl die Docker-Konfigurationsdatei $DOCKER_CONFIG/config.json zu lesen. $DOCKER_CONFIG ist standardmäßig ~/.docker .
Der lokale Client kopiert die Dateien direkt auf den Client. Dies ist nützlich, wenn BuildKit zum Erstellen von etwas anderem als Container-Images verwendet wird.
buildctl build ... --output type=local,dest=path/to/output-dir
Um bestimmte Dateien zu exportieren, verwenden Sie mehrstufige Builds mit einer Scratch-Stufe und kopieren Sie die benötigten Dateien mit COPY --from in diese Stufe.
...VON Grund auf neu als testresultCOPY --from=builder /usr/src/app/testresult.xml . ...
buildctl build ... --opt target=testresult --output type=local,dest=path/to/output-dir
Bei einem Multi-Plattform-Build wird im Zielverzeichnis ein Unterordner erstellt, der zu jeder Zielplattform passt:
FROM Busybox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROM scratchCOPY --from=build /out /
$ buildctl build
--frontend dockerfile.v0
--opt Plattform=linux/amd64,linux/arm64
--output type=local,dest=./bin/release
$ Baum ./bin
./bin/
└── Veröffentlichung
├── linux_amd64
│ └── hallo-linux-amd64
└── linux_arm64
└── hallo-linux-arm64 Sie können platform-split=false festlegen, um Dateien von allen Plattformen zusammen im selben Verzeichnis zusammenzuführen:
$ buildctl build
--frontend dockerfile.v0
--opt Plattform=linux/amd64,linux/arm64
--output type=local,dest=./bin/release,platform-split=false
$ Baum ./bin
./bin/
└── Veröffentlichung
├── hallo-linux-amd64
└── hallo-linux-arm64Der Tar-Exporter ähnelt dem lokalen Exporter, überträgt die Dateien jedoch über einen Tarball.
buildctl build ... --output type=tar,dest=out.tar buildctl build ... --output type=tar > out.tar
# exportierter Tarball ist auch mit OCI kompatibel specbuildctl build ... --output type=docker,name=myimage | Docker-Last
buildctl build ... --output type=oci,dest=path/to/output.tar buildctl build ... --output type=oci > output.tar
Der Containerd-Worker muss verwendet werden
buildctl build ... --output type=image,name=docker.io/username/image ctr --namespace=Buildkit-Bilder ls
Um den Containerd-Namespace zu ändern, müssen Sie worker.containerd.namespace in /etc/buildkit/buildkitd.toml ändern.
So zeigen Sie den lokalen Build-Cache an ( /var/lib/buildkit ):
buildctl du -v
So bereinigen Sie den lokalen Build-Cache:
buildctl prune
Siehe ./docs/buildkitd.toml.md .
BuildKit unterstützt die folgenden Cache-Exporteure:
inline : Betten Sie den Cache in das Image ein und übertragen Sie sie zusammen in die Registrierung
registry : Bild und Cache separat übertragen
local : In ein lokales Verzeichnis exportieren
gha : Export in den GitHub-Aktionscache
In den meisten Fällen möchten Sie den inline -Cache-Exporter verwenden. Beachten Sie jedoch, dass der inline -Cache-Exporter nur min -Cache-Modus unterstützt. Um max -Cache-Modus zu aktivieren, übertragen Sie das Image und den Cache separat mithilfe registry Cache-Exporters.
Sowohl inline als auch registry Exporteure speichern den Cache in der Registry. Für den Import des Caches reicht in beiden Fällen type=registry aus, da die Angabe des Cache-Formats nicht notwendig ist.
buildctl build ... --output type=image,name=docker.io/username/image,push=true --export-cache Typ=inline --import-cache type=registry,ref=docker.io/username/image
Beachten Sie, dass der Inline-Cache nicht importiert wird, es sei denn, --import-cache type=registry,ref=... wird bereitgestellt.
Der Inline-Cache bettet Cache-Metadaten in die Bildkonfiguration ein. Die Ebenen im Bild bleiben im Vergleich zum Bild ohne Cache-Informationen unberührt.
Für das in Docker integrierte BuildKit ( DOCKER_BUILDKIT=1 docker build ) und docker buildx muss --build-arg BUILDKIT_INLINE_CACHE=1 angegeben werden, um den inline -Cache-Exporter zu aktivieren. Das eigenständige buildctl erfordert jedoch NICHT --opt build-arg:BUILDKIT_INLINE_CACHE=1 und das Build-Arg wird einfach ignoriert.
buildctl build ... --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 Optionen:
type=registry
mode= : Geben Sie die zu exportierenden Cache-Ebenen an (Standard: min )
min : Nur Ebenen für das resultierende Bild exportieren
max : Alle Ebenen aller Zwischenschritte exportieren
ref= : Geben Sie die Repository-Referenz zum Speichern des Caches an, z. B. docker.io/user/image:tag
image-manifest= : ob das Cache-Manifest als OCI-kompatibles Bildmanifest und nicht als Manifestliste/Index exportiert werden soll (Standard: false , muss mit oci-mediatypes=true verwendet werden)
oci-mediatypes= : ob OCI-Medientypen in exportierten Manifesten verwendet werden sollen (Standard: true , seit BuildKit v0.8 )
compression= : Wählen Sie den Komprimierungstyp für neu erstellte und zwischengespeicherte Ebenen. gzip ist der Standardwert. estargz und zstd sollten mit oci-mediatypes=true verwendet werden
compression-level= : Wählen Sie die Komprimierungsstufe für gzip, estargz (0-9) und zstd (0-22)
force-compression=true : compression zwangsweise auf alle Ebenen anwenden
ignore-error= : Geben Sie an, ob der Fehler ignoriert wird, falls der Cache-Export fehlschlägt (Standard: false )
--import-cache Optionen:
type=registry
ref= : Geben Sie die Repository-Referenz an, aus der der Cache abgerufen werden soll, z. B. 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
Das Verzeichnislayout entspricht OCI Image Spec v1.0.
--export-cache Optionen:
type=local
mode= : Geben Sie die zu exportierenden Cache-Ebenen an (Standard: min )
min : Nur Ebenen für das resultierende Bild exportieren
max : Alle Ebenen aller Zwischenschritte exportieren
dest= : Zielverzeichnis für Cache-Exporter
tag= : Geben Sie ein benutzerdefiniertes Tag des Bildes an, das in den lokalen Index geschrieben werden soll (Standard: latest )
image-manifest= : ob das Cache-Manifest als OCI-kompatibles Bildmanifest und nicht als Manifestliste/Index exportiert werden soll (Standard: false , muss mit oci-mediatypes=true verwendet werden)
oci-mediatypes= : ob OCI-Medientypen in exportierten Manifesten verwendet werden sollen (Standard true , seit BuildKit v0.8 )
compression= : Wählen Sie den Komprimierungstyp für neu erstellte und zwischengespeicherte Ebenen. gzip ist der Standardwert. estargz und zstd sollten mit oci-mediatypes=true verwendet werden.
compression-level= : Komprimierungsstufe für gzip, estargz (0-9) und zstd (0-22)
force-compression=true : compression zwangsweise auf alle Ebenen anwenden
ignore-error= : Geben Sie an, ob der Fehler ignoriert wird, falls der Cache-Export fehlschlägt (Standard: false )
--import-cache Optionen:
type=local
src= : Quellverzeichnis für Cache-Importer
tag= : Geben Sie ein benutzerdefiniertes Tag des Bildes an, das aus dem lokalen Index gelesen werden soll (Standard: latest )
digest=sha256: : Geben Sie den expliziten Digest der zu importierenden Manifestliste an
buildctl build ... --output type=image,name=docker.io/username/image,push=true --export-cache Typ=gha --import-cache Typ=gha
Der GitHub Actions-Cache speichert sowohl Cache-Metadaten als auch Layer im Cache-Dienst von GitHub. Dieser Cache hat derzeit eine Größenbeschränkung von 10 GB, die auf verschiedene Caches im Repo gemeinsam genutzt wird. Wenn Sie dieses Limit überschreiten, speichert GitHub Ihren Cache, beginnt jedoch mit der Entfernung von Caches, bis die Gesamtgröße weniger als 10 GB beträgt. Ein zu häufiges Recycling von Caches kann insgesamt zu langsameren Laufzeiten führen.
Ähnlich wie bei der Verwendung von „actions/cache“ sind Caches nach Zweigen gegliedert, wobei die Standard- und Zielzweige für jeden Zweig verfügbar sind.
Die folgenden Attribute sind für die Authentifizierung bei der GitHub Actions Cache-Dienst-API erforderlich:
url : Cache-Server-URL (Standard: $ACTIONS_CACHE_URL )
token : Zugriffstoken (Standard $ACTIONS_RUNTIME_TOKEN )
Diese Art von Cache kann mit der Docker Build Push Action verwendet werden, bei der url und token automatisch festgelegt werden. Um dieses Backend in einem Inline run zu verwenden, müssen Sie Crazy-max/ghaction-github-runtime in Ihren Workflow einbinden, um die Laufzeit verfügbar zu machen.
--export-cache Optionen:
type=gha
mode= : Geben Sie die zu exportierenden Cache-Ebenen an (Standard: min )
min : Nur Ebenen für das resultierende Bild exportieren
max : Alle Ebenen aller Zwischenschritte exportieren
scope= : Zu welchem Scope-Cache-Objekt gehört (Standard- buildkit )
ignore-error= : Geben Sie an, ob der Fehler ignoriert wird, falls der Cache-Export fehlschlägt (Standard: false )
timeout= : legt die Timeout-Dauer für den Cache-Export fest (Standard: 10m )
--import-cache Optionen:
type=gha
scope= : Zu welchem Scope-Cache-Objekt gehört (Standard- buildkit )
timeout= : legt die Timeout-Dauer für den Cache-Import fest (Standard: 10m )
buildctl build ... --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
Die folgenden Attribute sind erforderlich:
bucket : AWS S3-Bucket (Standard: $AWS_BUCKET )
region : AWS-Region (Standard: $AWS_REGION )
Lagerorte:
Blobs: s3:// , Standard: s3://
Manifeste: s3:// , Standard: s3://
S3-Konfiguration:
blobs_prefix : globales Präfix zum Speichern/Lesen von Blobs auf s3 (Standard: blobs/ )
manifests_prefix : globales Präfix zum Speichern/Lesen von Manifesten auf s3 (Standard: manifests/ )
endpoint_url : Geben Sie einen bestimmten S3-Endpunkt an (Standard: leer)
use_path_style : Wenn auf true gesetzt, geben Sie den Bucket-Namen in die URL statt in den Hostnamen ein (Standard: false ).
AWS-Authentifizierung:
Der einfachste Weg ist die Verwendung eines IAM-Instanzprofils. Weitere Optionen sind:
Jedes System, das Umgebungsvariablen/Konfigurationsdateien verwendet, die vom AWS Go SDK unterstützt werden. Die Konfiguration muss für den Buildkit-Daemon verfügbar sein, nicht für den Client.
Verwendung der folgenden Attribute:
access_key_id : Zugriffsschlüssel-ID
secret_access_key : Geheimer Zugriffsschlüssel
session_token : Sitzungstoken
--export-cache Optionen:
type=s3
mode= : Geben Sie die zu exportierenden Cache-Ebenen an (Standard: min )
min : Nur Ebenen für das resultierende Bild exportieren
max : Alle Ebenen aller Zwischenschritte exportieren
prefix= : globales Präfix festlegen, um Dateien auf s3 zu speichern/lesen (Standard: leer)
name= : Geben Sie den Namen des zu verwendenden Manifests an (Standard- buildkit ).
Es können mehrere Manifestnamen gleichzeitig angegeben werden, getrennt durch ; . Der Standardanwendungsfall besteht darin, git sha1 als Namen und den Zweignamen als Duplikat zu verwenden und beide mit zwei import-cache -Befehlen zu laden.
ignore-error= : Geben Sie an, ob der Fehler ignoriert wird, falls der Cache-Export fehlschlägt (Standard: false )
touch_refresh=24h : Anstatt erneut hochgeladen zu werden, wenn sie nicht geändert werden, werden Blobs-Dateien bei jedem touch_refresh auf s3 „berührt“. Der Standardwert ist 24 Stunden. Aus diesem Grund kann für den S3-Bucket eine Ablaufrichtlinie festgelegt werden, um nutzlose Dateien automatisch zu bereinigen. Manifestdateien werden systematisch neu geschrieben, es besteht keine Notwendigkeit, sie zu berühren.
upload_parallelism=4 : Dieser Parameter ändert die Anzahl der Ebenen, die parallel auf s3 hochgeladen werden. Jede einzelne Ebene wird mit 5 Threads hochgeladen, wobei der vom AWS SDK bereitgestellte Upload-Manager verwendet wird.
--import-cache Optionen:
type=s3
prefix= : globales Präfix festlegen, um Dateien auf s3 zu speichern/lesen (Standard: leer)
blobs_prefix= : globales Präfix zum Speichern/Lesen von Blobs auf s3 festlegen (Standard: blobs/ )
manifests_prefix= : globales Präfix zum Speichern/Lesen von Manifesten auf s3 festlegen (Standard: manifests/ )
name= : Name des zu verwendenden Manifests (Standard- buildkit )
buildctl build ... --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
Die folgenden Attribute sind erforderlich:
account_url : Die URL des Azure Blob Storage-Kontos (Standard: $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL )
Lagerorte:
Blobs:
Manifeste:
Azure Blob Storage-Konfiguration:
container : Der Name des Azure Blob Storage-Containers (Standard: buildkit-cache oder $BUILDKIT_AZURE_STORAGE_CONTAINER , falls festgelegt)
blobs_prefix : Globales Präfix zum Speichern/Lesen von Blobs im Azure Blob Storage-Container ( blobs/ )
manifests_prefix : Globales Präfix zum Speichern/Lesen von Blobs im Azure Blob Storage-Container ( manifests/ )
Azure Blob Storage-Authentifizierung:
Für die Azure Blob Storage-Authentifizierung werden zwei Optionen unterstützt:
Jedes System, das Umgebungsvariablen verwendet, die vom Azure SDK für Go unterstützt werden. Die Konfiguration muss für den Buildkit-Daemon verfügbar sein, nicht für den Client.
Geheimer Zugriffsschlüssel. Verwenden Sie das Attribut secret_access_key , um den primären oder sekundären Kontoschlüssel für Ihr Azure Blob Storage-Konto anzugeben. Azure Blob Storage-Kontoschlüssel
Notiz
Der Kontoname kann auch mit dem Attribut account_name (oder $BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME ) angegeben werden, wenn er nicht Teil des Konto-URL-Hosts ist.
--export-cache Optionen:
type=azblob
mode= : Geben Sie die zu exportierenden Cache-Ebenen an (Standard: min )
min : Nur Ebenen für das resultierende Bild exportieren
max : Alle Ebenen aller Zwischenschritte exportieren
prefix= : Legen Sie das globale Präfix fest, um Dateien im Azure Blob Storage-Container (
name= : Geben Sie den Namen des zu verwendenden Manifests an (Standard: buildkit )
Es können mehrere Manifestnamen gleichzeitig angegeben werden, getrennt durch ; . Der Standardanwendungsfall besteht darin, git sha1 als Namen und den Zweignamen als Duplikat zu verwenden und beide mit zwei import-cache -Befehlen zu laden.
ignore-error= : Geben Sie an, ob der Fehler ignoriert wird, falls der Cache-Export fehlschlägt (Standard: false )
--import-cache Optionen:
type=azblob
prefix= : Legen Sie das globale Präfix fest, um Dateien im Azure Blob Storage-Container (
blobs_prefix= : Legen Sie das globale Präfix fest, um Blobs im Azure Blob Storage-Container ( blobs/ )
manifests_prefix= : Legen Sie das globale Präfix fest, um Manifeste im Azure Blob Storage-Container ( manifests/ )
name= : Name des zu verwendenden Manifests (Standard: buildkit )
Wenn Sie über mehrere BuildKit-Daemon-Instanzen verfügen, aber die Registrierung nicht für die gemeinsame Nutzung des Caches im Cluster verwenden möchten, sollten Sie einen clientseitigen Lastenausgleich mit konsistentem Hashing in Betracht ziehen.
Siehe ./examples/kubernetes/consistenthash .
Um Build-Metadaten wie den Image-Digest auszugeben, übergeben Sie das Flag --metadata-file . Die Metadaten werden als JSON-Objekt in die angegebene Datei geschrieben. Das Verzeichnis der angegebenen Datei muss bereits vorhanden und beschreibbar sein.
buildctl build ... --metadata-file metadata.json
jq '.' metadata.json
{ "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "containerimage.descriptor": {"annotations": { "config.digest": "sha256:2937f66a9 722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "org.opencontainers.image.created": " 2022-02-08T21:28:03Z"},"digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3", "mediaType": "application/vnd.oci.image.manifest.v1+json", "size": 50 6
}, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"} Auf Systemd-basierten Systemen können Sie mit dem Daemon über die Systemd-Socket-Aktivierung kommunizieren, verwenden Sie buildkitd --addr fd:// . Beispiele für die Verwendung der Systemd-Socket-Aktivierung mit BuildKit und Systemd finden Sie in ./examples/systemd .
Der buildkitd -Daemon kann die gRPC-API an einem TCP-Socket abhören.
Es wird dringend empfohlen, TLS-Zertifikate sowohl für den Daemon als auch für den Client zu erstellen (mTLS). Die Aktivierung von TCP ohne mTLS ist gefährlich, da die Executor-Container (auch Dockerfile RUN Container genannt) auch die BuildKit-API aufrufen können.
buildkitd --addr tcp://0.0.0.0:1234 --tlscacert /path/to/ca.pem --tlscert /path/to/cert.pem --tlskey /path/to/key.pem
buildctl --addr tcp://example.com:1234 --tlscacert /path/to/ca.pem --tlscert /path/to/clientcert.pem --tlskey /path/to/clientkey.pem bauen ...
buildctl build kann für buildkitd -Daemons mit zufälligem Lastausgleich aufgerufen werden.
Siehe auch Konsistentes Hashing für clientseitigen Lastausgleich.
BuildKit kann auch verwendet werden, indem der buildkitd -Daemon in einem Docker-Container ausgeführt und remote darauf zugegriffen wird.
Wir stellen die Container-Images als moby/buildkit zur Verfügung:
moby/buildkit:latest : erstellt aus der neuesten regulären Version
moby/buildkit:rootless : wie latest wird aber als unprivilegierter Benutzer ausgeführt, siehe docs/rootless.md
moby/buildkit:master : erstellt aus dem Master-Zweig
moby/buildkit:master-rootless : wie Master, wird aber als unprivilegierter Benutzer ausgeführt, siehe docs/rootless.md
So führen Sie einen Daemon in einem Container aus:
docker run -d --name buildkitd --privileged moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd buildctl build --help
Um eine Verbindung zu einem BuildKit-Daemon herzustellen, der in einem Podman-Container ausgeführt wird, verwenden Sie podman-container:// anstelle von 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 | Podman lädt foo
sudo ist nicht erforderlich.
Um eine Verbindung zu einem BuildKit-Daemon herzustellen, der in einem Nerdctl-Container ausgeführt wird, verwenden Sie nerdctl-container:// anstelle von 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 | nerdctl laden
sudo ist nicht erforderlich.
Informationen zu Kubernetes-Bereitstellungen finden Sie examples/kubernetes .
So führen Sie den Client und einen kurzlebigen Daemon in einem einzigen Container aus („Daemonless-Modus“):
Docker-Lauf
-Es
--rm
--privilegiert
-v /Pfad/zu/Verzeichnis:/tmp/work
--entrypoint buildctl-daemonless.sh
moby/buildkit:master
bauen
--frontend dockerfile.v0
--local context=/tmp/work
--local dockerfile=/tmp/workoder
Docker-Lauf
-Es
--rm
--security-opt seccomp=unconfined
--security-opt apparmor=unconfined
-e BUILDKITD_FLAGS=--oci-worker-no-process-sandbox
-v /Pfad/zu/Verzeichnis:/tmp/work
--entrypoint buildctl-daemonless.sh
moby/buildkit:master-rootless
bauen
--Frontend
dockerfile.v0
--local context=/tmp/work
--local dockerfile=/tmp/work BuildKit unterstützt OpenTelemetry für die buildkitd gRPC-API und buildctl-Befehle. Um den Trace zu Jaeger zu erfassen, setzen Sie die Umgebungsvariable JAEGER_TRACE auf die Sammlungsadresse.
docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latestexport JAEGER_TRACE=0.0.0.0:6831# starte buildkitd und buildctl neu, damit sie wissen, dass JAEGER_TRACE# jeder buildctl-Befehl auf http:/ zurückverfolgt werden sollte /127.0.0.1:16686/
Wenn Sie Jaeger unter Windows außerhalb eines Containers,
jaeger-all-in-one.exe, ausführen, legen Sie die Umgebungsvariablesetx -m JAEGER_TRACE "0.0.0.0:6831"fest, starten Siebuildkitdin einem neuen Terminal neu und die Traces werden angezeigt automatisch gesammelt.
Weitere Informationen finden Sie unter docs/rootless.md .
Weitere Informationen finden Sie unter docs/multi-platform.md .
buildctl konfigurieren buildctl unterstützt das Ändern der Farben, die zur Ausgabe von Informationen an das Terminal verwendet werden. Sie können die Umgebungsvariable BUILDKIT_COLORS auf etwa run=green:warning=yellow:error=red:cancel=255,165,0 setzen, um die Farben festzulegen, die Sie verwenden möchten. Wenn Sie NO_COLOR auf irgendetwas setzen, wird jede kolorierte Ausgabe deaktiviert, wie von no-color.org empfohlen.
Parsing-Fehler werden gemeldet, aber ignoriert. Dies führt dazu, dass bei Bedarf Standardfarbwerte verwendet werden.
Die Liste der vordefinierten Farben.
Sie können ändern, wie viele Protokollzeilen für aktive Schritte im TTY-Modus sichtbar sind, indem Sie BUILDKIT_TTY_LOG_LINES auf eine Zahl setzen (Standard: 6).
Möchten Sie zu BuildKit beitragen? Eindrucksvoll! Informationen zum Mitwirken an diesem Projekt finden Sie in CONTRIBUTING.md
