como criar rede overlay docker entre multi hosts?

Eu tenho tentado criar uma rede de sobreposição entre dois hosts sem sucesso. Eu continuo recebendo a mensagem de erro:

mavungu@mavungu-Aspire-5250:~$ sudo docker -H tcp://192.168.0.18:2380 network create -d overlay myapp Error response from daemon: 500 Internal Server Error: failed to parse pool request for address space "GlobalDefault" pool "" subpool "": cannot find address space GlobalDefault (most likely the backing datastore is not configured) mavungu@mavungu-Aspire-5250:~$ sudo docker network create -d overlay myapp [sudo] password for mavungu: Error response from daemon: failed to parse pool request for address space "GlobalDefault" pool "" subpool "": cannot find address space GlobalDefault (most likely the backing datastore is not configured) 

Meus detalhes do ambiente:

 mavungu@mavungu-Aspire-5250:~$ sudo docker info Containers: 1 Images: 364 Server Version: 1.9.1 Storage Driver: aufs Root Dir: /var/lib/docker/aufs Backing Filesystem: extfs Dirs: 368 Dirperm1 Supported: true Execution Driver: native-0.2 Logging Driver: json-file Kernel Version: 3.19.0-26-generic Operating System: Ubuntu 15.04 CPUs: 2 Total Memory: 3.593 GiB Name: mavungu-Aspire-5250 Registry: https://index.docker.io/v1/ WARNING: No swap limit support 

Eu tenho um cluster enxame trabalhando bem com cônsul como o mecanismo de descoberta:

 mavungu@mavungu-Aspire-5250:~$ sudo docker -H tcp://192.168.0.18:2380 info Containers: 4 Images: 51 Role: primary Strategy: spread Filters: health, port, dependency, affinity, constraint Nodes: 2 mavungu-Aspire-5250: 192.168.0.36:2375 └ Containers: 1 └ Reserved CPUs: 0 / 2 └ Reserved Memory: 0 B / 3.773 GiB └ Labels: executiondriver=native-0.2, kernelversion=3.19.0-26-generic, operatingsystem=Ubuntu 15.04, storagedriver=aufs mavungu-HP-Pavilion-15-Notebook-PC: 192.168.0.18:2375 └ Containers: 3 └ Reserved CPUs: 0 / 4 └ Reserved Memory: 0 B / 3.942 GiB └ Labels: executiondriver=native-0.2, kernelversion=4.2.0-19-generic, operatingsystem=Ubuntu 15.10, storagedriver=aufs CPUs: 6 Total Memory: 7.715 GiB Name: bb47f4e57436 

Meu cônsul está disponível em 192.168.0.18:8500 e funciona bem com o cluster de enxame.

Gostaria de poder criar uma rede de sobreposição nos dois hosts. Eu configurei os mecanismos do docker em ambos os hosts com essas configurações adicionais:

 DOCKER_OPTS="-D --cluster-store-consul://192.168.0.18:8500 --cluster-advertise=192.168.0.18:0" DOCKER_OPTS="-D --cluster-store-consul://192.168.0.18:8500 --cluster-advertise=192.168.0.36:0" 

Eu tive que parar e reiniciar os mecanismos e redefinir o cluster enxame … Depois de falhar para criar a rede de sobreposição, eu mudei a configuração –cluster-advertise para isso:

 DOCKER_OPTS="-D --cluster-store-consul://192.168.0.18:8500 --cluster-advertise=192.168.0.18:2375" DOCKER_OPTS="-D --cluster-store-consul://192.168.0.18:8500 --cluster-advertise=192.168.0.36:2375" 

Mas ainda assim não funcionou. Não tenho certeza de qual ip: port deve ser definido para o --cluster-advertise= . Docs, discussões e tutoriais não são claros sobre essa coisa publicitária.

Há algo que estou errando aqui. Por favor ajude.

Quando você executar o comando docker run , certifique-se de adicionar --net myapp . Aqui está um tutorial passo-a-passo completo ( versão online ):

Como implantar o swarm em um cluster com rede de vários hosts

