come creare una rete overlay docker tra più host?

Ho cercato di creare una rete di sovrapposizione tra due host senza successo. Continuo a ricevere il messaggio di errore:

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) 

I miei dettagli sull’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 

Ho un cluster di sciame che funziona bene con il console come meccanismo di scoperta:

 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 

Il mio console è disponibile a 192.168.0.18:8500 e funziona bene con il cluster swarm.

Mi piacerebbe essere in grado di creare una rete di sovrapposizione tra i due host. Ho configurato i motori di finestra mobile su entrambi gli host con queste impostazioni aggiuntive:

 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" 

Ho dovuto interrompere e riavviare i motori e resettare il cluster Swarm … Dopo aver fallito nel creare la rete di overlay, ho cambiato l’impostazione –cluster-advertise a questo:

 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" 

Ma ancora non ha funzionato. Non sono sicuro di quale ip: port dovrebbe essere impostato per --cluster-advertise= . Documenti, discussioni e tutorial non sono chiari su questa cosa pubblicitaria.

C’è qualcosa che sto sbagliando qui. Per favore aiuto.

Quando si esegue il comando di esecuzione della docker run , assicurarsi di aggiungere --net myapp . Ecco un tutorial passo-passo completo ( versione online ):

Come distribuire lo swarm su un cluster con rete multi-host

TL; DR: tutorial passo-passo per implementare una rete multi-host utilizzando Swarm . Volevo mettere online questo tutorial al più presto, così non ho nemmeno preso tempo per la presentazione. Il file markdown è disponibile sul github del mio sito web . Sentiti libero di adattarti e condividerli, è concesso in licenza con licenza Creative Commons Attribution 4.0 International .

Prerequisiti

Ambiente

  • Esercitazione fatta con il motore di docker 1.9.0 .
  • Gli agenti di sciame vengono scoperti attraverso un file condiviso ( sono disponibili altri metodi ).
  • Consul 0.5.2 viene utilizzato per il rilevamento dei contenitori di sciame della rete multi-host .

Il gestore sciame e il console supervis verranno eseguiti sulla macchina denominata bug20. Altri nodes, bug19, bug18, bug17 e bug16, saranno agenti di sciame e membri di console .

Prima di iniziare

Consul è utilizzato per il networking multihost, qualsiasi altro negozio con valore-chiave può essere utilizzato – si noti che il motore supporta Consul Etcd e ZooKeeper . Token (o file statico) vengono utilizzati per il rilevamento degli agenti di sciame . I token utilizzano l’API REST, un file statico è preferito.

Il network

La rete è compresa nell’intervallo 192.168.196.0/25. L’host denominato bugsN ha l’indirizzo IP 192.168.196.N.

Il daemon docker

Tutti i nodes eseguono il daemon docker come segue:

 /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 

Dettagli delle opzioni:

 -H tcp://0.0.0.0:2375 

Associa il demone a un’interfaccia per consentire di far parte del cluster swarm . Ovviamente è ansible specificare un indirizzo IP, è una soluzione migliore se si dispone di più tabs NIC.

 --cluster-advertise eth0:2375 

Definisce l’interfaccia e la porta del daemon docker deve essere utilizzata per pubblicizzarsi.

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

Definisce l’URL del back-end di storage distribuito. Nel nostro caso usiamo consul , anche se ci sono altri strumenti di scoperta che possono essere utilizzati, se vuoi prendere una decisione dovresti essere interessato a leggere questo confronto di scoperta dei servizi .

Una volta distribuito il console , l’URL può essere locale (ricorda che gli agenti di swarm sono anche membri del console ) e questo è più flessibile in quanto non è necessario specificare l’indirizzo IP del console console ed essere selezionato dopo l’avvio del daemon docker .

Gli alias utilizzati

Nei seguenti comandi vengono utilizzati questi due alias:

 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 

Assicurati di avere il percorso del console binario nel tuo $PATH . Una volta che sei nella directory digita export PATH=$PATH:$(pwd) farà il trucco.

Si presume inoltre che la variabile $IP sia stata correttamente impostata ed esportata. Può essere fatto, grazie a .bashrc o .zshrc o altro, con qualcosa di simile a questo:

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

Console

Iniziamo a distribuire tutti i membri del console e master in base alle esigenze.

Console maestro (bugs20)

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

Dettagli delle opzioni:

 agent -server 

Avviare l’agente consul come server.

 -bootstrap-expect 1 

Ci aspettiamo solo un maestro.

 -node=master20 

Questo console / master console sarà denominato “master20”.

 -bind=192.168.196.20 

Specifica l’indirizzo IP su cui deve essere associato. Facoltativo se si dispone di una sola scheda NIC.

 -client=192.168.196.20 

Specifica l’indirizzo IP RPC su cui il server deve essere associato. Di default è localhost. Si noti che non sono sicuro della necessità di questa opzione e questa forza per aggiungere -rpc-addr=192.168.196.20:8400 per la richiesta locale come i consul members -rpc-addr=192.168.196.20:8400 o consul join -rpc-addr=192.168.196.20:8400 192.168.196.9 per unirsi al membro del console che ha l’indirizzo IP 192.168.196.9 .

Membri di console (bug {16..19})

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

