Rede de contêineres do Windows

Consulte Rede de contêineres do Docker para conhecer comandos de rede, opções e sintaxe gerais do Docker. Com exceção dos casos descritos neste documento, todos os comandos de rede do Docker têm suporte no Windows com a mesma sintaxe que a do Linux. Observe, no entanto, que as pilhas de rede do Windows e do Linux são diferentes, e como tal, você verá que alguns comandos de rede do Linux (por exemplo, ifconfig) não têm suporte no Windows.

Arquitetura de rede básica

Este tópico fornece uma visão geral de como o Docker cria e gerencia as redes no Windows. Os contêineres do Windows funcionam da mesma forma que máquinas virtuais no que diz respeito à rede. Cada contêiner tem um vNIC (adaptador de rede virtual) que é conectado a um vSwitch (comutador virtual) do Hyper-V. O Windows oferece suporte a cinco modos ou drivers de rede diferentes que podem ser criados por meio do Docker: nat, overlay, transparent, l2bridge e l2tunnel. Dependendo de sua infraestrutura de rede física e dos requisitos de rede de host único ou multi-host, você deve escolher o driver de rede mais adequado às suas necessidades.

Na primeira vez o mecanismo do Docker for executado, ele criará uma rede NAT padrão, 'nat', que usará um vSwitch interno e um componente do Windows chamado WinNAT. Se no host houver vSwitches externos preexistentes que foram criados por meio do PowerShell ou do Gerenciador do Hyper-V, eles também estarão disponíveis para o Docker usando o driver de rede transparent e poderão ser vistos quando o comando docker network ls for executado.

  • Um vSwitch internal é aquele que não está diretamente conectado a um adaptador de rede no host do contêiner

  • Um vSwitch external é aquele que está diretamente conectado a um adaptador de rede no host do contêiner

A rede 'nat' é a rede padrão para os contêineres em execução no Windows. Os contêineres que são executados no Windows sem sinalizadores ou argumentos para implementar configurações de rede específicas serão conectados à rede 'nat' padrão e atribuídos automaticamente a um endereço IP do intervalo de IPs do prefixo interno da rede 'nat'. O prefixo IP interno padrão usado para 'nat' é 172.16.0.0/16.

Drivers de rede de contêineres do Windows

Além de aproveitar a rede 'nat' padrão' criada pelo Docker no Windows, os usuários podem definir redes de contêineres personalizados. Redes definidas pelo usuário podem ser criadas usando-se o comando CLI do Docker, docker network create -d <NETWORK DRIVER TYPE> <NAME>. No Windows, os seguintes tipos de driver de rede estão disponíveis:

  • nat – os contêineres conectados a uma rede criada com o driver 'nat' receberão um endereço IP do prefixo IP especificado pelo usuário (--subnet). Há suporte para o mapeamento/encaminhamento de porta do host de contêiner para os pontos de extremidade do contêiner.

    Observação: várias redes NAT agora são compatíveis com a Atualização do Windows 10 para Criadores!

  • transparent – os contêineres conectados a uma rede criada com o driver "transparent" serão diretamente conectados à rede física. Os IPs da rede física podem ser atribuídos de forma estática (requer a opção --subnet especificada pelo usuário) ou dinâmica usando um servidor DHCP.

  • overlay - novo! Quando o mecanismo do Docker é executado no modo Swarm, os contêineres conectados a uma rede overlay podem se comunicar com outros contêineres conectados à mesma rede entre vários hosts de contêiner. Cada rede overlay que é criada em um cluster Swarm tem a própria sub-rede IP, definida por um prefixo IP privado. O driver de rede overlay usa o encapsulamento de VXLAN.

    Requer o Windows Server 2016 com KB4015217 ou a Atualização do Windows 10 para Criadores

  • l2bridge – os contêineres conectados a uma rede criada com o driver 'l2bridge' ficarão na mesma sub-rede IP do host do contêiner. Os endereços IP devem ser atribuídos estaticamente diretamente do mesmo prefixo que o host do contêiner. Todos os pontos de extremidade do contêiner no host terão o mesmo endereço MAC devido à operação de conversão de endereço de camada 2 (re-write do MAC) na entrada e saída.

    Requer o Windows Server 2016 ou a Atualização do Windows 10 para Criadores

  • l2tunnel - esse driver deve ser usado somente em uma pilha do Microsoft Cloud

Para saber como conectar pontos de extremidade do contêiner a uma rede virtual overlay com a pilha de SDN Microsoft, consulte o tópico Anexando contêineres a uma rede virtual.

