Como ya sabrás, Docker es una de las plataformas de contenedorización más populares y emplea la virtualización a nivel de sistema operativo para agrupar aplicaciones de software y sus dependencias en unidades reutilizables llamadas contenedores.
Estos contenedores Docker pueden funcionar en cualquier ordenador que tenga instalado Docker, ya sea en una máquina local o en un entorno remoto en la nube.
Dentro de Docker, se incorpora un sistema de red para gestionar la comunicación entre:
- Los contenedores
- El host
- Y los sistemas externos
Lógicamente, disponemos de varios tipos de red para adaptarnos a diferentes escenarios. Son seis en concreto, y elegir la incorrecta es la causa de buena parte de los ratos perdidos con Docker: contenedores que no se ven entre sí, puertos que no responden o servicios que se pisan.
Vamos a analizarlos uno a uno, viendo cuándo tiene sentido utilizar cada uno y con qué comandos se manejan. Empezamos avisando de la trampa que más tiempo hace perder: la red que Docker te da hecha y la que creas tú no funcionan igual.
Tipos de Redes Docker
Para que los contenedores tengan conectividad, deben estar vinculados a una red de Docker. Las vías de comunicación de cada contenedor dependen de sus asociaciones de red. Docker ofrece seis controladores de red preconfigurados que sirven como columna vertebral de la funcionalidad de red:
Bridge o puente
Esta es la red por defecto. Cada vez que inicias Docker, se crea una red Bridge y todos los contenedores que se inicien se conectarán automáticamente a ella. Puedes utilizarla siempre que quieras que tus contenedores, que se ejecutan de forma aislada, se conecten y se comuniquen entre sí.
Aquí está el tropiezo que se lleva todo el mundo por delante, y conviene tenerlo claro desde el principio: la red bridge por defecto y una red bridge que creas tú no se comportan igual.
En la red por defecto, los contenedores solo se ven por dirección IP. Si intentas que uno llame a otro por su nombre, el sistema devuelve un bad address y te vuelves loco buscando el fallo donde no está. En cambio, en una red que hayas creado tú, Docker levanta un servidor DNS interno y los contenedores se encuentran por nombre sin que configures nada.
Por eso la recomendación práctica es siempre la misma: crea tu propia red y no uses la de por defecto para nada serio.
Como los contenedores se ejecutan de forma aislada, la red puente resuelve el problema del conflicto de puertos. Si los conceptos de red te bailan, los repasamos en redes y subredes explicadas. Los contenedores que se ejecutan en la misma red puente pueden comunicarse entre sí y Docker utiliza iptables en la máquina anfitriona para evitar el acceso fuera del puente.
Host
Los contenedores que utilizan el modo de red host comparten directamente la pila de red del host sin aislamiento.
La red del contenedor funciona como si estuviese directamente en el host. No recibe direcciones IP independientes, sino que los enlaces de puerto se exponen directamente a la interfaz de red del host. Por consiguiente, un proceso en un contenedor que escuche en el puerto 80 se enlazaría a <su_host_ip>:80.
Al no haber traducción de puertos de por medio, es también la opción más rápida y la que tiene sentido cuando un contenedor necesita abrir muchísimos puertos o escuchar tráfico de la red.
Overlay
Las redes superpuestas comprenden redes distribuidas que se extienden por múltiples hosts Docker, lo que permite que los contenedores se comuniquen entre distintos hosts sin necesidad de contar con soporte de enrutamiento a nivel de sistema operativo.
Aunque se emplean principalmente en clusters Docker Swarm, las redes superpuestas también pueden utilizarse para establecer una comunicación directa entre contenedores en distintas instancias de Docker Engine, lo que permite crear entornos personalizados tipo Swarm.
IPvLAN
IPvLAN funciona como un controlador avanzado que proporciona un control preciso sobre las direcciones IPv4 e IPv6 asignadas a los contenedores, además del etiquetado y el enrutamiento VLAN de capa 2 y 3.
Este controlador resulta especialmente útil para integrar servicios de contenedores en redes físicas existentes, ya que ofrece ventajas de usabilidad frente a las redes basadas en puentes.
MACVLAN
MACVLAN es otra opción sofisticada que permite a los contenedores emular dispositivos físicos en la red mediante la asignación de una dirección MAC única a cada uno. Este tipo de red requiere dedicar una de las interfaces físicas del host a la red virtual. Además, es necesario configurar adecuadamente la infraestructura de red general para admitir la posible afluencia de direcciones MAC provenientes de un host Docker activo que gestione muchos contenedores.
none
Aísla completamente un contenedor tanto del host como de otros contenedores.
¿Qué tipo de red debo utilizar?
| Tipo de red | Para qué sirve | Cuándo la quieres | Aislamiento |
| bridge (la que creas tú) | Red privada entre contenedores del mismo host | Casi siempre. Es la respuesta por defecto | Alto |
| bridge por defecto | La que Docker usa si no dices nada | Nunca a propósito: no resuelve nombres | Alto |
| host | El contenedor usa la red del anfitrión tal cual | Cuando necesitas rendimiento o abrir muchos puertos | Ninguno |
| overlay | Une contenedores repartidos en varios hosts | Swarm o varios servidores hablando entre sí | Alto |
| macvlan | Cada contenedor aparece como un aparato físico con su MAC | Domótica y captura de tráfico en la LAN | Medio |
| ipvlan | Como macvlan pero sin MAC propia por contenedor | Cuando el switch o el router limitan las MAC | Medio |
| none | Sin red de ningún tipo | Procesos de cálculo que no deben salir a Internet | Total |
Las redes bridge son la opción más adecuada para la mayoría de los casos, siempre que se trate de una red creada por ti, como mencionábamos anteriormente. Los contenedores que forman parte de ella se comunican entre sí por nombre, sin que sea necesario conocer las direcciones IP, y además tienen acceso a la red de tu host, por lo que pueden conectar con Internet y con tu LAN.
Las redes de host son la mejor opción cuando quieres vincular puertos directamente a las interfaces de tu host y no te preocupa el aislamiento de la red. Estas permiten que las aplicaciones en contenedores funcionen de forma similar a los servicios de red que se ejecutan directamente en el host.
Las redes Overlay son necesarias cuando los contenedores en diferentes hosts Docker necesitan comunicarse directamente entre sí. Estas redes permiten configurar entornos distribuidos propios para lograr una alta disponibilidad.
Las redes Macvlan resultan útiles en situaciones donde los contenedores deben aparecer como un dispositivo físico en la red de tu host, por ejemplo, al ejecutar una aplicación que monitoriza el tráfico de red. Por su parte, las redes IPvLAN son una opción avanzada para casos en los que existen requisitos específicos sobre las direcciones IP, las etiquetas y el enrutamiento de los contenedores.
Los comandos que vas a usar de verdad
Toda la teoría anterior se gestiona con unos pocos comandos. Estos son los que se utilizan el 95 % del tiempo.
Ver qué redes tienes
docker network ls
Aparecerán al menos tres, que Docker crea solo y no debes borrar: bridge (la de por defecto), host y none.
NETWORK ID NAME DRIVER SCOPE
2f259bab93aa bridge bridge local
7c1a0d4e88b2 host host local
b30fe9a71c04 none null local
Crear la tuya
docker network create mi-red
Si no añades más parámetros, se creará una red bridge, que es lo que necesitas en la inmensa mayoría de los casos. Si necesitas fijar el rango de direcciones:
docker network create --subnet 172.28.0.0/16 mi-red
Arrancar un contenedor dentro de ella
docker run -d --name web --network mi-red -p 8080:80 nginx
Meter o sacar un contenedor que ya está corriendo
docker network connect mi-red web
docker network disconnect mi-red web
Un contenedor puede estar en varias redes a la vez. Esta es la forma limpia de montar, por ejemplo, un servidor web accesible desde el exterior y una base de datos que solo se comunique con él.
Ver qué hay dentro de una red
docker network inspect mi-red
Es el comando que utilizarás cuando algo no conecte: te indica el rango de direcciones, la puerta de enlace y qué contenedores están enchufados, junto con su IP.
Limpiar
docker network rm mi-red
docker network prune
El segundo borra de golpe todas las redes que no esté usando ningún contenedor.
prune: elimina cualquier red que no tenga contenedores arrancados en ese momento. Si tienes un docker compose parado, su red también se borrará y, al levantarlo de nuevo, se recreará con un rango de direcciones distinto. Si algo dependía de esas IP, dejará de funcionar.Y con Docker Compose
Si utilizas Compose, casi nunca tendrás que escribir estos comandos: al levantar el proyecto se crea sola una red bridge propia con el nombre de la carpeta y todos los servicios del fichero se integran en ella. Por este motivo, en un compose.yaml puedes llamar a la base de datos por su nombre de servicio (db, postgres…) sin configurar nada: te encuentras en una red creada por ti y con el DNS interno funcionando.
Es exactamente el mismo comportamiento que el del apartado anterior, solo que Compose te lo da hecho.
Fuentes
