Cómo usar Docker Compose profiles para entornos distintos

Gestión de entornos con Docker Compose profiles

Cuando trabajas con aplicaciones Dockerizadas, es habitual tener configuraciones distintas para desarrollo, staging y producción. Para evitar duplicar archivos de docker-compose.yml y las inconsistencias que esto genera, utilizo Docker Compose profiles.

La solución que utilizo en mis proyectos es Docker Compose profiles. Permite definir servicios específicos para cada entorno dentro de un único archivo docker-compose.yml, activando solo lo necesario en cada despliegue.

Por qué profiles y no varios archivos compose

Muchos equipos crean docker-compose.dev.yml, docker-compose.prod.yml y luego intentan unirlos o gestionarlos por separado. Esto añade complejidad al control de versiones y es una fuente de errores. Un cambio en la configuración base, como una nueva red o un volumen compartido, debe replicarse manualmente en todos los archivos.

Docker Compose profiles resuelve este problema manteniendo una única fuente de verdad. Todos los servicios y sus configuraciones residen en un solo archivo, y solo se activan los que pertenecen al perfil seleccionado. Esto reduce la fricción en el despliegue y asegura que las diferencias entre entornos son intencionadas, no accidentales.

Declarando profiles en tu docker-compose.yml

Para usar profiles, simplemente añades la clave profiles a la definición de cada servicio que no deba estar siempre activo. Si un servicio no tiene profiles declarado, se considera parte del perfil default y siempre se inicia a menos que se excluya explícitamente.

Aquí tienes un ejemplo práctico de cómo estructuro un archivo docker-compose.yml con perfiles:

services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    # Este servicio siempre estará activo, no tiene profile.

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: app_db
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    volumes:
      - db_data:/var/lib/postgresql/data
    # Este servicio también siempre estará activo.

  adminer:
    image: adminer:latest
    ports:
      - "8080:8080"
    depends_on:
      - db
    profiles:
      - dev
      - staging
    # Adminer solo se iniciará con los perfiles 'dev' o 'staging'.

  metrics:
    image: prom/prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    profiles:
      - production
    # Prometheus solo se iniciará con el perfil 'production'.

volumes:
  db_data:

En este ejemplo, web y db siempre se inician. adminer solo lo hará en dev o staging, mientras que metrics se reserva para production.

Activando profiles para entornos específicos

Para iniciar los servicios con un perfil determinado, usas la bandera --profile con tu comando docker compose up. Puedes especificar múltiples perfiles si lo necesitas.

Para un entorno de desarrollo, donde quieres adminer:

docker compose --profile dev up -d

Esto iniciaría web, db y adminer. Si no especificas ningún perfil, solo se iniciarían web y db. Cuando un cliente me llega con problemas de configuraciones inconsistentes, el problema de que tu código funciona en local y falla en producción se debe a menudo a diferencias no controladas en los servicios auxiliares.

Para un entorno de producción, donde necesitas las métricas pero no adminer:

docker compose --profile production up -d

Esto iniciaría web, db y metrics. Todo se define en un único lugar.

Consideraciones al usar Docker Compose profiles

Usar perfiles es una herramienta con ventajas y desventajas.

Lo que ganas:

• Consistencia: Un solo archivo docker-compose.yml para todos los entornos, minimizando la duplicación y los errores.
• Claridad: Es fácil ver qué servicios pertenecen a qué entorno.
• Flexibilidad: Activas solo los componentes necesarios, optimizando el uso de recursos.
• Mantenimiento simplificado: Los cambios en servicios base solo se hacen en un lugar.

Lo que complicas:

• Curva de aprendizaje inicial: Requiere entender cómo se relacionan los servicios y los perfiles.
• docker-compose.yml más denso: Un archivo único puede ser más largo que múltiples archivos pequeños.

Lo que no negocias:

• La persistencia de datos: Los volúmenes deben estar bien gestionados independientemente del perfil. Si usas volúmenes Docker, versus bind mounts, la estrategia debe ser clara y consistente para evitar pérdidas de información.
• La seguridad en producción: Los servicios de producción deben estar configurados de forma segura, con credenciales en variables de entorno y sin puertos innecesariamente expuestos.

Si estás montando tu infraestructura, asegúrate de tener backups automáticos en un VPS —porque un servidor sin respaldo verificado es una bomba de relojería. También te recomiendo implementar Cloudflare Tunnel como única puerta de entrada al VPS para blindar tu servidor de accesos no deseados.