electrocucaracha

La arquitectura de Docker separó (a partir de la versión 1.6) la creación de Contenedores de la configuración de la red para beneficiar la movilidad de las aplicaciones. En este articulo analizaremos a detalle uno de los estándares propuestos para esta separación.

Container Network Model (CNM)

Es la especificación propuesta por Docker. La biblioteca de libnetwork ofrece una implementación escrita en lenguaje Go. Actualmente proyectos como Cisco Contiv, Kuryr y Weave Net soportan dicha implementación.

Este modelo define tres conceptos principales:

• Sandbox: El cual almacena la configuración de la red. Esta configuración incluye la administración de las interfaces de rede de los contenedores, la lista de rutas de tráfico y los valores de configuración para el DNS. Una implementación de un Sandbox puede ser Linux Network Namespace.
• Endpoint: Permite la conexión de un Sandbox con la red. Una implementación de un Endpoint puede ser veth pair.
• Network: Es un conjunto de Endpoints que se pueden comunicar entre si. Una implementación de un Network puede ser Linux bridge.

Libnetwork utiliza los siguientes objetos en su implementación.

• NetworkController provee un punto de entrada a la biblioteca a traves de una API simple para asignar y manejar redes.
• Driver realiza la implementación de la red. Los drivers pueden ser de dos tipos inbuilt (como Bridge, Host, None y Overlay) o remote.
• Network es la implementación del componente de Network definido anteriormente. El Driver es notificado cada vez que un Network es creado o actualizado.
• Endpoint ofrece conectividad para los servicios. Un Endpoint solo puede ser adjuntado a un Network.
• Sandbox representa la configuración de la red como la dirección IP, la dirección MAC, las rutas de tráfico de red y las entradas del DNS. Un Sandbox puede tener varios Endpoints conectados a diferentes Networks.

El siguiente código en Go muestra la creacion de la red network1 utilizando el driver bridge para mas tarde conectar el contenedor container1 a traves del endpoint Endpoint1.

import (
	"fmt"
	"log"

	"github.com/docker/docker/pkg/reexec"
	"github.com/docker/libnetwork"
	"github.com/docker/libnetwork/config"
	"github.com/docker/libnetwork/netlabel"
	"github.com/docker/libnetwork/options"
)

func main() {
	if reexec.Init() {
		return
	}

	// Select and configure the network driver
	networkType := "bridge"

	// Create a new controller instance
	driverOptions := options.Generic{}
	genericOption := make(map[string]interface{})
	genericOption[netlabel.GenericData] = driverOptions
	controller, err := libnetwork.New(config.OptionDriverConfig(networkType, genericOption))
	if err != nil {
		log.Fatalf("libnetwork.New: %s", err)
	}

	// Create a network for containers to join.
	// NewNetwork accepts Variadic optional arguments that libnetwork and Drivers can use.
	network, err := controller.NewNetwork(networkType, "network1", "")
	if err != nil {
		log.Fatalf("controller.NewNetwork: %s", err)
	}

	// For each new container: allocate IP and interfaces. The returned network
	// settings will be used for container infos (inspect and such), as well as
	// iptables rules for port publishing. This info is contained or accessible
	// from the returned endpoint.
	ep, err := network.CreateEndpoint("Endpoint1")
	if err != nil {
		log.Fatalf("network.CreateEndpoint: %s", err)
	}

	// Create the sandbox for the container.
	// NewSandbox accepts Variadic optional arguments which libnetwork can use.
	sbx, err := controller.NewSandbox("container1",
		libnetwork.OptionHostname("test"),
		libnetwork.OptionDomainname("docker.io"))
	if err != nil {
		log.Fatalf("controller.NewSandbox: %s", err)
	}

	// A sandbox can join the endpoint via the join api.
	err = ep.Join(sbx)
	if err != nil {
		log.Fatalf("ep.Join: %s", err)
	}

	// libnetwork client can check the endpoint's operational data via the Info() API
	epInfo, err := ep.DriverInfo()
	if err != nil {
		log.Fatalf("ep.DriverInfo: %s", err)
	}

	macAddress, ok := epInfo[netlabel.MacAddress]
	if !ok {
		log.Fatalf("failed to get mac address from endpoint info")
	}

	fmt.Printf("Joined endpoint %s (%s) to sandbox %s (%s)\n", ep.Name(), macAddress, sbx.ContainerID(), sbx.Key())
}

Esta propuesta ofrece una gran versatilidad para la creación y administración de las redes de los contenedores, sin embargo el grupo de desarrolladores de Kubernetes no escogió este modelo de red. En su sitio oficial se explica las razones técnicas de dicha selección.

Últimamente se habla mucho sobre contenedores, subrayando los beneficios de su uso para el desarrollo y despliegue de aplicaciones, y en ocasiones se hacen comparaciones erróneas con las Máquinas Virtuales. Este articulo pretende cubrir las opciones de red locales que ofrece Docker al crear contenedores.

Cuando el servicio de Docker inicia este crea localmente tres redes que ofrecen distintas capacidades.

$ docker network list
NETWORK ID          NAME                DRIVER              SCOPE
d1cd6bdefdb7        bridge              bridge              local
e14adf7f1918        host                host                local
9c7b12187b80        none                null                local

Se puede observar los distintos tipos de red local en la columna de DRIVER.

• Bridge: Valor por defecto. Se utiliza cuando las aplicaciones son ejecutadas en contenedores independientes que necesitan comunicarse entre ellos.
• Host: Valor usado en contenedores independientes donde se busca compartir los servicios de red ofrecidos por el servidor donde el contenedor fue creado.
• Null: Deshabilita los servicios de red para dicho contenedor.

Host network

Este tipo de red comparte los servicios de red del equipo donde se ejecuta.  Además de ofrecer las siguientes capacidades:

1. Las interfaces de red del contenedor son idénticas a las de la máquina donde se ejecuta.
2. Solo existe una red de tipo host por máquina.
3. Es necesario especificar el tipo de red como argumento «–net=host».
4. Ni container linking ni port mapping son soportados.

$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:92:e3:8c brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever
$ docker run --net=host bash:5.0.17 ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:92:e3:8c brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever

None network

Es posible crear un contenedor sin algún tipo de red asignada a el. Este contenedor es solo accesible a traves del shell del servidor donde fue creado.

Estos contenedores pueden ser útiles para la ejecución de tareas por lotes que no requieren conectividad hacia o desde ellos.

$ docker run --net=none bash:5.0.17 ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever

Bridge network

Permite la creación de múltiples redes en el mismo servidor ofreciendo una separación lógica de la red, es decir, solo contenedores conectados a la misma red se pueden comunicar entre si.

$ docker run --net=bridge bash:5.0.17 ip addr show eth0
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:50:00:03 brd ff:ff:ff:ff:ff:ff
    inet 172.80.0.3/24 brd 172.80.0.255 scope global eth0
       valid_lft forever preferred_lft forever

La red predeterminada creada por el servicio Docker al momento de iniciar es llamada bridge y crea un bridge llamado docker0 con los valores de una subnet en el rango de 172.80.0.0/24.

$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242eaa3ec7c       no

Todos los contenedores creados en este servidor donde no se especifique su red serán conectados a esta red.