7,540
edits
Changes
→GUI swarm manager with Portainer
<br><br>
=Portainer, GUI swarm manager with Portainer=
:[[File:ClipCapIt-180824-214115.PNG]]
Két lehetőségünk van a Portainer futtatására:
* 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.
Az a gond, hogy a Portainer stateful szolgáltatás, a /data konténer mappában tárolja az adatait (állapotát), tehát ezt . Staeful szolgáltatások kezelése egy kicsit nehézkes. A /data a mappát kéne legalább a guest VM-re lementeni, hogy ha a szolgáltatás újra indulna ne vesszenek el a Portainer adatok (á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 el a beállítások. Ehhez meg az kell, hogy minden manager node-ra mount-olva legyen ugyan az VM független, külső, közös meghajtó.
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 Portainer eredetileg telepítve volt, akkor a swarm automatikusan újra fogja telepíteni egy másik manager node-on. É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 újra telepíti újratelepíti a Portainer-t, az ott tudja folytatni, ahol a mások node-on abba hagyta.
Ahhoz hogy elérjük azt a célt, hogy a Portainer-t tetszőleges manager node-ra fel tudja telepíteni a swarm, ugyan azt a perzisztens meghajtót fel kell csatolni az összes manager noder-ra, ráadásul olyan mount típusra van szükségünk, amire aztán "tovább" lehet mount-olni lehet docker konténer mappát is. Sajnos a KVM host-guest file sharinge-el (9p) létrehozott mappákat nem lehet "tovább" mount-olni docker konténerek belsejébe, tehát az nem jó megoldás, hogy az összes manager 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 {{note|Ha van egy stateful szolgáltatásunk, amit már nem a manager node-okra akarunk telepíteni, de az S3állapotát fájl alapon kell tárolni, (mint a Portainer-at fogjuk használni. nek) }}