Cómo funciona la red en Docker

Lección 4 del curso de Docker.

Cómo funciona la red en Docker

Los contenedores son procesos aislados, pero casi siempre necesitan comunicarse: con el exterior, con otros contenedores o con servicios del anfitrión. Docker resuelve esto con su sistema de redes virtuales.

Los tipos de red (drivers)

  • bridge: la red por defecto. Crea una red privada interna en el anfitrión; los contenedores reciben una IP propia (normalmente del rango 172.17.0.0/16) y salen a Internet a través de NAT.
  • host: el contenedor comparte la red del anfitrión directamente, sin aislamiento ni traducción de puertos. Útil cuando el rendimiento de red es crítico.
  • none: el contenedor no tiene red. Solo para casos muy concretos de máximo aislamiento.
  • overlay: conecta contenedores que corren en máquinas Docker distintas (la base de Docker Swarm y de los clústeres).
  • macvlan: asigna al contenedor una dirección MAC propia para que aparezca como un dispositivo físico más en la red local.

Publicar puertos

Por defecto, un contenedor en una red bridge no es accesible desde fuera. Para exponer un servicio hay que publicar un puerto con -p:

docker run -d -p 8080:80 --name web nginx

Esto redirige el puerto 8080 del anfitrión al puerto 80 del contenedor. Cualquier petición a http://localhost:8080 llega al Nginx del contenedor.

Comunicación entre contenedores

Los contenedores conectados a la misma red bridge definida por el usuario se resuelven entre sí por nombre gracias al DNS interno de Docker. Es la forma correcta de conectar, por ejemplo, una aplicación con su base de datos:

docker network create mi-red
docker run -d --name db --network mi-red -e POSTGRES_PASSWORD=secreto postgres:16
docker run -d --name app --network mi-red -e DB_HOST=db -p 3000:3000 mi-app

Desde el contenedor app, la base de datos es accesible simplemente como db. Nunca dependas de las IPs internas: pueden cambiar en cada arranque.

Comandos útiles de redes

docker network ls                  # lista las redes
docker network inspect mi-red      # detalle: subred, contenedores conectados...
docker network create mi-red       # crea una red bridge
docker network connect mi-red web  # conecta un contenedor ya creado
docker network disconnect mi-red web
docker network rm mi-red           # elimina la red
docker network prune               # borra las redes sin uso

Regla práctica

Usa la red bridge por defecto solo para pruebas rápidas. Para cualquier proyecto real, crea redes propias por aplicación: mejoran el aislamiento, habilitan la resolución por nombre y hacen la arquitectura mucho más clara.

Cómo diagnosticar un problema de red

Cuando dos contenedores no se ven, empieza por lo más simple: comprueba que están en la misma red con docker network inspect NOMBRE, que muestra los contenedores conectados y sus direcciones. Si uno está en otra red, no se resolverán por nombre.

Después entra en uno de los contenedores con docker exec -it NOMBRE sh e intenta llegar al otro, por ejemplo con ping o wget si la imagen los incluye. Si falla la resolución del nombre, el problema está en la red; si el nombre se resuelve pero la conexión falla, suele ser que la aplicación de destino no escucha en la interfaz o el puerto esperado.

Recuerda una diferencia importante: entre contenedores de la misma red se usa el puerto interno, mientras que desde fuera se usa el puerto publicado en tu equipo. Mezclarlos es una causa muy frecuente de errores de conexión. Por último, si publicas puertos en tu equipo, comprueba con el cortafuegos que solo quedan abiertos los que de verdad necesitas.

Buenas prácticas con las redes

Con el tiempo es fácil acabar con muchas redes creadas sin ningún orden. Una costumbre sencilla que evita problemas es crear una red distinta para cada proyecto y darle un nombre que diga a qué pertenece. Así, cuando algo falla, sabes enseguida qué contenedores deberían verse entre sí y cuáles no.

También conviene exponer al exterior solo los puertos que de verdad necesitas. Cada puerto publicado es una puerta abierta a tu máquina, así que si un servicio solo habla con otros contenedores del mismo proyecto, lo correcto es dejarlo dentro de su red interna, sin publicarlo. Es una regla fácil de aplicar y mejora mucho la seguridad sin complicar la configuración.

Te puede interesar

Comentarios

Entradas populares de este blog

Cómo instalar Hermes Agent en Docker y conectarlo con tu suscripción de Antigravity

Docker: OpenBao - para qué sirve y cómo instalarlo

Cómo funciona Docker Compose