Oi Pessoal,
Como vimos nesse post, é possível utilizar plugins diversos para resolver o desafio da rede, e mostramos nesse post 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 contrario a comunicação entre os nós não ocorrerá, o que impossibilitará o funcionando do Overlay.
Veja abaixo os principais parâmetros que você deve ter atenção:
| Opção | Descriçã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 opicional, 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 onde 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 -bootstrapDessa 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 esse post 😉 ) 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 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.targetFeito 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 você criar a sua rede com o driver Overlay, para isso:
[root@docker01 ~]# docker network create --driver overlay rede1Você 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 esse comando em qualquer outro host:
[root@docker01 ~]# docker network lsSerá retornando algo como isso:
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/bashAgora 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 tenha acesso a esse trafego.
Legal né? Se gostou nos ajude divulgando o blog.
Grande abraço!
Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.
