Docker promete reducir el clásico problema de «en mi máquina sí funcionaba», y sí, lo logra en gran parte. Aun así, las arquitecturas importan: trabajar con imágenes multiplataforma cambia tiempos y tamaños de compilación, y exige una configuración clave en Docker Desktop para que todo fluya.
¿Qué problema resuelven las imágenes multiplataforma en Docker?
Las computadoras no son iguales. Coexisten amd64 (común en laptops y servidores) y arm64 (frecuente en sistemas embebidos). Con imágenes multiplataforma puedes generar artefactos para ambas arquitecturas y evitar sorpresas al desplegar.
¿Qué arquitecturas se mencionan y por qué importan?
linux/amd64: la arquitectura típica de «cualquier laptop».
linux/arm64: usada en sistemas embebidos; ejemplo: una tableta de Raspberry Pi.
Idea clave: una sola imagen puede empacarse para varias arquitecturas.
¿Qué habilidades y conceptos aplicas al trabajar con multiplataforma?
Interpretar errores y habilitar el almacenamiento con containerd.
Usar el parámetro --platform en el comando de construcción.
Evaluar tiempos de compilación y tamaño de imagen.
Decidir entre imagen genérica o multiplataforma según el entorno destino.
¿Cómo resolver el error inicial en Docker Desktop?
Aparece un error pidiendo habilitar containerd. La solución: abrir Docker Desktop, entrar al engrane de configuración, ir a general y activar la opción para utilizar containerd para jalar imágenes de diferentes tipos. Luego, aplicar y reiniciar el motor de Docker.
¿Cómo construir una imagen multiplataforma y qué implica?
El flujo es el mismo de siempre con docker build, añadiendo --platform para las arquitecturas objetivo. Durante la compilación, se observa alternancia entre ARM64 y AMD64: se generan ambas variantes al mismo tiempo y la espera es mayor.
Se crea una etiqueta de referencia, por ejemplo: docker-scan.
Se compilan las dos variantes de arquitectura en una sola ejecución.
¿Qué diferencias de tiempo y tamaño observarás?
Tiempo de compilación multiplataforma: 198 segundos, cerca de tres minutos.
Más pasos ejecutados: crear dos variantes incrementa el trabajo.
Tamaño de imagen multiplataforma: aproximadamente 1.5 GB.
Referencia de imagen base: alrededor de 800 MB; casi el doble al ir multiplataforma.
Construcción genérica sin --platform: 0.9 segundos, una diferencia notable.
Ahorro al ir genérico: cerca de 400 MB menos y unos tres minutos de compilación menos.
Nota práctica: aunque el tamaño no siempre baja de forma drástica, el tiempo sí mejora mucho.
¿Cuándo conviene usar multiplataforma y cuándo una imagen genérica?
Los escenarios multiplataforma son relevantes en circuitos embebidos e Internet de las Cosas, donde arm64 es habitual. En la mayoría de los casos, si conoces el servidor objetivo, crear una imagen genérica para esa arquitectura simplifica el trabajo y evita costos en tiempo y tamaño.
¿Has medido tiempos y tamaños en tus builds con --platform o genéricos? Comparte tu experiencia y dudas en los comentarios.
Creo que hay un error en esta clase alrededor del minuto 5. Cuando el profesor vuelve a ejecutar el comando "docker build" sin especificar "--platform", y muestra el tiempo de 0.9 segundos, docker utiliza CACHE para construir la imagen. Por eso es tan rapida la ejecucion la segunda vez. Sin embargo, el profesor dice que es debido a que no se creo la imagen para las dos arquitecturas del ejemplo linux/amd64 y linux/amd64
Oh!! No puede ser Reynaldo! Estás en todo lo correct y me tomó 7 meses dejar de llorar por darme cuenta de esa mala interpretación.
Estás en lo correcto, el caché en Docker es una varita mágica escondida.
No sé si fue sarcasmo del profe, o acepta el error XD bueno tampoco se si fue error, quede confundido
Para los que tienen macOS, el comando para crear una imagen multiplataforma es: docker buildx build --platform linux/amd64,linux/arm64 -t dockerscan2 .
Yo tengo Mac y funciono la que menciona el maestro en la clase, siempre y cuando containerd este on
Si, esto me paso cuando hice build de un proyecto de PHP y después correr esa imagen dentro de un servidor productivo. El tema fue que la arquitectura de mi maquina (ARM), no era compatible con la del servidor. Por eso dice que es parcialmente correcto lo de solucionar el problema de "en mi maquina si funciona". No conocía esto pero esta genial.
Al inicio no lograba entender bien las diferencias, pero basicamente es que una de las soluciones de Docker es que sea portable, pero existen problemas cuando las arquitecturas son diferentes, como ARM y AMD. Si construyo un contenedor desde una arquitectura AMD, lo hace con binarios que están optimizados para esa arquitectura, y si luego quiero ejecutarla en un ARM va a tener problemas de compatibilidad. Para eso nos ayudaría el multiplataforma
Activar "Usar containerd para descargar imágenes".
Tiempos de creación:
Imágenes multiplataforma tardan más y ocupan más espacio (ejemplo: 198 segundos vs. 0.9 segundos).
Recomendación: Si conoces el servidor de despliegue, usa imágenes estándar para optimizar tiempo y tamaño.
Docker ofrece la capacidad de crear imágenes multiplataforma, lo que permite adaptar aplicaciones a diferentes arquitecturas de procesadores (como AMD y ARM). Esto es útil en sistemas embebidos o IoT, aunque puede aumentar el tiempo de compilación y el tamaño de la imagen. La creación de estas imágenes requiere habilitar ContainerD en Docker Desktop. En la mayoría de los casos, si conoces la arquitectura del servidor donde se desplegará, es mejor crear una imagen específica para evitar complicaciones.
muy cierto, muchas veces no tomo en cuenta eso
Aqui la pregunta seria, el tiempo es directamente proporcional al tamaño en que se crea la imagen? Sin tomar el cuenta el cache de Docker, claro... Porque en ese caso el tamaño es exponencial al tiempo
El error estuvo en que, el profe solicitó hacer una misma imagen bajo una misma etiqueta apuntando a dos plataformas diferentes, y en las versiones anteriores de docker (antes de 2025) docker manejaba su storage local con su propio driver legado que no sopora el manifiesto para varias plataformas, lo que sucedió es que el profe debió activar manualmente containerd (porque containerd si puede manejar ese manifiesto de varias plataformas), actualmente ese error no debería salir si tienes el docker actualizado, ojo con las ciencias de la computación jóvenes.
Para generar una imagen de Docker que se ejecute en un Raspberry Pi 5, debes crear una imagen multiplataforma. Utiliza el comando docker build con el parámetro --platform especificando linux/arm64 para asegurarte de que sea compatible con la arquitectura ARM del Raspberry Pi.
Recuerda que al crear imágenes para múltiples arquitecturas, el tiempo de compilación y el tamaño de la imagen pueden aumentar. Asegúrate de tener habilitado ContainerD en Docker Desktop para facilitar el proceso.
¿Todas las imágenes se pueden compilar para que sean multiplataforma, incluso las distroless de google?
No me atrevería a decir que TODAS pero si estoy seguro que son tantas que se acercan al 95%. Las imágenes de Google, por cierto son muy efectivas!
En mi caso tengo windows 11 y un debian con wsl2, tuve que habilitar la opción de "use conteinerd for pulling and storing images" que estaba en la sección de "Features in development" desde el docker desktop, gran clase!!
