Builds Docker multi-arch em 2026 — entregar ARM e x86 do mesmo pipeline

Há alguns anos, «ARM em produção» era um projeto de hobby. Em 2026, instâncias AWS Graviton são rotineiramente 20-40 % mais baratas para a mesma carga, GCP Axion é mainstream, Azure Ampere está GA, e metade do time de dev está em Apple Silicon. Se suas imagens de container não rodam nativamente em ARM, você está deixando dinheiro e experiência de desenvolvedor na mesa.

A boa notícia: builds Docker multi-arch em 2026 são mais fáceis do que builds single-arch eram em 2019. O truque é saber onde o tempo e o custo de fato vão.

Builds paralelos nativos batem a emulação 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

Builds paralelos nativos terminam em mais ou menos o mesmo tempo de um build single-arch. Builds arm64 emulados via QEMU para stacks compute-pesadas (releases Rust, Go) levam 4-8× mais que o nativo.

O artigo completo cobre:

• Manifest lists OCI — o que uma imagem multi-arch realmente é
• As variáveis de Dockerfile TARGETARCH e TARGETPLATFORM
• Armadilhas comuns de dependências transitivas Python/npm ao atravessar arquiteturas
• Cache de build baseado em registry, mantido separado por arch
• Smoke-test de ambas as variantes como passo de CI (não opcional)
• Números reais de custo do GitHub Actions — emulado vs nativo

Rodamos este pipeline para cada cliente Docker gerenciado em Graviton / Ampere.