Oi, pessoal!

Como vimos neste artigo, é possível utilizar plugins diversos para resolver o desafio da rede, e mostramos neste aqui  um pouco da teoria de como usar o driver de overlay. Hoje, queremos mostrar isso na prática e, para isso, nada melhor do que colocar a mão na massa, certo?  Claro, mas antes precisamos entender um pouco de teoria, e lá vamos nós.

Se você estiver utilizando o Swarm, não é necessário configurar um serviço de chave-valor externo, pois o próprio Swarm faz o controle e persistência das informações de rede que você utiliza. E você deve ter cuidado, pois se quiser utilizar o Overlay com um serviço externo de chave-valor, o modo de cluster via Swarm fica impossibilitado.

Veja abaixo uma tabela com algumas informações relevantes sobre o funcionamento do Overlay:

Protocolo	Porta	Descrição
udp	4789	Data plane (VXLAN)
tcp/udp	7946	Control plane

Ou seja, você deve cuidar para que em seus firewalls essas portas estejam liberadas; caso contrário, a comunicação entre os nós não ocorrerá, o que impossibilitará o funcionamento do Overlay.

Veja abaixo os principais parâmetros em que você deve ter atenção:

• –cluster-store=PROVIDER://URL: Endereço do seu servidor/serviço de chave-valor
• –cluster-advertise=HOST_IP|HOST_IFACE:PORT: IP ou interface do host que será utilizado para comunicação do cluster
• –cluster-store-opt=KEY-VALUE OPTIONS: Configuração opcional, onde é possível definir regras de monitoramento dos hosts e validação TLS

Ok, Cristiano, entendi tudo isso, mas, como vamos testar, qual será o ambiente de laboratório que vamos seguir? Vamos lá, para exemplificar como será o ambiente que vamos montar, segue abaixo uma imagem que ilustra o funcionamento do Docker com o serviço de chave-valor. Todos os hosts consultam esse serviço para identificar quais redes existem e qual bloco/ip deve ser alocado por container. Veja:

Vamos colocar a mão na massa?

Dependências/configuração

Você deve ter um serviço de chave-valor, no qual o Docker persistirá as informações de rede que você criar. Em nosso lab, utilizamos o Consul dentro de um container Docker, rodando em um server a parte dos que participarão do ambiente multi-host. Para isso, executamos:

[root@consul ~]# docker run -d  -p "8500:8500"  -h "consul"  progrium/consul -server -bootstrap

Dessa forma, iniciamos um container com Consul, mapeando a porta 8500 do host para o container, ou seja, para ter acesso ao serviço do Consul, basta acessar ip-do-host:8500. Agora, vamos ao nosso ambiente de Docker.

Nos hosts de Docker (obviamente você já tem o Docker instalado, mas se quiser saber como instalar, veja este artigo), você precisará configurar o daemon para consultar o Consul e buscar as informações de rede. Em nosso laboratório, utilizamos o CentOS; com isso, o arquivo a ser modificado é o: /lib/systemd/system/docker.service, e o deixamos da seguinte forma:

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --cluster-advertise=eth0:2376 --cluster-store=consul://ip-do-consul:8500
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
#TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process

[Install]
WantedBy=multi-user.target

Feito isso, basta reiniciar o serviço e seguirmos para o próximo passo.

Utilização/testes

Agora que você já definiu um serviço de chave-valor a ser consultado, basta criar a sua rede com o driver Overlay. Para isso:

[root@docker01 ~]# docker network create --driver overlay rede1

Você pode definir ainda qual o bloco de ip que deseja para essa rede. Caso não faça essa definição, o Docker associará um bloco automaticamente para você. Fácil, certo? Basta testarmos; para isso, vamos validar em todos os hosts se ambos estão visualizando a mesma rede. Execute este comando em qualquer outro host:

[root@docker01 ~]# docker network ls

Será retornado algo como isto:

NETWORK ID          NAME                DRIVER
64507d0be843f        rede1               overlay
d0bdae8fbe7bd        bridge              bridge
1c0eb8f68962d        none                null
3412c2496d0eb        host                host
697102a22e8d2        docker_gwbridge     bridge

Vamos utilizar essa rede; crie os containers em pelo menos 2 hosts, informando essa nova rede, veja:

[root@docker01 ~]# docker run -it --net=rede1 centos /bin/bash

Agora basta pingar ou acessar os serviços entre os containers que estão nessa mesma rede.

Dessa forma, você pode definir uma rede diferente por grupo de containers, e pode ainda isolar essas redes utilizando o método VXLAN. Para isso, deve passar como parâmetro na criação da rede o seguinte argumento: –opt “com.docker.network.driver.overlay.vxlanid_list=257″. Esse parâmetro fará com que essa rede receba uma vlan, ou seja, todo o trafego direcionado a essa rede receberá uma identificação, impossibilitando que outros containers que não estejam nessa vlan tenham acesso a esse trafego. 

Grande abraço!