Hasta ahora hemos visto, la Docker network de tipo bridge. Sin embargo a veces, no
queremos usar la red de Docker y usar directamente la red de nuestro host. Esto es
posible usando el argumento ‐‐net=host cuando despleguemos nuestro contenedor.
Recordar que el argumento ‐‐net puede ser usado para determinar que red usar
cuando despleguemos nuestro contenedor (igual que en rkt, coíncidencia ??).

$ docker inspect ‐‐format='{‌{json .NetworkSettings}}'

Sí por el contrario quieres que tu contenedor no tenga acceso a la red, puedes utilizar
el mismo argumento pero pasándole el valor '­­net=none'. Docker añadirá el contenedor
a un network group pero sin interfaz de red.
A parte de usar estos tres tipos de redes es posible crear tu propia configuración de red
para utilizar en tus contenedores Docker.

Por  defecto, los contenedores están protegidos por el firewall del  anfitrión y no abren ninguna ruta a sistemas externos. Esto puede  cambiarse manipulando un poco con la bandera –network con las siguientes  opciones:

• bridge : Red a través del bridge por defecto de docker

• none : No hay red

• container : red unida con otro contenedor especificado

• host : red de anfitrión (sin firewall)

Todas estas opciones pueden ser gestionadas con el comando docker network

$ docker network ls

NETWORK ID          NAME                           DRIVER              SCOPE

86f4403c1e05        bridge                         bridge              local

d030ab158e04        host                           host                local

2765cfb12659        none                           null                local

Si especificamos none como  la red entonces no seremos capaces de conectarnos al contenedor y vice  versa; El contenedor no tiene acceso al mundo exterior. la opción host  hace que las interfaces del contenedor sean idénticas a las del  anfitrión, comparten la misma IP así que todo lo que corre en el  contenedor es visible desde afuera del mismo. Y finalmente la opción mas  usada es la que viene por defecto: bridge, ya que nos permite controlar  que vamos a exponer y que no, lo cual es mas seguro y accesible.

Drivers de red con Docker

Weave

Weave es independiente de la topología de red que utilices. Esta compuesto de varios componentes que se instalan en cada host:

weave: El daemon que se encarga de todo la gestión de la red a nivel de cada host.

weave­dns: Herramienta para crear dominios que pueden ser accedidos desde cualquier contenedor.

weave­proxy: Crea un proxy que engloba y substituye el proxy de Docker para la comunicación entre Docker hosts.

weave­scope: Herramienta para visualizer la topología que forman todos los contendores.

Algunos de los aspectos a destacar de Weave:

De los primeros en ofrecer soporte para la comunicación entre hosts.

Simple, weave routers se retro alimentan de la información de otros weave router en otros hosts. Esto les permite tener conocimiento de los contenedores y hosts con los que pueden comunicarse.

La información de red está distribuida a través de todos los nodos que componen la Weave network. Esto mejora la tolerancia a fallos.

Sistema de encriptado incorporado, aunque caro a nivel de performance.

• Es capaz de hacer tunneling incluso a través de cortafuegos.

• Service discovery usando weave DNS.

• Usa NAT multicast y MTUs.

• Simple DNS load balancing (round­robin), usand weave­dns.

• Funciona en Giant Swarm, Kubernetes, Mesos.Permite tener una visión de la topología de red y donde estan tus contenedores

• usando Weave­scope.

• Uso de Gossip protocol para compartir la información de red y la reglas de

• enrutado.

Desventajas de Weave:

No es el más rápido de todos los drivers de networking. Aunque ha mejorado su performance recientemente.

Flannel

Desarrollado por CoreOS y pensado para Kubernetes con el concepto de subnets para pods. Al igual que Docker networking utiliza una base de datos clave/valor, Flannel hace uso de etcd para almacenar toda la información de red.

Algunos aspectos a destacar de Flannel son:

Proporciona la posibilidad de crear una network overlay (L3)

• Una subnet CIDR (enrutamiento entre dominios sin clases) por host (como con Kubernetes)

• Host A: 11.0.47.1/24

• Host B: 11.0.87.1/24

• No hay necesidad de hacer mapeos estáticos de puertos y IPs

• Usa etcd para salvaguardar la información de la network

• Contenedores hablan via direcciones IP

• Uso de IPSEC como protocolo de encapsulación

• Ofrece dos tipos de mecanismos para encapsular los paquetes:

• UDP

• VxLAN

• Ofrece drivers para configurar distintos tipos de networks: VxLAN, UDP, alloc,

• host­gw, aws­vpc.

  
  

  Calico

Ofrece un modelo de networking parecido al de Internet (L2­L3).

Permite definir perfiles ACLs para los contenedores. Incrementa la seguridad entre contenedores ya que no es necesario que los contenedores creen iptables si usan links entre ellos.

Usa BGP para compartir la información de enrutado entre todos los hosts que componen el cluster de Calico.

Escala bastante bien con una gran cantidad de contenedores.

Uno de los mejores a nivel de Performance por detrás de Flannel.