Práctica: Desplegar y probar el sistema completo en producción

Introducción: El Último Paso hacia la Producción

Has diseñado, desarrollado y probado en local un sistema de microservicios para e-commerce utilizando Go y Gorilla/Mux. Ahora llega el momento crucial: llevar tu creación al mundo real. Esta lección no es solo sobre ejecutar comandos de despliegue; es sobre internalizar las prácticas, configuraciones y mentalidad necesarias para que un sistema distribuido funcione de manera confiable, escalable y observable en un entorno de producción. El salto del entorno de desarrollo a producción es donde la teoría se encuentra con la complejidad de la red, la carga variable de usuarios y la imprevisibilidad de la infraestructura.

En esta práctica integral, cubriremos el proceso completo, desde la preparación de tus imágenes de Docker hasta la configuración de orquestación con Docker Compose para un entorno simplificado, pasando por la implementación de health checks, la exposición de métricas y la configuración de un gateway API básico. Finalmente, realizaremos pruebas de carga para validar el rendimiento y la resiliencia del sistema. El objetivo es que comprendas cada componente del flujo de producción y puedas diagnosticar y resolver problemas cuando surjan.

Asumiremos que tienes tu sistema compuesto por al menos tres microservicios: usuarios, productos y pedidos, cada uno con su propia base de datos (o esquema) y una API REST definida. También contaremos con un servicio de API Gateway que enruta las peticiones y un servicio de métricas (como Prometheus) para la monitorización.

Concepto Clave: Inmutabilidad y Orquestación en Producción

Un principio fundamental en el despliegue moderno de aplicaciones, especialmente microservicios, es la inmutabilidad. En lugar de modificar servidores o contenedores ya desplegados (un enfoque "pets"), se trata a cada despliegue como un artefacto nuevo e inmutable ("cattle"). Esto significa que para cualquier cambio, por pequeño que sea, se construye una nueva imagen de contenedor, se versiona y se reemplaza la instancia antigua por completo. Este enfoque garantiza consistencia entre entornos, permite rollbacks sencillos y elimina la deriva de configuración.

La orquestación es el cerebro que gestiona este ganado de contenedores. Herramientas como Docker Compose (para entornos más simples o de prueba), Kubernetes o Nomad automatizan el despliegue, el escalado, la recuperación ante fallos y la conexión en red de los contenedores. Piensa en la orquestación como el control de tráfico aéreo de un aeropuerto muy concurrido. Cada avión (contenedor) tiene un plan de vuelo (la imagen y configuración), pero es el controlador (el orquestador) quien le asigna una pista (un nodo/host), gestiona su despegue y aterrizaje (ciclo de vida), y lo redirige si hay problemas, asegurando que todo el sistema funcione de manera coordinada y eficiente.

Tip: Incluso en una práctica o entorno de staging, adopta la mentalidad de producción. Usa variables de entorno para la configuración, nunca credenciales embebidas en el código, y trata tus contenedores como efímeros: cualquier dato persistente debe vivir fuera de ellos, en volúmenes o servicios gestionados.

Cómo Funciona en la Práctica: Flujo de Despliegue con Docker Compose

Para nuestro proyecto integrador, utilizaremos Docker Compose como orquestador, ideal para entornos de prueba de concepto, desarrollo y pequeñas producciones. El flujo comienza con la creación de un Dockerfile optimizado para cada microservicio en Go. La clave está en usar una etapa de construcción multi-stage: se compila la aplicación en un contenedor con el SDK completo de Go, y luego se copia el binario estático resultante a una imagen mínima como alpine o scratch. Esto produce imágenes seguras y ligeras (de apenas unos MB).

Una vez construidas las imágenes, el archivo docker-compose.yml actúa como el plano maestro. Define cada servicio (nuestros microservicios, bases de datos, gateway, y recolector de métricas), sus dependencias, las variables de entorno específicas de producción (como cadenas de conexión a BD, secretos, y niveles de log), los volúmenes para persistencia, los puertos expuestos y, críticamente, las políticas de reinicio y los health checks. Al ejecutar docker-compose up -d, el motor de Compose se encarga de crear una red aislada, levantar todos los contenedores en el orden correcto y mantenerlos en ejecución.