A Atualização do Windows 10 para Criadores introduziu o suporte à plataforma para adicionar um novo ponto de extremidade do contêiner a um contêiner em execução (ou seja, 'hot-add'). Isso acenderá de uma ponta a outra pendente uma solicitação de pull pendente do Docker

Topologias de rede e IPAM

A tabela a seguir mostra como a conectividade de rede é fornecida para conexões internas (contêiner para contêiner) e externas para cada driver de rede.

IPAM

Endereços IP são alocados e atribuídos de modo diferente para cada driver de rede. O Windows usa o HNS (Serviço de Rede Host) para fornecer o IPAM ao driver nat e funciona com o modo de Swarm do Docker (KVS interno) para fornecer o IPAM para sobreposição. Todos os outros drivers de rede usam um IPAM externo.

Detalhes sobre a rede de contêineres do Windows

Isolamento (Namespace) com os compartimentos de rede

Cada ponto de extremidade do contêiner é colocado em seu próprio compartimento de rede, que é análogo a um namespace de rede no Linux. O host de gerenciamento vNIC e a pilha da rede do host estão localizados no compartimento de rede padrão. Para impor o isolamento de rede entre contêineres no mesmo host, um compartimento de rede é criado para cada contêiner do Hyper-V e do Windows Server no qual o adaptador de rede do contêiner estiver instalado. Contêineres do Windows Server usam uma vNIC do host para se conectar ao comutador virtual. Os contêineres do Hyper-V usam uma NIC de VM sintética (não exposta à VM do utilitário) para se conectar ao comutador virtual.

Get-NetCompartment

Segurança do Firewall do Windows

O Firewall do Windows é usado para reforçar a segurança de rede por meio de ACLs de porta.

Observação: por padrão, todos os pontos de extremidade do contêiner conectados a uma rede overlay têm uma regra ALLOW ALL (PERMITIR TUDO) criada

Gerenciamento de rede de contêineres com o Serviço de Rede Host

A figura abaixo mostra como o HNS (Serviço de Rede Host) e o HCS (Serviço de Computação de Host) funcionam juntos para criar contêineres e conectar os pontos de extremidade a uma rede.

Opções de rede avançadas no Windows

Várias opções de driver de rede têm suporte para aproveitar os recursos e funcionalidades específicas do Windows.

Agrupamento incorporado do comutador com redes do Docker

Aplicável a todos os drivers de rede

Você pode tirar proveito do Agrupamento incorporado do comutador ao criar redes de host de contêineres para o uso pelo Docker especificando vários adaptadores de rede (separados por vírgulas) com a opção -o com.docker.network.windowsshim.interface.

C:\> docker network create -d transparent -o com.docker.network.windowsshim.interface="Ethernet 2", "Ethernet 3" TeamedNet

Definir a ID de VLAN para uma rede

Aplicável aos drivers de rede transparent e l2bridge

Para definir uma ID de VLAN para uma rede, use a opção -o com.docker.network.windowsshim.vlanid=<VLAN ID> para o comando docker network create. Por exemplo, você pode usar o comando a seguir para criar uma rede transparent com uma ID de VLAN de 11:

C:\> docker network create -d transparent -o com.docker.network.windowsshim.vlanid=11 MyTransparentNetwork

Quando você configura a ID da VLAN para uma rede, está configurando o isolamento da VLAN para os pontos de extremidade de contêiner que serão anexados à rede.

Verifique se o adaptador de rede host (físico) está no modo de tronco para permitir que todo o tráfego marcado seja processado pelo vSwitch com a porta vNIC (ponto de extremidade do contêiner) no modo de acesso na VLAN correta.

Especificar o nome de uma rede para o serviço HNS

Aplicável a todos os drivers de rede

Normalmente, quando você cria a uma rede de contêiner usando docker network create, o nome da rede fornecido é usado pelo serviço Docker, mas não pelo serviço HNS. Se você estiver criando uma rede, pode especificar o nome que é fornecido pelo serviço HNS usando a opção -o com.docker.network.windowsshim.networkname=<network name> para o comando docker network create. Por exemplo, você pode usar o comando a seguir para criar uma rede transparent com um nome que é especificado para o serviço HNS:

C:\> docker network create -d transparent -o com.docker.network.windowsshim.networkname=MyTransparentNetwork MyTransparentNetwork

Associar uma rede a uma interface de rede específica

Aplicável a todos os drivers de rede, exceto 'nat'

