kit de construction
0.17.0
BuildKit est une boîte à outils permettant de convertir le code source pour créer des artefacts de manière efficace, expressive et reproductible.
Principales caractéristiques :
Collecte automatique des déchets
Formats frontaux extensibles
Résolution des dépendances simultanées
Mise en cache efficace des instructions
Importer/exporter le cache de construction
Appels de tâches de build imbriquées
Travailleurs distribuables
Plusieurs formats de sortie
Architecture enfichable
Exécution sans privilèges root
Lisez la proposition de moby/moby#32925
Article de blog d'introduction https://blog.mobyproject.org/introducing-buildkit-17e056cc5317
Rejoignez la chaîne #buildkit sur Docker Community Slack
Note
Si vous visitez ce référentiel pour utiliser les fonctionnalités Dockerfile uniquement BuildKit telles que RUN --mount=type=(bind|cache|tmpfs|secret|ssh) , veuillez vous référer à la référence Dockerfile.
Note
docker build utilise Buildx et BuildKit par défaut depuis Docker Engine 23.0. Vous n'avez pas besoin de lire ce document, sauf si vous souhaitez utiliser la version autonome complète de BuildKit.
Utilisé par
Démarrage rapide
Image/Registre
Annuaire local
archive tar Docker
archive tar OCI
magasin d'images conteneur
Construire un Dockerfile avec buildctl
Construire un Dockerfile à l'aide d'une interface externe
Configuration Linux
Installation de Windows
Configuration macOS
Construire à partir des sources
Explorer le LLB
Explorer les fichiers Docker
Sortir
Cache
En ligne (pousser l'image et le cache ensemble)
Registre (pousser l'image et le cache séparément)
Annuaire local
Cache d'actions GitHub (expérimental)
Cache S3 (expérimental)
Cache Azure Blob Storage (expérimental)
Collecte des déchets
Exporter le cache
Hachage cohérent
Métadonnées
Activation du socket système
Exposer BuildKit en tant que service TCP
Équilibrage de charge
Conteneuriser BuildKit
Podman
Nerdctl
Kubernetes
Sans démon
Prise en charge d'OpenTelemetry
Exécuter BuildKit sans privilèges root
Créer des images multiplateformes
Contrôles de sortie couleur
Nombre de lignes de journal (pour les étapes actives en mode tty)
Configuration de buildctl
Contribuer
BuildKit est utilisé par les projets suivants :
Moby & Docker ( DOCKER_BUILDKIT=1 docker build )
img
Cloud OpenFaaS
interface de création de conteneur
Tekton Pipelines (anciennement Knative Build Templates)
l'outil de construction Sanic
vab
Rio
Kim
PochetteConteneur
Construction Dockerx
Nuage Okteto
Fichiers terrestres
Gitpod
Poignard
envd
Dépôt
Espace de noms
Unicraft
DevZéro
dacc
Pour les déploiements Kubernetes, voir examples/kubernetes .
BuildKit est composé du démon buildkitd et du client buildctl . Bien que le client buildctl soit disponible pour Linux, macOS et Windows, le démon buildkitd n'est actuellement disponible que pour Linux et *Windows.
Les derniers binaires de BuildKit sont disponibles ici pour Linux, macOS et Windows.
Le démon buildkitd nécessite l'installation des composants suivants :
runc ou crun
conteneurd (si vous souhaitez utiliser le travailleur conteneurd)
Démarrage du démon buildkitd : vous devez exécuter buildkitd en tant qu'utilisateur root sur l'hôte.
$ sudo buildkitd
Pour exécuter buildkitd en tant qu'utilisateur non root, consultez docs/rootless.md .
Le démon buildkitd prend en charge deux backends de travail : OCI (runc) et containersd.
Par défaut, le travailleur OCI (runc) est utilisé. Vous pouvez définir --oci-worker=false --containerd-worker=true pour utiliser le travailleur conteneurd.
Nous sommes disposés à ajouter davantage de backends.
Pour démarrer le démon buildkitd à l'aide de l'activation du socket systemd, vous pouvez installer les fichiers d'unité buildkit systemd. Voir Activation du socket Systemd
Le démon buildkitd écoute l'API gRPC sur /run/buildkit/buildkitd.sock par défaut, mais vous pouvez également utiliser des sockets TCP. Voir Exposer BuildKit en tant que service TCP.
Voir les instructions et les notes sur docs/windows.md .
La formule Homebrew (non officielle) est disponible pour macOS.
$ Brew Installer le kit de construction
La formule Homebrew ne contient pas le démon ( buildkitd ).
Par exemple, Lima peut être utilisé pour lancer le démon dans une machine virtuelle Linux.
Brew install limalimactl start template://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"
Pour créer BuildKit à partir des sources, voir .github/CONTRIBUTING.md .
Pour une référence buildctl , consultez ce document.
Les builds BuildKit sont basés sur un format intermédiaire binaire appelé LLB qui est utilisé pour définir le graphe de dépendances pour les processus exécutant une partie de votre build. tl;dr : LLB est au Dockerfile ce que LLVM IR est au C.
Réorganisé en tant que messages Protobuf
Exécutable simultanément
Mise en cache efficace
Indépendant du fournisseur (c'est-à-dire que les langages non Dockerfile peuvent être facilement implémentés)
Voir solver/pb/ops.proto pour la définition du format et voir ./examples/README.md pour des exemples d'applications LLB.
Actuellement, les langages de haut niveau suivants ont été implémentés pour LLB :
Dockerfile (voir Explorer les fichiers Docker)
Packs de construction
Fichier moqueur
Fichier Gocker
bldr (fichier paquet)
HLB
Fichier terrestre (terrestre)
Quai de fret (rouille)
Rien
mopy (Python)
envd (starlark)
Chialer
Basse
kraft.yaml (Unikraft)
r2d4/llb (passerelle JSON)
(ouvrez un PR pour ajouter votre propre langue)
Les frontends sont des composants qui s'exécutent dans BuildKit et convertissent n'importe quelle définition de build en LLB. Il existe une interface spéciale appelée gateway ( gateway.v0 ) qui permet d'utiliser n'importe quelle image comme interface.
Pendant le développement, l'interface Dockerfile ( dockerfile.v0 ) fait également partie du dépôt BuildKit. À l'avenir, cela sera supprimé et les Dockerfiles pourront être créés à l'aide d'une image externe.
buildctl buildctl construire
--frontend=dockerfile.v0
--contexte local=.
--local dockerfile=.# oubuildctl build
--frontend=dockerfile.v0
--contexte local=.
--local dockerfile=.
--opt cible=foo
--opt build-arg:foo=bar --local expose les fichiers sources locaux du client au constructeur. context et dockerfile sont les noms que l'interface Dockerfile recherche pour le contexte de construction et l'emplacement Dockerfile.
Si le Dockerfile a un nom de fichier différent, il peut être spécifié avec --opt filename=./Dockerfile-alternative .
Les versions externes de l'interface Dockerfile sont transférées vers https://hub.docker.com/r/docker/dockerfile-upstream et https://hub.docker.com/r/docker/dockerfile et peuvent être utilisées avec l'interface de la passerelle . La source du frontend externe se trouve actuellement dans ./frontend/dockerfile/cmd/dockerfile-frontend mais quittera ce référentiel à l'avenir (#163). Pour la construction automatique à partir de la branche principale de ce référentiel, l'image docker/dockerfile-upstream:master ou docker/dockerfile-upstream:master-labs peut être utilisée.
buildctl construire
--passerelle frontale.v0
--opt source=docker/dockerfile
--contexte local=.
--local dockerfile=.
buildctl construire
--passerelle frontale.v0
--opt source=docker/dockerfile
--opt contexte=https://github.com/moby/moby.git
--opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.orgPar défaut, le résultat de la construction et le cache intermédiaire ne resteront qu'en interne dans BuildKit. Une sortie doit être spécifiée pour récupérer le résultat.
buildctl build ... --output type=image,name=docker.io/username/image,push=true
Pour exporter l'image vers plusieurs registres :
buildctl build ... --output type=image,"name=docker.io/username/image,docker.io/username2/image2",push=true
Pour exporter le cache intégré avec l'image et les transférer ensemble vers le registre, tapez registry est requis pour importer le cache, vous devez spécifier --export-cache type=inline et --import-cache type=registry,ref=... . Pour exporter le cache directement vers un local, vous devez spécifier --export-cache type=local . Détails dans le cache d'exportation.
buildctl construire... --output type=image,name=docker.io/username/image,push=true --export-cache type=en ligne --import-cache type=registry,ref=docker.io/username/image
Clés prises en charge par la sortie d'image :
name= : spécifiez le(s) nom(s) de l'image
push=true : push après la création de l'image
push-by-digest=true : pousser une image sans nom
registry.insecure=true : pousser vers le registre HTTP non sécurisé
oci-mediatypes=true : utiliser les types de médias OCI dans la configuration JSON au lieu de ceux de Docker
unpack=true : décompresser l'image après la création (à utiliser avec containersd)
dangling-name-prefix= : nom de l'image avec prefix@ , utilisé pour les images anonymes
name-canonical=true : ajoute un nom canonique supplémentaire name@
compression= : choisissez le type de compression pour les couches nouvellement créées et mises en cache, gzip est la valeur par défaut. estargz doit être utilisé avec oci-mediatypes=true .
compression-level= : niveau de compression pour gzip, estargz (0-9) et zstd (0-22)
rewrite-timestamp=true : réécrit les horodatages du fichier à la valeur SOURCE_DATE_EPOCH . Voir docs/build-repro.md pour savoir comment spécifier la valeur SOURCE_DATE_EPOCH .
force-compression=true : appliquer de force l'option compression à tous les calques (y compris les calques déjà existants)
store=true : stocke les images résultantes dans le magasin d'images du travailleur (par exemple, containersd) et garantit que l'image contient tous les blobs dans le magasin de contenu ( true par défaut). Ignoré si le travailleur n'a pas de magasin d'images (par exemple, le travailleur OCI).
annotation. : attache une annotation avec la key et value respectives à l'image construite
En utilisant les syntaxes étendues, annotation- , annotation[ et les deux combinées avec annotation- , permet de configurer exactement où attacher l'annotation.
manifest (valeur par défaut), manifest-descriptor , index et index-descriptor
platform , voir docs/multi-platform.md .
Voir docs/annotations.md pour plus de détails.
Si des informations d'identification sont requises, buildctl tentera de lire le fichier de configuration Docker $DOCKER_CONFIG/config.json . $DOCKER_CONFIG est par défaut ~/.docker .
Le client local copiera les fichiers directement sur le client. Ceci est utile si BuildKit est utilisé pour créer autre chose que des images de conteneur.
buildctl build ... --output type=local,dest=chemin/vers/output-dir
Pour exporter des fichiers spécifiques, utilisez des constructions en plusieurs étapes avec une étape de travail et copiez les fichiers nécessaires dans cette étape avec COPY --from .
...FROM scratch en tant que testresultCOPY --from=builder /usr/src/app/testresult.xml . ...
buildctl build ... --opt target=testresult --output type=local,dest=path/to/output-dir
Avec une version multi-plateforme, un sous-dossier correspondant à chaque plateforme cible sera créé dans le répertoire de destination :
FROM busbox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROM scratchCOPY --from=build /out /
$ buildctl construire
--frontend dockerfile.v0
--opt plateforme=linux/amd64,linux/arm64
--output type=local,dest=./bin/release
$ arbre ./bin
./bin/
└── libération
├── linux_amd64
│ └── bonjour-linux-amd64
└── linux_arm64
└── bonjour-linux-arm64 Vous pouvez définir platform-split=false pour fusionner les fichiers de toutes les plates-formes dans le même répertoire :
$ buildctl construire
--frontend dockerfile.v0
--opt plateforme=linux/amd64,linux/arm64
--output type=local,dest=./bin/release,platform-split=false
$ arbre ./bin
./bin/
└── libération
├── bonjour-linux-amd64
└── bonjour-linux-arm64L'exportateur Tar est similaire à l'exportateur local mais transfère les fichiers via une archive tar.
buildctl build ... --output type=tar,dest=out.tar buildctl build ... --output type=tar > out.tar
# L'archive tar exportée est également compatible avec la build OCI specbuildctl ... --output type=docker,name=myimage | chargement du docker
buildctl build ... --output type=oci,dest=path/to/output.tar buildctl build ... --output type=oci > sortie.tar
Le travailleur conteneurd doit être utilisé
buildctl build ... --output type=image,name=docker.io/username/image ctr --namespace=buildkit images ls
Pour modifier l'espace de noms containersd, vous devez modifier worker.containerd.namespace dans /etc/buildkit/buildkitd.toml .
Pour afficher le cache de build local ( /var/lib/buildkit ) :
buildctl du -v
Pour élaguer le cache de build local :
buildctl prune
Voir ./docs/buildkitd.toml.md .
BuildKit prend en charge les exportateurs de cache suivants :
inline : intégrez le cache dans l'image et transférez-les ensemble vers le registre
registry : pousser l'image et le cache séparément
local : exporter vers un répertoire local
gha : exporter vers le cache GitHub Actions
Dans la plupart des cas, vous souhaitez utiliser l'exportateur de cache inline . Cependant, notez que l'exportateur de cache inline ne prend en charge que le mode cache min . Pour activer le mode cache max , transférez l'image et le cache séparément à l'aide de l'exportateur de cache registry .
Les exportateurs inline et registry stockent tous deux le cache dans le registre. Pour importer le cache, type=registry suffit dans les deux cas, car il n'est pas nécessaire de spécifier le format du cache.
buildctl construire... --output type=image,name=docker.io/username/image,push=true --export-cache type=en ligne --import-cache type=registry,ref=docker.io/username/image
Notez que le cache en ligne n'est pas importé sauf si --import-cache type=registry,ref=... est fourni.
Le cache en ligne intègre les métadonnées du cache dans la configuration de l'image. Les calques de l'image resteront intacts par rapport à l'image sans informations de cache.
BuildKit intégré à Docker ( DOCKER_BUILDKIT=1 docker build ) et docker buildx nécessitent que --build-arg BUILDKIT_INLINE_CACHE=1 soit spécifié pour activer l'exportateur de cache inline . Cependant, le buildctl autonome ne nécessite PAS --opt build-arg:BUILDKIT_INLINE_CACHE=1 et le build-arg est simplement ignoré.
buildctl construire... --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= : spécifie les couches de cache à exporter (par défaut : min )
min : exporter uniquement les calques pour l'image résultante
max : exporte toutes les couches de toutes les étapes intermédiaires
ref= : spécifiez la référence du référentiel pour stocker le cache, par exemple docker.io/user/image:tag
image-manifest= : s'il faut exporter le manifeste du cache en tant que manifeste d'image compatible OCI plutôt qu'en tant que liste/index de manifeste (par défaut : false , doit être utilisé avec oci-mediatypes=true )
oci-mediatypes= : s'il faut utiliser les types de médias OCI dans les manifestes exportés (par défaut : true , depuis BuildKit v0.8 )
compression= : choisissez le type de compression pour les couches nouvellement créées et mises en cache, gzip est la valeur par défaut. estargz et zstd doivent être utilisés avec oci-mediatypes=true
compression-level= : choisissez le niveau de compression pour gzip, estargz (0-9) et zstd (0-22)
force-compression=true : appliquer de force l'option compression à tous les calques
ignore-error= : spécifie si l'erreur est ignorée en cas d'échec de l'exportation du cache (par défaut : false )
--import-cache :
type=registry
ref= : spécifiez la référence du référentiel à partir duquel récupérer le cache, par exemple docker.io/user/image:tag
buildctl build ... --export-cache type=local,dest=chemin/vers/output-dir buildctl build ... --import-cache type=local,src=chemin/vers/input-dir
La disposition du répertoire est conforme à OCI Image Spec v1.0.
--export-cache :
type=local
mode= : spécifie les couches de cache à exporter (par défaut : min )
min : exporter uniquement les calques pour l'image résultante
max : exporte toutes les couches de toutes les étapes intermédiaires
dest= : répertoire de destination pour l'exportateur de cache
tag= : spécifiez la balise personnalisée de l'image à écrire dans l'index local (par défaut : latest )
image-manifest= : s'il faut exporter le manifeste du cache en tant que manifeste d'image compatible OCI plutôt qu'en tant que liste/index de manifeste (par défaut : false , doit être utilisé avec oci-mediatypes=true )
oci-mediatypes= : s'il faut utiliser les types de médias OCI dans les manifestes exportés ( true par défaut, depuis BuildKit v0.8 )
compression= : choisissez le type de compression pour les couches nouvellement créées et mises en cache, gzip est la valeur par défaut. estargz et zstd doivent être utilisés avec oci-mediatypes=true .
compression-level= : niveau de compression pour gzip, estargz (0-9) et zstd (0-22)
force-compression=true : appliquer de force l'option compression à tous les calques
ignore-error= : spécifie si l'erreur est ignorée en cas d'échec de l'exportation du cache (par défaut : false )
--import-cache :
type=local
src= : répertoire source pour l'importateur de cache
tag= : spécifiez la balise personnalisée de l'image à lire à partir de l'index local (par défaut : latest )
digest=sha256: : spécifie un résumé explicite de la liste des manifestes à importer
buildctl construire... --output type=image,name=docker.io/username/image,push=true --export-cache type=gha --import-cache type=gha
Le cache GitHub Actions enregistre à la fois les métadonnées et les couches du cache dans le service Cache de GitHub. Ce cache a actuellement une taille limite de 10 Go qui est partagée entre différents caches du dépôt. Si vous dépassez cette limite, GitHub enregistrera votre cache mais commencera à l'expulser jusqu'à ce que la taille totale soit inférieure à 10 Go. Le recyclage trop fréquent des caches peut entraîner un ralentissement global des exécutions.
De la même manière que pour l'utilisation d'actions/cache, les caches sont limités à chaque branche, les branches par défaut et cibles étant disponibles pour chaque branche.
Les attributs suivants sont requis pour s'authentifier auprès de l'API du service GitHub Actions Cache :
url : URL du serveur de cache (par défaut $ACTIONS_CACHE_URL )
token : Jeton d'accès (par défaut $ACTIONS_RUNTIME_TOKEN )
Ce type de cache peut être utilisé avec Docker Build Push Action où url et token seront automatiquement définis. Pour utiliser ce backend dans une étape run en ligne, vous devez inclure crazy-max/ghaction-github-runtime dans votre flux de travail pour exposer le runtime.
--export-cache :
type=gha
mode= : spécifie les couches de cache à exporter (par défaut : min )
min : exporter uniquement les calques pour l'image résultante
max : exporte toutes les couches de toutes les étapes intermédiaires
scope= : à quel objet de cache de portée appartient ( buildkit par défaut)
ignore-error= : spécifie si l'erreur est ignorée en cas d'échec de l'exportation du cache (par défaut : false )
timeout= : définit la durée du délai d'expiration pour l'exportation du cache (par défaut : 10m )
--import-cache :
type=gha
scope= : à quel objet de cache de portée appartient ( buildkit par défaut)
timeout= : définit la durée du délai d'attente pour l'importation du cache (par défaut : 10m )
buildctl construire... --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
Les attributs suivants sont requis :
bucket : compartiment AWS S3 (par défaut : $AWS_BUCKET )
region : région AWS (par défaut : $AWS_REGION )
Lieux de stockage :
blobs : s3:// , par défaut : s3://
manifestes : s3:// , par défaut : s3://
Configuration S3 :
blobs_prefix : préfixe global pour stocker/lire les blobs sur s3 (par défaut : blobs/ )
manifests_prefix : préfixe global pour stocker/lire les manifestes sur s3 (par défaut : manifests/ )
endpoint_url : spécifiez un point de terminaison S3 spécifique (par défaut : vide)
use_path_style : s'il est défini sur true , placez le nom du bucket dans l'URL plutôt que dans le nom d'hôte (par défaut : false )
Authentification AWS :
Le moyen le plus simple consiste à utiliser un profil d'instance IAM. Les autres options sont :
Tout système utilisant des variables d'environnement/fichiers de configuration pris en charge par le SDK AWS Go. La configuration doit être disponible pour le démon buildkit, pas pour le client.
En utilisant les attributs suivants :
access_key_id : ID de clé d'accès
secret_access_key : Clé d'accès secrète
session_token : jeton de session
--export-cache :
type=s3
mode= : spécifie les couches de cache à exporter (par défaut : min )
min : exporter uniquement les calques pour l'image résultante
max : exporte toutes les couches de toutes les étapes intermédiaires
prefix= : définit le préfixe global pour stocker/lire les fichiers sur s3 (par défaut : vide)
name= : spécifiez le nom du manifeste à utiliser ( buildkit par défaut)
Plusieurs noms de manifeste peuvent être spécifiés en même temps, séparés par ; . Le cas d'utilisation standard consiste à utiliser le git sha1 comme nom et le nom de la branche comme doublon, et à charger les deux avec 2 commandes import-cache .
ignore-error= : spécifie si l'erreur est ignorée en cas d'échec de l'exportation du cache (par défaut : false )
touch_refresh=24h : Au lieu d'être téléchargés à nouveau lorsqu'ils ne sont pas modifiés, les fichiers blobs seront "touchés" sur s3 à chaque touch_refresh , la valeur par défaut est 24h. Pour cette raison, une politique d'expiration peut être définie sur le compartiment S3 pour nettoyer automatiquement les fichiers inutiles. Les fichiers manifestes sont systématiquement réécrits, il n'est pas nécessaire d'y toucher.
upload_parallelism=4 : Ce paramètre modifie le nombre de couches téléchargées sur s3 en parallèle. Chaque couche individuelle est téléchargée avec 5 threads, à l'aide du gestionnaire de téléchargement fourni par le SDK AWS.
--import-cache :
type=s3
prefix= : définit le préfixe global pour stocker/lire les fichiers sur s3 (par défaut : vide)
blobs_prefix= : définit le préfixe global pour stocker/lire les blobs sur s3 (par défaut : blobs/ )
manifests_prefix= : définir le préfixe global pour stocker/lire les manifestes sur s3 (par défaut : manifests/ )
name= : nom du manifeste à utiliser ( buildkit par défaut)
buildctl construire... --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
Les attributs suivants sont requis :
account_url : URL du compte Azure Blob Storage (par défaut : $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL )
Lieux de stockage :
blobs :
manifestes :
Configuration du stockage Blob Azure :
container : Le nom du conteneur Azure Blob Storage (par défaut : buildkit-cache ou $BUILDKIT_AZURE_STORAGE_CONTAINER si défini)
blobs_prefix : Préfixe global pour stocker/lire les blobs sur le conteneur Azure Blob Storage ( blobs/ )
manifests_prefix : préfixe global pour stocker/lire les blobs sur le conteneur Azure Blob Storage ( manifests/ )
Authentification Azure Blob Storage :
Il existe 2 options prises en charge pour l’authentification Azure Blob Storage :
Tout système utilisant des variables d’environnement prises en charge par le SDK Azure pour Go. La configuration doit être disponible pour le démon buildkit, pas pour le client.
Clé d'accès secrète, utilisant l'attribut secret_access_key pour spécifier la clé de compte primaire ou secondaire de votre compte Azure Blob Storage. Clés de compte Azure Blob Storage
Note
Le nom du compte peut également être spécifié avec l'attribut account_name (ou $BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME ) s'il ne fait pas partie de l'hôte de l'URL du compte.
--export-cache :
type=azblob
mode= : spécifie les couches de cache à exporter (par défaut : min )
min : exporter uniquement les calques pour l'image résultante
max : exporte toutes les couches de toutes les étapes intermédiaires
prefix= : définit le préfixe global pour stocker/lire les fichiers sur le conteneur Azure Blob Storage (
name= : spécifiez le nom du manifeste à utiliser (par défaut : buildkit )
Plusieurs noms de manifeste peuvent être spécifiés en même temps, séparés par ; . Le cas d'utilisation standard consiste à utiliser le git sha1 comme nom et le nom de la branche comme doublon, et à charger les deux avec 2 commandes import-cache .
ignore-error= : spécifie si l'erreur est ignorée en cas d'échec de l'exportation du cache (par défaut : false )
--import-cache :
type=azblob
prefix= : définit le préfixe global pour stocker/lire les fichiers sur le conteneur Azure Blob Storage (
blobs_prefix= : définit le préfixe global pour stocker/lire les blobs sur le conteneur Azure Blob Storage ( blobs/ )
manifests_prefix= : définir le préfixe global pour stocker/lire les manifestes sur le conteneur Azure Blob Storage ( manifests/ )
name= : nom du manifeste à utiliser (par défaut : buildkit )
Si vous disposez de plusieurs instances de démon BuildKit, mais que vous ne souhaitez pas utiliser le registre pour partager le cache sur le cluster, envisagez l'équilibrage de charge côté client à l'aide d'un hachage cohérent.
Voir ./examples/kubernetes/consistenthash .
Pour générer des métadonnées de construction telles que le résumé de l'image, transmettez l'indicateur --metadata-file . Les métadonnées seront écrites sous forme d'objet JSON dans le fichier spécifié. Le répertoire du fichier spécifié doit déjà exister et être accessible en écriture.
buildctl build ... --metadata-file métadata.json
jq'.' métadonnées.json
{ "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "containerimage.descriptor": {"annotations": { "config.digest": "sha256:2937f66a9722f7" f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "org.opencontainers.image.created": " 2022-02-08T21:28:03Z"},"digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3","mediaType": "application/vnd.oci.image.manifest.v1+json","size": 506
}, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"} Sur les systèmes basés sur Systemd, vous pouvez communiquer avec le démon via l'activation du socket Systemd, utilisez buildkitd --addr fd:// . Vous pouvez trouver des exemples d'utilisation de l'activation du socket Systemd avec BuildKit et Systemd dans ./examples/systemd .
Le démon buildkitd peut écouter l'API gRPC sur un socket TCP.
Il est fortement recommandé de créer des certificats TLS pour le démon et le client (mTLS). L'activation de TCP sans mTLS est dangereuse car les conteneurs exécuteurs (alias conteneurs Dockerfile RUN ) peuvent également appeler l'API BuildKit.
kit de construction --addr tcp://0.0.0.0:1234 --tlscacert /chemin/vers/ca.pem --tlscert /chemin/vers/cert.pem --tlskey /chemin/vers/key.pem
construirectl --addr tcp://exemple.com:1234 --tlscacert /chemin/vers/ca.pem --tlscert /chemin/vers/clientcert.pem --tlskey /chemin/vers/clientkey.pem construire ...
buildctl build peut être appelé contre des démons buildkitd à charge aléatoire.
Voir également Hachage cohérent pour l’équilibrage de charge côté client.
BuildKit peut également être utilisé en exécutant le démon buildkitd dans un conteneur Docker et en y accédant à distance.
Nous fournissons les images du conteneur sous la forme moby/buildkit :
moby/buildkit:latest : construit à partir de la dernière version régulière
moby/buildkit:rootless : identique au latest mais s'exécute en tant qu'utilisateur non privilégié, voir docs/rootless.md
moby/buildkit:master : construit à partir de la branche master
moby/buildkit:master-rootless : identique à master mais s'exécute en tant qu'utilisateur non privilégié, voir docs/rootless.md
Pour exécuter un démon dans un conteneur :
docker run -d --name buildkitd --privileged moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd buildctl construire --help
Pour vous connecter à un démon BuildKit exécuté dans un conteneur Podman, utilisez podman-container:// au lieu de 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 charge foo
sudo n'est pas obligatoire.
Pour vous connecter à un démon BuildKit exécuté dans un conteneur Nerdctl, utilisez nerdctl-container:// au lieu de 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 | charge nerdctl
sudo n'est pas obligatoire.
Pour les déploiements Kubernetes, voir examples/kubernetes .
Pour exécuter le client et un démon éphémère dans un seul conteneur (« mode sans démon ») :
exécution du docker
-il
--rm
--privilégié
-v /chemin/vers/rép:/tmp/work
--entrypoint buildctl-daemonless.sh
moby/buildkit:maître
construire
--frontend dockerfile.v0
--local context=/tmp/work
--local dockerfile=/tmp/workou
exécution du docker
-il
--rm
--security-opt seccomp=non confiné
--security-opt apparmor=non confiné
-e BUILDKITD_FLAGS=--oci-worker-no-process-sandbox
-v /chemin/vers/rép:/tmp/work
--entrypoint buildctl-daemonless.sh
moby/buildkit:master-rootless
construire
--l'extrémité avant
dockerfile.v0
--local context=/tmp/work
--local dockerfile=/tmp/work BuildKit prend en charge OpenTelemetry pour l'API gRPC buildkitd et les commandes buildctl. Pour capturer la trace vers Jaeger, définissez la variable d'environnement JAEGER_TRACE sur l'adresse de collecte.
docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latestexport JAEGER_TRACE=0.0.0.0:6831# redémarrez buildkitd et buildctl pour qu'ils sachent JAEGER_TRACE# toute commande buildctl doit être tracée vers http:/ /127.0.0.1:16686/
Sous Windows, si vous exécutez Jaeger en dehors d'un conteneur,
jaeger-all-in-one.exe, définissez la variable d'environnementsetx -m JAEGER_TRACE "0.0.0.0:6831", redémarrezbuildkitddans un nouveau terminal et les traces seront collectés automatiquement.
Veuillez vous référer à docs/rootless.md .
Veuillez vous référer à docs/multi-platform.md .
buildctl buildctl prend en charge la modification des couleurs utilisées pour afficher les informations vers le terminal. Vous pouvez définir la variable d'environnement BUILDKIT_COLORS sur quelque chose comme run=green:warning=yellow:error=red:cancel=255,165,0 pour définir les couleurs que vous souhaitez utiliser. Définir NO_COLOR sur n'importe quoi désactivera toute sortie colorisée comme recommandé par no-color.org.
Les erreurs d'analyse seront signalées mais ignorées. Cela entraînera l'utilisation des valeurs de couleur par défaut lorsque cela est nécessaire.
La liste des couleurs prédéfinies.
Vous pouvez modifier le nombre de lignes de journal visibles pour les étapes actives en mode tty en définissant BUILDKIT_TTY_LOG_LINES sur un nombre (par défaut : 6).
Vous souhaitez contribuer à BuildKit ? Génial! Vous pouvez trouver des informations sur la contribution à ce projet dans CONTRIBUTING.md
