Imágenes Docker para múltiples arquitecturas

Contenido del curso

Optimización Avanzada en Docker

Buenas Prácticas en Docker

Instalación y Configuración en Entornos Multiplataforma

Redes Avanzadas y Balanceo de Carga

Automatización de CI/CD

Orquestación

Develop

34
Dev containers en VS Code con Docker
09:54 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:15

Imágenes Docker para múltiples arquitecturas

Curso de Docker Avanzado

Clase 6 de 34

Clase 6 / 34

Recursos

Docker prometió acabar con el clásico "en mi máquina sí funciona", y en gran medida lo logró. Pero cuando entras al detalle de las arquitecturas de procesador, aparece un matiz importante: una imagen creada para tu laptop puede no correr en un servidor ARM o en un Raspberry Pi. Ahí entran las imágenes multiplataforma de Docker, una técnica clave si trabajas con sistemas embebidos, IoT o despliegues heterogéneos.

¿Qué son las imágenes multiplataforma en Docker?

Una imagen multiplataforma es una imagen Docker que se construye para más de una arquitectura de procesador a la vez, de modo que el mismo tag funcione tanto en máquinas x86_64 (AMD64) como en dispositivos ARM64. En lugar de mantener imágenes separadas por hardware, Docker empaqueta varias variantes y elige la correcta según el sistema donde la corras.

¿Para qué sirve una imagen multiplataforma? Para que la misma imagen corra en arquitecturas distintas, como una laptop con procesador AMD64 y un Raspberry Pi con ARM64, sin reconstruir nada por separado.

Esto importa porque hoy convivimos con un espectro amplio: arquitecturas x86, 64 bits, ARM, procesadores móviles y sistemas embebidos. Si tu imagen no contempla esa diversidad, te arriesgas a que falle al desplegarla.

¿Cómo se construye una imagen multiplataforma con docker build?

La magia ocurre con un solo parámetro extra dentro de docker build: la bandera --platform, donde especificas las arquitecturas separadas por coma.

El comando luce así:

bash docker build --platform=linux/amd64,linux/arm64 -t docker-scan .

Aquí linux/amd64 cubre prácticamente cualquier laptop o servidor convencional, y linux/arm64 cubre dispositivos como tabletas Raspberry Pi y muchos sistemas embebidos. El resto del comando (el tag, el contexto) se mantiene exactamente igual a como lo usarías normalmente.

¿Por qué aparece el error de containerd al ejecutar el build?

La primera vez que intentas construir multiplataforma, Docker te lanza un error pidiendo habilitar el almacenamiento de containerd. Esto se resuelve en pocos pasos dentro de Docker Desktop:

Abre Docker Desktop y entra al engrane de configuración.
Ve a la sección General y baja hasta la opción "Utilizar containerd para jalar imágenes de diferentes tipos".
Habilítala, aplica los cambios y reinicia el motor de Docker.

Después de reiniciar, basta con repetir el comando en la terminal y el build arranca sin problema.

¿Qué pasa durante el proceso de build multiplataforma?

Al observar la terminal vas a notar que los pasos se alternan entre ARM64 y AMD64: Docker está construyendo dos imágenes en paralelo dentro del mismo proceso. Por eso el tiempo de compilación crece bastante respecto a una build común.

¿Cuánto cuestan en tiempo y tamaño las imágenes multiplataforma?

La diferencia es brutal y conviene tenerla clara antes de decidir cómo construir tus imágenes. En el ejemplo de la clase con el proyecto docker-scan, los números fueron contundentes:

Build multiplataforma (AMD64 + ARM64): 198 segundos, algo más de tres minutos.
Build genérica de la misma imagen: 0.9 segundos.
Tamaño multiplataforma: 1.5 GB en Docker Desktop.
Tamaño aproximado de la imagen base equivalente: 800 MB.

Es decir, la imagen casi duplica su peso y el tiempo de compilación se dispara, porque en el fondo estás generando dos imágenes apiladas dentro de un mismo tag.

¿Por qué pesa el doble una imagen multiplataforma? Porque internamente Docker construye una variante por cada arquitectura declarada en --platform, y ambas viajan dentro del mismo manifest.

¿Cuándo conviene usar imágenes multiplataforma y cuándo no?

La respuesta corta es: úsalas solo cuando realmente vayas a correr tu imagen en hardware distinto. Tiene mucho sentido en escenarios como:

Proyectos de internet de las cosas (IoT) donde despliegas en sensores o gateways ARM.
Circuitos embebidos y dispositivos como Raspberry Pi.
Equipos mixtos donde algunos desarrolladores usan Apple Silicon (ARM) y otros máquinas Intel/AMD.
Imágenes públicas que vas a publicar para una comunidad amplia.

En cambio, si ya sabes a qué servidor vas a publicar tu imagen y ese servidor tiene una arquitectura definida, lo más práctico es construir una imagen genérica para ese procesador. Te ahorras minutos de build, cientos de megas en disco y dolores de cabeza en el pipeline.

La regla mental es simple: construye multiplataforma cuando el destino sea incierto o heterogéneo; construye sencillo cuando el destino sea conocido. ¿Tú en qué arquitectura estás desplegando hoy tus contenedores? Cuéntame en los comentarios.