Changes

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ő.

=GUI swarm managementwith Portainer=

Több grafikus docker monitor manager/monitoring eszköz is létezik:

* Ahhoz hogy a swarm cluster adatait tudjuk monitorozniA Portainer konténerünket lokálisan futtatjuk, és távolról kapcsolódik valamelyik manager noderemote API-on futó docker démonhoz kell kapcsolódni jához, ahonnan a swarm adatokat is ki tudja olvasni, illetve módosítani is tudja a lokális docker -ben futó Portainer-elkonfigurációt. Ezt A távoli kapcsolatot TLS autentikációval lehet megoldani. Ekkor a Portanier a localhost-on érhető elA Portainer webes felülete csak lokálisan lesz elérhető.* A Portainer-t eleve a manager nodeswarm service-ot is futtató docker démonban ként telepítjük fel azzal a távoli gépenmegkötéssel, ekkor Portanier a távoli gép IP címén érhető elhogy csak manager noder-ra telepíthető. Ekkor a Portainer közvetlen tud csatlakozni a docker A managernode-en on az ottan ott lokális docker démonhoz (ez inkább csak tesztelés céljárasocket-re fog kapcsolódni, ahonnan a swarm adatokat is ki tudja olvasni manager node-okon nem szokás semmi mást futtatni)ról lévén szó. Ekkor a Portainer webes felülete globálisan lesz elérhető mindenki számára.  

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. Egy a fontos, hogy a Portainer adat mappája (/data, ahol a felhasználókat is tárolja) egy közös, perzisztens meghajtón legyen, ami az összes manager node-on elérhető, így mindegy hogy melyik manager node-ra kerül a Portainer.  

A swarm service-ként való futtatásnak az Az a nagy előnyegond, hogy a Portainer életciklusát nem nekünk kell kezelnistateful szolgáltatás, ha 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 manager node meghalguest VM-re lementeni, ahova hogy ha a szolgáltatás újra indulna ne vesszenek el a Portainer eredetileg telepítve volt, akkor adatok (állapot). Azonban ha a swarm automatikusan újra fogja telepíteni egy másik manager nodenodre-on. És mivel ra újratelepítené, akkor fontos hogy ott is rendelkezésre álljon ugyan az a Portainer '''/data mappáját a manager node-ok között egy közös perzisztens meghajtóra csatoltuk föl''' mappa tartalom (állapot), miután hogy ne vesszenek el a swarm újra telepíti a Portainerbeállítások. Ehhez valamelyik docker volume plugin -tkell használjuk, az ott tudja folytatni, ahol lásd a mások node-on abba hagyta[[Docker volume orchestration]] című cikket.

Ahhoz hogy elérjük azt A swarm service-ként való futtatásnak az a céltnagy előnye, hogy a Portainer-t tetszőleges életciklusát nem nekünk kell kezelni, ha az a manager node-ra fel tudja telepíteni meghal, ahova a swarmPortainer eredetileg telepítve volt, ugyan azt akkor a perzisztens meghajtót fel kell csatolni az összes swarm automatikusan újra fogja telepíteni egy másik manager nodernode-ra, ráadásul olyan mount típusra van szükségünk, amire aztán mount-olni lehet docker konténer mappát ison. Sajnos És mivel a KVM hostPortainer /data mappáját a manager node-guest file sharingeok között egy közös perzisztens meghajtóra csatoltuk föl, miután a swarm újratelepíti a Portainer-el (9p) létrehozott mappákat nem lehet "tovább" mount-olni docker konténerek belsejébet, tehát az nem jó megoldásott tudja folytatni, hogy az összes manager ahol a mások node alá felcsatoljuk ugyan azt a KVM megosztott host mappát. Erre a célra KVM környezetben a legjobb az NFS megosztás vagy esetleg a samba. Mi most az NFS megosztást fogjuk használni. AWS esetén az S3-at fogjuk használnion abba hagyta.