TL; DR: tutorial passo-a-passo para implantar uma rede de vários hosts usando o Swarm . Eu queria colocar on-line este tutorial o mais rápido possível, então nem tive tempo para a apresentação. O arquivo de marcação está disponível no github do meu site . Sinta-se à vontade para adaptá-lo e compartilhá-lo. Ele está licenciado sob uma licença Creative Commons Atribuição 4.0 Internacional .

Pré-requisitos

Meio Ambiente

  • Tutorial feito com o mecanismo de encaixe 1.9.0 .
  • Agentes Swarm são descobertos através de um arquivo compartilhado ( outros methods estão disponíveis ).
  • O Consul 0.5.2 é usado para descoberta de contêineres de enxames de rede de vários hosts .

Swarm manager e consul master serão executados na máquina chamada bugs20. Outros nós, bugs19, bugs18, bugs17 e bugs16, serão agentes de enxame e membros consul .

Antes de começarmos

Cônsul é usado para a rede multihost, qualquer outro armazenamento de valor-chave pode ser usado – note que o mecanismo suporta Consul Etcd e ZooKeeper . Token (ou arquivo estático) são usados ​​para a descoberta de agentes de enxame . Os tokens usam a API REST, um arquivo estático é o preferido.

A rede

A rede está no intervalo 192.168.196.0/25. O host chamado bugsN tem o endereço IP 192.168.196.N.

O daemon do estivador

Todos os nós estão executando o daemon do docker da seguinte forma:

 /usr/bin/docker daemon -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock --cluster-advertise eth0:2375 --cluster-store consul://127.0.0.1:8500 

Detalhes das opções:

 -H tcp://0.0.0.0:2375 

Liga o daemon a uma interface para permitir fazer parte do cluster de enxame . Um endereço IP pode obviamente ser específico, é uma solução melhor se você tiver vários NICs.

 --cluster-advertise eth0:2375 

Define a interface e a porta do daemon do docker deve usar para anunciar a si mesma.

 --cluster-store consul://127.0.0.1:8500 

Define o URL do back-end de armazenamento distribuído. No nosso caso, usamos cônsul , embora existam outras ferramentas de descoberta que possam ser usadas, se você quiser se decidir, deve estar interessado em ler essa comparação de descoberta de serviço .

Como o consul é distribuído, a URL pode ser local (lembre-se, os agentes swarm também são membros consul ) e isso é mais flexível, pois você não precisa especificar o endereço IP do cônsul mestre e ser selecionado depois que o daemon do docker foi iniciado .

Os aliases usados

Nos comandos a seguir, esses dois aliases são usados:

 alias ldocker='docker -H tcp://0.0.0.0:2375' alias swarm-docker='docker -H tcp://0.0.0.0:5732' #used only on the swarm manager 

Certifique-se de ter o caminho do binário consul em seu $PATH . Quando estiver no diretório, basta digitar export PATH=$PATH:$(pwd) fará o truque.

Também é assumido que a variável $IP foi adequadamente configurada e exportada. Isso pode ser feito graças a .bashrc ou .zshrc ou então, com algo assim:

 export IP=$(ifconfig |grep "192.168.196."|cut -d ":" -f 2|cut -d " " -f 1) 

Cônsul

Vamos começar a implantar todos os membros do cônsul e mestre conforme necessário.

Cônsul mestre (bugs20)

 consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul -node=master -bind=$IP -client $IP 

Detalhes das opções:

 agent -server 

Inicie o agente consul como um servidor.

 -bootstrap-expect 1 

Esperamos apenas um mestre.

 -node=master20 

Este servidor / mestre consul será nomeado “master20”.

 -bind=192.168.196.20 

Especifica o endereço IP no qual ele deve ser ligado. Opcional se você tiver apenas um NIC.

 -client=192.168.196.20 

Especifica o endereço IP de RPC no qual o servidor deve ser ligado. Por padrão, é localhost. Note que não tenho certeza sobre a necessidade desta opção, e esta força para adicionar -rpc-addr=192.168.196.20:8400 para solicitação local, como consul members -rpc-addr=192.168.196.20:8400 ou consul join -rpc-addr=192.168.196.20:8400 192.168.196.9 para se juntar ao membro consul que tem o endereço IP 192.168.196.9 .

