Builds Docker multi-arch en 2026 — livrer ARM et x86 depuis le même pipeline

Il y a quelques années, « ARM en production » était un projet de hobby. En 2026, les instances AWS Graviton sont régulièrement 20-40 % moins chères pour la même charge, GCP Axion est mainstream, Azure Ampere est GA, et la moitié de l'équipe de dev est sur Apple Silicon. Si vos images de conteneurs ne tournent pas nativement sur ARM, vous laissez de l'argent et de l'expérience développeur sur la table.

La bonne nouvelle : les builds Docker multi-arch en 2026 sont plus faciles que les builds single-arch en 2019. L'astuce est de savoir où va réellement le temps et le coût.

Les builds parallèles natifs battent l'émulation QEMU

build-amd64:
  runs-on: ubuntu-latest
  steps:
  - run: docker buildx build --platform linux/amd64 \
      -t ghcr.io/example/app:${SHA}-amd64 --push .
 
build-arm64:
  runs-on: ubuntu-24.04-arm
  steps:
  - run: docker buildx build --platform linux/arm64 \
      -t ghcr.io/example/app:${SHA}-arm64 --push .
 
manifest:
  needs: [build-amd64, build-arm64]
  steps:
  - run: docker buildx imagetools create \
      -t ghcr.io/example/app:${SHA} \
      ghcr.io/example/app:${SHA}-amd64 \
      ghcr.io/example/app:${SHA}-arm64

Les builds parallèles natifs finissent à peu près en même temps qu'un build single-arch. Les builds arm64 émulés QEMU pour des stacks lourdes en calcul (release Rust, Go) prennent 4-8× plus longtemps que le natif.

L'article complet couvre :

Les manifest lists OCI — ce qu'est réellement une image multi-arch
Les variables Dockerfile TARGETARCH et TARGETPLATFORM
Les pièges courants de dépendances transitives Python/npm en croisant les architectures
Cache de build basé sur registry, gardé séparé par arch
Smoke-tester les deux variantes comme étape CI (pas optionnel)
Chiffres de coût réels GitHub Actions — émulé vs natif

Nous faisons tourner ce pipeline pour chaque client Docker managé sur Graviton / Ampere.