Docker
Hosts, despliegues, proxy, disponibilidad, storage y operación.
Docker en producción no es “ejecutar Compose en un servidor”. Es operar un sistema donde artefactos, hosts, red, estado, secretos, telemetría y despliegues pueden fallar sin convertir cada incidente en improvisación.
image aprobada
+ configuración segura
+ capacidad
+ disponibilidad
+ observabilidad
+ recuperación
+ procedimientos
→ servicio operableEl contenedor es una unidad de empaquetado y ejecución. La confiabilidad pertenece al sistema completo.
Define:
Sin estos objetivos no puedes decidir si un host con Compose es suficiente o necesitas un orquestador/servicio administrado.
Producción debe ejecutar un digest aprobado:
registry.example.com/api@sha256:...Conserva:
No construyas en el servidor. No edites archivos dentro del container para “parchar”.
La misma image recibe configuración externa:
Valida al startup y falla cerrado. No uses defaults que desactiven auth o conecten a recursos equivocados.
Una instancia stateless puede recrearse sin perder negocio.
Externaliza:
No todo debe externalizarse: /tmp y cache recreable pueden ser efímeros. La frontera debe ser consciente.
Databases, queues y storage requieren:
Un restart policy no vuelve altamente disponible una database.
Puede ser razonable para:
Requisitos mínimos:
Riesgo aceptado: la pérdida del host interrumpe todos los servicios hasta recuperar.
Cuando necesitas:
necesitas un orquestador/scheduler o una plataforma equivalente.
Docker Engine por sí solo administra un host, no decide dónde reubicar un workload si ese host desaparece.
Topología:
internet
→ load balancer/reverse proxy :443
→ API instances en network privadaEl proxy puede manejar:
No expongas directamente databases, admin UIs o workers.
Flujo de rollout:
crear nueva instancia
→ startup
→ migrations compatibles
→ readiness correcta
→ añadir al tráfico
→ observar
→ retirar anterior con graceful shutdownUn process running no debe recibir tráfico antes de estar ready.
Al retirar una instancia:
Prueba con señales reales. Un kill -9 durante cada deploy genera errores y pérdida de jobs.
Detiene anterior y arranca nueva. Simple, con downtime.
Conviven versiones. Requiere compatibilidad de API/schema.
Mantiene dos entornos y cambia tráfico. Consume más recursos, facilita rollback.
Expone una fracción y compara señales.
Elige según riesgo y capacidad de observación.
Antes de desplegar define:
Un rollback de image no revierte migrations destructivas. Usa expand/contract y backups.
Dimensiona:
Los límites protegen el host, pero también pueden causar throttling u OOM. Basa valores en carga y p95/p99.
Mantén margen para:
Escalar réplicas ayuda solo si:
CPU no siempre es la métrica adecuada. Queue depth, latency o concurrency pueden ser mejores.
Baseline:
user: "10001:10001"
read_only: true
cap_drop: [ALL]
security_opt:
- no-new-privileges:trueAdemás:
No montes Docker socket en una app ordinaria.
Quien controla el daemon normalmente controla el host.
Puede reducir blast radius, pero verifica:
No adoptes un control sin probar el workload.
Producción debe usar una fuente protegida y auditable cuando el riesgo lo exige.
Define:
Un secret entregado a la app puede ser robado si la app es comprometida. Usa permisos mínimos en sistemas externos.
Modela flujos:
proxy → api
api → database
worker → queue + database
observability → collectorsNo una única network global.
Considera:
Necesitas:
Alertas útiles se basan en síntomas:
Evita alertar por cada restart sin contexto o por CPU breve.
Un container healthy puede incumplir el SLO.
Define indicadores:
Usa error budgets para equilibrar releases y estabilidad.
Configura rotación incluso con centralización. Monitorea:
/var/lib/docker o data root;Disk full puede derribar todo el host.
Para cada estado crítico:
Incluye configuración de proxy, Compose/IaC y secrets metadata sin copiar secretos inseguros.
Runbook:
Practícalo. Un documento no ejecutado puede estar incompleto.
Planea:
En un solo host habrá mantenimiento o riesgo acumulado. Multi-host permite drenar nodos.
No dependas de comportamiento accidental. Valida:
Registra la plataforma en inventario.
Puede servir para single-host si:
No ofrece por sí solo:
Crea runbooks para:
Cada runbook debe incluir diagnóstico, mitigación, escalamiento y verificación.
Antes de release:
Después:
Cloud VM
├── firewall 22 restringido, 80/443 públicos
├── Caddy/Nginx
├── API container por digest
├── worker por digest
├── PostgreSQL o servicio externo
├── volumes
├── metrics/log agent
└── backups externosAcepta que la VM es SPOF y define RTO para reconstruirla.
fase 1: Compose single-host
fase 2: database administrada + object storage
fase 3: varios app hosts detrás de load balancer
fase 4: scheduler/orquestador si la complejidad lo justificaNo adoptes Kubernetes solo por moda; adopta capacidades cuando el coste del riesgo/operación lo justifique.
Instancias actuales siguen, pero nuevos nodos/deploys fallan. Mantén retención/cache y plan.
Restart local no recupera conectividad.
Rolling requiere capacidad para versiones simultáneas.
Pools o procesos deben recargar/recrearse gradualmente.
Puede retirar todas las instancias durante outage ajeno.
La métrica correcta incluye pruebas de restore.
No cubre host.
Rompe segmentación.
Pierde trazabilidad.
Disk full.
Image anterior no basta.
Ruido sin respuesta.
Cambios no probados.
Orquestación y límites de Compose, donde se define con precisión cuándo el modelo single-host deja de ser suficiente.