Docker Compose Networks

Redes en compose.yaml

Docker Compose permite definir y gestionar redes de forma declarativa mediante el archivo compose.yaml, proporcionando una alternativa más organizada y reproducible que los comandos manuales de docker network. Esta aproximación facilita la orquestación de aplicaciones multi-contenedor con requisitos específicos de conectividad.

Red por defecto

Cuando no especificas ninguna red en tu archivo compose.yaml, Docker Compose crea automáticamente una red bridge personalizada para todos los servicios del proyecto. Esta red recibe el nombre del directorio del proyecto seguido de _default.

services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
  
  app:
    image: node:24-alpine
    command: npm start

En este ejemplo, ambos servicios web y app pueden comunicarse entre sí usando sus nombres de servicio como hostnames, gracias a la resolución DNS automática que proporciona Docker Compose.

Definición de redes personalizadas

Para casos más complejos, puedes definir redes personalizadas en la sección top-level networks del archivo compose.yaml:

services:
  frontend:
    image: nginx:latest
    networks:
      - frontend-net
      - shared-net
  
  backend:
    image: node:24-alpine
    networks:
      - backend-net
      - shared-net
  
  database:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secretpassword
    networks:
      - backend-net

networks:
  frontend-net:
    driver: bridge
  backend-net:
    driver: bridge
  shared-net:
    driver: bridge

Esta configuración crea tres redes separadas que permiten aislar y segmentar la comunicación entre servicios según las necesidades arquitecturales.

Configuración de redes en servicios

Dentro de cada servicio, la clave networks puede utilizarse de varias formas para controlar la conectividad:

1 - Asignación simple a redes:

services:
  api:
    image: node:24-alpine
    networks:
      - backend
      - monitoring

2 - Configuración avanzada con aliases:

services:
  database:
    image: mysql:8.0
    networks:
      backend:
        aliases:
          - db
          - mysql-server
          - primary-db
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword

Los aliases permiten que otros servicios en la misma red accedan al contenedor utilizando nombres alternativos, proporcionando flexibilidad en la comunicación entre servicios.

Opciones de configuración de red

Las redes definidas en el nivel superior admiten diversas opciones de configuración:

networks:
  production-net:
    driver: bridge
    driver_opts:
      com.docker.network.bridge.name: prod-bridge
    ipam:
      driver: default
      config:
        - subnet: 172.20.0.0/16
          gateway: 172.20.0.1
    
  external-net:
    external: true
    name: company-network

La opción external: true permite reutilizar redes existentes creadas fuera de Compose, útil cuando múltiples proyectos necesitan compartir la misma infraestructura de red.

Redes con configuración IPAM

Para entornos que requieren control específico sobre direccionamiento IP, puedes configurar el IPAM (IP Address Management):

services:
  web-server:
    image: nginx:latest
    networks:
      custom-subnet:
        ipv4_address: 172.25.0.10

networks:
  custom-subnet:
    driver: bridge
    ipam:
      config:
        - subnet: 172.25.0.0/24
          gateway: 172.25.0.1

Esta configuración asigna una dirección IP estática específica al servicio, proporcionando predictibilidad en la comunicación de red.

Uso de múltiples redes por servicio

Un servicio puede conectarse a múltiples redes simultáneamente, permitiendo arquitecturas complejas donde diferentes aspectos de la aplicación requieren distintos niveles de acceso:

services:
  api-gateway:
    image: nginx:latest
    networks:
      - public
      - internal
      - monitoring
    ports:
      - "80:80"
      - "443:443"
  
  payment-service:
    image: node:24-alpine
    networks:
      internal:
        aliases:
          - payments
          - billing-api
      secure:
        aliases:
          - secure-payments

networks:
  public:
    driver: bridge
  internal:
    driver: bridge
  secure:
    driver: bridge
    internal: true  # Red sin acceso externo
  monitoring:
    driver: bridge

La opción internal: true crea una red completamente aislada del tráfico externo, ideal para comunicaciones sensibles como procesamiento de pagos o datos confidenciales.

Aislamiento y puertos

El aislamiento de servicios y la publicación controlada de puertos constituyen aspectos fundamentales de la seguridad y arquitectura en Docker Compose. Las redes personalizadas proporcionan un mecanismo robusto para segmentar la comunicación, mientras que la gestión de puertos permite controlar qué servicios son accesibles desde el exterior.

Aislamiento mediante segmentación de redes

La separación por redes permite crear boundaries lógicos entre diferentes capas de una aplicación. Los servicios que no comparten ninguna red no pueden comunicarse entre sí, proporcionando un aislamiento efectivo:

services:
  # Frontend público
  web:
    image: nginx:latest
    ports:
      - "80:80"
    networks:
      - frontend-tier
  
  # API intermedia
  api:
    image: node:24-alpine
    networks:
      - frontend-tier  # Acceso desde web
      - backend-tier   # Acceso a base de datos
  
  # Base de datos privada
  database:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secretpassword
    networks:
      - backend-tier   # Solo accesible desde API
    volumes:
      - db-data:/var/lib/postgresql/data