El paso final de la puesta en marcha es la verificación. No basta con que los contenedores estén "Up". Debemos verificar que las aplicaciones dentro de ellos estén saludables. Para ello, configuramos health checks a nivel de Docker Compose que realizan peticiones HTTP a endpoints como /health en cada microservicio. Solo cuando ese endpoint responde con un código 200, Docker considera el contenedor como "healthy". Esto es vital para que servicios dependientes (como el gateway) no intenten comunicarse con un backend que aún no está listo.

Código en Acción: Dockerfile, Compose y Health Check

A continuación, se muestra un ejemplo real y funcional de los artefactos centrales para el despliegue. Comenzamos con un Dockerfile eficiente para un microservicio Go.

# Dockerfile para el microservicio de pedidos
# Etapa 1: Construcción
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main ./cmd/orderservice

# Etapa 2: Imagen final mínima
FROM alpine:latest
RUN apk --no-cache add ca-certificates tzdata
WORKDIR /root/
COPY --from=builder /app/main .
COPY --from=builder /app/.env.production ./.env
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD wget --quiet --tries=1 --spider http://localhost:8080/health || exit 1
CMD ["./main"]

Ahora, el archivo docker-compose.yml que orquesta todo el sistema. Nota la definición de variables de entorno, volúmenes, dependencias y health checks.

# docker-compose.yml
version: '3.8'
services:
  postgres-users:
    image: postgres:15-alpine
    container_name: postgres-users-db
    environment:
      POSTGRES_DB: usersdb
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: ${DB_PASSWORD} # Secreto desde .env
    volumes:
      - pgdata-users:/var/lib/postgresql/data
    networks:
      - ecommerce-net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U admin -d usersdb"]
      interval: 10s
      timeout: 5s
      retries: 5

  user-service:
    build:
      context: ./user-service
      dockerfile: Dockerfile
    container_name: user-service
    environment:
      DB_HOST: postgres-users
      DB_PORT: 5432
      DB_NAME: usersdb
      DB_USER: admin
      DB_PASSWORD: ${DB_PASSWORD}
      JWT_SECRET: ${JWT_SECRET}
      LOG_LEVEL: "info"
    ports:
      - "8081:8080"
    depends_on:
      postgres-users:
        condition: service_healthy
    networks:
      - ecommerce-net
    healthcheck:
      test: ["CMD", "wget", "--quiet", "--tries=1", "--spider", "http://localhost:8080/health"]
      interval: 30s
      timeout: 3s
      retries: 3
      start_period: 40s
    restart: unless-stopped

  # ... Servicios similares para product-service (con su BD) y order-service.

  api-gateway:
    build:
      context: ./api-gateway
      dockerfile: Dockerfile
    container_name: api-gateway
    environment:
      USER_SERVICE_URL: "http://user-service:8080"
      PRODUCT_SERVICE_URL: "http://product-service:8080"
      ORDER_SERVICE_URL: "http://order-service:8080"
    ports:
      - "8000:8080" # Puerto expuesto al mundo exterior
    depends_on:
      - user-service
      - product-service
      - order-service
    networks:
      - ecommerce-net
    restart: always

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
    ports:
      - "9090:9090"
    networks:
      - ecommerce-net

networks:
  ecommerce-net:
    driver: bridge

volumes:
  pgdata-users:
  pgdata-products:
  pgdata-orders:
  prometheus-data:

Finalmente, un ejemplo del endpoint de health check en Go, esencial para la monitorización.

// handlers/health.go en el microservicio de usuarios
package handlers

import (
    "database/sql"
    "net/http"
    "github.com/gorilla/mux"
)

type HealthHandler struct {
    DB *sql.DB
}

func (h *HealthHandler) Check(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    
    // 1. Verificar conexión a la base de datos
    if err := h.DB.Ping(); err != nil {
        w.WriteHeader(http.StatusServiceUnavailable)
        w.Write([]byte(`{"status": "DOWN", "error": "Database connection failed"}`))
        return
    }
    
    // 2. (Opcional) Verificar otros recursos: caché, servicio externo, etc.)
    
    // 3. Si todo está bien
    w.WriteHeader(http.StatusOK)
    w.Write([]byte(`{"status": "UP", "timestamp": "` + time.Now().UTC().Format(time.RFC3339) + `"}`))
}

// En main.go
func main() {
    r := mux.NewRouter()
    healthHandler := &handlers.HealthHandler{DB: db} // db es la conexión global
    r.HandleFunc("/health", healthHandler.Check).Methods("GET")
    // ... otras rutas
    http.ListenAndServe(":8080", r)
}