Para associar uma rede (conectada por meio do comutador virtual do Hyper-V) a uma interface de rede específica, use a opção -o com.docker.network.windowsshim.interface=<Interface> para o comando docker network create. Por exemplo, você pode usar o comando a seguir para criar uma rede transparent que é anexada à interface de rede "Ethernet 2":

C:\> docker network create -d transparent -o com.docker.network.windowsshim.interface="Ethernet 2" TransparentNet2

Observação: o valor de com.docker.network.windowsshim.interface é o nome do adaptador de rede, que pode ser encontrado com:

PS C:\> Get-NetAdapter

Specify the DNS Suffix and/or the DNS Servers of a Network

Applies to all network drivers

Use the option, -o com.docker.network.windowsshim.dnssuffix=<DNS SUFFIX> to specify the DNS suffix of a network, and the option, -o com.docker.network.windowsshim.dnsservers=<DNS SERVER/S> to specify the DNS servers of a network. For example, you might use the following command to set the DNS suffix of a network to "example.com" and the DNS servers of a network to 4.4.4.4 and 8.8.8.8:

C:\> docker network create -d transparent -o com.docker.network.windowsshim.dnssuffix=abc.com -o com.docker.network.windowsshim.dnsservers=4.4.4.4,8.8.8.8 MyTransparentNetwork

VFP

A extensão VFP (Plataforma de Filtragem Virtual) é um comutador virtual do Hyper-V, uma extensão de encaminhamento usada para impor a política de rede e manipular pacotes. Por exemplo, a VFP é usada pelo driver de rede 'overlay' para executar o encapsulamento de VXLAN e pelo driver 'l2bridge' para executar o re-write do MAC na entrada e na saída. A extensão VFP estará presente somente no Windows Server 2016 e na Atualização do Windows 10 para Criadores. Para verificar se ela está sendo executada corretamente, o usuário executa dois comandos:

Get-Service vfpext

# This should indicate the extension is Running: True 
Get-VMSwitchExtension  -VMSwitchName <vSwitch Name> -Name "Microsoft Azure VFP Switch Extension"

Dicas e percepções

Veja uma lista de dicas úteis e percepções, inspiradas por perguntas comuns sobre as rede de contêineres do Windows que recebemos da comunidade...

O HNS requer que o IPv6 esteja habilitado nos computadores host do contêiner

Como parte do KB4015217, o HNS requer que o IPv6 esteja habilitado em hosts de contêiner do Windows. Se você estiver encontrando um erro, como o mostrado abaixo, há uma chance de que o IPv6 esteja desabilitado no computador host.

docker: Error response from daemon: container e15d99c06e312302f4d23747f2dfda4b11b92d488e8c5b53ab5e4331fd80636d encountered an error during CreateContainer: failure in a Windows system call: Element not found.

Estamos trabalhando em alterações na plataforma para detectar/evitar automaticamente esse problema. Atualmente, a seguinte solução alternativa pode ser usada para garantir o que IPv6 esteja habilitado no computador host:

C:\> reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters  /v DisabledComponents  /f

As máquinas virtuais Moby Linux usam o comutador DockerNAT com o Docker para Windows (um produto do Docker CE) em vez do vSwitch interno do HNS

O Docker para Windows (o driver do Windows para o mecanismo do Docker CE) no Windows 10 usará um vSwitch interno chamado 'DockerNAT' para conectar as máquinas virtuais Moby Linux ao host do contêiner. Os desenvolvedores que usam as máquinas virtuais Moby Linux no Windows devem estar cientes de que seus hosts estão usando o vSwitch DockerNAT em vez do vSwitch criado pelo serviço HNS (que é o comutador padrão usado para contêineres do Windows).

Para usar o protocolo DHCP para atribuição de IP em um host de contêiner virtual, habilite MACAddressSpoofing

Se o host do contêiner for virtualizado e você desejar usar o protocolo DHCP para a atribuição de IP, será necessário habilitar MACAddressSpoofing no adaptador de rede da máquina virtual. Caso contrário, o host Hyper-V bloqueará o tráfego de rede dos contêineres na VM com vários endereços MAC. Você pode habilitar MACAddressSpoofing com este comando PowerShell:

PS C:\> Get-VMNetworkAdapter -VMName ContainerHostVM | Set-VMNetworkAdapter -MacAddressSpoofing On

Criando várias redes transparent em um único host do contêiner

