A Docker fejlődése megállíthatatlan, persze az új feature-ök jelentősége olykor megkérdőjelezhető, de a szubjektív véleményem, hogy nagyon is jó irányba tartó. A 19.03-as verzióval megjelent a context, ami egyszerűbbé teszi a távoli Docker démonok elérését, ugyanakkor előtte sem volt lehetetlen. Tudtad-e, hogy már a 18.09-es verziótól van lehetőség akár távoli unix Docker sockethez is csatlakozni SSH-n keresztül pusztán a Docker kliens segítségével? Vagy talán nem is hiányzott, mert anélkül is meg lehet és meg lehetett oldani. Hogy pontosan miről is van szó, kiderül a cikkből.
Tartalomjegyzék
Helyi démon elérése
[Tartalom]
Aki repülni akar, előbb tanuljon meg járni. Elsőként azt kell tudni, hogy a Docker kliens a démonnal két módon tud kommunikálni. Unix socketen keresztül vagy TCP socketet használva, ám ezt a démon konfigurációjával lehet beállítani. Egy friss telepítéssel valószínűleg unix sockettel fogsz találkozni és ez elég is. Rendszerint az útvonala /var/run/docker.sock. De természetesen bármi más is lehet.
A fájl felcsatolható akár konténerbe is, így a Docker kliens is futhat Docker konténerben. Hasznos, amikor egy konténerizált alkalmazás a démonnal szeretne kommunikálni. Gondnak az tűnik, amikor egy távoli gép a Docker hoszt. Például saját munkaállomásról szeretnél távoli szervert menedzselni tegyük fel Portainer segítségével.
TCP socket beállítása a Docker hoszton
[Tartalom]
Operációs rendszertől, telepítéstől függ, hogy mi a javasolt módja, de a démonnak paraméterként átadható egy vagy több socket is.
Mindezt gyakran a systemd-n keresztül lehet megadni, de a /etc/docker/daemon.json konfigurációs fájlban is felvehető.
"hosts": ["unix:///var/run/docker.sock", "tcp://127.0.0.1:2375"]
}
Arra viszont a dokumentáció is felhívja a figyelmet, hogy egyszerre egy helyen legyenek ezek a beállítások. A megadott IP címtől és tűzfalbeállításoktól függően akár távoli gépről is hozzáférhetsz a démonhoz.
Távoli elérés
Publikus TCP socket
[Tartalom]
A legegyszerűbb, amikor a távoli hoszton a Docker démon eleve engedélyezve van egy publikus TCP socketen. Ekkor ugyanúgy, ahogy a démonnál, a kliensnél is lehet paraméterezni, hogy melyik hoszt felé forduljon a kérésekkel:
Vagy egyszerűbben a DOCKER_HOST környezeti változó beállításával akár globálisan, csak egy terminál session idejére.
# ...
docker info
Távoli unix socket
[Tartalom]
A Docker 18.09-es verziójától van lehetőség jelszó nélküli SSH kulcsos kapcsolaton keresztül csatlakozni a démonhoz. A verzió a kliensen és a szerveren is követelmény.
#...
docker info
Ez gyakorlatilag csak egy egyszerűbb formája az alábbinak, ami viszont régebbi Docker verzióval is alkalmazható 2 terminál ablakkal:
1. terminál
2. terminál
# ...
docker info
SSH tunnel privát IP-re
[Tartalom]
Speciális esetben előfordulhat, hogy egy távoli gépen nem unix socketen, hanem egy privát TCP socketen figyel a Docker démon, például a 127.0.0.1-es IP címen. A Unix socketnél alkalmazott SSH tunnel ebben az esetben is működik, csak egy kicsit másképp.
1. terminál
2. terminál
# ...
docker info
A fenti példában csak azért változtattam meg az első IP címet 2-re végződőre, hogy egyértelmű legyen, melyik a távoli, melyik a lokális gép IP-je. Ha viszont helyben már van egy Docker, ami szintén a 127.0.0.1 lokális IP-re van beállítva, akkor muszáj is más címet megadni.
Kontextus használata
[Tartalom]
A 19.03-as verziótól megjelent a docker context. Többek között a DOCKER_HOST változó beállítása is kiváltható vele, de a kontextusok előre definiálhatók felhasználói szinten egy választott névvel, leírással. Ezek között pedig tetszőlegesen lehet váltani.
Kontextus létrehozása:
A létrehozott kontextusok listázhatók a Dockernél megszokott módon:
Majd kiválaszthatod a megfelelőt:
Innentől minden docker parancs ebben a kontextusban fog futni. Szépséghibája, ami ugyanakkor előnye is lehet, hogy az összes terminál sessionre érvényes lesz az adott felhasználónak. Ha egyszerre két kontextussal szeretnél dolgozni, vagy az előzőekben leírt módon felülbírálhatod az adott session-re a DOCKER_HOST változót, vagy ha a kontextus egyéb paramétereit is szeretnéd változtatni, egyszerűen csak a DOCKER_CONTEXT változóval állítsd be a kontextus nevét, vagy a docker --context my-remote-machine info módon paraméterezd a klienst. Hosszabb távra létrehozhatsz egy új felhasználót a távoli hoszt részére, majd ennek az új felhasználónak telepíted az SSH kulcsát a szerverre és állítod be a megfelelő kontextust. Ekkor egy új terminálban felhasználót váltva egyszerre két kontextussal dolgozhatsz.
Nem elég SSH-zni a távoli gépre?
[Tartalom]
Attól függ, mi a célod. Ha csak nézegetnéd a konténereket, lekérdeznéd az image-eket, belépnél a konténerbe, akkor elég. A docker build és a docker cp utasítások viszont a klienstől is függnek. Ha saját image-et buildelsz, akkor a kliensen levő fájlrendszeren lesz minden, ami az image készítéséhez szükséges, majd a build lefuttatásakor ezek tömörítve át lesznek másolva a távoli gépre, az image pedig már ott fog elkészülni. Ellenkező esetben fejlesztés közben minden alkalommal át kellene másolnod a fájlokat például rsync-kel.
Ezen kívül ott van még az image exportálás is. Ha a szerveren levő image-et saját gépre szeretnéd exportálni, a kontextusok nélkül az export után még tovább kellene másolnod a szerverről a kliensre.
Összefoglalás
[Tartalom]
A cikkben felsorolt megoldások éppen nélkülözhetők lennének, de a távoli docker démon elérése sok esetben könnyíti meg, teszi kényelmesebbé a munkát, még ha nem is lesznek a mindennapjaid része. Más részt az ember olyan eszközökkel dolgozik, amik rendelkezésére állnak, de nem mindig látja előre, mik azok, amikre majd holnap szüksége lesz, de ma teljesen feleslegesnek tűnik.
Alapfelállás szerint egy helyi unix socketre csatlakozás bőven megfelelő, ráadásul a fájlra vonatkozó jogosultságokat is könnyebb kezelni. Az SSH-val átirányított unix socket praktikus megoldás, viszont a kliens gépen a felhasználó módosíthatná a socket fájl jogait és ezzel bárki számára elérhetővé tehetné az adott gépen a távoli Docker démont, bár alapértelmezetten csak a tunnelt indító felhasználó számára engedélyezett a socket elérése.
A kontextusok valamivel leegyszerűsítik a csatlakozást, ráadásul permanensen lehet váltani közöttük és minden terminál sessionre érvényesen. Ugyanakkor pont ezért nagyon kell figyelni, aktuálisan milyen kontextus van beállítva, különben véletlenül is telepíthetsz rossz gépre szolgáltatásokat, vagy ami rosszabb, törölhetsz is fontos konténereket. Bár a kontextusok váltása mellett környezeti változókkal is kezelheted, elyik szerver felé forduljon a kliens, a két módszert nagyon nem javaslom együtt alkalmazni, mivel ha beállítottad a DOCKER_CONTEXT változót, hiába váltasz a kontextusok között a klienssel, a változó törléséig semmi nem fog változni. Ha pedig csak a DOCKER_HOST változót állítod be, még egy figyelmeztetés is megjelenik. Ekkor ugyanis azt fogod látni, hogy a megfelelő kontextusban vagy, de ha nem figyelsz az endpoint beállítására, ettől függetlenül is rossz démont fogsz utasítani.
A kontextusokkal egyébként egy kubernetes endpoint is megadható, hogy a docker klienssel egy kubernetes klasztert menedzselhess. Ez már következő cikk témája lesz, de addig is kövess Facebookon, hogy ne maradj le az új tartalmakról és like-old a cikket, hogy boldog legyek :). Én pedig tovább dolgozom a hasznos cikkeken a te visszajelzéseidet is figyelembe véve, hogy te is boldog lehess.
Források
[Tartalom]
