Docker Bake passe en GA et rend le build multi-architecture natif

Février 2025. Docker sort Docker Desktop 4.38 et annonce la disponibilité générale de Docker Bake après des années en statut expérimental. La promesse tient en une commande : docker buildx bake.

Juin 2026. AWS Graviton4 équipe la sixième génération d’instances EC2. AmpereOne double la densité cœur par socket. Apple Silicon est le poste de travail par défaut des développeurs. Et pourtant, une majorité d’équipes maintiennent encore deux pipelines de build séparés — un pour linux/amd64, un pour linux/arm64 — avec des Makefile de 400 lignes et des scripts shell devenus illisibles.

Docker Bake résout ce décalage. Il ne se contente pas d’automatiser les builds ; il rend le multi-architecture natif, déclaratif et reproductible en une seule configuration versionnée. Le genre de bascule qui transforme un irritant quotidien en non-sujet.

Ce que Docker Bake remplace — et pourquoi ça compte

Avant Bake, le build multi-plateforme ressemblait à ceci :

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag registry.example.com/app:latest \
  --tag registry.example.com/app:v1.2.3 \
  --cache-from type=registry,ref=registry.example.com/app:cache \
  --cache-to type=registry,ref=registry.example.com/app:cache,mode=max \
  --provenance=true \
  --sbom=true \
  --push \
  .

Une ligne, mais 8 flags à mémoriser, 3 formats de tag à coordonner et aucune isolation entre les environnements. Multipliez par 12 microservices, ajoutez les variantes dev/staging/prod, et le script shell explose. C’est le mur que toute équipe DevOps rencontre entre le sixième et le douzième service.

Docker Bake remplace ce script par un fichier déclaratif unique — docker-bake.hcl — versionné avec le code. Même build, même résultat, mais lisible, auditable et reproductible d’un git clone :

target "app" {
  context    = "."
  dockerfile = "Dockerfile"
  platforms  = ["linux/amd64", "linux/arm64"]
  tags       = [
    "registry.example.com/app:latest",
    "registry.example.com/app:v1.2.3",
  ]
  cache-from = ["type=registry,ref=registry.example.com/app:cache"]
  cache-to   = ["type=registry,ref=registry.example.com/app:cache,mode=max"]
}

La différence est structurelle. Les flags deviennent des attributs nommés. La configuration est versionnée, revue en pull request et partagée entre le poste local et la CI. Une équipe qui gérait 12 microservices dans un monorepo avec un Makefile de 400 lignes passe à un docker-bake.hcl de 60 lignes — et l’ajout d’un nouveau service tombe de 30 lignes de boilerplate à 3.

Multi-plateforme natif : la fin des scripts par architecture

Le cœur de la proposition Bake, c’est la gestion native des platforms. Un bloc platforms = ["linux/amd64", "linux/arm64"] suffit à déclencher un build parallèle pour chaque architecture, avec création automatique du manifest multi-arch (OCI image index). Docker ou Kubernetes sélectionnent ensuite l’image correspondant à l’architecture du nœud cible.

Cette simplification arrive au bon moment. L’écosystème ARM64 dans le cloud a atteint un point de bascule en 2025-2026 :

• AWS Graviton4 (décembre 2024) offre jusqu’à 30 % de performance supplémentaire par rapport à Graviton3, avec une consommation énergétique inférieure de 40 % aux instances x86 comparables.
• AmpereOne (2025) propose des serveurs ARM64 natifs jusqu’à 192 cœurs par socket, poussant l’adoption dans les datacenters on-premise.
• Apple Silicon domine le parc développeur : selon l’enquête Stack Overflow 2025, 62 % des développeurs utilisent un Mac comme machine principale, dont la quasi-totalité sous Apple Silicon.

Le résultat est un split architecture quasi-systématique : le développeur build sur ARM64, la CI tourne souvent sur AMD64, et la production peut mixer les deux selon les niveaux de service. Sans Bake, ce split se traduit par des scripts de build dupliqués, des tags incohérents et des fenêtres où une des deux architectures manque dans le registre.

Avec Bake, le build est atomique : les deux architectures sont produites ensemble, taguées ensemble, poussées ensemble. Plus de « j’ai oublié de pousser l’image ARM64 ».

Matrix builds : une config, N variantes

La fonctionnalité la plus puissante de Bake est le matrix build. Là où un docker buildx build suppose un build par invocation, Bake permet de définir un build paramétré qui s’expand en N builds parallèles :