Membros Consul (bugs {16..19})

 consul agent -data-dir /tmp/consul -node=$HOSTNAME -bind=192.168.196.N 

Sugere-se usar o tmux , ou similar, com a opção :setw synchronize-panes on um comando: consul -d agent -data-dir /tmp/consul -node=$HOST -bind=$IP inicia todos os membros do consul .

Junte-se aos membros da consul

 consul join -rpc-addr=192.168.196.20:8400 192.168.196.16 consul join -rpc-addr=192.168.196.20:8400 192.168.196.17 consul join -rpc-addr=192.168.196.20:8400 192.168.196.18 consul join -rpc-addr=192.168.196.20:8400 192.168.196.19 

Um comando de uma linha pode ser usado também. Se você estiver usando zsh, então consul join -rpc-addr=192.168.196.20:8400 192.168.196.{16..19} é suficiente, ou um loop foor: for i in $(seq 16 1 19); do consul join -rpc-addr=192.168.196.20:8400 192.168.196.$i;done for i in $(seq 16 1 19); do consul join -rpc-addr=192.168.196.20:8400 192.168.196.$i;done . Você pode verificar se seus membros fazem parte da implantação de seu cônsul com o comando:

 consul members -rpc-addr=192.168.196.20:8400 Node Address Status Type Build Protocol DC master20 192.168.196.20:8301 alive server 0.5.2 2 dc1 bugs19 192.168.196.19:8301 alive client 0.5.2 2 dc1 bugs18 192.168.196.18:8301 alive client 0.5.2 2 dc1 bugs17 192.168.196.17:8301 alive client 0.5.2 2 dc1 bugs16 192.168.196.16:8301 alive client 0.5.2 2 dc1 

Consul membros e mestre estão implantados e trabalhando. O foco agora será no docker e no swarm .


Enxame

A seguir, a criação da descoberta de membros do swarm manager e swarm é detalhada usando dois methods diferentes: token e arquivo estático. Os tokens usam um serviço de descoberta hospedado com o Docker Hub, enquanto o arquivo estático é apenas local e não usa a rede (nem qualquer servidor). Solução de arquivo estático deve ser preferida (e é realmente mais fácil).

[arquivo estático] Inicie o gerenciador de enxames ao ingressar em membros do swarm

Crie um arquivo chamado /tmp/cluster.disco com o conteúdo swarm_agent_ip:2375 .

 cat /tmp/cluster.disco 192.168.196.16:2375 192.168.196.17:2375 192.168.196.18:2375 192.168.196.19:2375 

Então apenas inicie o gerenciador de enxames como segue:

 ldocker run -v /tmp/cluster.disco:/tmp/cluster.disco -d -p 5732:2375 swarm manage file:///tmp/cluster.disco 

E pronto!

[token] Crie e inicie o gerenciador de enxames

No mestre do enxame (bugs20), crie um enxame:

 ldocker run --rm swarm create > swarm_id 

Isso cria um enxame e salva o ID do token no arquivo swarm_id do diretório atual. Uma vez criado, o gerenciador de enxames precisa ser executado como um daemon:

 ldocker run -d -p 5732:2375 swarm manage token://`cat swarm_id` 

Para verificar se é iniciado, você pode executar:

 ldocker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d28238445532 swarm "/swarm manage token:" 5 seconds ago Up 4 seconds 0.0.0.0:5732->2375/tcp cranky_liskov 

[token] Junte membros do swarm ao cluster de enxames

Então o gerenciador de enxames precisará de algum agente de enxame para participar.

 ldocker run swarm join --addr=192.168.196.16:2375 token://`cat swarm_id` ldocker run swarm join --addr=192.168.196.17:2375 token://`cat swarm_id` ldocker run swarm join --addr=192.168.196.18:2375 token://`cat swarm_id` ldocker run swarm join --addr=192.168.196.19:2375 token://`cat swarm_id` 

std [in | out] estará ocupado, esses comandos precisam ser executados em terminais diferentes. Adicionar -d antes da join deve resolver isso e permite que um for-loop seja usado para as junções.