Se desejar criar mais de uma rede transparent, você deverá especificar com qual adaptador de rede (virtual) o Comutador Virtual do Hyper-V externo deverá se associar. Para especificar a interface para uma rede, use a seguinte sintaxe:

# General syntax:
C:\> docker network create -d transparent -o com.docker.network.windowsshim.interface=<INTERFACE NAME> <NETWORK NAME> 

# Example:
C:\> docker network create -d transparent -o com.docker.network.windowsshim.interface="Ethernet 2" myTransparent2

Lembre-se de especificar a 1--subnet e o --gateway ao usar a atribuição de IP estática

Ao usar a atribuição de IP estática, primeiro você deve certificar-se de que os parâmetros --subnet e --gateway sejam especificados quando a rede for criada. O endereço IP da sub-rede e do gateway deve ser o mesmo das configurações de rede para o host do contêiner, isto é, a rede física. Por exemplo, veja como você pode criar uma rede transparent e depois executar um ponto de extremidade da rede usando a atribuição de IP estática:

# Example: Create a transparent network using static IP assignment
# A network create command for a transparent container network corresponding to the physical network with IP prefix 10.123.174.0/23
C:\> docker network create -d transparent --subnet=10.123.174.0/23 --gateway=10.123.174.1 MyTransparentNet
# Run a container attached to MyTransparentNet
C:\> docker run -it --network=MyTransparentNet --ip=10.123.174.105 windowsservercore cmd

A atribuição de IP DHCP não é compatível com redes L2Bridge

Somente a atribuição de IP estática é compatível com as redes de contêiner criadas usando o driver l2bridge. Como mencionado anteriormente, lembre-se de usar os parâmetros 1--subnet e --gateway para criar uma rede que esteja configurada para a atribuição de IP estática.

As redes que aproveitam o vSwitch externo devem ter seu próprio adaptador de rede

Observe que, se várias redes que usam um vSwitch externo para conectividade (por exemplo, transparent, L2 Bridge, L2 Transparent) forem criadas no mesmo host do contêiner, cada um delas precisará ter seu próprio adaptador de rede.

Atribuição de IP em contêineres interrompidos em relação a contêineres em execução

A atribuição de IP estático é executada diretamente no adaptador de rede do contêiner e deve ser executada apenas quando o contêiner estiver em um estado PARADO. Não há suporte para funcionalidade "hot-add" de adaptadores de rede de contêiner ou para alterações da pilha de rede (no Windows Server 2016) enquanto o contêiner estiver em execução.

Observação: esse comportamento está mudando na Atualização do Windows 10 para Criadores, já que a plataforma agora oferece suporte à funcionalidade "hot-add". Essa funcionalidade acenderá o E2E depois que essa solicitação de pull pendente do Docker for mesclada

O vSwitch existente (que não é visível para o Docker) pode bloquear a criação da rede transparent

Se você encontrar um erro ao criar uma rede transparent, possivelmente haverá um vSwitch externo no sistema que não foi descoberto automaticamente pelo Docker e, portanto, estará impedindo a rede transparent de ser associada ao adaptador de rede externo do host do contêiner.

Ao criar uma rede transparent, o Docker cria um vSwitch externo para a rede, então, ele tenta associar o comutador a um adaptador de rede (externo) – o adaptador pode ser um adaptador de rede VM ou adaptador de rede física. Se já tiver sido criado um vSwitch no host do contêiner e ele estiver visível para o Docker, o mecanismo do Windows Docker usará essa opção em vez de criar uma nova. No entanto, se vSwitch tiver sido criado fora de banda (ou seja, criado no host do contêiner usando o Gerenciador de Hyper-V ou PowerShell) e ainda não estiver visível para o Docker, o mecanismo Windows Docker tentará criar um novo vSwitch e, em seguida, estará impossibilitado de conectar o novo comutador ao adaptador externo de rede do host do contêiner (porque o adaptador de rede já estará conectado ao comutador que foi criado fora de banda).

Por exemplo, esse problema surgiria se você primeiro criasse um novo vSwitch em seu host enquanto o serviço Docker estivesse em execução e você tentasse criar uma rede transparent. Nesse caso, o Docker não reconheceria a opção que você criou e criaria um novo vSwitch para a rede transparent.

