Path to production

El workflow básico

El camino a producción pasa por estos pasos:

1. Build local de la imagen en tu máquina de desarrollo.
2. Build oficial desde CI o build system.
3. Push de la imagen al registry.
4. Deploy al server, configurar, arrancar el container.

A medida que el workflow madura, todos estos pasos colapsan en un pipeline automatizado que orquesta build, test, storage y deploy.

Una historia de producción debe cubrir tres cosas:

• Repeatable: cada invocación hace lo mismo.
• Maneja configuration: puedes definir la config por entorno y garantiza que se aplique.
• Entrega un artefacto ejecutable.

Docker’s role en producción

Docker provee la base de la aplicación containerized, pero la plataforma (Kubernetes, Swarm, ECS, etc.) maneja la mayoría de las decisiones de producción. La plataforma suele ser un sistema que envuelve un cluster de servers con una interfaz común para gestión de containers.

Job control y resource limits

Docker provee primitivas de job control (docker container start, stop, run, kill) que se mapean a las fases del lifecycle de una aplicación. Todas las plataformas (Kubernetes, Swarm, ECS) respetan este lifecycle.

Para resource limits, usa las flags de docker container run (--memory, --cpu-shares, --cpuset-cpus, etc.) o, mejor, configúralas en tu plataforma (en Kubernetes, los Pod specs; en ECS, los task definitions).

Networking

Docker provee muchas opciones de networking, pero en producción, deja que la plataforma decida. Tu app solo debe:

• Confiar en el DNS que Docker/plataforma provee.
• Aceptar puertos vía env vars (no hardcoded).
• Evitar protocolos con puertos dinámicos (FTP, RTSP).

# Ejemplo de service discovery automático
environment:
  DATABASE_URL: "postgresql://postgres-db:5432/myapp"
  # 'postgres-db' es el nombre del service, no un IP

Configuration

Docker’s native mechanism es environment variables. Esto funciona en todas las plataformas modernas.

docker container run -d \
  -e DATABASE_URL="postgresql://..." \
  -e LOG_LEVEL=info \
  -e FEATURE_FLAGS="new_ui,beta_export" \
  myapp:1.2.3

Para secrets, usa el mecanismo de la plataforma:

• Docker Swarm: Docker secrets.
• Kubernetes: Secret resources, montados como env vars o volumes.
• AWS: SSM Parameter Store, Secrets Manager.
• Vault, Consul, etc. para setups más complejos.

Logging

Docker captura todo lo que el container escribe a stdout/stderr y lo streamea a un backend de logging configurable. Tu app solo necesita escribir a stdout/stderr. La plataforma se encarga del resto.

# json-file (default, hasta que configures log rotation)
# syslog (UDP, recomendado para producción)
# fluentd, awslogs, gcplogs, splunk
# journald (Linux con systemd)

Monitoring

Health checks

Define HEALTHCHECK en tu Dockerfile o en el spec de tu plataforma. Es la forma estándar de preguntar “¿está esta app funcionando?”:

HEALTHCHECK CMD curl -f http://localhost:3000/health || exit 1

El status aparece en docker container ls, en Kubernetes (readiness probes), en ECS, etc. Todos los orquestadores lo respetan.

Métricas y APM

• Métricas básicas: docker container stats, docker system events, métricas para Prometheus (metrics-addr).
• APM externos: New Relic, Datadog, Honeycomb, etc. Todos tienen soporte first-class para containers.
• Auto-healing: muchos schedulers (Kubernetes, ECS) re-arrancan containers que fallan sus health checks automáticamente.

Scheduling y service discovery

Scheduling es la decisión de qué corre en qué servidor. Service discovery es cómo las apps se encuentran unas a otras en la red. Ambos los maneja la plataforma, no Docker directamente.

Service discovery patterns

• Load balancers con addresses bien conocidos.
• Round-robin DNS.
• DNS SRV records.
• Multicast DNS (mDNS).
• Service mesh: Linkerd, Istio + Envoy.
• Kubernetes Ingress: Traefik, Contour, etc.

Testing en CI con Docker

El workflow típico de testing:

1. Build trigger (webhook desde Git, manual, schedule).
2. Build server kickea un container image build.
3. La imagen se crea en el Docker server.
4. La imagen se taggea con un build number o commit hash.
5. Se crea un nuevo container con la imagen, corriendo el test suite.
6. Los resultados se capturan (exit code es la señal principal).
7. Build pasa/falla según los resultados.
8. Builds pasados se pushean al registry.

# Build de la imagen
docker image build -t myapp:commit-abc123 .

# Tag con el commit hash
docker image tag myapp:commit-abc123 myapp:build-42

# Run tests
docker container run --rm -e ENVIRONMENT=testing -e API_KEY=12345 \
  myapp:build-42 /opt/myapp/test.sh

# Si exit code es 0, push
docker image push myapp:build-42

External dependencies con Docker Compose

Para tests con DBs, cache, etc., Docker Compose es ideal:

# docker-compose.test.yml
services:
  app:
    build: .
    command: /opt/myapp/test.sh
    environment:
      DATABASE_URL: "postgresql://test-db:5432/myapp_test"
    depends_on:
      test-db:
        condition: service_healthy
  test-db:
    image: postgres:14
    environment:
      POSTGRES_DB: myapp_test
    healthcheck:
      test: ["CMD-SHELL", "pg_isready"]
      interval: 2s

Próximos pasos

• 11-containers-at-scale: orchestration a escala. Docker Swarm mode (built-in), introducción a Kubernetes y Minikube, qué es un pod, services, deployments, kubectl básico.