Docker Deep Dive con IA Generativa

Introducción: por qué Docker y por qué ahora

#

Seamos sinceros: si alguna vez oíste “en mi máquina funciona”, mereces un aplauso... y un contenedor. ¿Me sigues? Bien. Hoy hacemos un viaje práctico por Docker —sí, ese que salva la relación entre devs y ops— y además vemos cómo la IA generativa está entrando al ecosistema. Spoiler: no es magia, es ingeniería (y un poco de encanto de consola).

Dato útil: según CNCF, el uso de contenedores en producción está por las nubes (más del 90% en encuestas). No es una moda; es la capa base de muchas arquitecturas modernas.

Fundamentos: qué es la contenerización y por qué te importa

#

Contenerización = empaquetar tu aplicación + runtime + librerías + configuración en una imagen inmutable. Esa imagen corre como contenedor: proceso aislado, sistema de ficheros propio y red aislada.

• Entorno consistente entre dev/test/prod
• Escalabilidad mediante réplicas
• Imágenes minimalistas = menos superficie de ataque
• Aislamiento entre servicios
• Portabilidad: “si corre en Docker, corre en cualquier lado”
• Arranque rápido: menos tiempo para ver logs, más tiempo para celebrar

Mi regla personal: si haces una tarea manual más de 3 veces, la dockerizo. Como el principio DRY pero para infraestructura: Don’t Repeat Yourself… deployments.

Herramientas y flujo práctico

#

Docker Init — inicio rápido para dockerizar un proyecto

#

Qué hace: docker init crea archivos iniciales para dockerizar tu proyecto: Dockerfile, compose.yaml, .dockerignore y README.Docker.md. Es determinista y aplica buenas prácticas por defecto.

Flujo básico:

1. Ve a la raíz del proyecto.
2. Ejecuta: docker init
3. Responde las preguntas sobre plataforma, versión, puerto y comando.

Caso real: en un proyecto Java/Spring Boot, docker init deja un Dockerfile optimizado (multi-stage, copia del JAR, configuración JVM adecuada) y un compose básico para desarrollo con base de datos. Te facilita el trabajo sin quitarte el control.

Docker Bake — builds multi-imagen y multi-plataforma

#

Para qué sirve: Construir múltiples imágenes con un solo comando usando Buildx y soportar multi-arquitectura (linux/amd64, linux/arm64).

Comando:

docker buildx bake

Ejemplo de docker-bake.hcl:

group "default" {
  targets = ["api", "worker"]
}

target "api" {
  context = "./api"
  dockerfile = "Dockerfile"
  platforms = ["linux/amd64", "linux/arm64"]
}

target "worker" {
  context = "./worker"
  dockerfile = "Dockerfile"
  platforms = ["linux/amd64"]
}

Ventajas: builds paralelos, soporte ARM (hola Raspberry Pi y nodos cloud ARM) y visualización del progreso en Docker Desktop.

Consejo práctico: añade soporte ARM si planeas ejecutar en instancias ARM o edge. Y prueba varias versiones de runtime: a veces un parche menor lo cambia todo.

SBOM — inventario de tu software (sí, importa)

#

La seguridad de la cadena de suministro no es solo para compliance officers. Es para quien quiere saber exactamente qué librerías y versiones hay en la imagen.

Comandos:

docker sbom <imagen:tag>
docker sbom --format spdx-json <imagen:tag> > sbom.spdx.json

Recomendación: genera SBOMs en tu pipeline CI/CD y guárdalos como artefacto. Cuando el auditor toque la puerta (o el SOC), no improvises.

Docker Scout — escaneo y recomendaciones de seguridad

#

Qué es: Docker Scout analiza imágenes en busca de CVEs, malas configuraciones y ofrece recomendaciones accionables.

Comando de ejemplo:

docker scout cves <imagen:tag>

Qué obtienes: lista de paquetes vulnerables y su severidad, recomendaciones para mitigación e integración visual en Docker Desktop.

Uso en CI: ejecuta Scout y bloquea despliegues si aparecen CVEs críticos. Como un bouncer en la puerta del club: si no cumples los requisitos de seguridad, no entras a producción.

Docker Compose — orquestación local sin complicaciones

#

Compose permite definir stacks multi-contenedor con YAML. Ideal para reproducir entornos de desarrollo.

Comandos comunes:

• docker compose up — Levantar
• docker compose up --build — Reconstruir y levantar

Ejemplo simple (API + Postgres):

services:
  api:
    build: ./api
    ports:
      - "8080:80"
    depends_on:
      - db
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Ventaja: onboarding rápido para devs nuevos —un comando y tienes todo corriendo. Magia? No, compose.yaml.

