Difference between revisions of "Docker Swarm Mode"
(→Ingress hálózat kezelése) |
(→Ingress hálózat kezelése) |
||
| Line 113: | Line 113: | ||
* '''docker_gwbridge''': Nem teljesen értem mire jó. Egy fizikai hálózati elem, tehát nem a docker emulálja. Az overlay network és a node interfésze között hoz létre egy virtuális hidat. Ha nincs, akkor a docker létrehozza. A neve számít. Ha újat akarunk csinálni, akkor Linux operendszer szinten kell törölni, majd egy pont ilyen nevű új hálózatot kell létrehozni a megfelelő paraméterekkel. | * '''docker_gwbridge''': Nem teljesen értem mire jó. Egy fizikai hálózati elem, tehát nem a docker emulálja. Az overlay network és a node interfésze között hoz létre egy virtuális hidat. Ha nincs, akkor a docker létrehozza. A neve számít. Ha újat akarunk csinálni, akkor Linux operendszer szinten kell törölni, majd egy pont ilyen nevű új hálózatot kell létrehozni a megfelelő paraméterekkel. | ||
| + | |||
| + | :[[File:ClipCapIt-180718-213610.PNG]] | ||
| + | <br> | ||
| + | |||
==Ingress hálózat kezelése== | ==Ingress hálózat kezelése== | ||
| Line 118: | Line 122: | ||
* 7946 TCP/UDP for container network discovery. | * 7946 TCP/UDP for container network discovery. | ||
* 4789 UDP for the container ingress network. | * 4789 UDP for the container ingress network. | ||
| − | |||
| − | |||
Az ingress hálózat segítségével tudja megvalósítani a swarm a stateless load balancer funkciót alapértelmezetten round rubin módon. | Az ingress hálózat segítségével tudja megvalósítani a swarm a stateless load balancer funkciót alapértelmezetten round rubin módon. | ||
Revision as of 19:36, 18 July 2018
Contents
Bevezető
IPTV
IPVS (IP Virtual Server) implements transport-layer load balancing, usually called Layer 4 LAN switching, as part of the Linux kernel. IPVS can direct requests for TCP- and UDP-based services to the real servers, and make services of the real servers appear as virtual services on a single IP address. IPVS is built on top of the Netfilter.[
routing mesh
A swarm -on futó szolgáltatások portjait az úgynevezett routing mesh tartja nyilván. Ha egy szolágáltatást egy adott porton el kell hogy érjünk a swarm-on kívülről, akkor be kell regisztrálni a portot a routing mesh-be.
Az alábbi portokat kell kinyitni a VM-ek között még a swarm létrehozása előtt:
- 7946 TCP/UDP for container network discovery.
- 4789 UDP for the container ingress network.
Tip
A docker-machine-el KVM-re létrehozott gépeken minden port nyitva van
Create swarm cluster
A swarm mode cluster-t egy bash szkripttel fogjuk létrehozni. 3 manager-t és 3 worker node-t. Elsőként a három manager virtuális gépet hozzuk létre. Ezután a mg0-ás gépen inicializáljuk a cluster-t, majd az m1 és m2 node-okat manager-ként beléptetjük a cluster-be. Ha ez megvan, akkor létrehozzuk a három worker node-t és azokat worker-ként léptetjük be a cluster-be.
#!/bin/bash
Create managers
for i in 0 1 2; do
docker-machine create -d kvm --kvm-network "docker-network" --kvm-disk-size "5000" --kvm-memory "800" mg$i
done
#Init cluster
docker-machine ssh mg0 docker swarm init --advertise-addr $(docker-machine ip mg0)
#Join managers
MANAGER_TOKEN=`docker-machine ssh mg0 docker swarm join-token -q manager`
WORKER_TOKEN=`docker-machine ssh mg0 docker swarm join-token -q worker`
for i in 0 1 2; do
docker-machine ssh mg$i docker swarm join --token $MANAGER_TOKEN $(docker-machine ip mg0)
done
#Create workers
for i in 0 1 2; do
docker-machine create -d kvm --kvm-network "docker-network" --kvm-disk-size "5000" --kvm-memory "800" worker$i
docker-machine ssh worker$i docker swarm join --token $WORKER_TOKEN $(docker-machine ip mg0)
done
Tip
A KVM helyett itt használhattunk volna Amzaon EC2-es driver-t is, pont ugyan így létrehozta volna az egész cluster-t pár perc alatt. Részletek itt: Docker Swarm on AWS
Ha lefutottak a script, nézzük meg a keletkezett VM-eket elsőként docker-machine szemszögből:
# docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS mg0 - kvm Running tcp://192.168.42.41:2376 v18.05.0-ce mg1 - kvm Running tcp://192.168.42.79:2376 v18.05.0-ce mg2 - kvm Running tcp://192.168.42.154:2376 v18.05.0-ce worker0 - kvm Running tcp://192.168.42.162:2376 v18.05.0-ce worker1 - kvm Running tcp://192.168.42.74:2376 v18.05.0-ce worker2 - kvm Running tcp://192.168.42.136:2376 v18.05.0-ce
Majd nézzük meg a virsh-val is.
# virsh list Id Name State ---------------------------------------------------- 2 mg0 running 3 mg1 running 7 mg2 running 8 worker0 running 9 worker1 running 10 worker2 running
Most listázzuk ki a swarm cluster node-jait elsőként az mg0-án, majd az mg1-en. Mind a két esetben ugyan azt az eredményt kapjuk. Láthatjuk, hogy jelenleg az mg0 a vezető.
# docker-machine ssh mg0 docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION nl5mmm994ckimhe5vjazjjecs * mg0 Ready Active Leader 18.05.0-ce vacts6xlgb6ufyx49vx6fxgt0 mg1 Ready Active Reachable 18.05.0-ce 3llb2b0qh7oids0qhych9w73r mg2 Ready Active Reachable 18.05.0-ce s7hp748qu6u4bb98doss31t4r worker0 Ready Active 18.05.0-ce 211o588k4qw2uymq6dl977mmt worker1 Ready Active 18.05.0-ce hlzuosjp7wx6rxt0a66fms698 worker2 Ready Active 18.05.0-ce
# docker-machine ssh mg1 docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION nl5mmm994ckimhe5vjazjjecs mg0 Ready Active Leader 18.05.0-ce vacts6xlgb6ufyx49vx6fxgt0 * mg1 Ready Active Reachable 18.05.0-ce 3llb2b0qh7oids0qhych9w73r mg2 Ready Active Reachable 18.05.0-ce s7hp748qu6u4bb98doss31t4r worker0 Ready Active 18.05.0-ce 211o588k4qw2uymq6dl977mmt worker1 Ready Active 18.05.0-ce hlzuosjp7wx6rxt0a66fms698 worker2 Ready Active 18.05.0-ce
Networking
Hálózat típusok
Háromféle fontos hálózat típus van a swarm-ban az alap docker hálózatokon felül (ebből egyik a másik részlalmaza)
https://docs.docker.com/v17.09/engine/swarm/networking/
- overlay network: Ez egy hostokon átívelő virtuális hálózat fajta, amit a docker emulál. (tehát nem Linux kernel funkció). A rá kapcsolódott konténerek számára transzparensen működik, hiába vannak más és más fizikai hálózatokban, úgy látják, mind ha közös hálózaton lennénk. Az overlay hálózatot a docker az úgynevezett overlay driver-el hozza létre. Ezzel emulálja a hálózatot.
- ingress network: Ez egy speciális overlay hálózat, ebből csak 1 lehet egy swarm-on belül. Nem a neve, hanem a típusa számít. Ha mi nem hozzuk létre, akkor a docker fogja létrehozni a cluster inicializálásakor. Ezt load-balancolásra használja a docker. Ha bármelyik swarm node -ra érkezik egy kérés (akár olyanra is amin nem is fut konténer) akkor is továbbítja a kérést a megfelelő node-ra. A load-balancer-t a Linux kernelben található IPVS-el hozza létre, ami egy szállítási réteg beli load-balancer. A megfelelő konténer megtalálását (IP cím + port) az úgynevezett "routing mesh" végzi.
- docker_gwbridge: Nem teljesen értem mire jó. Egy fizikai hálózati elem, tehát nem a docker emulálja. Az overlay network és a node interfésze között hoz létre egy virtuális hidat. Ha nincs, akkor a docker létrehozza. A neve számít. Ha újat akarunk csinálni, akkor Linux operendszer szinten kell törölni, majd egy pont ilyen nevű új hálózatot kell létrehozni a megfelelő paraméterekkel.
Ingress hálózat kezelése
Ahogy azt már láthattuk, az ingress network virtuálisan összeköti az összes swarm node-ot, még akkor is ha azok nem egy lokális hálózaton vannak. Annyi a megkötés, hogy a node-oknak el kell tudni egymást érni az alábbi portokon:
- 7946 TCP/UDP for container network discovery.
- 4789 UDP for the container ingress network.
Az ingress hálózat segítségével tudja megvalósítani a swarm a stateless load balancer funkciót alapértelmezetten round rubin módon.
Ingres hálózat monitorozása
Bármelyik swarm node-on (akár manager, akár worker) adjuk ki a docker network ls parancsot, hogy kilistázzuk az összes ottani docker hálózatot:
# docker-machine ssh mg0 docker network ls NETWORK ID NAME DRIVER SCOPE b71223c228cd bridge bridge local 410e603aa9c2 docker_gwbridge bridge local 53cd23b3594b host host local idf7f51tp95i ingress overlay swarm <<<< 4fb53b47cf55 none null local
Ha mi magunk nem hoztunk létre új overlay hálózatot kézzel, akkor csak az ingress hálózat lesz swarm szkőpú, az összes többi hálózat lokális lesz
Új ingress hálózat létrehozása
- overlay hálózatból többet is csinálhatunk, de csak egynek lehet ingress a típusa. Az alapértelmezett ingress hálózaton felül a --network kapcsolóval adhatunk meg további overlay hálózatokat a docker service create -nek.
- Ha az ingress hálózatnak nem megfelelőek az alapértelmezett beállításai, pl nem jó az IP tartomány, vagy a service-ek egymás között kommunikációját is titkosítani a akarjuk, akkor sajnos ki kell törölni és kézzel létre kell hozni --ingress kapcsolóval.
- Ez a docker által létrehozott eszköz, nem a linux kernel hozza létre
- Egyszerre csak egy ingress típusú hálózat lehet létezhet egy swarm-ban, ezért fontos, hogy előtt kitöröljük. A neve bármi lehet, nem csak ingress. A swarm nem a neve alapján fogja megtalálni, hanem a típusa alapján. Mivel csak egy lehet, ezért ez egyértelmű.
- az egyetlen hálózat swarm scope-al
docker network create \ --driver overlay \ --ingress \ --subnet=10.11.0.0/16 \ --gateway=10.11.0.2 \ -- --opt encrypted \ <<< a service-ek kommunikációját titkosítja --opt com.docker.network.driver.mtu=1200 \ my-ingress
docker_gwbridge
- A docker_gwbridge egy valódi fizikai hálózat, egy virtuális bridge, amit a Linux kernel-ben hoz létre a docker. Ezt láthatjuk a VM-en kiadott ifconfig paranccsal
- viszont itt a név nagyon is számít. Mivel ez egy fizikai hálózat, a docker pont ilyen néven fogja keresni, mikor a swarm -ot létrehozza. Ha nincs készíteni fog egy újat, ha már van, akkor ezt fogja felhasználni.
- Ha módosítani akarnánk, akkor ki kell törölni Linux parancsokkal (pl: ip), majd kézzel létre kell hozni az új beállításokkal a docker network create paranccsal.
# docker-machine ssh mg0 docker network ls NETWORK ID NAME DRIVER SCOPE b71223c228cd bridge bridge local 410e603aa9c2 docker_gwbridge bridge local <<<< 53cd23b3594b host host local idf7f51tp95i ingress overlay swarm <<<< 4fb53b47cf55 none null local
# docker-machine ssh mg0 ifconfig
...
docker_gwbridge Link encap:Ethernet HWaddr 02:42:DF:B6:9C:AE
inet addr:172.18.0.1 Bcast:172.18.255.255 Mask:255.255.0.0
inet6 addr: fe80::42:dfff:feb6:9cae/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:1418 (1.3 KiB)
Load balancing
Routing mesh for stateless services
A dokker-ben van egy "layer 4", szállítási rétegbeli, beépített load balnacer.
Ha a --publis kulcsszóval hozunk létre úgy szolgáltatást, akkor
Load balancing for statefull services
A dokker-ben van egy beépített "layer 4", szállítási rétegbeli, beépített load balnacer.
Ha a --publis kulcsszóval hozunk létre úgy szolgáltatást, akkor
- Ahogy azt már a bevezetőben láthattuk, az úgynevezett routing mesh felelős azért, hogy egy külső portról elérjük a swarm szolgáltatást egy megadott porton.
- A --publish kulcsszóval kell regisztrálni a port mapping-et. A published a külső még a target a belső port.
Warning
A routing mesh-t logikus módon csak akkor tudjuk használni, ha minden host-on a service-nek csak 1 példánya fut. Különben ki kell kapcsolni a routing mesh-t (lásd lentebb)
$ docker service create \ --name my-web \ --publish published=8080,target=80 \ --replicas 2 \ nginx
Vagy meglévő szolgáltatáshoz meg lehet adni új port mapping-et a --publish-add kapcsolóval.
$ docker service update \ --publish-add published=8080,target=80 \ my-web
A --publish és --publish-add parancs alapértelmezetten csak tcp portot ad hozzá. A protocol=udp kapcsolóval lehet udp portot is hozzáadni
--publish published=53,target=53,protocol=udp
A routing mesh akkor van bekapcsolva egy adott service-re, ha a --publish kapcsolónak megadjuk ezt: mode=ingress Ez az alapértelmezett. Ha ki akarjuk kapcsolni a routing mesh-t, akkor ezt host-re kell állítani:
# docker service create --name dns-cache \ --publish published=53,target=53,protocol=udp,mode=host \ dns-cache
Load balancer
https://docs.docker.com/network/overlay/#operations-for-standalone-containers-on-overlay-networks
Minden egyes swarm node-on fut egy load balancer, így teljesen mindegy hogy melyik node-t szólítjuk meg, még akkor is a helyes konténerbe fog irányítani, ha az adott node-on nem is fut az a service, amit megcímeztünk (a port alapján).
Ezt egy beépített DNS szerverrel éri el a swarm.
--endpoint-mode dnsrr
Monitorozás
Több grafikus docker monitor eszköz is létezik:
- Shipyard (webes)
- Portainer (webes)
- Kitematic (vastag kliens)
A legegyszerűbb a Portainer használata, ami egyetlen konténert telepít fel a docker-be, képes távoli docker démonho is kapcsolódni, és van benne swarm mode támogatás is.
Két lehetőségünk van a Portainer futtatására:
- Ahhoz hogy a swarm klászer adatait tudjuk monitorozni, valamelyik manager node-on futó docker démonhoz kell kapcsolódni a lokális docker -ben futó Portainer-el. Ezt TLS autentikációval lehet megoldani. Ekkor a Portanier a localhost-on érhető el. (mi ezt fogjuk használni)
- A Portainer-t eleve a manager node-ot is futtató docker démonban telepítjük fel a távoli gépen, ekkor Portanier a távoli gép IP címén érhető el.
A KVM dirver-el készült docker-machine-ekre boot2docker operációs rendszer kerül feltelepítésre, ha ezt nem változtatjuk meg. A boot2docker-ben alapértelmezetten be van kapcsolva a TLS remote docker API (port: 2376), és a titkosítatlan távoli hozzáférés ki van kapcsolva (port: 2375)
Note
A példában a mg0 manager node-ra fogunk kapcsolódni, de pont ugyan ezt az eredményt kapnánk az mg1 és mg2 manager-ekkel is.
TLS kulcsok begyűjtése
Mikor a docker-machine létrehozta a manager node-okat, legyártotta azokat az ssh kulcsokat, aminek a segítségével a docker-machine be tud ssh-zni a VM-re jelszó és felhasználó név megadása nélkül (docker-machine ssh mg0). Ezeket a kulcsokat fogjuk mi is felhasználni, hogy a lokálisan futó Portainer hozzá tudjon kapcsolódni a (távoli) virtuális gépen futó docker démonhoz.
Adjuk ki docker-machine env parancsot, hogy megtudjuk, hol tárolja a lokális docker-machine környezetünk a távoli VM SSH kulcsait:
# docker-machine env mg0 export DOCKER_TLS_VERIFY="1" export DOCKER_HOST="tcp://192.168.42.41:2376" export DOCKER_CERT_PATH="/root/.docker/machine/machines/mg0" export DOCKER_MACHINE_NAME="mg0" # Run this command to configure your shell: # eval $(docker-machine env mg0)
Látható, hogy a kulcsok a /root/.docker/machine/machines/mg0 mappában vannak
Nekünk három fájlra van innen szükségünk. A CA-ra, a certifikációnkra és a titkos kulcsunkra. A docker-machine a publikus kulcsot még telepítés közben felmásolta a VM-re.
# ll /root/.docker/machine/machines/mg0 total 316444 .. -rw-r--r-- 1 root root 1029 Jul 15 22:41 ca.pem -rw-r--r-- 1 root root 1070 Jul 15 22:41 cert.pem ... -rw------- 1 root root 1675 Jul 15 22:41 key.pem ...
Másoljuk a kulcsokat egy olyan mappába, ahol a böngészőt futtató user is feléri. (Ugyanis nagy valószínűséggel a root mappában jöttek ezek létre)
Portainer telepítése
A Portainer-hez egyetlen egy image-et kell telepíteni: portainer/portainer
# docker container run -d -p 9000:9000 --privileged -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer
- A webes konzol a localhost:9000 -as porton lehsz elérhető:
- Ha a lokális docker démon-t is monitorozni akarjuk, akkor a docker démon socket-re rá kell kötni a portainer-t.
Ha elindult a konténer, akkor válasszuk Remote lehetőséget
- Adjuk meg a manager-t futtató VM IP címét a 2376 portal (alapértelmezett TLS port)
- Kapcsoljuk be a TLS-t.
- TLS CA certificate: ca.pem
- TLS certificate: cert.pem
- TLS key: key.pem
Majd mondjuk hogy connect. Ekkor bejön a desboard. Innentől kezdve a távoli manager docker démonjához kapcsolódunk.
Cluster monitorozása
Nyomjunk rá a Go to cluster visualizer linkre, vagy a baloldali menüben a swarm menüpontra.
Nézzük meg az mg0 node részleteit. Láthatjuk, hogy jelenleg ő a managerek vezetője:
Service futtatása
https://blog.scottlogic.com/2016/08/30/docker-1-12-swarm-mode-round-robin.html
Service létrehozása image-ből
Szolgáltatás definiálása
Hozzunk létre
# docker-machine ssh mg0 docker service create --name web --replicas 3 --mount type=bind,src=/etc/hostname,dst=/usr/share/nginx/html/index.html,readonly --publish 80:80 nginx
Monitorozás
Listázzuk ki a swarm-unkon futó szolgáltatásokat. Ezt bármelyik manager-en kiadhatjuk:
# docker-machine ssh mg1 docker service ls ID NAME MODE REPLICAS IMAGE PORTS yv47d25nc6dr web replicated 3/3 nginx:latest *:80->80/tcp
Most listázzuk ki ps-el a szolgáltatás részleteit. Láthatjuk hogy a woker0, 1 és az mg1-re telepítette fel.
# docker-machine ssh mg1 docker service ps web ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS deytk9w7z3et web.1 nginx:latest worker0 Running Running 14 minutes ago j6lwloj4q101 web.2 nginx:latest mg1 Running Running 14 minutes ago wfhucxtrq7pm web.3 nginx:latest worker1 Running Running 14 minutes ago
Nézzük meg a portainer-ben is az új szolgáltatásunkat a services menüpont alatt:
Load balancing
Nézzük meg a swarm nativ load balancert. Hívjuk meg a cluster bármelyik tagjának az IP címét a 80-as porton:
# curl http://192.168.42.41:80 worker0 # curl http://192.168.42.41:80 worker1 # curl http://192.168.42.41:80 mg1
Ha a böngészőben hívjuk meg a swarm bármelyik node-jának az ip címét, akkor viszont mindig ugyan arra a lábra fogunk beesni, mert a load-balancer megjegyzi, hogy előzőleg hova irányított.
Scaling
A replikák számát a docker service scale paranccsal változtathatjuk meg. Növeljük meg 5-re:
# docker-machine ssh mg0 docker service scale web=5 web scaled to 5
Majd nézzük meg mi lett:
# docker-machine ssh mg1 docker service ps web ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS deytk9w7z3et web.1 nginx:latest worker0 Running Running 28 minutes ago j6lwloj4q101 web.2 nginx:latest mg1 Running Running 28 minutes ago wfhucxtrq7pm web.3 nginx:latest worker1 Running Running 28 minutes ago 7nwtcd43vva9 web.4 nginx:latest worker2 Running Running about a minute ago kbz72e0wf1ba web.5 nginx:latest mg2 Running Running about a minute ago
A portanier-ben egy kattintással növelni tudjuk a szolgáltatás replika számát felfelé vagy lefelé a scale nyílra kattintva a Services listában.