Elsőként ===Portainer telepítése===Telepítsük fel a host gépen (vagy bárhol máshol, amit elérnek majd '''Netshare''' docker volume plugin-t a VM-ek) hozzunk létre egy [[Docker_volume_orchestration#Netshare|Docker volume orchestration/Netshare]] fejezetben leírtak alapján. A Netshare segítségével felcsatolhatunk NFS megosztást. <pre># dnf install közvetlen a Portainer konténerbe on-y nfsdemand alapon, tehát a megosztás csak azon a node-utils# firewallon fog létrejönni, ahova a swarm a Portainer-cmd --add-service=nfs --permanent# firewall-cmd --reload# systemctl enable nfs# systemctl restart nfs</pre>t telepíti majd.

eval $(docker-machine env mg0) docker service create \--name portainer \--publish 9000:9000 \--replicas=1 \--constraint 'node.role == manager' \--mount type=bind,src=/homevar/adamrun/docker.sock,dst=/portainervar/datarun/ docker.sock \--mount type=volume,src=192.168.42.01/home/adam/Projects/DockerCourse/persistentstore/portainer/data/255.255.255.0(rw,syncdst=/data,no_root_squash,no_subtree_check)volume-driver=nfs \portainer/portainer -H unix:///var/run/docker.sock

VagyisHa a portainer-t swarm service-ként futtatjuk, akkor fontos, hogy command-nak is megadjuk a unix-docker socket használatát: '''-H unix://home/adamvar/run/docker.sock'''{{note|A command részben fontos, hogy a unix után három /portainerjel van. 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 /datarun/ mappának docker.sock-ban fogja keresni a megosztását megengedjük a 192.168.42/var/run/docker. -ás alhálózatonsock helyett}}

Töltsük újra Nézzük meg melyik manager node-ra települt a NFS fájlt: portainer.

# exportfs -radocker service ps portainer ID NAME IMAGE NODEjh04xrikkskh portainer.1 portainer/portainer:latest mg0

===NFS kliens beállításaBelépés a web-es konzolra===Az összes manager node-on mount-olni kell az előbb létrehozott NFS megosztást, amiben a Portainer a perzisztens adatait fogja tárolni (pl. user adatok). Ehhez be kell lépni SSH-val egyenként a manager node-kora és ott futtatni kell a '''mount''' parancsot.  {{note|KVM driver által telepített boot2docker Linux-okon csak a /var/lib/boot2docker mappa tartalma boot perzisztens, minden máshol történt módosítást ki fog dobni}}

A boot2docker9000-ben az NFS mount-nak speciális szerkezete vanas portot publikáltuk a swarm ingress hálózatán, ami azt jelenti, leírás itt: https://gist.github.com/leeor/e70419fd7f656ca4bff3<br>Mivel hogy a boot2dockerswarm node-ben csak a '''/var/lib/boot2docker/''' tartalma boot perzisztensok bármelyikének az IP címén, ezen a mappán belül hozzuk létre 9000-as porotn el fogjuk érni a portainer számára azt a mappát ahova az NFS megosztást fel fogjuk csatolni. Portainer webes konzolját:

sudo /var/lib/boot2docker/portainerdatasudo /usr/local/etc/init.d/nfs# docker-client startmachine ip mg0sudo mount 192.168.42.1:/home/adam/docker/portainer/data/ /var/lib/boot2docker/portainerdata -o rw,async,noatime,rsize=32768,wsize=32768,proto=tcp231

PORTA_HOST_DIR='http:/home/adam192.168.42.231:9000/docker#/portainerinit/data'adminPORTA_GUEST_DIR='/var/lib/boot2docker/portainerdata'PORTA_MOUNT_OPT=':[[File:ClipCapIt-180824-o rw,async,noatime,rsize=32768,wsize=32768,proto=tcp'215348.PNG]]

#Make the NFS mount boot persistent docker-machine ssh mg$i sudo chmod 777 /var/lib/boot2docker/profile docker-machine ssh mg$i "echo 'sudo /usr/local/etc/init.d/nfs-client start'" docker-machine ssh mg$i "echo 'sudo mount 192.168.42.1:$PORTA_DATA_DIR $PORTA_GUEST_DIR $PORTA_MOUNT_OPT' >> /var/lib/boot2docker/profile"done</source>A script többi része megegyezik a [[/Docker_Swarm_Mode#Swarm_cluster_l.C3.A9trehoz.C3.A1sa|''Swarm cluster létrehozása'']] fejezetben leírtakkal. A fenti script-et futtatva három olyan VM-et kapunkhost gépen láthatjuk, ahova ugyan hogy az a NFS megosztás van felcsatolva mappában megjelentek a '''/var/lib/boot2docker/portainerdata''' mappába. A portainer docker konténer '''/data''' mappáját erre a mappára kell mountfájlok: :[[File:ClipCapIt-olni, így bármelyik manager noder180824-ra is kerül majd a '''portainer''', ugyan azt a '''/data''' mappát fogja látni234015.PNG]]

# 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