IA Generativa en Docker: Gordon, MCP y Docker Model Runner (DMR)

#

Docker también está integrando LLMs con sentido: mejorar la experiencia del desarrollador, ayudar en revisiones y automatizar tareas.

Ask Gordon

#

Agente de IA integrado en Docker Desktop/CLI (beta). Puedes preguntar: muéstrame los contenedores o revisa este Dockerfile y sugiere mejoras. Útil para quick wins: sugerencias de capas, caché y reducción de tamaño.

MCP (Model Context Protocol) Servers

#

Docker puede hablar con servidores MCP externos o propios. Permite integrar modelos personalizados y herramientas de IA. Se definen con YAML tipo Compose (ej.: Gordon-MCP.yaml) para conectar distintos MCP servers.

Gateway e integración: MCP Gateway conecta clientes (IDE, Copilot) a un hub de MCP servers, centralizando modelos y control de acceso. Ideal para empresas que gestionan modelos internos y quieren control sobre su uso.

Casos prácticos: Ask Gordon sugiere optimizaciones del Dockerfile; MCP automatiza generación de tests, documentación y revisiones de seguridad. Sí, un copiloto que no se queja del café hace el día más llevadero.

Docker Model Runner (DMR) — ejecutar modelos localmente (beta)

#

Qué es: DMR permite ejecutar modelos de IA generativa localmente dentro del ecosistema Docker. Ideal para reducir latencia y mantener control sobre los datos.

Disponibilidad: Linux: Docker CE + plugin; macOS: Docker Desktop 4.40+; Windows: Docker Desktop 4.41+

Comando interactivo:

docker model run ai/gemma3

Eso abre una sesión conversacional en tu terminal con el modelo. Es como chatear, pero sin pestañas ni notificaciones.

Integración con Compose: Compose puede incluir una sección top-level models. Ejemplo:

models:
  gemma3:
    image: oci.registry/ai/gemma3:latest
    context_size: 2048
    runtime_flags:
      - --gpu

Esto declara que tu servicio depende de un modelo local; el runtime se encarga de aprovisionarlo donde sea posible. Portabilidad y API: los modelos ejecutados por DMR pueden exponer APIs compatibles con OpenAI SDK, facilitando la integración en aplicaciones existentes.

Nota práctica: modelos grandes pueden necesitar GPU o arquitecturas especiales. Si tu laptop se queja, pásalo a un nodo con GPU.

Buenas prácticas y recomendaciones

#

• Empieza con docker init para obtener una base sólida.
• Genera SBOMs y móntalos en tu pipeline CI/CD.
• Integra Docker Scout para bloquear despliegues con CVEs críticos.
• Usa docker buildx bake para builds multi-plataforma.
• Compose sigue siendo tu mejor amigo para desarrollo local reproducible.
• Considera DMR si necesitas modelos locales por latencia o privacidad.
• Versiona y publica imágenes con tags claros; no uses “latest” como excusa existencial.

Opinión honesta: la IA es útil, pero no reemplaza buenas prácticas. Un asistente que sugiere optimizaciones no sustituye una revisión humana en código crítico.

Conclusión y próximos pasos

#

Docker sigue siendo la columna vertebral para desplegar aplicaciones modernas. Con docker init, bake, SBOMs, Scout, Compose y las nuevas integraciones de IA (Gordon, MCP, DMR), tu flujo se vuelve más seguro, rápido y automatizable. Si quieres que tu CI tenga menos sorpresas el lunes por la mañana, estos pasos ayudan.

Próximos pasos prácticos:

1. Prueba docker init en un proyecto existente.
2. Añade SBOM en tu pipeline y ejecuta docker scout.
3. Experimenta con docker buildx bake para builds multi-arquitectura.
4. Si trabajas con ML, revisa Docker Model Runner y la sección models de Compose.

Lecturas y recursos

#

• Documentación oficial de Docker
• CNCF Cloud Native Survey
• NTIA SBOM resources
• Docker Blog y Release Notes (para estar al día con Gordon, MCP y DMR)

¿Quieres ejemplos listos para copiar/pegar? Puedo compartir:

• Dockerfiles optimizados (multi-stage y cache-friendly)
• Un docker-bake.hcl completo para un monorepo
• Un compose.yaml con models listo para probar DMR

Gracias por llegar hasta acá. Si sigues leyendo, oficialmente eres mi favorito. Y si tu equipo necesita ayuda para dockerizar su monolito o montar un pipeline con SBOMs y scans automáticos… pásame el café y hacemos arte.