A analista Maria gerencia a aplicação WebJus. A WebJus requer a execução de dois containers Docker que necessitam de comunicação entre si. No entanto, para fins de balanceamento de carga, cada container da WebJus foi alocado em um servidor diferente. A fim de configurar a comunicação entre os containers da WebJus de forma simples, Maria criou a rede Docker NetJus, que é capaz de conectar containers rodando em servidores diferentes. A NetJus utiliza o driver de rede Docker:
- A)host;
Errada, porque o driver host compartilha a pilha de rede do próprio host e não é a solução típica para conectar containers em servidores diferentes.
- B)ipvlan;
Errada, porque ipvlan é um driver voltado a integração mais direta com a rede física, mas não é o padrão para comunicação simples entre containers distribuídos em múltiplos hosts.
- C)bridge;
Errada, porque bridge é normalmente usada para comunicação entre containers no mesmo host, não entre servidores diferentes.
- D)overlay;
Certa, porque overlay cria uma rede virtual que conecta containers em hosts distintos, facilitando a comunicação entre eles.
- E)macvlan.
Errada, porque macvlan atribui MAC próprio ao container na rede física, mas não é a solução clássica para unir containers em servidores diferentes.
Gabarito: D
Quando você pensa em containers Docker em servidores diferentes, o ponto central é a comunicação entre hosts. Nesse cenário, a solução mais usada é uma rede do tipo overlay, porque ela cria uma camada de rede virtual que “costura” vários nós do cluster como se estivessem no mesmo ambiente lógico. Isso facilita bastante a vida quando a aplicação tem serviços que precisam conversar entre si, mesmo estando em máquinas distintas. O driver overlay foi pensado justamente para isso: conectar containers distribuídos em diferentes hosts Docker, algo muito comum em arquiteturas de microsserviços e em ambientes orquestrados, como o Docker Swarm. Ele abstrai a complexidade da rede física e permite que os containers se enxerguem por uma rede virtual única. Por isso o gabarito é a letra D. As outras opções até são drivers válidos do Docker, mas têm outras finalidades. A questão deixou a pista bem clara ao dizer que os containers estão em servidores diferentes e precisam se comunicar de forma simples. Esse é o cartão de visita do overlay. Em provas, vale guardar a regra prática: bridge costuma ficar no mesmo host, enquanto overlay é para vários hosts. Essa divisão resolve muitas questões sem sofrimento e sem precisar “recalcular a rota” no susto.