Errores Comunes y Cómo Evitarlos

1. Imágenes de Contenedor Gigantescas: Compilar tu aplicación Go directamente en la imagen final incluye todo el toolchain, resultando en imágenes de +1GB. Solución: Usa siempre Dockerfiles multi-stage como el mostrado anteriormente. La imagen final solo debe contener el binario y las librerías mínimas del sistema.

2. Health Checks Inexistentes o Débiles: Sin health checks, Docker no sabe si tu aplicación está realmente funcionando. Un check que solo verifica si el proceso existe (el default) es inútil. Solución: Implementa un endpoint /health significativo que verifique dependencias críticas (BD, caché) y configúralo en docker-compose.yml con intervalos y timeouts adecuados.

3. Secretos Hardcodeados en el Código o la Imagen: Committear contraseñas de base de datos o claves API es un riesgo de seguridad gravísimo. Solución: Usa siempre variables de entorno. En Docker Compose, puedes usar un archivo .env (excluido del control de versiones) y referenciar variables con ${VARIABLE}. En producción real, usa un vault de secretos (HashiCorp Vault, AWS Secrets Manager).

4. Falta de Configuración de Límites de Recursos: Un microservicio con una fuga de memoria puede agotar toda la RAM del host. Solución: En tu docker-compose.yml, define límites para cada servicio usando las directivas deploy.resources.limits (para Compose en modo swarm) o usa flags de runtime como --memory y --cpus para limitar memoria y CPU.

5. No Prepararse para el Fallo: Asumir que todo funcionará siempre. Solución: Configura la política restart: unless-stopped o restart: always en Compose. Diseña tus servicios para ser resilientes (usando timeouts, retries y circuit breakers en las comunicaciones) y prueba su comportamiento apagando contenedores aleatoriamente.

Pruebas de Carga y Monitorización Post-Despliegue

Desplegar el sistema es solo el comienzo. Ahora debemos validar que cumple con los requisitos de alto rendimiento bajo estrés. Para ello, utilizamos herramientas de pruebas de carga como k6 o Apache Bench (ab). El objetivo no es solo medir las peticiones por segundo, sino observar cómo se comporta el sistema: si la latencia se degrada, si aparecen errores HTTP 5xx bajo carga, o si algún microservicio se convierte en un cuello de botella.

Paralelamente, la monitorización es tus ojos y oídos en producción. Configuramos cada microservicio Go para exponer métricas en el formato que Prometheus puede raspar (usando la librería prometheus/client_golang). Métricas clave incluyen: número de peticiones HTTP por endpoint, latencias (p50, p95, p99), tasa de errores, y métricas de negocio como "pedidos creados por minuto". Un dashboard en Grafana, conectado a Prometheus, te dará una visión en tiempo real de la salud del sistema.

Realiza una prueba de carga progresiva. Comienza con una carga baja y auméntala gradualmente mientras monitoreas el dashboard. Observa los puntos de inflexión. ¿A qué carga la latencia del 95% supera los 500ms? ¿Algún servicio empieza a devolver errores? Esta información es oro puro para planificar la escalabilidad (¿necesitas más réplicas del servicio de pedidos?) y para ajustar los parámetros de tu base de datos y de Go (como el tamaño del pool de conexiones a la BD o el número de GOMAXPROCS).

Checklist de Dominio

• He construido imágenes Docker multi-stage para cada microservicio, resultando en imágenes finales de menos de 50MB.
• He configurado un archivo docker-compose.yml que define todos los servicios, sus dependencias, variables de entorno, volúmenes y una red aislada.
• Cada servicio en mi docker-compose.yml tiene un health check HTTP significativo que verifica sus dependencias (ej., conexión a BD).
• He eliminado todos los secretos (contraseñas, API keys) del código y los gestiono mediante variables de entorno o un archivo .env seguro.
• He expuesto un endpoint /metrics en cada microservicio y configurado Prometheus para rasparlos, visualizando datos clave en un dashboard de Grafana.
• He ejecutado una prueba de carga con k6 o herramienta similar, identificado los cuellos de botella y documentado el rendimiento máximo del sistema actual.
• He simulado fallos (apagando un contenedor de base de datos) y verificado que los health checks y políticas de reinicio funcionan como se espera.
• Puedo explicar la diferencia entre un contenedor "Up" y un contenedor "Healthy", y por qué esta distinción es crítica para el arranque ordenado del sistema.

Falar no WhatsApp