Depois da união dos membros do enxame:

 auzias@bugs20:~$ ldocker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d1de6e4ee3fc swarm "/swarm join --addr=1" 5 seconds ago Up 4 seconds 2375/tcp fervent_lichterman 338572b87ce9 swarm "/swarm join --addr=1" 6 seconds ago Up 4 seconds 2375/tcp mad_ramanujan 7083e4d6c7ea swarm "/swarm join --addr=1" 7 seconds ago Up 5 seconds 2375/tcp naughty_sammet 0c5abc6075da swarm "/swarm join --addr=1" 8 seconds ago Up 6 seconds 2375/tcp gloomy_cray ab746399f106 swarm "/swarm manage token:" 25 seconds ago Up 23 seconds 0.0.0.0:5732->2375/tcp ecstatic_shockley 

Após a descoberta dos membros do enxame

Para verificar se os membros são bem descobertos, você pode executar informações do swarm-docker info :

 auzias@bugs20:~$ swarm-docker info Containers: 4 Images: 4 Role: primary Strategy: spread Filters: health, port, dependency, affinity, constraint Nodes: 4 bugs16: 192.168.196.16:2375 └ Containers: 0 └ Reserved CPUs: 0 / 12 └ Reserved Memory: 0 B / 49.62 GiB └ Labels: executiondriver=native-0.2, kernelversion=3.16.0-4-amd64, operatingsystem=Debian GNU/Linux 8 (jessie), storagedriver=aufs bugs17: 192.168.196.17:2375 └ Containers: 0 └ Reserved CPUs: 0 / 12 └ Reserved Memory: 0 B / 49.62 GiB └ Labels: executiondriver=native-0.2, kernelversion=3.16.0-4-amd64, operatingsystem=Debian GNU/Linux 8 (jessie), storagedriver=aufs bugs18: 192.168.196.18:2375 └ Containers: 0 └ Reserved CPUs: 0 / 12 └ Reserved Memory: 0 B / 49.62 GiB └ Labels: executiondriver=native-0.2, kernelversion=3.16.0-4-amd64, operatingsystem=Debian GNU/Linux 8 (jessie), storagedriver=aufs bugs19: 192.168.196.19:2375 └ Containers: 4 └ Reserved CPUs: 0 / 12 └ Reserved Memory: 0 B / 49.62 GiB └ Labels: executiondriver=native-0.2, kernelversion=3.16.0-4-amd64, operatingsystem=Debian GNU/Linux 8 (jessie), storagedriver=aufs CPUs: 48 Total Memory: 198.5 GiB Name: ab746399f106 

Nesse ponto, o swarm é implementado e todos os contêineres executados serão executados em diferentes nós. Executando vários:

 auzias@bugs20:~$ swarm-docker run --rm -it ubuntu bash 

e depois um:

 auzias@bugs20:~$ swarm-docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 45b19d76d38e ubuntu "bash" 6 seconds ago Up 5 seconds bugs18/boring_mccarthy 53e87693606e ubuntu "bash" 6 seconds ago Up 5 seconds bugs16/amazing_colden b18081f26a35 ubuntu "bash" 6 seconds ago Up 4 seconds bugs17/small_newton f582d4af4444 ubuntu "bash" 7 seconds ago Up 4 seconds bugs18/naughty_banach b3d689d749f9 ubuntu "bash" 7 seconds ago Up 4 seconds bugs17/pensive_keller f9e86f609ffa ubuntu "bash" 7 seconds ago Up 5 seconds bugs16/pensive_cray b53a46c01783 ubuntu "bash" 7 seconds ago Up 4 seconds bugs18/reverent_ritchie 78896a73191b ubuntu "bash" 7 seconds ago Up 5 seconds bugs17/gloomy_bell a991d887a894 ubuntu "bash" 7 seconds ago Up 5 seconds bugs16/angry_swanson a43122662e92 ubuntu "bash" 7 seconds ago Up 5 seconds bugs17/pensive_kowalevski 68d874bc19f9 ubuntu "bash" 7 seconds ago Up 5 seconds bugs16/modest_payne e79b3307f6e6 ubuntu "bash" 7 seconds ago Up 5 seconds bugs18/stoic_wescoff caac9466d86f ubuntu "bash" 7 seconds ago Up 5 seconds bugs17/goofy_snyder 7748d01d34ee ubuntu "bash" 7 seconds ago Up 5 seconds bugs16/fervent_einstein 99da2a91a925 ubuntu "bash" 7 seconds ago Up 5 seconds bugs18/modest_goodall cd308099faac ubuntu "bash" 7 seconds ago Up 6 seconds bugs19/furious_ritchie 

