Requisitos de aplicativos e ambientes de rede são diversos e, às vezes, forças opostas. Entre as aplicações e a rede está a Docker networking, carinhosamente chamada de Container Network Model ou CNM. É que o CNM que media a conectividade para os seus containers Docker e também o que abstrai a diversidade e complexidade tão comum na rede. O resultado é a portabilidade, e ela vem dos poderosos drivers de rede do CNM. Eles são interfaces plugáveis para o Docker Engine, Swarm e UCP que fornecem recursos especiais como rede multi-host, criptografia de camada de rede e descoberta de serviço.

Naturalmente, a próxima pergunta é qual driver de rede devo usar? Cada driver oferece tradeoffs e tem vantagens diferentes, dependendo do caso de uso. Há drivers de rede internos que vêm incluídos com Docker Engine e também há drivers de rede plug-in oferecidos pelos fornecedores de rede e pela comunidade. Os drivers de rede internos mais utilizados são bridge, overlay e macvlan. Juntos eles cobrem uma lista muito ampla de casos de uso de rede e ambientes. Para uma comparação mais aprofundada e discussão de mais drivers de rede, confira a Docker Network Reference Architecture.

Driver de rede Bridge

O driver de rede bridge é o primeiro driver na nossa lista. É simples de entender, simples de usar e simples de solucionar problemas, o que o torna uma boa opção de rede para os desenvolvedores e os novos no Docker. O driver bridge cria uma rede privada interna para o host para que os containers dessa rede possam se comunicar. O acesso externo é concedido pela exposição de portas a containers. O Docker protege a rede gerenciando regras que bloqueiam a conectividade entre diferentes redes Docker.

Nos bastidores, o Docker Engine cria as pontes Linux necessárias, interfaces internas, regras iptables e rotas de host para tornar possível essa conectividade. No exemplo destacado abaixo, uma rede bridge Docker é criada e dois containers são anexados a ela. Sem configuração extra, o Docker Engine faz a fiação necessária, fornece descoberta de serviço para os containers e configura regras de segurança para evitar a comunicação com outras redes. Um driver IPAM interno fornece as interfaces de container com endereços IP privados da sub-rede da rede de bridge.

Nos exemplos a seguir, usamos um aplicativo fictício chamado pets composto de um container web e db. Sinta-se livre para experimentá-lo em seu próprio cluster UCP ou Swarm. Seu aplicativo estará acessível em `<host-ip>: 8000`.

 docker network create -d bridge mybridge
 docker run -d --net mybridge --name db redis
 docker run -d --net mybridge -e DB=db -p 8000:5000 --name web chrch/web

Nosso aplicativo agora está sendo servido no nosso host na porta 8000. O bridge Docker está permitindo que web se comunique com db pelo seu nome de container. O driver bridge faz a descoberta do serviço para nós automaticamente, porque eles estão na mesma rede. Todos os mapeamentos de portas, regras de segurança e pipework entre bridges Linux são tratados para nós pelo driver de rede, já que os containers estão agendados e remarcados em um cluster.

O driver bridge é um driver de escopo local, o que significa que ele só fornece descoberta de serviço, IPAM e conectividade em um único host. A detecção de serviço de vários hosts requer uma solução externa que pode mapear os containers para a localização do host. Isso é exatamente o que torna o driver overlay tão legal.

Driver de rede Overlay

O driver de rede embutido Docker overlay simplifica radicalmente muitas das complexidades na rede multi-host. É um driver de escopo swarm, o que significa que ele opera em todo um cluster Swarm ou UCP, em vez de em hosts individuais. Com o driver overlay, as redes multi-host são cidadãos de primeira classe dentro do Docker sem provisionamento externo ou componentes. O IPAM, descoberta de serviços, conectividade multi-host, criptografia e balanceamento de carga são construídos diretamente. Para controle, o driver overlay usa o plano de controle Swarm criptografado para gerenciar clusters de grande escala em tempos de convergência baixos.

O driver overlay utiliza um plano de dados VXLAN padrão da indústria que desacopla a rede de containers da rede física subjacente (a underlay). Isso tem a vantagem de fornecer portabilidade máxima em várias nuvens e redes locais. A política de rede, a visibilidade e a segurança são controladas centralmente através do UCP (Universal Control Plane) do Docker.