Há três abordagens para solucionar esse problema:

  • Você pode, é claro, excluir o vSwitch que foi criado fora de banda, que permitirá que o docker crie um novo vSwitch e conecte-o ao adaptador de rede do host, sem problemas. Antes de escolher essa abordagem, certifique-se de que seu vSwitch fora de banda não está sendo usado por outros serviços (por exemplo, Hyper-V).
  • Como alternativa, se você decidir usar um vSwitch externo que foi criado fora de banda, reinicie os serviços de Docker e HNS para tornar a opção visível para o Docker. none PS C:\> restart-service hns PS C:\> restart-service docker
  • Outra alternativa é usar a opção '-o com.docker.network.windowsshim.interface' para associar o vSwitch externo da rede transparent a um adaptador de rede específico que já não está em uso no host do contêiner (ou seja, um adaptador de rede diferente daquele que está sendo usado por vSwitch que foi criado fora de banda). A opção '-o' está descrita acima, na seção Rede Transparent deste documento.

Opções de rede e recursos sem suporte

As seguintes opções de redes não têm suporte no Windows e não podem ser passadas para docker run:

  • Vinculação de contêiner (por exemplo, --link) – a alternativa é contar com a Descoberta de Serviços
  • Endereços IPv6 (por exemplo, --ip6)
  • Opções de DNS (por exemplo, --dns-option)
  • Vários domínios de pesquisa DNS (por exemplo, --dns-search)

As opções de rede e os recursos a seguir não têm suporte no Windows e não podem ser passadas para docker network create:

  • --aux-address
  • --internal
  • --ip-range
  • – ipam-driver
  • --ipam-opt
  • --ipv6

As opções de redes a seguir não são compatíveis com os serviços do Docker

  • Criptografia de plano de dados (por exemplo, --opt encrypted)

Soluções alternativas do Windows Server 2016

Embora continuemos a adicionar novos recursos e promover o desenvolvimento, alguns desses recursos não serão levados de volta para plataformas mais antigas. Em vez disso, o melhor plano de ação é "ficar atento" nas atualizações mais recentes do Windows 10 e do Windows Server. A seção a seguir lista algumas soluções alternativas e avisos que se aplicam ao Windows Server 2016 e a versões mais antigas do Windows 10 (ou seja, antes da Atualização para Criadores 1704)

Várias redes NAT no Host do contêiner WS2016

As partições para qualquer nova rede NAT devem ser criadas sob o maior prefixo interno da rede NAT. O prefixo pode ser encontrado executando o seguinte comando do PowerShell e consultando o campo "InternalIPInterfaceAddressPrefix".

PS C:\> Get-NetNAT

Por exemplo, o prefixo interno da rede NAT do host pode ser, 172.16.0.0/16. Nesse caso, o Docker pode ser usado para criar redes NAT adicionais desde que elas sejam um subconjunto do prefixo 172.16.0.0/16. Por exemplo, duas redes NAT poderiam ser criadas com os prefixos IP 172.16.1.0/24 (gateway, 172.16.1.1) e 172.16.2.0/24 (gateway, 172.16.2.1).

C:\> docker network create -d nat --subnet=172.16.1.0/24 --gateway=172.16.1.1 CustomNat1
C:\> docker network create -d nat --subnet=172.16.2.0/24 --gateway=172.16.1.1 CustomNat2

As redes recém-criadas podem ser listadas usando:

C:\> docker network ls

Docker Compose

Docker Compose pode ser usado para definir e configurar redes de contêiner juntamente com os contêineres/serviços que usarão essas redes. A chave das 'redes' Compose é usada como a chave de nível superior para definir as redes ao qual serão conectados os contêineres. Por exemplo, a sintaxe a seguir define a rede NAT preexistente criada pelo Docker para ser a rede 'padrão' para todos os contêineres/serviços definidos em um determinado arquivo Compose.

networks:
 default:
  external:
   name: "nat"

Da mesma forma, a sintaxe a seguir pode ser usada para definir uma rede NAT personalizada.

Observação: a 'rede NAT personalizada' definida no exemplo abaixo é definida como uma partição do prefixo interno de NAT preexistente do host do contêiner. Consulte a seção acima, 'Várias redes NAT,' para obter mais contexto.

networks:
  default:
    driver: nat
    ipam:
      driver: default
      config:
      - subnet: 172.16.3.0/24

Para obter mais informações sobre como definir/configurar redes de contêiner usando o Docker Compose, consulte a referência de arquivo Compose.

Descoberta de Serviços

A Descoberta de Serviços é compatível somente com determinados drivers de rede do Windows.

Descoberta de Serviços local Descoberta de Serviços global
nat SIM N/D
overlay SIM SIM
transparent NÃO NÃO
l2bridge NÃO NÃO