A Docker Swarm, a Kubernetes és a Mesos a legnépszerűbb konténer hangszerelési keretrendszerek. Arun Gupta előadásában a Docker, a Swarm és a Kubernetes következő szempontjait hasonlítja össze:
- Helyi fejlesztés.
- Telepítési funkciók.
- Több konténeres alkalmazások.
- Szolgáltatás felfedezése.
- A szolgáltatás méretezése.
- Egyszeri feladatok.
- Integráció a Maven-nel.
- "Gördülő" frissítés.
- Couchbase adatbázis-fürt létrehozása.
Ennek eredményeként világosan megérti, mit kínálnak az egyes hangszerelési eszközök, és megtanulja, hogyan kell ezeket a platformokat hatékonyan használni.
Arun Gupta az Amazon Web Services nyílt forráskódú termékek fő technológusa, aki több mint 10 éve fejleszti a Sun, Oracle, Red Hat és Couchbase fejlesztői közösségeket. Széleskörű tapasztalattal rendelkezik többfunkciós csoportok vezetői marketingkampányok és programok stratégiájának kidolgozásában és megvalósításában. A Sun mérnökeiből álló csapatokat vezetett, a Java EE csapat egyik alapítója és a Devoxx4Kids egyesült államokbeli ágának megalkotója. Arun Gupta több mint 2 ezer bejegyzés szerzője IT-blogokban, és több mint 40 országban tartott előadásokat.
Az 55. sor egy COUCHBASE_URI-t tartalmaz, amely erre az adatbázis-szolgáltatásra mutat, amely szintén a Kubernetes konfigurációs fájl segítségével jött létre. Ha megnézi a 2. sort, láthatja, hogy milyen: A szolgáltatás az általam létrehozandó szolgáltatás, melynek neve couchbase-service, és ugyanez a név szerepel a 4. sorban. Az alábbiakban néhány port található.
A kulcssorok a 6-os és a 7-es. A szervizben azt mondom: „Hé, ezeket a címkéket keresem!”, és ezek a címkék nem mások, mint változópárnevek, és a 7. sor a couchbase-rs-pod-omra mutat. Alkalmazás. A következő portok ezekhez a címkékhez biztosítanak hozzáférést.
A 19. sorban létrehozok egy új típusú ReplicaSet-et, a 31. sor tartalmazza a kép nevét, a 24-27. sorok pedig a podatomhoz társított metaadatokra mutatnak. Pontosan ezt keresi a szolgáltatás, és ehhez kell a kapcsolatot létrehozni. A fájl végén az 55-56-os és a 4-es sor között van valamiféle kapcsolat, amely így szól: „használd ezt a szolgáltatást!”
Tehát akkor indítom el a szolgáltatást, amikor van replikakészlet, és mivel minden replikakészletnek saját portja van a megfelelő címkével, ez benne van a szolgáltatásban. A fejlesztő szemszögéből egyszerűen fel kell hívni a szolgáltatást, amely ezután a szükséges replikakészletet használja.
Ennek eredményeként van egy WildFly pod, amely a Couchbase szolgáltatáson keresztül kommunikál az adatbázis háttérrendszerével. A frontendet több WildFly poddal is tudom használni, ami a couchbase szolgáltatáson keresztül is kommunikál a couchbase backenddel.
Később megvizsgáljuk, hogyan kommunikál a klaszteren kívül található szolgáltatás az IP-címén keresztül a fürtön belül található és belső IP-címmel rendelkező elemekkel.
Tehát az állapot nélküli konténerek nagyszerűek, de mennyire jó állapottartó konténereket használni? Nézzük meg az állapottartó vagy állandó tárolók rendszerbeállításait. A Dockerben 4 különböző megközelítés létezik az adattárolás elrendezésére, amelyekre figyelni kell. Az első az Implicit Per-Container, ami azt jelenti, hogy a couchbase, MySQL vagy MyDB satateful konténerek használatakor mindegyik az alapértelmezett Sandbox-szal kezdődik. Vagyis minden, ami az adatbázisban tárolva van, magában a tárolóban tárolódik. Ha a tároló eltűnik, az adatok is eltűnnek vele együtt.
A második az Explicit Per-Container, amikor egy adott tárolót hoz létre a Docker kötet Create paranccsal, és abban tárol adatokat. A harmadik állomásonkénti megközelítés a tárolási leképezéshez kapcsolódik, amikor a tárolóban tárolt minden egyidejűleg megkettőződik a gazdagépen. Ha a tároló meghibásodik, az adatok a gazdagépen maradnak. Ez utóbbi több Multi-Host gazdagép használata, ami a különféle megoldások gyártási szakaszában célszerű. Tegyük fel, hogy a konténereid az alkalmazásaiddal futnak a gazdagépen, de az adataidat valahol az interneten szeretnéd tárolni, és ehhez az elosztott rendszerek automatikus leképezését használod.
Ezen módszerek mindegyike egy adott tárolási helyet használ. Az implicit és explicit konténerenkénti adattárolás a gazdagépen a /var/lib/docker/volumes címen történik. A Per-Host módszer használatakor a tároló a tároló belsejébe, maga a tároló pedig a gazdagépre van felszerelve. Multihost esetén olyan megoldások használhatók, mint a Ceph, ClusterFS, NFS stb.
Ha egy állandó tároló meghibásodik, a tárolókönyvtár az első két esetben elérhetetlenné válik, de az utolsó két esetben a hozzáférés megmarad. Az első esetben azonban egy virtuális gépen futó Docker-gazdagépen keresztül érheti el a tárat. A második esetben sem vesznek el az adatok, mert Explicit tárhelyet hozott létre.
Ha a gazdagép meghibásodik, az első három esetben a tárolókönyvtár nem érhető el, az utolsó esetben a tárolóval való kapcsolat nem szakad meg. Végül a megosztott funkció az első esetben teljesen kizárt a tárolásból, a többi esetben pedig lehetséges. A második esetben megoszthatja a tárhelyet attól függően, hogy az adatbázis támogatja-e az elosztott tárolást vagy sem. Per-Host esetén az adatelosztás csak egy adott gazdagépen lehetséges, multihost esetén pedig klaszterbővítéssel.
Ezt figyelembe kell venni állapotjelző tárolók létrehozásakor. Egy másik hasznos Docker-eszköz a Volume bővítmény, amely az „elemek jelen vannak, de ki kell cserélni” elven működik. Amikor elindít egy Docker-tárolót, a következőt mondja: „Ha egyszer elindított egy tárolót egy adatbázissal, tárolhatja adatait ebben a tárolóban!” Ez az alapértelmezett funkció, de módosíthatja. Ez a beépülő modul lehetővé teszi hálózati meghajtó vagy valami hasonló használatát tároló adatbázis helyett. Tartalmaz egy alapértelmezett illesztőprogramot a gazdagép alapú tároláshoz, és lehetővé teszi a tárolók integrációját külső tárolórendszerekkel, például az Amazon EBS-sel, az Azure Storage-szal és a GCE Persistent Diskekkel.
A következő dia a Docker Volume beépülő modul architektúráját mutatja be.
A kék szín a kék Docker-állomáshoz társított Docker-ügyfelet jelöli, amely egy helyi tárolómotorral rendelkezik, amely konténereket biztosít az adatok tárolására. A zöld a Plugin Client és a Plugin Daemont jelzi, amelyek szintén csatlakoznak a gazdagéphez. Lehetővé teszik az adatok tárolását olyan hálózati tárolóban, amelyre szüksége van a Storage Backend típusának.
A Docker Volume beépülő modul használható a Portworx tárolóval. A PX-Dev modul valójában egy Ön által futtatott tároló, amely csatlakozik a Docker gazdagéphez, és lehetővé teszi az adatok egyszerű tárolását az Amazon EBS-en.
A Portworx kliens lehetővé teszi a gazdagéphez csatlakoztatott különféle tárolókonténerek állapotának figyelését. Ha felkeresi a blogomat, elolvashatja, hogyan hozhatja ki a legtöbbet a Portworxből a Dockerrel.
A Kubernetes tárolási koncepciója hasonló a Dockerhez, és olyan könyvtárak képviselik, amelyek egy podban érhetők el a tároló számára. Függetlenek bármely tartály élettartamától. A leggyakrabban elérhető tárolási típusok a hostPath, az nfs, az awsElasticBlockStore és a gsePersistentDisk. Nézzük meg, hogyan működnek ezek az üzletek a Kubernetesben. Az összekapcsolásuk folyamata jellemzően 3 lépésből áll.
Az első az, hogy valaki a hálózati oldalon, általában rendszergazda, állandó tárhelyet biztosít Önnek. Ehhez létezik egy megfelelő PersistentVolume konfigurációs fájl. Ezután az alkalmazás fejlesztője megírja a PersistentVolumeClaim nevű konfigurációs fájlt vagy egy PVC-tárolási kérelmet, amely a következőt írja: „50 GB elosztott tárhelyem van, de azért, hogy mások is használhassák a kapacitását, közlöm ezzel a PVC-vel, hogy jelenleg csak 10 GB kell”. Végül a harmadik lépés az, hogy a kérelmet tárolóként csatoljuk, és az alkalmazás, amelyik rendelkezik a pod-val, replikakészlettel vagy valami hasonlóval, elkezdi használni. Fontos megjegyezni, hogy ez a folyamat az említett 3 lépésből áll, és méretezhető.
A következő dia az AWS architektúra Kubernetes Persistence Container-jét mutatja be.
A Kubernetes-fürtöt ábrázoló barna téglalap belsejében egy főcsomópont és két dolgozó csomópont található, sárga színnel jelölve. Az egyik munkavégző csomópont tartalmaz egy narancssárga pod, tárolót, egy replikavezérlőt és egy zöld Docker Couchbase tárolót. A fürtön belül, a csomópontok felett egy lila téglalap jelzi a kívülről elérhető szolgáltatást. Ez az architektúra magán az eszközön való adatok tárolására ajánlott. Ha szükséges, az EBS-ben tárolhatom az adataimat a fürtön kívül, ahogy a következő dián is látható. Ez egy tipikus méretezési modell, de használatánál figyelembe kell venni egy pénzügyi szempontot is – az adatok valahol a hálózaton való tárolása drágább lehet, mint egy gazdagépen. A konténerezési megoldások kiválasztásakor ez az egyik fontos érv.
Csakúgy, mint a Docker esetében, a Portworx-szal is használhat állandó Kubernetes-tárolókat.
Ez az, amit a jelenlegi Kubernetes 1.6 terminológiában „StatefulSet”-nek neveznek – ez az állapotalapú alkalmazásokkal való munkavégzés módja, amely feldolgozza a Pod leállításával és a Graceful Shutdown végrehajtásával kapcsolatos eseményeket. Esetünkben az ilyen alkalmazások adatbázisok. A blogomban elolvashatja, hogyan hozhat létre StatefulSet-et Kubernetesben a Portworx segítségével.
Beszéljünk a fejlesztési oldalról. Mint mondtam, a Dockernek 2 verziója van - CE és EE, az első esetben a Community Edition stabil verziójáról beszélünk, amely 3 havonta egyszer frissül, ellentétben az EE havonta frissített verziójával. Letöltheti a Dockert Mac, Linux vagy Windows rendszerre. A telepítés után a Docker automatikusan frissül, és nagyon könnyű elkezdeni.
A Kubernetes esetében a Minikube verziót részesítem előnyben – ez egy jó módja annak, hogy elkezdje a platform használatát, ha egyetlen csomóponton hoz létre egy klasztert. Több csomópontból álló fürtök létrehozásához a verziók választéka szélesebb: ezek a kops, kube-aws (CoreOS+AWS), kube-up (elavult). Ha az AWS-alapú Kubernetes-et szeretné használni, azt javaslom, hogy csatlakozzon az AWS SIG-hez, amely minden pénteken online találkozik, és számos érdekes anyagot tesz közzé az AWS Kubernetes-szel való együttműködésről.
Nézzük meg, hogyan működik a Rolling Update ezeken a platformokon. Ha több csomópontból álló fürt van, akkor a kép egy adott verzióját használja, például WildFly:1. A gördülő frissítés azt jelenti, hogy a képverziót egymás után minden csomóponton cserélik ki egy újra.
Ehhez a docker service update (szolgáltatás neve) parancsot használom, amelyben megadom a WildFly:2 kép új verzióját és a frissítési módot update-parallelism 2. A 2-es szám azt jelenti, hogy a rendszer 2 alkalmazásképet frissít. ezzel egyidőben, majd 10 másodperces frissítési késleltetés 10s, ami után a következő 2 kép frissül még 2 csomóponton stb. Ezt az egyszerű gördülő frissítési mechanizmust a Docker részeként biztosítjuk Önnek.
A Kubernetesben a folyamatos frissítés így működik. Az rc replikációs vezérlő létrehozza az azonos verziójú replikák készletét, és ebben a webapp-rc-ben minden egyes pod az etcd-ben található címkével rendelkezik. Ha podra van szükségem, az Application Service segítségével hozzáférek az etcd lerakathoz, amely a megadott címke használatával biztosítja számomra a pod-ot.
Ebben az esetben a WildFly 3-es verziójú alkalmazást futtató replikációs vezérlőben 1 pod van, a háttérben történő frissítéskor a végén egy másik replikációs vezérlő jön létre azonos névvel és indexszel - - xxxxx, ahol az x véletlen számok, ill. ugyanazokkal a címkékkel. Mostantól az Application Service három poddal rendelkezik az alkalmazás régi verziójával, és három poddal az új verzióval az új replikációs vezérlőben. Ezt követően a régi podokat töröljük, az új podokkal rendelkező replikációs vezérlőt átnevezzük és üzembe helyezzük.
Térjünk át a megfigyelésre. A Docker számos beépített megfigyelési parancsot tartalmaz. Például a docker konténerstatisztikák parancssori felülete lehetővé teszi, hogy másodpercenként információt jelenítsen meg a konzolon a tárolók állapotáról – processzorhasználat, lemezhasználat, hálózati terhelés. A Docker Remote API eszköz adatokat szolgáltat arról, hogy az ügyfél hogyan kommunikál a szerverrel. Egyszerű parancsokat használ, de a Docker REST API-n alapul. Ebben az esetben a REST, Flash, Remote szavak ugyanazt jelentik. Amikor kommunikál a gazdagéppel, az egy REST API. A Docker Remote API lehetővé teszi, hogy további információkat kapjon a tárolók futtatásáról. A blogom felvázolja a megfigyelés Windows Serverrel való használatának részleteit.
A dokkolórendszer eseményeinek megfigyelése több gazdagépes fürt futtatásakor lehetővé teszi a gazdagép-összeomlásról vagy egy adott gazdagépen, a skálázási szolgáltatásokról és hasonlókról szóló konténer-összeomlásról szóló adatok beszerzését. A Docker 1.20-tól kezdve tartalmazza a Prometheust, amely végpontokat ágyaz be a meglévő alkalmazásokba. Ez lehetővé teszi a mutatók fogadását HTTP-n keresztül, és az irányítópultokon való megjelenítését.
Egy másik megfigyelési funkció a cAdvisor (a konténer tanácsadó rövidítése). Elemezi és biztosítja a futó konténerekből származó erőforrás-használati és teljesítményadatokat, így a Prometheus mérőszámait azonnal elérhetővé teszi. Ennek az eszköznek az a különlegessége, hogy csak az utolsó 60 másodpercre vonatkozóan szolgáltat adatokat. Ezért ezeket az adatokat össze kell gyűjtenie és adatbázisba kell helyeznie, hogy egy hosszú távú folyamatot nyomon tudjon követni. Használható a műszerfali mutatók grafikus megjelenítésére is a Grafana vagy Kibana segítségével. A blogom részletes leírást tartalmaz arról, hogyan használhatom a cAdvisort konténerek figyelésére a Kibana irányítópultján.
A következő dia bemutatja, hogy néz ki a Prometheus végpont kimenete, és milyen mérőszámok jeleníthetők meg.
A bal alsó sarokban a HTTP-kérések, válaszok stb. mérőszámai láthatók, a jobb oldalon pedig ezek grafikus megjelenítése.
A Kubernetes beépített felügyeleti eszközöket is tartalmaz. Ez a dia egy tipikus fürtöt mutat be, amely egy fő és három dolgozó csomópontot tartalmaz.
Mindegyik működő csomópont tartalmaz egy automatikusan induló cAdvisort. Ezen kívül van egy Heapster, a Kubernetes 1.0.6 és újabb verziójával kompatibilis teljesítményfigyelő és mérőszámgyűjtő rendszer. A Heapster nemcsak a munkaterhelések, pod-ok és tárolók teljesítménymutatóinak gyűjtését teszi lehetővé, hanem a teljes fürt által generált eseményeket és egyéb jeleket is. Az adatok gyűjtéséhez minden egyes pod Kubeletjével kommunikál, automatikusan tárolja az információkat az InfluxDB adatbázisban, és metrikaként adja ki a Grafana irányítópultjára. Ne feledje azonban, hogy ha miniKube-ot használ, ez a funkció alapértelmezés szerint nem érhető el, ezért a megfigyeléshez kiegészítőket kell használnia. Tehát minden attól függ, hogy hol futtatja a tárolókat, és mely megfigyelő eszközöket használhatja alapértelmezés szerint, és melyeket kell külön kiegészítőként telepíteni.
A következő dia a Grafana irányítópultjait mutatja be, amelyek a tárolóim futási állapotát mutatják. Nagyon sok érdekes adat található itt. Természetesen számos kereskedelmi Docker és Kubernetes folyamatfigyelő eszköz létezik, mint például a SysDig, DataDog, NewRelic. Néhányuknak 30 éves ingyenes próbaidőszaka van, így megpróbálhatja megtalálni az Önnek legmegfelelőbbet. Személy szerint szívesebben használom a SysDig-et és a NewRelic-et, amelyek jól integrálhatók a Kubernetes-szel. Vannak olyan eszközök, amelyek egyformán jól integrálhatók mind a Docker, mind a Kubernetes platformokba.
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com