MINI TUTORIAL DOCKER – DÍA 5
Redes Docker y comunicación entre contenedores
(bridge, redes personalizadas, comunicación por nombre, puertos internos vs externos)
1. Objetivo del día
Hoy aprenderás:
- qué redes crea Docker por defecto
- qué significa que un contenedor está “en la red bridge”
- cómo crear redes personalizadas
- cómo conectar varios contenedores en una red común
- cómo hacer que se comuniquen por nombre, sin usar IP
- diferencia entre:
- puertos internos del contenedor
- puertos publicados en el host
- diagnóstico de red básico dentro de contenedores
Todo esto es imprescindible para entender Docker Compose y, más adelante, Kubernetes.
2. Redes por defecto en Docker
Al instalar Docker, se crean varias redes automáticamente:
docker network ls
Salida típica:
NETWORK ID NAME DRIVER SCOPE
xxx bridge bridge local
xxx host host local
xxx none null local
Las importantes:
✔ bridge (la que usan la mayoría de contenedores)
- modo NAT
- cada contenedor obtiene una IP interna
- los contenedores pueden verse entre sí
- para acceder desde fuera → necesitas
-p
✔ host
El contenedor usa directamente la red del host.
No lo tocará un principiante. Lo dejamos fuera (contenido avanzado).
✔ none
Sin red. Cero conectividad.
Sirve para contenedores aislados. Tampoco se usa hoy.
👉 Para nosotros: todo en bridge salvo que creemos otra red personalizada.
3. ¿Qué redes usa un contenedor?
Ejecuta un contenedor:
docker run -d --name test-nginx nginx
Y mira su red:
docker inspect test-nginx | grep IPAddress
Verás algo como:
"IPAddress": "172.17.0.2"
Esta es la IP interna dentro de la red bridge.
Pero no sirve para acceso directo desde tu PC, a menos que publiques puertos con -p.
4. Crear una red personalizada
Esto es clave.
En una red personalizada:
- los contenedores se resuelven por nombre
- Docker crea un DNS interno
- el tráfico es más controlable
- perfecto para apps que deben hablar entre sí
Crear red:
docker network create red-demo
Verla:
docker network ls
5. Lanzar dos contenedores dentro de la misma red
Ejemplo perfecto:
- un contenedor Nginx
- un contenedor Alpine que hace peticiones curl a Nginx
5.1 Crear contenedor Nginx en red-demo
docker run -d --name web --network red-demo nginx
5.2 Crear contenedor Alpine en la misma red
docker run -it --name cliente --network red-demo alpine sh
Una vez dentro del contenedor cliente:
Instalar curl (Alpine es muy minimalista):
apk add curl
Probar conexión por nombre del contenedor:
curl http://web
Si todo va bien, verás el HTML por defecto de Nginx.
6. ¿Por qué funciona esto?
Porque Docker crea un DNS interno para las redes personalizadas.
En red-demo:
web→ nombre del contenedor- Docker resuelve ese nombre a su IP interna
Esto permite construir microservicios y stacks enteros sin usar IPs duras.
7. Diferencia clave: puertos internos vs puertos publicados
En este ejemplo, Nginx escucha en su puerto interno 80.
Pero como NO hemos usado:
-p 8080:80
→ Nginx NO es accesible desde tu PC
→ SOLO es accesible desde contenedores dentro de red-demo
Esto explica:
| Acción | ¿Accesible desde tu PC? | ¿Accesible desde contenedor? |
|---|---|---|
docker run nginx | ❌ NO | ✔ SÍ |
docker run -p 8080:80 nginx | ✔ SÍ | ✔ SÍ |
Esta diferencia es FUNDAMENTAL.
8. Práctica guiada del Día 5 (30–40 min)
✔ 1) Ver redes disponibles
docker network ls
✔ 2) Crear red personalizada
docker network create red-demo
✔ 3) Ejecutar Nginx en esa red
docker run -d --name web --network red-demo nginx
✔ 4) Ejecutar Alpine en esa red
docker run -it --name cliente --network red-demo alpine sh
Dentro instala curl:
apk add curl
✔ 5) Desde Alpine, acceder al servidor Nginx por nombre
curl http://web
✔ 6) (Opcional) Ver IP interna de web
En tu PC:
docker inspect web | grep IPAddress
9. Checklist del Día 5
- Entiendo la red
bridge - Sé crear redes personalizadas
- Sé lanzar contenedores en una red concreta
- Sé comunicar contenedores por nombre
- Entiendo puertos internos vs publicados
- He realizado la práctica guiada
Si todo está marcado → Día 5 completado ✔