networks:
  frontend-tier:
    driver: bridge
  backend-tier:
    driver: bridge

volumes:
  db-data:

En este ejemplo, el servicio web no puede acceder directamente a database, ya que no comparten ninguna red común. Toda la comunicación debe pasar a través del servicio api, creando un punto de control centralizado.

Publicación selectiva de puertos

La clave ports en Docker Compose controla qué servicios son accesibles desde el host y desde redes externas. Solo los servicios que necesitan acceso público deben exponer puertos:

services:
  # Proxy público - único punto de entrada
  reverse-proxy:
    image: nginx:latest
    ports:
      - "80:80"
      - "443:443"
    networks:
      - public
      - internal
  
  # Aplicación - sin puertos públicos
  app:
    image: node:24-alpine
    # Sin ports: solo accesible internamente
    networks:
      - internal
      - database-tier
  
  # Base de datos - completamente privada
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
    networks:
      - database-tier
    # Sin ports: sin acceso externo

networks:
  public:
    driver: bridge
  internal:
    driver: bridge
  database-tier:
    driver: bridge
    internal: true  # Red sin routing externo

Esta configuración implementa un patrón de proxy reverso donde solo el componente reverse-proxy tiene acceso público, mientras que los servicios internos permanecen completamente aislados del exterior.

Configuración avanzada de puertos

Docker Compose ofrece opciones específicas para controlar cómo se publican los puertos:

services:
  web-secure:
    image: nginx:latest
    ports:
      # Puerto específico del host
      - "8080:80"
      
      # Solo localhost
      - "127.0.0.1:8443:443"
      
      # Rango de puertos
      - "9000-9005:9000-9005"
      
      # UDP específico
      - "53:53/udp"
      
      # Múltiples protocolos
      - target: 80
        published: 8080
        protocol: tcp
        mode: host
    
    networks:
      - web-tier

networks:
  web-tier:
    driver: bridge

La sintaxis extendida permite controlar precisamente el protocolo, la interfaz de escucha y el modo de publicación del puerto.

Estrategias de aislamiento por entorno

Para diferentes entornos de despliegue, puedes implementar niveles de aislamiento variables usando archivos de configuración específicos:

# compose.prod.yaml
services:
  api:
    image: mycompany/api:production
    networks:
      - internal-only
    # Sin ports: solo acceso interno
    
  monitoring:
    image: prometheus:latest
    networks:
      - internal-only
      - monitoring-tier
    # Solo métricas internas

networks:
  internal-only:
    driver: bridge
    internal: true
  monitoring-tier:
    driver: bridge
    internal: true

# compose.dev.yaml  
services:
  api:
    image: mycompany/api:dev
    ports:
      - "3000:3000"  # Acceso directo en desarrollo
    networks:
      - development
      
  monitoring:
    image: prometheus:latest
    ports:
      - "9090:9090"  # Dashboard accesible
    networks:
      - development

networks:
  development:
    driver: bridge

Esta aproximación permite mantener la seguridad en producción mientras facilita el debugging y desarrollo local.

Aislamiento con redes internas

Las redes marcadas como internal proporcionan el máximo nivel de aislamiento, bloqueando completamente el acceso a internet y a otras redes del host:

services:
  payment-processor:
    image: payment-service:latest
    networks:
      - payment-secure
      - audit-logs
    environment:
      - ENCRYPTION_KEY_FILE=/run/secrets/payment_key
  
  audit-service:
    image: audit-logger:latest
    networks:
      - audit-logs
      - external-reporting
  
  external-gateway:
    image: nginx:latest
    ports:
      - "443:443"
    networks:
      - external-reporting
      - public

networks:
  payment-secure:
    driver: bridge
    internal: true  # Sin acceso a internet
    
  audit-logs:
    driver: bridge
    internal: true  # Comunicación interna únicamente
    
  external-reporting:
    driver: bridge
    
  public:
    driver: bridge

En este ejemplo, el payment-processor opera en una red completamente aislada, mientras que external-gateway actúa como único punto de contacto con el exterior, implementando un patrón de defensa en profundidad.

Validación de aislamiento

Para verificar que el aislamiento funciona correctamente, puedes usar comandos de diagnóstico desde los contenedores:

services:
  test-isolation:
    image: alpine:latest
    command: sleep infinity
    networks:
      - isolated-net
  
  should-be-unreachable:
    image: alpine:latest
    command: sleep infinity
    networks:
      - different-net

networks:
  isolated-net:
    driver: bridge
  different-net:
    driver: bridge

Desde un contenedor en isolated-net, intentar hacer ping o conectar al servicio en different-net debería fallar, confirmando que el aislamiento está funcionando según lo esperado.