Builds Docker multi-arch en 2026 — entregar ARM y x86 desde el mismo pipeline

Hace unos años, «ARM en producción» era un proyecto de hobby. En 2026 las instancias AWS Graviton son habitualmente 20-40 % más baratas para la misma carga, GCP Axion es mainstream, Azure Ampere está en GA, y la mitad del equipo de desarrollo está en Apple Silicon. Si tus imágenes de contenedor no corren nativamente en ARM, estás dejando dinero y experiencia de desarrollador sobre la mesa.

La buena noticia: los builds Docker multi-arch en 2026 son más fáciles que los builds single-arch en 2019. El truco es saber dónde va realmente el tiempo y el coste.

Los builds paralelos nativos baten la emulación 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

Los builds paralelos nativos terminan más o menos en el mismo tiempo que un build single-arch. Los builds arm64 emulados con QEMU para stacks pesadas en cómputo (releases Rust, Go) tardan 4-8× más que el nativo.

El artículo completo cubre:

• Las manifest lists OCI — qué es realmente una imagen multi-arch
• Las variables de Dockerfile TARGETARCH y TARGETPLATFORM
• Trampas comunes de dependencias transitivas Python/npm al cruzar arquitecturas
• Caché de build basada en registry, mantenida separada por arch
• Smoke-test de ambas variantes como paso de CI (no opcional)
• Cifras de coste reales de GitHub Actions — emulado vs nativo

Ejecutamos este pipeline para cada cliente Docker gestionado en Graviton / Ampere.