Redes Overlay en Docker Swarm: Comunicación entre Servicios

Conecta servicios en Docker Swarm con seguridad y claridad: aquí verás cómo funciona el networking de Swarm, por qué las redes overlay son clave y cómo lograr que una app hable con MongoDB usando resolución por hostname y variables de entorno. Todo con comandos reproducibles y sin tocar la red especial ingress.

¿Cómo funciona el networking de Swarm y qué redes existen?

Swarm agrega capacidades de red distintas al Docker local. En cuanto activas el modo Swarm, aparecen redes con roles bien definidos y un alcance de clúster.

• overlay con scope Swarm: red distribuida, disponible en todos los nodos. Ideal para conectar servicios, ya que el scheduler puede mover tareas entre hosts sin romper la conectividad.
• ingress (overlay especial): red de entrada usada por el enrutamiento de solicitudes. Es compartida por todo el clúster y no debería modificarse. Si necesitas tocarla, probablemente estés resolviendo otro problema.
• docker_gwbridge (bridge): puente local que conecta la red overlay (como ingress) con la red física del nodo. Cada nodo tiene su propia docker_gwbridge.
• bridge, host, none (locales): las clásicas del Docker standalone. No son distribuidas ni comparten alcance entre nodos.

¿Por qué usar overlay para servicios en Swarm?

• Porque no sabes en qué nodo caerá una tarea: el scheduler mueve y reprograma.
• Porque necesitas conectividad cross-host: la overlay garantiza que cualquier tarea, en cualquier host, acceda a la red.

¿Qué implica el scope Swarm?

• La red existe a nivel clúster.
• Solo ves detalles de contenedores conectados en el nodo donde están activos al hacer docker network inspect.

¿Qué es el service discovery por hostname?

• Si dos servicios comparten la misma overlay, se resuelven por hostname usando el nombre del servicio.
• Ejemplo: la app puede alcanzar a db en mongodb://db/test sin IPs duras.

¿Cómo crear una red overlay y conectar servicios por hostname?

Configura una red overlay, despliega MongoDB y tu app, y enlázalos por nombre.

¿Cómo crear la red y verificarla?

• Crea la overlay con driver overlay.

# crear red overlay
docker network create --driver overlay appnet

# listar redes
docker network ls

# inspeccionar la red
docker network inspect appnet

• Verás scope: swarm. Al inicio el inspect luce “vacío” si no hay servicios conectados.

¿Cómo desplegar MongoDB y la app en la misma red?

• Crea el servicio de base de datos y conéctalo a la overlay.

# servicio de base de datos
docker service create \
  --name db \
  --network appnet \
  <imagen_mongo>

# servicio de aplicación
docker service create \
  --name app \
  --network appnet \
  -p 3000:3000 \
  <imagen_app>

• Publica el puerto de la app si necesitas acceso externo (-p 3000:3000). La base no requiere puerto publicado para el uso interno.

¿Cómo pasar la URL de Mongo por variable de entorno?

• Por defecto, la app intentará localhost. Actualiza el servicio para usar el hostname db dentro de la overlay.

# añadir variable de entorno a la app
docker service update \
  --env-add mongoURL=mongodb://db/test \
  app

• Clave: service discovery por hostname en overlay. No necesitas IPs ni puertos explícitos si usas el predeterminado del servicio.

¿Qué validaciones y buenas prácticas se observaron?

Comprueba la comunicación, explora la red y recuerda cuándo no usar bases en Swarm para producción.

¿Cómo verificar tareas, contenedores y escritura en Mongo?

• Revisa el estado de los servicios y en qué nodos corren.

# estado de servicios
docker service ls

docker service ps db

docker service ps app

• En el nodo que ejecuta Mongo, ingresa al contenedor y valida inserts.

# entrar al contenedor
docker ps

docker exec -it <id_contenedor_mongo> bash

# en el shell de mongo
mongo
use test
db.pings.find()

• Si recargas la app y ves “éxito” y más documentos en db.pings, la conectividad funciona entre manager y worker mediante overlay.

¿Qué muestra network inspect cuando hay servicios conectados?

• Ejecuta docker network inspect appnet en un nodo con tareas conectadas.
• Verás:
  • Contenedores adheridos a la red.
  • Componentes internos que permiten el balanceo de carga entre tareas (VIP interno).
  • Lista de peers: nodos que participan de la overlay.

¿Qué buenas prácticas aplicar con databases en Swarm?

• Úsalo para entornos efímeros: pruebas de pull requests o playgrounds.
• Evítalo en producción: una base crítica no debería vivir como servicio de Swarm.
• Consejo adicional: no toques la red ingress. Es una red especial del enrutador de entrada.

¿Tienes dudas o casos de uso específicos con redes overlay, service discovery o publicación de puertos? Cuéntalo y seguimos la conversación.