Docker
Redes bridge definidas por usuario, resolución y acceso externo.
Una user-defined bridge network conecta containers dentro de un mismo host mediante interfaces virtuales, routing y DNS administrados por Docker. Es la opción adecuada para la mayoría de aplicaciones multi-container en un solo Engine.
api namespace ─┐
├─ bridge network ─ host routing/NAT
db namespace ─┘Frente a la bridge predeterminada, una network creada explícitamente ofrece nombres DNS, aislamiento por proyecto y control más claro de membresía.
docker network create backend
docker run -d --network backend --name db postgres:17
docker run -d --network backend --name api my-apiInspección:
docker network inspect backendLa salida permite revisar:
La bridge predeterminada es un recurso global con comportamiento histórico. Las redes definidas por el usuario ofrecen:
No conectes todos los containers a la red predeterminada por comodidad. Crea networks por aplicación o flujo.
Dentro de backend:
api resuelve dbLa IP puede cambiar cuando db se recrea. El nombre continúa siendo la abstracción estable.
Diagnóstico:
docker run --rm --network backend nicolaka/netshoot getent hosts db
docker run --rm --network backend nicolaka/netshoot dig dbLa imagen de aplicación no necesita incluir herramientas de red solo para investigar. Un container temporal en la misma network reduce la superficie del runtime.
docker network connect \
--alias postgres \
--alias database \
backend dbAliases son específicos por network. Pueden facilitar:
No uses aliases para ocultar múltiples servicios no equivalentes. Define un contrato claro.
docker network create \
--subnet 172.30.0.0/24 \
--gateway 172.30.0.1 \
backendFijar subnets puede ser necesario para evitar conflictos con VPN o redes corporativas. Pero aumenta responsabilidad:
No asignes IP estática a cada container salvo requisito real. DNS y service discovery son más flexibles.
docker run -d \
--network backend \
-p 127.0.0.1:3000:3000 \
--name api my-api-p crea una ruta desde host hacia el container. No modifica el puerto en el que escucha la aplicación.
Containers de backend usan:
api:3000No:
host:3000El host port es una frontera externa, no service discovery interno.
La implementación puede utilizar reglas del host, NAT y proxies según plataforma.
Flujo de salida conceptual:
container source IP
→ bridge
→ masquerade/NAT en host
→ red externaFlujo publicado:
host IP:port
→ regla de publicación
→ container IP:portNo edites reglas internas de Docker al azar. Integra firewall mediante políticas soportadas y prueba después de upgrades.
Un puerto publicado puede interactuar con reglas del host de formas que sorprenden a quien asume que un firewall genérico lo bloquea automáticamente. Verifica exposición desde otra máquina.
Checklist:
docker network create --internal dataUna network interna limita acceso externo desde sus miembros según implementación.
Útil para:
Un container conectado además a otra network puede actuar como puente lógico. La topología completa importa.
proxy: public + backend
api: backend + data
db: dataCada interface tiene dirección y rutas. El DNS puede devolver respuestas según la network compartida.
No conectes un servicio a una network solo para “que resuelva”. Pregunta qué flujo de negocio necesita.
api-blue
api-green
proxyAmbas versiones viven en backend. El proxy dirige tráfico a una. Tras health y smoke tests, cambia el upstream.
DNS y aliases facilitan el cambio, pero necesitas:
La network no resuelve el deployment completo.
docker network inspect backenddocker run --rm --network backend nicolaka/netshoot getent hosts dbdocker run --rm --network backend nicolaka/netshoot ip routedocker run --rm --network backend nicolaka/netshoot nc -zv db 5432docker run --rm --network backend postgres:17 \
pg_isready -h db -p 5432docker port api
curl -v http://127.0.0.1:3000/healthContainers pierden acceso a ciertas redes porque la subnet Docker coincide. Elige rangos coordinados.
La IP cambia, pero la app conserva una resolución antigua. Revisa librería, TTL y reconexión.
No puede borrarse si tiene endpoints activos normalmente. La automatización debe desconectar o eliminar containers de forma ordenada.
La ruta de salida elegida puede no ser la esperada. Inspecciona ip route.
Publicar o resolver en IPv6 requiere configuración completa en daemon, network, proceso y firewall.
Pierde reemplazabilidad. Usa DNS.
Amplía superficie. Usa network compartida.
Reduce aislamiento y hace ambiguo ownership.
Sigue capas en orden.
La aplicación todavía necesita autenticación y autorización.
Drivers de red avanzados, donde cambia la integración con host, varios nodos o red física y aparecen trade-offs operativos mayores.