⚠️ Traduction non officielle - Cette documentation est une traduction communautaire non officielle de Docker.

BuildKit

Table des matières

Vue d'ensemble

BuildKit est un backend amélioré destiné à remplacer l'ancien builder. BuildKit est le builder par défaut pour les utilisateurs de Docker Desktop, et de Docker Engine à partir de la version 23.0.

BuildKit apporte de nouvelles fonctionnalités et améliore les performances de vos builds. Il introduit également le support de scénarios plus complexes :

  • Détecter et sauter l'exécution des étapes de build inutilisées
  • Paralléliser la construction des étapes de build indépendantes
  • Transférer de manière incrémentale uniquement les fichiers modifiés de votre contexte de build entre les builds
  • Détecter et sauter le transfert des fichiers inutilisés de votre contexte de build
  • Utiliser des implémentations de frontend Dockerfile avec de nombreuses nouvelles fonctionnalités
  • Éviter les effets de bord avec le reste de l'API (images et conteneurs intermédiaires)
  • Prioriser votre cache de build pour une purge automatique

Outre de nombreuses nouvelles fonctionnalités, les principaux domaines dans lesquels BuildKit améliore l'expérience actuelle sont la performance, la gestion du stockage et l'extensibilité. Côté performance, une mise à jour majeure est le nouveau solveur de graphe de build entièrement concurrent. Il peut exécuter des étapes de build en parallèle lorsque c'est possible et optimiser les commandes qui n'ont pas d'impact sur le résultat final. Nous avons également optimisé l'accès aux fichiers sources locaux. En ne suivant que les mises à jour de ces fichiers entre les invocations de build répétées, il n'est plus nécessaire d'attendre que les fichiers locaux soient lus ou téléversés pour que le travail puisse commencer.

LLB

Au cœur de BuildKit se trouve un format de définition Low-Level Build (LLB). LLB est un format binaire intermédiaire qui permet aux développeurs d'étendre BuildKit. LLB définit un graphe de dépendances adressable par contenu qui peut être utilisé pour assembler des définitions de build très complexes. Il supporte également des fonctionnalités non exposées dans les Dockerfiles, comme le montage direct de données et l'invocation imbriquée.

Tout ce qui concerne l'exécution et la mise en cache de vos builds est défini dans LLB. Le modèle de mise en cache est entièrement réécrit par rapport à l'ancien builder. Plutôt que d'utiliser des heuristiques pour comparer les images, LLB suit directement les sommes de contrôle des graphes de build et du contenu monté sur des opérations spécifiques. Cela le rend beaucoup plus rapide, plus précis et portable. Le cache de build peut même être exporté vers un registre, où il peut être récupéré à la demande par des invocations ultérieures sur n'importe quel hôte.

LLB peut être généré directement en utilisant un paquet client Go qui permet de définir les relations entre vos opérations de build en utilisant les primitives du langage Go. Cela vous donne toute la puissance nécessaire pour exécuter tout ce que vous pouvez imaginer, mais ce ne sera probably pas la façon dont la plupart des gens définiront leurs builds. Au lieu de cela, la plupart des utilisateurs utiliseraient un composant frontend, ou une invocation imbriquée de LLB, pour exécuter un ensemble préparé d'étapes de build.

Frontend

Un frontend est un composant qui prend un format de build lisible par l'homme et le convertit en LLB pour que BuildKit puisse l'exécuter. Les frontends peuvent être distribués sous forme d'images, et l'utilisateur peut cibler une version spécifique d'un frontend qui est garantie de fonctionner pour les fonctionnalités utilisées par sa définition.

Par exemple, pour construire un Dockerfile avec BuildKit, vous utiliseriez un frontend Dockerfile externe.

Démarrage

BuildKit est le builder par défaut pour les utilisateurs de Docker Desktop et de Docker Engine v23.0 et versions ultérieures.

Si vous avez installé Docker Desktop, vous n'avez pas besoin d'activer BuildKit. Si vous utilisez une version de Docker Engine antérieure à la 23.0, vous pouvez activer BuildKit soit en définissant une variable d'environnement, soit en faisant de BuildKit le paramètre par défaut dans la configuration du démon.

Pour définir la variable d'environnement BuildKit lors de l'exécution de la commande docker build, exécutez :

$ DOCKER_BUILDKIT=1 docker build .
Note

Buildx utilise toujours BuildKit.

Pour utiliser Docker BuildKit par défaut, modifiez la configuration du démon Docker dans /etc/docker/daemon.json comme suit, et redémarrez le démon.

{
  "features": {
    "buildkit": true
  }
}

Si le fichier /etc/docker/daemon.json n'existe pas, créez un nouveau fichier appelé daemon.json et ajoutez-y ce qui suit. Redémarrez ensuite le démon Docker.

BuildKit sur Windows

Warning

BuildKit ne supporte pleinement que la construction de conteneurs Linux. Le support des conteneurs Windows est expérimental.