target "app" {
  matrix = {
    mode = ["release", "debug"]
  }
  name   = "app-${mode}"
  tags   = [mode == "release" ? "app:latest" : "app:dev"]
  args   = {
    BUILD_MODE = mode
  }
}

Deux valeurs de mode produisent deux builds distincts — app-release et app-debug — exécutés en parallèle, chacun avec ses propres tags et arguments. Combinez avec les platforms et vous obtenez 4 builds parallèles (2 modes × 2 architectures) à partir de 4 lignes de configuration.

Le name dynamique ("app-${mode}") garantit que chaque combinaison du script matrix produit un target unique dans le graphe de build. Pas de collision de tags, pas de build qui en écrase un autre.

Les cas d’usage concrets sont nombreux :

• Variantes par environnement : dev / staging / prod avec des build-args différents (endpoints API, niveaux de log, clés de feature flag).
• Variantes par runtime : une image node:20 et une node:22 pour valider la compatibilité avant migration.
• Variantes par distribution : alpine, debian-slim, distroless pour des contraintes de taille ou de compliance différentes.

Docker Build Cloud : le build distribué sans infrastructure

Bake s’intègre nativement avec Docker Build Cloud (DBC), le service de build managé de Docker. L’intérêt est immédiat pour les équipes qui buildent du multi-architecture sur du matériel limité :

• Un build ARM64 émulé via QEMU sur une machine AMD64 ajoute 8 à 12 minutes par image pour des langages compilés (Go, Rust, C++). Sur DBC, le build ARM64 tourne sur du matériel ARM64 natif — pas d’émulation, pas de pénalité.
• Les matrix builds sont parallélisés sur l’infrastructure cloud de Docker, pas sur le runner CI local. Un build 12 cibles × 2 architectures × 2 modes = 48 builds parallèles devient réaliste.
• Le cache est partagé entre les builds via le registry cache de DBC, éliminant la recompilation de couches identiques entre les targets.

Résultat concret : une équipe qui passait 45 minutes par pipeline de build multi-arch sur un runner GitHub Actions standard tombe à 8 minutes en déportant le build sur Docker Build Cloud avec Bake.

Ce que la GA apporte de neuf

Docker Bake existait en mode expérimental depuis plusieurs années. La GA de février 2025 apporte quatre améliorations qui changent la donne pour la production :

• Déduplication des contextes : quand plusieurs targets partagent le même build context, Bake ne le transfère qu’une seule fois au builder au lieu de N fois. Gain mesurable dès qu’on dépasse 3-4 targets.
• Entitlements : contrôle fin de ce que le builder a le droit d’accéder — réseau host, sandbox, système de fichiers, agent SSH. Critique pour les environnements où le build accède à des secrets ou des registres privés.
• Attributs composables : des blocs de configuration réutilisables (inherits) qui peuvent être mixés et surchargés entre targets. L’équivalent Docker des mixins CSS.
• Validation de variables : comme en Terraform, les variables de build peuvent être validées avant exécution. Plus de build qui échoue après 20 minutes parce qu’un IMAGE_REGISTRY est mal formaté.

Verdict

Docker Bake ne résout pas un problème que vous n’avez pas encore. Il résout celui que vous avez depuis que votre deuxième service est passé en production.

Le seuil de pertinence est simple :

• Une image, une architecture : docker buildx build suffit. Bake est un surcoût.
• Deux architectures ou plus, ou plus de deux services : Bake devient rentable. La configuration déclarative, le versionnement et la déduplication des contextes justifient l’investissement d’apprentissage (une après-midi).
• Matrix builds ou Docker Build Cloud : Bake est indispensable. Aucun script shell ne gère proprement la combinatorie plateformes × modes × environnements sur du build distribué.

Si vous maintenez encore un Makefile de build Docker qui dépasse 100 lignes, arrêtez de lire et migrez. Le docker-bake.hcl de remplacement fera 20 lignes, passera en code review, et ne plantera plus à 3 h du matin parce que quelqu’un a changé l’ordre des flags.

Références

• Docker Bake: Now Generally Available — Docker Blog, 5 février 2025
• Farewell to Build Scripts as Docker Bake Goes GA — InfoQ, 24 février 2025
• Mastering multi-platform builds with Docker Buildx Bake — Docker Docs
• Docker Bake and Buildx: Declarative Multi-Platform Builds — TheCodeForge, juillet 2026
• AWS Graviton4 — Annonce générale, décembre 2024
• AmpereOne Family — Ampere Computing, 2025
• Stack Overflow Developer Survey 2025