Changes

[[Docker Orchestration|<< Back to Orchestration Docker main]]

for i in 0 1 2; do docker-machine ssh mg$i docker swarm join --token $MANAGER_TOKEN $(docker-machine ip mg0) --advertise-addr $(docker-machine ip mg$i)

docker-machine ssh worker$i docker swarm join --token $WORKER_TOKEN $(docker-machine ip mg0) --advertise-addr $(docker-machine ip worker$i)

{{tip|A KVM helyett itt használhattunk volna Amzaon EC2-es driver-t is, pont ugyan így ugyanígy létrehozta volna az egész cluster-t pár perc alatt. Részletek itt: [[Docker_Swarm_on_AWS|Docker Swarm on AWS]] }} A '''--advertise-addr''' paraméterre azt mondjuk meg, hogy az újonnan létrehozandó swarm node a swarm-management node-to-node kommunikációra melyik interfészét használja a VM-nek (ha több is van). A swarm node ezen az interfészen (alhálózaton) fogja magát reklámozni a swarm cluster-ben, a többi node az itt megadott interfészen fogja keresni. A swarm management node-to-node kommunikációt biztonsági okokból mindig VM internal hálózaton kell bonyolítani, tehát a '''--advertise-addr''' paraméternek mindig egy VM internal hálózati interfészt kell megadni.  A VM-eket mindig úgy kell létrehozni, hogy legalább két hálózatra csatlakozzanak. Legyen egy VM internal hálózat, ami a publikusan nem érhető el, csak a guest-ek látják rajta egymást, és legyen egy második hálózat, ahol a VM-ek kilátnak a netre, és akár a publikus hálózatból elérhetőek. A "'''docker-machine create'''"-el olyan VM-eket hoztunk létre, amikre ez teljesül: * '''eth0''':192.168.123.0/255.255.255.0 - ('''docker-network''') Azt a hálózatot mi definiáltuk, ez kilát a publikus internetre. (Ezt a hálózatot a KVM a "'''forward mode=nat'''" paraméterrel hoztuk létre, ezért lát ki a publikus net-re, lásd [[KVM#Add new network]] cikket a részletekért.) Ha az ingress load balance-olt hálózaton akarunk elérni egy service-t akkor az adott node ezen IP címét kell használni. * '''eth1''':192.168.42.0/255.255.255.0 - ('''docker-machines''') Ezt a hálózatot a KVM driver hozta létre automatikusan a VM internál kommunikációra, tehát minden node-nak az '''eth1''' interfész IP címét kell megadni az '''--advertise-addr''' paraméterben. Szerencsére a "'''docker-machine ip node-name'''" parancs pont ezt az ip-t adja vissza. <br>Részletek itt: [[Docker Machine#Create machines with KVM]] (ugyan ezen az IP-n is működik az ingress hálózat lokálisan, távolról ez nem elérhető)  KVM driver esetén ha nem az alapértelmezett OS-t akarjuk használni, akkor a '''--kvm-boot2docker-url''' kapcsolóval kell megadni a .ISO helyét. Én a rancherOS-t próbáltam ki és működött. Innen lehet letölteni: https://github.com/rancher/os (közvetlen link: https://releases.rancher.com/os/v1.5.0/rancheros.iso) <pre>docker-machine create -d kvm --kvm-boot2docker-url "/home/adam/Downloads/rancheros.iso" --kvm-network "docker-network" manager1</pre>    <pre># virsh net-list Name State Autostart Persistent---------------------------------------------------------- default active yes yes docker-machines active yes yes docker-network active yes yes</pre>

Most Végezetül 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ő.

=MonitorozásGUI swarm management with Portainer=

:[[File:ClipCapIt-180824-214115.PNG]]  Több grafikus docker monitor manager/monitoring eszköz is létezik:

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. (docker nélkül is futtatható)

* Ahhoz hogy A Portainer konténerünket lokálisan futtatjuk, és távolról kapcsolódik valamelyik manager node remote API-jához, ahonnan a swarm cluster adatait tudjuk monitorozniadatokat is ki tudja olvasni, illetve módosítani is tudja a konfigurációt. A távoli kapcsolatot TLS autentikációval lehet megoldani. A Portainer webes felülete csak lokálisan lesz elérhető. * A Portainer-t swarm service-ként telepítjük fel azzal a megkötéssel, valamelyik hogy csak manager noder-ra telepíthető. A manager node-on futó az ott lokális docker démonhoz kell socket-re fog kapcsolódni , ahonnan a swarm adatokat is ki tudja olvasni manager node-ról lévén szó. Ekkor a Portainer webes felülete globálisan lesz elérhető mindenki számára.   ==Portainer telepítése swarm service-ként== A legkézenfekvőbb megoldás, ha a Portainer-t swarm service-ként a manager node-ok valamelyikére telepítjük föl. Az már mindegy, hogy melyik manager node-ra kerül, azt bízzuk a swarm-ra (cow személet), bármelyikre is kerül, lokális docker socket-re csatlakozva el fogja érni a cluster adatokat.   Az a gond, hogy a Portainer stateful szolgáltatás, a '''/data''' konténer mappában tárolja az adatait (állapotát). Staeful szolgáltatások kezelése egy kicsit nehézkes. A /data a mappát kéne legalább a guest VM-ben futó re lementeni, hogy ha a szolgáltatás újra indulna ne vesszenek el a Portaineradatok (állapot). Azonban ha a swarm egy másik manager nodre-ra újratelepítené, akkor fontos hogy ott is rendelkezésre álljon ugyan az a '''/data''' mappa tartalom (állapot), hogy ne vesszenek ela beállítások. Ezt TLS autentikációval lehet megoldaniEhhez valamelyik docker volume plugin -t kell használjuk, lásd a [[Docker volume orchestration]] című cikket. Ekkor   A swarm service-ként való futtatásnak az a nagy előnye, hogy a Portainer életciklusát nem nekünk kell kezelni, ha az a manager node meghal, ahova a Portanier Portainer eredetileg telepítve volt, akkor a localhostswarm automatikusan újra fogja telepíteni egy másik manager node-on érhető el. (mi ezt fogjuk használniÉs mivel a Portainer /data mappáját a manager node-ok között egy közös perzisztens meghajtóra csatoltuk föl, miután a swarm újratelepíti a Portainer-t, ez az ajánlott megoldás produkciós környezetben)ott tudja folytatni, ahol a mások node-on abba hagyta.    ===Portainer telepítése===* Telepítsük fel a '''Netshare''' docker volume plugin-t a [[Docker_volume_orchestration#Netshare|Docker volume orchestration/Netshare]] fejezetben leírtak alapján. A Netshare segítségével felcsatolhatunk NFS megosztást közvetlen a Portainer konténerbe on-demand alapon, tehát a megosztás csak azon a node-on fog létrejönni, ahova a swarm a Portainer-t eleve a telepíti majd.  A portainer-t swarm service-ként fogjuk telepíteni. Ki fogjuk kötni hogy csak manager node-ra telepítheti a swarm, tehát biztos, hogy az előbb létrehozott mg0, mg1 és mg2 valamelyikén fog landolni. Fontos, hogy megadjuk, hogy csak egy példány jöhessen belőle létre. Két fontos mount-ot kell beállítani: # '''/data''': Egy távoli NFS megosztást fogunk felcsatolni a Netshare plugin segítségével, ahol a Portainer a perzisztens adatait fogja tárolni. # '''/var/run/docker.sock''': ezt a guest VM docker socket-jére kell rákötni, hogy a portainer hozzáférjen a docker/swarm adatokhoz és tudja is futtató módosítani azokat.  <pre>eval $(docker démonban telepítjük fel -machine env mg0) docker service create \--name portainer \--publish 9000:9000 \--replicas=1 \--constraint 'node.role == manager' \--mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \--mount type=volume,src=192.168.42.1/home/adam/Projects/DockerCourse/persistentstore/portainer/data/,dst=/data,volume-driver=nfs \portainer/portainer -H unix:///var/run/docker.sock</pre>Ha a portainer-t swarm service-ként futtatjuk, akkor fontos, hogy command-nak is megadjuk a távoli gépenunix-docker socket használatát: '''-H unix:///var/run/docker.sock'''{{note|A command részben fontos, ekkor Portanier hogy a távoli gép IP címén érhető elunix után három / jel van. Ekkor Ebből aztán kettő lesz mire konténer lesz belőle, nem pontosan értem, hogy ha escape-elni kell, akkor miért nem négy kell, minden esetre ha csak kettőt írunk, akkor a Portainer közvetlen tud csatlakozni /run/docker.sock-ban fogja keresni a /var/run/docker .sock helyett}}  Nézzük meg melyik managernode-en ra települt a portainer. <pre># docker service ps portainer ID NAME IMAGE NODEjh04xrikkskh portainer.1 portainer/portainer:latest mg0 </pre>Láthatjuk hogy az ottan lokális docker démonhoz (ez inkább csak tesztelés céljáramg0 manager node-ra került ki.   <br>===Belépés a web-es konzolra=== A 9000-as portot publikáltuk a swarm ingress hálózatán, ami azt jelenti, hogy a manager swarm node-okon nem szokás semmi mást futtatni)ok bármelyikének az IP címén, a 9000-as porotn el fogjuk érni a Portainer webes konzolját:<pre># docker-machine ip mg0192.168.42.231</pre>  http://192.168.42.231:9000/#/init/admin:[[File:ClipCapIt-180824-215348.PNG]] Első induláskor be kell állítani az admin felhasználót.

A host gépen láthatjuk, hogy az NFS mappában megjelentek a portainer fájlok: :[[File:ClipCapIt-180824-234015.PNG]]    <br> ==Portainer telepítése lokális konténerként==A következőkben megnézzük, hogyan lehet távolról kapcsolódni a Portainer-el egy swarm cluster manager node-jához. Ez a megoldás több szempontból sem annyira előnyös mint a swarm service-ként való telepítés, ezek a következők: # Egy dedikált manager-hez kapcsolódunk, ha az kiesik, ugrott az egész GUI management. # Csak azon a laptopon elérhető a portainer, ahol összelőttük a Remote kapcsolatot, tehát csak egy ember fér így hozzá, nem az egész csapat. # Nekünk kell kezelni a Portainer életciklusát, vagyis ha a Portainert konténer, vagy az azt futtató VM leáll, akkor nekünk kell kézzel újra indítani, vagy akár újra telepíteni a szolgáltatást. Ezzel szemben előnyök: # Egy Portainer példányból az összes swarm cluster-ünket kezelhetjük, mivel tetszőleges számú remote rendszert lehet hozzáadni. Ennek az az előnye, hogy a Portainer autentikációt és authorizációt csak egyszer kell beállítani.   A Portainer a távoli docker-hez a TLS API-n keresztül fog csatlakozni, amihez szükségünk van az ott futó docker démon publikus és titkos kulcsára. 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), tehát csak TLS-el lehet a manager-en futó docker démon-ra csatlakozni

===Portainer telepítéselokális docker-en===

===Cluster monitorozása===

Azt elöljáróban elmondhatjuk, hogy a swarm-ot illetve, úgy általában a konténer cluster-eket elsősorban stateless micorservicehttps://stackstorm.com/2017/06/22/autoscaling-ekre találták ki, ahol egymás mellett akár több ezer stateless service példány fut, és tényleg teljesen mindegy hogy éppen melyik kapja a kérést. Ilyen méretekben nincs is értelme statefull szolgáltatásokról beszélni. A swarm mode is erre készül, a nagy számú, statless végpontok kezelésére tökéletes a swarm-ba beépített Layer 4 (szállítási rétegbeli) loadaws-balancer, ami Round-rubin módon mindig a következő elérhető konténernek adja a feladatot.   Azonban igen is szükség van statefull szolgáltatásokra, és bár akkora cluster nem építhető belőlük mint a stateless szolgáltatásokból, kiválóan passzolnak a swarm világba. stackstorm/  A konténeres cluster világban Session kezelést kétféle módon hozhatunk létre ha nagyon messziről nézzükhttps: * '''Elosztott session kezelés''': minden egyes konténer, ami részt vesz a szolgáltatásban hozzáfér egy központi sesison tárhoz, ahonnan minden egyes hozzá beérkező request estén ki tudja olvasni, hogy hol tart a session és onnan folytatja//github. Ebben az esetben használható a com/sahajsoft/docker-swarm beépített Layer 4 load-balancing szolgáltatása. Előnye, hogy az architektúrából fakadóan követi a cluster váltózásait. Ha egy új példányra van szükség, csak simán elindítjuk, és az is hozzá fog férni a közös session tárhoz. Azonban a szakirodalom szerint ez a megoldás nagyon rosszul skálázódik. Míg pár láb esetén remekül működik, akár már 50 láb esetén is nagyon nehézkessé válik, hogy minden node tényleg megkapja megfelelő sebességgel a legfrissebb session-t. Nagy lábszám mellett ez gyakorlatilag használhatatlan. * '''Központosított session kezelés a load-balacer-ben''': Ebben az esetben a beépített Layer 4 load-balancer értelem szerűen nem használható, ezért itt egy olyan, külső load-balancer megoldásra van szükség, ami tud sticky session-t kezelni, ezen felül képes automatikusan lekövetni a swarm cluster változásait és remekül bírja a terhelést.   A session kezelésen felül, még több okunk is lehet, hogy miért tegyünk egy loadservice-balancing szolgáltatást a swarm cluster elé: * SSL/TLS termination* Content‑based routing (based, for example, on the URL or a header)* Access control and authorization* Rewrites and redirectsautoscaler

<br>==Áttekintés==A Traefik egy univerzális Layer 7 (http) load-balancer és reverse proxyhttps://docs.stackstorm.com/install/docker. Direkt microservice környezetre találták ki és támogatja is gyakorlatilag az összes konténer orchestration platformot és többféle service discovery szolgáltatást is: <br>* Docker* '''Swarm mode''' <<<* Kubernetes* Marathon* Consul, Etcd --> service discovery* Rancher* Amazon ECS)html

{{warning|A Traefik nem webserverAuto Scaling Docker Containers in Amazon ECS: https://www.codementor.io/jholub/amazon-ecs-auto-scale-docker-containers-6keydo24nECS is an alternative to tools such as Kubernetes, Docker Swarm, csak egy reverse proxy. Nem tud pl static tartalmat kiszolgálni!}}or Mesos

A Traefik úgy működik, hogy valamelyik swarm manager-tről periodikusan lekérdezi az aktuális swarm konfigurációt (szolgáltatások, és azokat futtató node-ok listája). Ez alapján teljesen automatikusan konfigurálja magát és változás estén újra konfigurálja magát (pl. ha nő vagy csökken a cluster, vagy ha új szolgáltatás kerül telepítésre). Mivel magától leköveti a swarm cluster változásait, ideális megoldás mint reverse proxy és Layer 7 load balancerhttps://github. com/gianarb/orbiter

A '''PathPrefix'''-et a swarm szolgáltatás telepítése közben kell megadni label-ek segítségével. A Traefik nem kezd el automatikusan minden a cluster-re telepített szolgáltatáshoz load balancerhttps://reverse proxy szolgáltatást nyújtanidocs. A neki szánt szolgáltatásokat a szolgáltatás telepítése közben megadott traefik specifikus címék segítségével azonosítja be és konfiguráljadocker. com/config/thirdparty/prometheus/#use-prometheus

Több fórumon is azt írják, hogy a Traefik-et csak valamelyik manager node-on lehet futtatni. Egyrészről ez nem igaz, másrészről hiba lenne ha így lenne. A manager node-ot egyrészt nem szabad load-balanc feladatokkal terhelni. Ha a manager-t túlterhelnénk, leállhat a swarm cluster-ünk. Másrészről másféle hardver konfigurációra van szükség load-balanceoláshoz mint swarm manager futtatásához nem is beszélve a tűzfal szabályokra/hálózati beállításokra. (A manager node-koat nyilván nem lehet elérni a publikus internetről). Ugyan a Traefik dokumentációból ez implicit nem derül ki, de ettől még lehet remote worker node-on futtatni a Traefik-et.   A Traefik a docker swarm API-n keresztül olvassa ki a swarm adatait (szolgáltatások, címék és nodok). Ezt vagy valamelyik manager lokális socker-jét csatlakozva teheti meg, vagy a docker remote API-n keresztül, ami általában TLS felett fut (pláne produkciós környezetben). Nyilván a legegyszerűbb ha az egyik manager node-ra telepítjük föl, és ott mount-oljuk a manager docker engine lokális socket-jét: /var/run/docker.sock:/var/run/docker.sockÍgy s swarm információkat ki tudja olvasni a lokális docker démonból. Azonban ezt csak tesztelésre szabad így megcsinálni, ahogy erre több helyen is felhívják a figyelmet. Ha megnézzük a Traefik konfigurációs leírásának docker szekcióját, találunk benne egy ilyet: # Can be a tcp or a unix socket endpoint. endpoint = Ezen felül van benne egy TLS szekció is: [docker.tls] ca = ...Tehát képes távoli docker démonhoz kapcsolódni TLS felett a portainer-hez hasonlóan. Tehát ez a része kipipálva.   Van még egy fontos megkötés. A Traefik-nek közös overlay hálózaton kell lenni az összes olyan konténerrel, akiknek load-balancer szolgáltatást nyújt, mindjárt meglátjuk miért. Nyilván az ingress (routing mesh) hálózaton lévő konténer interfészek nem megfelelőek layer 7 load balanc-olásra, mert ott már fut egy layer 4 load banacer, ami minden egyes kérésre másik node-ra irányítja a kérést (még akkor is ha direktbe a node IP címét adjuk =Statefull load-balancing with NGINGX=https://wwwmonitor.nginxdockerflow.com/blog/docker-swarm-load-balancing-nginx-plus/#nginx-demo <br><br> =Auto scaling= A Docker swarmauto-ban nincs beépített auto scaling out of the box, nekünk kell implementálni, vagy használhatunk 3rd party eszközöket is. A Kubernetes-ben erre van egy remek beépített algoritmus, de a docker-swarm-ban is meg tudjuk ezt valósítani.  https://stackstorm.com/2017/06/22/autoscaling-swarm-aws-stackstorm/https://github.com/sahajsoft/docker-swarm-service-autoscaler