Redes Docker: conecta servicios sin abrir la base
Las redes Docker definen parte de la comunicación entre servicios. Una red bridge creada por el usuario permite resolver nombres de contenedores y separar proyectos mejor que conectar todo indiscriminadamente.
Esta guía utiliza dos contenedores de práctica. No necesita publicar puertos en el host para demostrar su comunicación.
Crea y examina la red
docker network create red-lab
docker network inspect red-labSi el nombre ya existe, revisa quién lo utiliza antes de modificarlo. Una red pertenece a un conjunto de recursos y puede ser compartida por proyectos.
Ejecuta un servidor y un cliente
docker run -d --name servidor-lab --network red-lab nginx:stable-alpine
docker run --rm --network red-lab busybox:1.37 \
wget -qO- http://servidor-labEl cliente utiliza el nombre del contenedor. No necesita la dirección IP, que puede cambiar. Esta prueba confirma una petición dentro de esa red, no disponibilidad pública.
Las imágenes deben estar disponibles para tu arquitectura. Antes de usar una etiqueta de referencia en un entorno real, comprueba mantenimiento.
Puerto interno y publicación
Un servicio puede escuchar dentro de la red sin publicar un puerto del host. EXPOSE es documentación de imagen y no sustituye una opción de publicación.
Para una aplicación con base de datos, normalmente puedes publicar solo la entrada web y mantener la base en una red necesaria para los componentes autorizados.
No confundas “sin publicación” con inaccesibilidad frente a todos los actores del host o de la plataforma. El diseño completo incluye permisos y otras rutas de acceso.
El mismo concepto en Compose
services:
web:
image: nginx:stable-alpine
networks: [frontal]
base:
image: redis:8-alpine
networks: [privada]
networks:
frontal: {}
privada:
internal: trueEste fragmento muestra separación; no describe una aplicación que conecte web con la base. Una aplicación que necesite ambos lados debe pertenecer a las redes apropiadas y controlar qué retransmite.
Una red internal restringe conectividad según el modelo Docker, pero no sustituye autenticación, permisos ni protección del host.
Diagnóstico por capas
Comprueba primero qué redes tiene cada contenedor y qué dirección utiliza el cliente. Después revisa puerto y listener, y finalmente autenticación y protocolo de la aplicación.
Un nombre resuelto no significa que el servicio esté listo. Un connection refused no es lo mismo que un rechazo de credenciales.
Redes externas y retirada
Una red declarada como external en Compose debe existir y tiene un ciclo de vida distinto al de una red creada por el proyecto. Documenta quién la administra.
Para limpiar, retira los contenedores de práctica y luego la red cuando ya no tenga consumidores. No desconectes servicios importantes para eliminar una red cuyo nombre no reconoces.
Preguntas frecuentes
¿Debo usar IP fija para cada contenedor?
No para el caso habitual descrito. Los nombres de servicio y redes adecuadas permiten evitar dependencias de direcciones que cambian.
¿La base necesita un puerto publicado para mi app Docker?
No si ambos se comunican por una red compartida y el servicio escucha correctamente dentro de ella.
¿Separar redes garantiza seguridad completa?
No. Es una capa; también necesitas permisos, autenticación, mantenimiento y pruebas del recorrido real del tráfico.
En pocas palabras
Una red definida por el usuario facilita comunicación y resolución de nombres entre contenedores. Publicar un puerto es otra decisión y no hace falta para toda conexión interna.
Conclusión
Dibuja qué servicios deben hablar entre sí y prueba tanto el acceso permitido como el que debe fallar. Revisa rutas y puertos después de cada cambio de arquitectura.
Para continuar, revisa Docker: qué es y cómo usarlo para ejecutar contenedores y Cómo instalar Docker en Ubuntu 24.04: guía práctica paso a paso.