Docker Buildx: Cómo crear imágenes de contenedores multiplataforma

Casos prácticos avanzados

Hasta ahora, te he mostrado comandos básicos de Buildx y casos de uso. Buildx puede hacer muchas más cosas, y algunas de las funciones son imposibles de implementar con el constructor clásico.

Exploremos algunas técnicas avanzadas para llevar tu flujo de trabajo de contenerización al siguiente nivel.

Optimización de la construcción en varias fases

Las compilaciones multietapa son una de las características más potentes de Docker para crear imágenes eficientes, y Buildx las hace aún mejores.

Para demostrarlo, vamos a crear una aplicación Python optimizada con varias etapas:

# Dockerfile.optimized
FROM python:3.13-slim AS base
WORKDIR /app
COPY requirements.txt .

FROM base AS builder
RUN pip install --no-cache-dir --target=/install -r requirements.txt

FROM base AS linter
COPY --from=builder /install /usr/local/lib/python3.13/site-packages
COPY app.py .
RUN pip install pylint && pylint app.py || exit 0

FROM base AS tester
COPY --from=builder /install /usr/local/lib/python3.9/site-packages
COPY app.py .
RUN pip install pytest && python -m pytest app.py -v || exit 0

FROM python:3.13-alpine AS final
WORKDIR /app
COPY --from=builder /install /usr/local/lib/python3.13/site-packages
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]

Con Buildx, puedes construirlo de forma más eficiente:

docker buildx build --file Dockerfile.optimized -t myapp:optimized --load .

Imagen 9 - Construcciones multietapa

Entonces, ¿qué lo hace especial? Buildx procesa etapas independientes en paralelo. Mientras que el constructor heredado ejecutaría cada etapa secuencialmente, Buildx identifica que las etapas linter y tester no dependen unas de otras y las construye simultáneamente.

Otra ventaja añadida de esta optimización de la construcción es la reducción del tamaño del archivo. Puedes verificar el tamaño de la imagen ejecutando lo siguiente:

docker images myapp

Verás algo así:

Imagen 10 - Tamaños de imagen Docker

La imagen final alpina es mucho más pequeña.

Integración de tuberías CI/CD

Mientras trabajas localmente, puedes establecer configuraciones de Buildx que reflejen tu entorno CI/CD.

Para empezar, crea un archivo .dockerignore para mantener limpias las construcciones:

.git
__pycache__
*.pyc
*.pyo
*.pyd
.Python
env
venv
*.so
.coverage
htmlcov

A continuación, crea una secuencia de comandos de compilación que imite lo que podría hacer tu canalización CI:

#!/bin/bash
# build.sh - Local CI/CD simulation

echo "Starting CI/CD build process..."

# Setup builder with emulation support
echo "Setting up builder..."
docker buildx create --name cibuilder --use || true
docker buildx inspect --bootstrap

# Run linting
echo "Running lint stage..."
docker buildx build --file Dockerfile.optimized --target linter .

# Run tests
echo "Running test stage..."
docker buildx build --file Dockerfile.optimized --target tester .

# Build for multiple platforms
echo "Building multi-platform image..."
docker buildx build --file Dockerfile.optimized \
  --platform linux/amd64,linux/arm64 \
  --tag myapp:$(date +%Y%m%d) \
  --tag myapp:latest \
  --load \
  --progress=plain \
  .

echo "Build process complete!"

En pocas palabras, este script hace lo siguiente:

• Crea un constructor dedicado para CI/CD.
• Ejecuta la fase de pelusa.
• Ejecuta la fase de prueba.
• Construye la imagen final multiplataforma con etiquetas versionadas.

Ahora viene la parte divertida: haz que el script sea ejecutable y ejecútalo:

chmod +x build.sh
./build.sh

Edición local

Un punto doloroso habitual al trabajar con Docker es que cada vez que cambias el archivo fuente, tienes que reconstruir la imagen y ejecutar el contenedor. Simplemente lleva demasiado tiempo.

Aquí está la buena noticia: para el desarrollo local con iteraciones más rápidas, puedes crear una versión de desarrollo:

# Dockerfile.dev
FROM python:3.13-slim
WORKDIR /app

RUN pip install flask psutil python-dotenv

# Install development tools
RUN pip install pytest pylint watchdog

# Mount app code at runtime instead of copying
CMD ["python", "app.py"]