Como mostrado, os containers são disseminados através de bugs {16 … 19}.


Rede multi-hosts

Uma sobreposição de rede é necessária para que todos os contêineres possam ser “conectados” a essa sobreposição. Para criar essa sobreposição de rede, execute:

 auzias@bugs20:~$ swarm-docker network create -d overlay net auzias@bugs20:~$ swarm-docker network ls|grep "net" c96760503d06 net overlay 

E voilà!

--net net essa sobreposição for criada, adicione --net net ao comando swarm-docker run --rm -it ubuntu bash e todos os seus contêineres poderão se comunicar nativamente como se estivessem na mesma LAN. A rede padrão é 10.0.0.0/24.

Ativando Multicast

Multicast não é suportado pela sobreposição padrão. Outro driver é necessário para poder usar multicast. O docker plugin weave net suporta multicast.

Para usar este driver, uma vez instalado, você precisará executar o $weave launch em todos os agentes Swarm e no Swarm manager. Então você precisará conectar o weave, isso é feito executando $weave connect $SWARM_MANAGER_IP . Não é obviamente o endereço IP do gerenciador Swarm, mas é mais limpo fazer isso (ou usar outro nó do que os agentes Swarm).

Neste ponto, o cluster tecer é implantado, mas nenhuma rede de tecer foi criada. Correndo $swarm-docker network create --driver weave weave-net irá criar a rede de weave-net denominado weave-net . O início de contêineres com a --net weave-net permitirá que eles compartilhem a mesma LAN e usem multicast. Exemplo de um comando completo para iniciar tais contêineres é: $swarm-docker run --rm -it --privileged --net=weave-net ubuntu bash .

Eu acho que as opções que você especificar deve usar cluster-store=consul vez de cluster-store-consul . Tente redefinir e reiniciar o motor e enxame e verifique se funciona. Deve funcionar depois disso. O documento inicial explica claramente como configurar as redes de sobreposição do docker usando o consul como armazenamento de dados de apoio.

 DOCKER_OPTS="-D --cluster-store=consul://192.168.0.18:8500 --cluster-advertise=192.168.0.18:2375" DOCKER_OPTS="-D --cluster-store=consul://192.168.0.18:8500 --cluster-advertise=192.168.0.36:2375" 

Para qualquer um que acesse isso desde que o Docker 1.12 foi lançado, isso agora é trivialmente fácil – o Swarm Mode está embutido no mecanismo e você não precisa do Consul nem de nenhum outro componente extra.

Supondo que você tenha dois hosts com o Docker instalado, inicie o Swarm na primeira máquina:

 > docker swarm init Swarm initialized: current node (6ujd4o5fx1dmav5uvv4khrp33) is now a manager To add a worker to this swarm, run the following command: docker swarm join \ --token SWMTKN-1-54xs4bn7qs6su3xjjn7ul5am9z9073by2aqpey56tnccbi93zy-blugim00fuozg6qs289etc \ 172.17.0.54:2377 

Esse host se torna o primeiro nó do gerenciador no swarm e grava o comando usado para unir outros nós ao swarm – o token secreto e o endereço IP em que o gerenciador está escutando.

No segundo host:

 > docker swarm join 172.17.0.54:2377 --token SWMTKN-1-54xs4bn7qs6su3xjjn7ul5am9z9073by2aqpey56tnccbi93zy-blugim00fuozg6qs289etc This node joined a swarm as a worker. 

Agora você tem um enxame seguro de 2 nós que tem descoberta de serviço , atualizações contínuas e escala de serviço .

Crie sua rede de sobreposição no nó do gerenciador com:

 > docker network create -d overlay my-net d99lmsfzhcb16pdp2k7o9sehv 

E agora você tem uma rede de sobreposição de vários hosts com DNS interno, para que os serviços possam resolver um ao outro com base no nome do serviço.