BuildKit a un support expérimental pour les conteneurs Windows (WCOW) depuis la version 0.13. Cette section vous guide à travers les étapes pour l'essayer. Nous apprécions tout commentaire que vous soumettez en ouvrant une issue ici, en particulier concernant buildkitd.exe.

Limitations connues

Pour plus d'informations sur les bogues ouverts et les limitations liés à BuildKit sur Windows, consultez les issues GitHub.

Prérequis

  • Architecture : amd64, arm64 (binaires disponibles mais pas encore officiellement testés).
  • OS supportés : Windows Server 2019, Windows Server 2022, Windows 11.
  • Images de base : ServerCore:ltsc2019, ServerCore:ltsc2022, NanoServer:ltsc2022. Consultez la carte de compatibilité ici.
  • Docker Desktop version 4.29 ou ultérieure

Étapes

Note

Les commandes suivantes nécessitent des privilèges d'administrateur (élevés) dans un terminal PowerShell.

  1. Activez les fonctionnalités Windows Hyper-V et Containers.

    > Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V, Containers -All

    Si RestartNeeded est True, redémarrez votre machine et rouvrez un terminal PowerShell en tant qu'administrateur. Sinon, passez à l'étape suivante.

  2. Basculez vers les conteneurs Windows dans Docker Desktop.

    Sélectionnez l'icône Docker dans la barre des tâches, puis Switch to Windows containers....

  3. Installez containerd version 1.7.7 ou ultérieure en suivant les instructions de configuration ici.

  4. Téléchargez et extrayez la dernière version de BuildKit.

    $version = "v0.22.0" # spécifiez la version de la release, v0.13+
$arch = "amd64" # binaire arm64 également disponible
curl.exe -LO https://github.com/moby/buildkit/releases/download/$version/buildkit-$version.windows-$arch.tar.gz
# il pourrait y avoir un autre répertoire `.\bin` des instructions de containerd
# vous pouvez le déplacer
mv bin bin2
tar.exe xvf .\buildkit-$version.windows-$arch.tar.gz
## x bin/
## x bin/buildctl.exe
## x bin/buildkitd.exe

  5. Installez les binaires BuildKit dans le PATH.

    # une fois les binaires extraits dans le répertoire bin
# déplacez-les vers un chemin approprié dans vos répertoires $Env:PATH ou :
Copy-Item -Path ".\bin" -Destination "$Env:ProgramFiles\buildkit" -Recurse -Force
# ajoutez les binaires `buildkitd.exe` et `buildctl.exe` dans le $Env:PATH
$Path = [Environment]::GetEnvironmentVariable("PATH", "Machine") + `
    [IO.Path]::PathSeparator + "$Env:ProgramFiles\buildkit"
[Environment]::SetEnvironmentVariable( "Path", $Path, "Machine")
$Env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + `
    [System.Environment]::GetEnvironmentVariable("Path","User")

  6. Démarrez le démon BuildKit.

    > buildkitd.exe
    Note

    Si vous exécutez un processus containerd géré par dockerd, utilisez-le plutôt, en fournissant l'adresse : buildkitd.exe --containerd-worker-addr "npipe:////./pipe/docker-containerd"

  7. Dans un autre terminal avec des privilèges d'administrateur, créez un builder distant qui utilise le démon BuildKit local.

    Note

    Cela nécessite Docker Desktop version 4.29 ou ultérieure.

    > docker buildx create --name buildkit-exp --use --driver=remote npipe:////./pipe/buildkitd
buildkit-exp

  8. Vérifiez la connexion du builder en exécutant docker buildx inspect.

    > docker buildx inspect

    La sortie doit indiquer que la plateforme du builder est Windows, et que le point de terminaison du builder est un pipe nommé.

    Name:          buildkit-exp
 Driver:        remote
 Last Activity: 2024-04-15 17:51:58 +0000 UTC
 Nodes:
 Name:             buildkit-exp0
 Endpoint:         npipe:////./pipe/buildkitd
 Status:           running
 BuildKit version: v0.13.1
 Platforms:        windows/amd64
...

  9. Créez un Dockerfile et construisez une image hello-buildkit.

    > mkdir sample_dockerfile
> cd sample_dockerfile
> Set-Content Dockerfile @"
FROM mcr.microsoft.com/windows/nanoserver:ltsc2022
USER ContainerAdministrator
COPY hello.txt C:/
RUN echo "Goodbye!" >> hello.txt
CMD ["cmd", "/C", "type C:\\hello.txt"]
"@
Set-Content hello.txt @"
Hello from BuildKit!
This message shows that your installation appears to be working correctly.
"@

  10. Construisez et poussez l'image vers un registre.

    > docker buildx build --push -t <username>/hello-buildkit .

  11. Après avoir poussé vers le registre, exécutez l'image avec docker run.

    > docker run <username>/hello-buildkit