Ejecútalo con un montaje de volumen para recargar el código en vivo:

docker buildx build -f Dockerfile.dev -t myapp:dev --load .
docker run -it --rm -p 5000:5000 -v $(pwd):/app myapp:dev

Ahora puedes editar tu archivo app.py localmente, ¡y los cambios se reflejarán inmediatamente en el contenedor en ejecución!

A continuación, hablemos del rendimiento.

Consideraciones sobre el rendimiento

A nadie le gusta un flujo de trabajo de desarrollo lento, y la potencia de la paralelización con Docker Buildx puede ayudar.

Exploremos cómo optimizar tus construcciones y aprovechar las funciones de rendimiento de Buildx para crear imágenes más rápidamente.

Construye técnicas de paralelización

Una de las mayores ventajas de Buildx es su capacidad para construir etapas en paralelo. El constructor de Docker tradicional ejecuta cada paso secuencialmente, pero Buildx analiza tu Dockerfile e identifica qué pasos pueden ejecutarse al mismo tiempo.

Para demostrarlo, utilizaré dos archivos: Dockerfile.standard y Dockerfile.parallel. Aquí tienes el contenido de ambos:

Dockerfile.estándar

FROM python:3.13-slim
WORKDIR /app

# System dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    && rm -rf /var/lib/apt/lists/*

# Python dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Application code
COPY app.py .

# Linting
RUN pip install pylint && pylint app.py || true

EXPOSE 5000
CMD ["python", "app.py"]

Dockerfile.parallel

FROM python:3.13-slim AS python-base
WORKDIR /app

