Multi-Arch-Docker-Builds 2026 — ARM und x86 aus derselben Pipeline ausliefern

Vor ein paar Jahren war „ARM in Produktion" ein Hobbyprojekt. 2026 sind AWS-Graviton-Instances regelmäßig 20-40 % günstiger für dieselbe Workload, GCP Axion ist Mainstream, Azure Ampere ist GA, und die halbe Dev-Mannschaft sitzt an Apple Silicon. Wenn Ihre Container-Images nicht nativ auf ARM laufen, lassen Sie spürbares Geld und Developer Experience auf dem Tisch.

Die gute Nachricht: Multi-Arch-Docker-Builds sind 2026 einfacher als Single-Arch-Builds 2019 waren. Der Trick ist zu wissen, wo Zeit und Kosten tatsächlich entstehen.

Native parallele Builds schlagen QEMU-Emulation

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

Native parallele Builds enden ungefähr in der gleichen Zeit wie ein Single-Arch-Build. QEMU-emulierte arm64-Builds für rechenintensive Stacks (Rust-, Go-Release-Builds) dauern 4-8× länger als nativ.

Der vollständige Beitrag behandelt:

• OCI Manifest Lists — was ein Multi-Arch-Image tatsächlich ist
• Die Dockerfile-Variablen TARGETARCH und TARGETPLATFORM
• Häufige Python/npm-Transitive-Dep-Fallen beim Architektur-Wechsel
• Registry-basierter Build-Cache, pro Arch separat gehalten
• Smoke-Test beider Varianten als CI-Schritt (nicht optional)
• Echte GitHub-Actions-Kostenzahlen — emuliert vs nativ

Wir betreiben diese Pipeline für jeden gemanagten Docker-Kunden auf Graviton / Ampere.