Alcanzar servicios externos

La regla que causa la mayoría de las fallas

Así que cualquier app clonada cuya configuración diga redis://localhost:6379 o postgres://localhost:5432 falla en un contenedor, a menos que ese servicio también corra dentro del mismo contenedor. Todo lo demás aquí es solo: qué dirección usas en su lugar, y si el camino está abierto.

Dos cosas que revisar cada vez

Direccionamiento

¿La configuración de la app apunta a algo distinto de localhost?

Alcanzabilidad

¿El servicio que escucha está ligado a una dirección alcanzable desde fuera de su propio loopback, y su firewall permite la conexión?

Caso 1 — servicio en el mismo host

El servicio corre en tu Mac y el contenedor es local. Aplican las dos revisiones a la vez: nombra el host correctamente, y asegúrate de que el servicio del host acepte la conexión.

Direccionamiento — cómo nombra el contenedor al host

Alcanzabilidad — el servicio del host debe aceptar la conexión

Direccionar bien no basta: un servicio ligado solo a localhost rechazará al contenedor, porque desde la vista del host la conexión llega desde la IP de la VM o del bridge, no desde loopback.

• PostgreSQL: define listen_addresses (p. ej. '*') en postgresql.conf, más una línea en pg_hba.conf para la subred del contenedor.
• Redis: bind debe incluir una dirección que no sea loopback. Si lo abres, define requirepass.
• El firewall del host debe permitir la subred del contenedor.

Caso 2 — servicio en otro contenedor

Cuando la base de datos o el caché corre en su propio contenedor, dirígete a él por nombre — no por localhost, que solo alcanza el loopback del propio contenedor.

• Misma red definida por el usuario: dirígete por nombre de contenedor o servicio vía el DNS interno, p. ej. redis://redis:6379. El puerto interno se usa directo — los puertos publicados con -p son irrelevantes entre contenedores. Es el caso normal y portable.
• Redes o runtimes distintos: no se ven por nombre. Ponlos en una red compartida, o recurre al ruteo por IP del host (Caso 1) a través del puerto publicado del host.
• Un contenedor hermano en una red compartida no necesita trucos de host-gateway — la conexión nunca sale de la red de contenedores.

Caso 3 — servicio remoto o administrado

El caso más simple. Usa el hostname o la IP real — postgres://user:[email protected]:5432/..., redis://cache.internal:6379 — y el contenedor hace una conexión saliente normal. Sin trucos de host-gateway.

• El contenedor tiene salida (por defecto), así que el TCP saliente funciona como siempre.
• El DNS resuelve el hostname.
• El firewall del servicio remoto debe permitir la IP de salida del contenedor — que tras el NAT suele ser la IP del host, no la IP interna del contenedor. Esto importa para las listas de IP permitidas de RDS o Redis administrado.
• TLS está en su lugar si el servicio lo requiere.

Referencia rápida