# Independent stage for installing system dependencies
FROM python-base AS system-deps
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    && rm -rf /var/lib/apt/lists/*

# Independent stage for installing Python dependencies
FROM python-base AS python-deps
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Independent stage for static code analysis
FROM python-deps AS linting
COPY app.py .
RUN pip install pylint && pylint app.py || true

# Final stage that combines dependencies
FROM python-base AS final
# Copy from system deps stage
COPY --from=system-deps /usr/bin/gcc /usr/bin/gcc
# Copy from Python deps stage
COPY --from=python-deps /usr/local/lib/python3.13/site-packages /usr/local/lib/python3.13/site-packages
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]

Midamos cómo esta estructura paralela mejora los tiempos de construcción:

# Time the standard sequential build
time docker build -t myapp:standard -f Dockerfile.standard .

# Time the parallel-optimized build with Buildx
time docker buildx build --load -t myapp:parallel -f Dockerfile.parallel .

Como referencia, la compilación estándar tardó 18,48 segundos, ¡mientras que la compilación paralela tardó sólo 1,17 segundos!

Para mejorar aún más el rendimiento, puedes probar a utilizar las banderas --cache-from y --cache-to para aprovechar la caché de disco local:

# First build - create cache
docker buildx build --load -t myapp:latest --cache-to type=local,dest=./buildcache .

# Subsequent builds - use cache
docker buildx build --load -t myapp:latest --cache-from type=local,src=./buildcache .

También puedes limitar el tamaño del contexto con archivos .dockerignore cuidadosos:

# Create a comprehensive .dockerignore
cat > .dockerignore << 'EOF'
.git
.github
.dockerignore
.pytest_cache
__pycache__
*.pyc
*.pyo
*.pyd
.Python
venv
env
node_modules
.coverage
htmlcov
.DS_Store
EOF

Resumiendo, estructurando tus archivos Docker con la paralelización en mente y aprovechando la caché avanzada de Buildx, pasarás menos tiempo esperando las compilaciones y más tiempo desarrollando funciones.

Integración del ecosistema

Docker Buildx no existe de forma aislada. Está diseñado para integrarse perfectamente con otras herramientas de tu entorno de desarrollo.

Exploremos cómo Buildx funciona con las herramientas locales de los programadores y hace que tu flujo de trabajo con contenedores sea más eficiente.

Construir clusters Kubernetes

Kubernetes ofrece potentes capacidades para ejecutar operaciones distribuidas Docker Buildx en un clúster. Al integrar Buildx con Kubernetes, puedes obtener construcciones más rápidas y resistentes que se adaptan a las necesidades de tu proyecto.

> ¿Eres nuevo en Kubernetes? En Kubernetes vs Docker: Diferencias que todo programador debe conocer post es tu próxima parada.

Utilizar Kubernetes para tu infraestructura de construcción ofrece un par de ventajas:

1. Escala automática: Kubernetes puede escalar tus nodos constructores hacia arriba o hacia abajo en función de la demanda, asignando recursos de forma eficiente a través de tu clúster. Incluso puedes establecer reglas de autoescalado basadas en la utilización de la CPU.
2. Optimización de recursos: La programación de Kubernetes garantiza que tus construcciones obtengan los recursos que necesitan sin sobrecargar los nodos individuales. Puedes establecer límites de recursos y peticiones para garantizar un rendimiento constante.
3. Alta disponibilidad: Al distribuir las instancias de BuildKit entre varios nodos, tu infraestructura de compilación sigue estando disponible aunque fallen nodos individuales.
4. Entornos coherentes: Todos los miembros del equipo se conectan a la misma infraestructura de compilación, eliminando los problemas de "funciona en mi máquina".
5. Ejecución paralela: Las construcciones complejas con muchas etapas pueden ejecutarse en paralelo en varios nodos, reduciendo significativamente los tiempos de construcción. Un proyecto que podría tardar 15 minutos en construirse localmente podría completarse en 3-4 minutos cuando se distribuye.

Considera ésta una sección más "teórica", ya que profundizar en Kubernetes es un tema avanzado en sí mismo.

Para empezar, crea un archivo llamado buildkit-deployment.yaml con el siguiente contenido:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: buildkit
  namespace: buildkit
spec:
  replicas: 3
  selector:
    matchLabels:
      app: buildkit
  template:
    metadata:
      labels:
        app: buildkit
    spec:
      containers:
      - name: buildkit
        image: moby/buildkit:latest
        args:
        - --addr
        - tcp://0.0.0.0:1234
        ports:
        - containerPort: 1234
        securityContext:
          privileged: true
---
apiVersion: v1
kind: Service
metadata:
  name: buildkit
  namespace: buildkit
spec:
  type: ClusterIP
  ports:
  - port: 1234
    targetPort: 1234
  selector:
    app: buildkit

El siguiente paso es aplicar este archivo a tu clúster Kubernetes:

kubectl create namespace buildkit
kubectl apply -f buildkit-deployment.yaml

Por último, conéctate a esta implantación desde tu máquina local:

docker buildx create --name k8s-builder \
  --driver remote \
  --driver-opt endpoint=tcp://<cluster-ip>:1234 \
  --use

Y ya está, ¡ya puedes empezar!

Compatibilidad con plugins IDE

IDEs como Visual Studio Code ofrecen una excelente integración con Docker Buildx a través de su extensión Docker. Esta integración facilita la gestión de tus flujos de trabajo Buildx directamente desde tu entorno de desarrollo.

Para empezar a utilizar Docker Buildx en VS Code, instala la extensión "Docker" del marketplace de VS Code.

Una vez instalado, obtendrás varias funciones específicas de Buildx:

• Haz clic con el botón derecho en cualquier archivo Docker para ver un menú contextual con una opción "Construir imagen..." compatible con Buildx.
• Accede a los argumentos de construcción, objetivos de plataforma y opciones de salida a través de la interfaz de usuario.
• Capacidad para gestionar y cambiar entre diferentes instancias del constructor.
• Integración con el terminal VS Code para ejecutar comandos Buildx complejos.

Imagen 11 - Extensión Docker para VSCode

He aquí un ejemplo de personalización de las tareas de VS Code para utilizar Buildx creando un archivo .vscode/tasks.json:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Docker: Buildx Build",
      "type": "shell",
      "command": "docker buildx build --load -t ${input:imageName} .",
      "group": {
        "kind": "build",
        "isDefault": true
      }
    },
    {
      "label": "Docker: Buildx Multi-Platform",
      "type": "shell",
      "command": "docker buildx build --platform linux/amd64,linux/arm64 -t ${input:imageName} ."
    }
  ],
  "inputs": [
    {
      "id": "imageName",
      "description": "Image name (with tag):",
      "default": "myapp:latest",
      "type": "promptString"
    }
  ]
}

Con esta configuración, puedes acceder rápidamente a comandos Buildx comunes desde el menú Tareas de VS Code(Terminal > Ejecutar tarea). La extensión también proporciona un útil resaltado de sintaxis para archivos Docker y autocompletado para comandos Docker comunes, todo lo cual hace que tu flujo de trabajo Buildx sea más productivo.

Solución de problemas y depuración

Toda herramienta de desarrollo necesitará a veces (demasiado a menudo) solucionar problemas, y Docker Buildx no es una excepción. En esta sección, te guiaré a través de un par de problemas comunes para que puedas diagnosticarlos tú mismo rápidamente y volver a ponerte en marcha.

Problemas comunes y resoluciones

Al trabajar con Buildx, puedes encontrarte con un par de retos comunes. Aquí tienes los problemas más frecuentes y sus soluciones:

• Falla la creación del constructor. Si ves errores al crear un constructor con docker buildx create, comprueba tu versión de Docker:

docker version

Buildx requiere Docker 19.03 o posterior. Si utilizas una versión anterior, actualiza Docker para acceder a las funciones de Buildx.

Para los errores "no such plugin", asegúrate de que Buildx está correctamente instalado ejecutando:

docker buildx version

• Fallos de construcción multiplataforma. Cuando construyas para varias plataformas con errores como "error de formato de ejecución" o "manifiesto no coincidente", comprueba si QEMU está instalado:

docker buildx inspect --bootstrap

Si es necesario, instala emuladores de plataforma:

docker run --privileged --rm tonistiigi/binfmt --install all

• Problemas relacionados con la caché. Si tienes problemas con la caché, intenta borrar la caché de compilación local:

# Remove specific builder's cache
docker buildx prune -b mybuilder

# Remove all build cache
docker buildx prune --all

> ¿Qué es exactamente el comando Docker prune? Aprende con un montón de ejemplos prácticos.

• Problemas de conexión del demonio BuildKit. Si ves "no se ha podido resolver" o errores de conexión, reinicia el constructor:

docker buildx rm mybuilder
docker buildx create --name mybuilder --use
docker buildx inspect --bootstrap

• Cuestiones relacionadas con el rendimiento. Si las construcciones son lentas, prueba la salida de depuración para identificar los cuellos de botella:

docker buildx build --progress=plain --no-cache .

Esta salida detallada ayuda a identificar las fases de compilación que requieren más tiempo, permitiéndote optimizar tu archivo Docker en consecuencia.

• Fallos del comando "Cargar". Si te encuentras con el "error: docker exporter does not currently support exporting manifest lists" al utilizar --load con construcciones multiplataforma, recuerda que no se admite la carga simultánea de varias plataformas en el demonio Docker. En lugar de eso:

# Build for your current platform and load it
docker buildx build --platform linux/amd64 --load -t myapp:latest .

• Prácticas de depuración. Para problemas más complejos, estos métodos de depuración te ayudarán:

# Enable BuildKit debug logs
BUILDKIT_DEBUG=1 docker buildx build .

# Inspect the builder's internal state
docker buildx inspect

# Check system requirements
docker info

# For specific stage failures, build only up to that stage
docker buildx build --target problem-stage .

# Verify your Docker context
docker context ls

Si sigues sistemáticamente estos pasos para solucionar problemas, podrás resolver la mayoría de los problemas de Buildx y mantener un flujo de trabajo de construcción de contenedores eficiente.

Resumiendo la Guía Docker Buildx

¡Hemos cubierto mucho terreno en este artículo de Docker Buildx! Ya has visto cómo esta potente herramienta puede hacer que tus construcciones de contenedores sean más rápidas y flexibles.

Recuerda los beneficios clave: Puedes crear imágenes para múltiples plataformas con un solo comando, acelerar tus creaciones con un almacenamiento en caché avanzado y mantener tus imágenes seguras con una gestión secreta adecuada. Las mejoras de rendimiento son reales, especialmente cuando estructuras tus archivos Docker para aprovechar la construcción en paralelo.

Yo lo uso siempre en mi Macbook con chip M, ya que no todas las imágenes están disponibles para ARM.

Tanto si eres un programador en solitario como si formas parte de un gran equipo, Buildx te ofrece herramientas que se adaptan a tu flujo de trabajo. Puedes ejecutar compilaciones localmente, distribuirlas a través de contenedores, o incluso escalar a clusters Kubernetes a medida que crezcan tus necesidades.

Para saber más sobre Docker y Docker Buildx, te recomiendo que te inscribas en los siguientes cursos de DataCamp:

• Conceptos de contenedorización y virtualización
• Introducción a Docker
• Docker intermedio
• Containerización y virtualización con Docker y Kubernetes
• CI/CD para el machine learning