Módulo 12 | Docker para Automatizadores

¿Por qué un automatizador debe dominar Docker?

Un workflow funciona hoy en tu máquina y falla mañana en la del cliente. Docker resuelve ese "en mi máquina sí funciona" haciendo el entorno idéntico en cualquier lugar:

Portabilidad: la misma imagen corre en tu PC, en OCI, en DigitalOcean, en AWS.
Reproducibilidad: cada despliegue es una copia exacta. No hay configuración "de memoria".
Aislamiento: n8n y su base de datos no tocan el sistema operativo del host.
Actualizaciones: docker pull de una nueva versión = actualizar toda tu automatización.

Analogía del Camarero (reciclada)

Docker es el menú estandarizado de la cocina: todos los camareros usan exactamente los mismos ingredientes y recetas, sin importar en qué restaurante (servidor) estén trabajando.

Imagen vs. Contenedor

Concepto	Definición	Analogía
Imagen	Plantilla inmutable con el sistema + app + config	El archivo .iso o la receta de cocina
Contenedor	Instancia en ejecución creada desde una imagen	El plato servido en el restaurante
Registro	Repositorio de imágenes (Docker Hub, OCI Registry)	La biblioteca de recetas
Volumen	Almacenamiento persistente fuera del contenedor	La despensa (no se pierde si el plato se rompe)

Error crítico del principiante

Si no usas un volumen, todos tus datos (workflows, credenciales, claves de cifrado) se borran cuando el contenedor se detiene. El volumen es la diferencia entre un servicio y una demo.

Comandos Docker Esenciales para n8n

Comando	Función
`docker volume create n8n_data`	Crea el volumen persistente (una vez)
`docker pull docker.n8n.io/n8nio/n8n`	Descarga la última imagen estable de n8n
`docker compose up -d`	Levanta todos los servicios del archivo compose en segundo plano
`docker compose down`	Detiene y elimina los contenedores
`docker logs n8n`	Ve los logs del contenedor (diagnóstico #1)
`docker exec -it n8n sh`	Entra al shell del contenedor para inspeccionar
`docker stats`	Monitorea CPU/RAM de todos los contenedores

El Comando docker run Oficial de n8n

La forma mínima de levantar n8n con Docker (según documentación oficial):

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -e GENERIC_TIMEZONE="America/Bogota" \
  -e TZ="America/Bogota" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -e N8N_RUNNERS_ENABLED=true \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Elemento	Qué hace
`-p 5678:5678`	Expone el puerto 5678 del contenedor al host → `http://localhost:5678`
`GENERIC_TIMEZONE`	Zona horaria para los nodos de programación (Schedule)
`TZ`	Zona horaria del sistema del contenedor
`-v n8n_data:/home/node/.n8n`	Persiste datos: claves de cifrado, logs, workflows, assets de source control
`N8N_RUNNERS_ENABLED`	Habilita task runners (requerido en 1.x, por defecto en 2.x)

Checklist del Módulo 12

Distingo imagen vs contenedor vs volumen y sé por qué el volumen es crítico.
Ejecuto los comandos docker pull, compose up, logs, exec y stats sin mirar.
Levanto n8n con docker run oficial y accedo a localhost:5678.
Entiendo por qué Docker hace reproducible un despliegue de n8n.

Desafío de Arquitecto

docker-compose.yml: n8n + PostgreSQL

Escribe tu propio archivo docker-compose.yml que levante dos servicios: n8n y PostgreSQL, cumpliendo:

Servicio n8n con imagen docker.n8n.io/n8nio/n8n, puerto 5678:5678
Servicio postgres con imagen postgres:16, credenciales por variable de entorno
n8n apuntando a postgres vía variables DB_TYPE=postgresdb, DB_POSTGRESDB_HOST=postgres, DB_POSTGRESDB_PORT=5432, DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_USER, DB_POSTGRESDB_PASSWORD
Un volumen para n8n y otro para postgres (persistencia total)
Verifica: docker compose up -d, abre localhost:5678 y confirma que el login de n8n funciona (lo que prueba que postgres acepta la conexión)

Pista: Define primero el servicio de postgres con healthcheck, y n8n con depends_on: postgres: condition: service_healthy.