Neste exemplo, criamos uma rede overlay em UCP para que possamos conectar nossos containers web e db quando eles estão vivendo em hosts diferentes. A detecção de serviços baseados em DNS nativos para serviços e containers em uma rede overlay garante que web possa resolver para db e vice-versa. Ativamos a criptografia para que a comunicação entre nossos containers seja segura como padrão. Além disso, visibilidade e uso da rede no UCP são restringidas pelo rótulo de permissões que usamos.

O UCP agendará serviços em todo o cluster e dinamicamente programará a rede overlay para fornecer conectividade aos containers onde quer que estejam. Quando os serviços são suportados por vários containers, o balanceamento de carga baseado em VIP distribuirá o tráfego em todos os containers.

Sinta-se livre para executar este exemplo em seu cluster UCP com os seguintes comandos CLI:

docker network create -d overlay --opt encrypted pets-overlay

docker service create --network pets-overlay --name db redis

docker service create --network pets-overlay -p 8000:5000 -e DB=db --name web chrch/web

Neste exemplo, ainda estamos servindo nosso aplicativo web na porta 8000, mas agora implementamos a nossa aplicação em diferentes hosts. Se quiséssemos dimensionar nossos containers web, as redes Swarm & UCP carregariam o balanço do tráfego para nós automaticamente.

O driver overlay é um driver rico em recursos que lidam com grande parte da complexidade e integração com que as organizações se debatem ao criar soluções fragmentadas. Ele fornece uma solução pronta para muitos desafios de rede e faz isso em escala.

Driver MACVLAN

O driver macvlan é o mais recente driver de rede embutido e oferece várias características exclusivas. É um driver muito leve, porque em vez de usar qualquer bridge Linux ou mapeamento de portas, ele conecta interfaces de container diretamente a interfaces de host. Os containers são endereçados com endereços IP roteáveis que estão na sub-rede da rede externa.

Como resultado de endereços IP roteáveis, os containers se comunicam diretamente com recursos que existem fora de um cluster Swarm sem o uso de NAT e mapeamento de portas. Isso pode ajudar na visibilidade da rede e na solução de problemas. Além disso, o caminho de tráfego direto entre os containers e a interface do host ajuda a reduzir a latência. macvlan é um driver de rede de escopo local que é configurado por host. Como resultado, existem dependências mais estritas entre MACVLAN e redes externas, o que é tanto uma restrição e uma vantagem que é diferente de overlay ou bridge.

O driver macvlan usa o conceito de uma interface pai. Essa interface pode ser uma interface de host como eth0, uma subinterface ou até mesmo um adaptador de host ligado que agrupa interfaces Ethernet em uma única interface lógica. É necessário um endereço de gateway da rede externa durante a configuração da rede MACVLAN, uma vez que uma rede MACVLAN é um segmento L2 do container para o gateway de rede. Como todas as redes Docker, as redes MACVLAN são segmentadas entre si, fornecendo acesso dentro de uma rede, mas não entre redes.

O driver macvlan pode ser configurado de diferentes maneiras para obter resultados diferentes. No exemplo abaixo, criamos duas redes MACVLAN unidas a diferentes subinterfaces. Esse tipo de configuração pode ser usado para estender várias VLANs L2 através da interface do host diretamente para os containers. O gateway padrão VLAN existe na rede externa.

Os containers db e web estão conectados a diferentes redes MACVLAN nesse exemplo. Cada container reside na sua respectiva rede externa com um IP externo fornecido a partir dessa rede. Usando esse projeto, um operador pode controlar a política de rede fora do host e dos containers de segmentos em L2. Os containers também poderiam ter sido colocados na mesma VLAN, configurando-os na mesma rede MACVLAN. Isso mostra apenas a quantidade de flexibilidade oferecida por cada driver de rede.

A portabilidade e a escolha são inquilinos importantes na filosofia Docker. O Docker Container Network Model fornece uma interface aberta para fornecedores e comunidade para construir drivers de rede. A evolução complementar das tecnologias Docker e SDN está proporcionando mais opções e capacidades a cada dia.

Feliz networking!

Mais recursos:

• Confira as últimas atualizações do Docker Datacenter networking
• Leia o mais recente RA: Docker UCP Service Discovery e Load Balancing
• Veja o que há de novo no Docker Datacenter
• Inscreva-se para uma avaliação gratuita de 30 dias

***

Este artigo é do Docker Core Engineering. A tradução do artigo foi feita pela Redação iMasters com autorização, e você pode acompanhar o artigo em inglês no link: https://blog.docker.com/2016/12/understanding-docker-networking-drivers-use-cases/.