Docker
Namespaces de red, interfaces, DNS y conectividad entre servicios.
Cada contenedor obtiene su propio namespace de red: interfaces, direcciones, rutas, puertos y tabla de conexiones. Docker conecta esos namespaces mediante networks y drivers, y ofrece service discovery en redes definidas por el usuario.
container api namespace
├── loopback
├── eth0
├── rutas
└── sockets
↓ veth / driver
Docker network
↓
host y otros containersLa consecuencia más importante es que localhost, una IP y un puerto siempre deben interpretarse desde el namespace donde se ejecuta el proceso.
Dentro del contenedor, el proceso ve una red aislada:
Dos containers pueden escuchar ambos en 0.0.0.0:3000 sin conflicto porque están en namespaces diferentes. El conflicto aparece al publicar ambos en el mismo puerto del host.
docker network create app-net
docker run -d \
--network app-net \
--name db \
postgres:17
docker run -d \
--network app-net \
--name api \
my-apiLa API conecta a:
db:5432No necesita conocer la IP asignada. Docker mantiene resolución DNS para miembros de la network.
Dentro de api:
localhost
→ namespace de apiNo significa:
db;Para otro container usa su nombre DNS. Para el host usa un mecanismo explícito soportado por la plataforma. Para un sistema externo usa su hostname o IP enrutable.
Una aplicación que escucha en:
127.0.0.1:3000solo acepta conexiones desde el loopback del mismo namespace.
Para recibir tráfico desde la network:
0.0.0.0:3000o la dirección específica de la interfaz.
No confundas bind del proceso con publicación del puerto. Ambos deben estar correctos.
En user-defined networks, Docker ofrece resolución para nombres y aliases.
docker network inspect app-netLos nombres son más estables que las IPs, que pueden cambiar al recrear.
No guardes:
DATABASE_HOST=172.18.0.3Prefiere:
DATABASE_HOST=dbLa aplicación debe volver a resolver y reconectar tras reemplazos o pérdida temporal.
Puedes separar flujos:
public network
proxy ↔ internet
backend network
proxy ↔ api
data network
api ↔ dbCompose conceptual:
services:
proxy:
networks: [public, backend]
api:
networks: [backend, data]
db:
networks: [data]
networks:
public:
backend:
internal: true
data:
internal: trueLa database no comparte network con el proxy.
Una network limita qué endpoints son directamente alcanzables, pero no reemplaza:
Un proceso comprometido dentro de api puede usar todas las conexiones permitidas a api. Aplica mínimo acceso también a credenciales y roles de database.
Containers suelen obtener una ruta hacia redes externas mediante el driver y host.
Si falla:
internal;Que el host navegue no garantiza que el container tenga la misma configuración.
En Linux, macOS y Windows el mecanismo puede diferir. Docker Desktop suele ofrecer un nombre especial para el host. En Engine nativo pueden usarse gateways o mappings explícitos.
No hardcodees una IP descubierta manualmente. Documenta la dependencia y prueba en cada plataforma.
Una arquitectura mejor suele evitar que un container dependa de un proceso local no gestionado cuando se despliega fuera del equipo del desarrollador.
docker network connect observability api
docker network disconnect observability apiUn container puede pertenecer a varias networks y tener aliases diferentes en cada una.
Cambiar conectividad en vivo es útil para diagnóstico o migraciones, pero la configuración final debe quedar declarada.
docker network connect \
--alias database \
app-net dbPermiten compatibilidad durante migraciones, pero demasiados aliases ocultan ownership. Mantén un nombre canónico y documenta temporales.
Entre containers de la misma network se usa el puerto del proceso:
api → db:5432El host port solo importa para tráfico que cruza al host:
host:15432 → db:5432No configures la API para conectar a localhost:15432; eso añade un recorrido innecesario y falla dentro del namespace.
docker network inspect app-net¿Ambos containers están conectados?
docker exec api getent hosts dbSi la image no incluye getent, usa un container de diagnóstico en la misma network.
docker run --rm --network app-net nicolaka/netshoot \
nc -zv db 5432Un puerto abierto no demuestra que el protocolo o credenciales funcionen.
docker logs db
docker inspect db --format '{{json .State}}'El destino responde en red, pero no existe listener en ese puerto/interfaz o el proceso rechazó.
Puede ser routing, firewall, proceso bloqueado o destino no alcanzable.
La red funciona; el problema está en la capa de aplicación o confianza.
Containers Linux viven dentro de una VM. Diferencias:
Prueba producción en Linux si ese será el destino.
Tienes db-old y db-new en la misma data network.
api usa alias db
→ inicialmente alias apunta a db-old
→ se replica/migra
→ se actualiza configuración o alias
→ se verifica
→ se retira db-oldLa red facilita coexistencia, pero no realiza consistencia, replicación o rollback. Esas responsabilidades pertenecen al motor y deployment.
El DNS se actualiza, pero pools existentes pueden conservar conexiones fallidas. Implementa retry y reconexión.
DNS puede resolver, pero la database aún no acepta conexiones. Usa readiness y resiliencia.
Puede impedir salida externa. Útil para aislamiento, pero un service que necesita APIs públicas fallará.
La resolución puede ser ambigua según contexto. Evita nombres superpuestos sin necesidad.
VPNs y overlays pueden causar paquetes fragmentados o conexiones que fallan solo con payloads grandes. Revisa MTU cuando pequeños requests funcionan y grandes no.
Corrección: DNS y service names.
Corrección: comunicación interna por network.
Corrección: auth, TLS y roles mínimos.
Corrección: nombre DNS.
Corrección: membresía → DNS → ruta → puerto → protocolo.
localhost apunta al mismo container.Bridge, DNS y port publishing, donde se profundiza en redes bridge, aliases, reglas del host y diagnóstico del flujo completo.