Si consiglia di usare tmux , o simili, con l’opzione :setw synchronize-panes on questo comando: consul -d agent -data-dir /tmp/consul -node=$HOST -bind=$IP avvia tutti i membri del console .

Unisciti ai membri del console

 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 

Può essere usato anche un comando a linea singola. Se stai usando zsh, allora consul join -rpc-addr=192.168.196.20:8400 192.168.196.{16..19} è sufficiente, o un ciclo 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 . Puoi verificare se i tuoi membri fanno parte della distribuzione del tuo console con il 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 

I membri del console e il comandante sono schierati e lavorano. L’attenzione sarà ora sulla finestra mobile e sullo sciame .


Sciame

Di seguito la creazione del gestore sciami e la scoperta dei membri dello sciame sono dettagliati utilizzando due metodi diversi: token e file statico. I token utilizzano un servizio di rilevamento in hosting con Docker Hub mentre il file statico è locale e non utilizza la rete (né alcun server). La soluzione di file statici dovrebbe essere preferita (ed è in realtà più semplice).

[file statico] Avvia il gestore sciame mentre si uniscono membri dello sciame

Crea un file chiamato /tmp/cluster.disco con il contenuto 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 

Quindi avvia il gestore sciame come segue:

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

E hai finito !

[token] Crea e avvia il gestore sciame

Sul master dello sciame (bug20), crea uno sciame:

 ldocker run --rm swarm create > swarm_id 

Questo crea uno sciame e salva l’ID del token nel file swarm_id della directory corrente. Una volta creato, il gestore sciame deve essere eseguito come un demone:

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

Per verificare se è stato avviato puoi eseguire:

 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] Unisciti ai membri dello sciame nel cluster dello sciame

Quindi il gestore dello sciame avrà bisogno di un agente sciame per unirsi.

 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] sarà occupato, questi comandi devono essere eseguiti su terminali diversi. Aggiungere -d prima del join dovrebbe risolvere questo e abilitare un ciclo for da utilizzare per i join.

Dopo l’unione dei membri dello sciame:

 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 

Dopo la scoperta dei membri dello sciame

Per verificare se i membri sono ben scoperti, è ansible eseguire le informazioni di 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 

A questo punto, swarm viene distribuito e tutti i contenitori vengono eseguiti su più nodes. Eseguendo diversi:

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

e quindi a:

 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 

Come mostrato, i contenitori sono disseminati su bug {16 … 19}.


Rete multi-host

È necessario un overlay di rete in modo che tutti i contenitori possano essere “collegati” a questo overlay. Per creare questo overlay di rete, eseguire:

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

E voilà!

Una volta creato questo overlay, aggiungi --net net al comando swarm-docker run --rm -it ubuntu bash e tutti i tuoi contenitori saranno in grado di comunicare in modo nativo come se fossero sulla stessa LAN. La rete predefinita è 10.0.0.0/24.

Abilitare il multicast

Il multicast non è supportato dall’overlay predefinito. È necessario un altro driver per poter usare multicast. Il plugin docker weave net supporta il multicast.

Per utilizzare questo driver, una volta installato, sarà necessario eseguire $weave launch su tutti gli agenti Swarm e il gestore Swarm. Quindi dovrai connettere la tessitura insieme, ciò avviene facendo funzionare $weave connect $SWARM_MANAGER_IP . Ovviamente non è l’indirizzo IP del manager di Swarm, ma è più pulito farlo (o usare un altro nodo rispetto agli agenti di Swarm).

A questo punto viene distribuito il cluster di tessere, ma non è stata creata alcuna rete di tessere. L’esecuzione della rete $swarm-docker network create --driver weave weave-net crea la rete di weave-net denominata weave-net . L’avvio di contenitori con la --net weave-net consentirà loro di condividere la stessa LAN e utilizzare il multicast. Esempio di un comando completo per avviare tali contenitori è: $swarm-docker run --rm -it --privileged --net=weave-net ubuntu bash .

Penso che le opzioni specificate dovrebbero usare cluster-store=consul invece di cluster-store=consul cluster-store-consul . Prova a ripristinare e riavviare il motore e sciame e controllare se funziona. Dovrebbe funzionare dopo. Il documento introduttivo spiega chiaramente come configurare le reti di overlay di docker utilizzando console come archivio di backup.

 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" 

Per chiunque si avvicini a questo poiché Docker 1.12 è stato rilasciato, questo è ora banalmente semplice: la modalità Swarm è integrata nel motore e non è necessario Console o altri componenti aggiuntivi.

Supponendo di avere due host con Docker installato, inizializzare lo Swarm sulla prima macchina:

 > 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 

Quell’host diventa il primo nodo manager nello swarm e scrive il comando che usi per unire altri nodes allo swarm: il token segreto e l’indirizzo IP in cui il gestore è in ascolto.

Sul secondo host:

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

Ora disponi di uno sciame a 2 nodes sicuro con rilevamento dei servizi , aggiornamenti continui e ridimensionamento dei servizi .

Crea la tua rete overlay sul nodo manager con:

 > docker network create -d overlay my-net d99lmsfzhcb16pdp2k7o9sehv 

E ora disponi di una rete overlay multi-host con DNS integrato, in modo che i servizi possano risolversi a vicenda in base al nome del servizio.