Docker Swarm, Kubernetes in Mesos so najbolj priljubljena ogrodja za orkestracijo vsebnikov. V svojem govoru Arun Gupta primerja naslednje vidike Dockerja, Swarma in Kubernetesa:
- Lokalni razvoj.
- Funkcije uvajanja.
- Aplikacije z več vsebniki.
- Odkrivanje storitve.
- Skaliranje storitve.
- Enkratna opravila.
- Integracija z Maven.
- "Tekoča" posodobitev.
- Ustvarjanje gruče baze podatkov Couchbase.
Posledično boste pridobili jasno razumevanje, kaj ponuja vsako orodje za orkestracijo, in se naučili učinkovito uporabljati te platforme.
Arun Gupta je glavni tehnolog za odprtokodne izdelke pri Amazon Web Services, ki že več kot 10 let razvija skupnosti razvijalcev Sun, Oracle, Red Hat in Couchbase. Ima bogate izkušnje pri vodenju medfunkcionalnih skupin, ki razvijajo in izvajajo strategijo za trženjske akcije in programe. Vodil je ekipe inženirjev Sun, je eden od ustanoviteljev ekipe Java EE in ustvarjalec ameriške podružnice Devoxx4Kids. Arun Gupta je avtor več kot 2 tisoč objav v IT blogih in je imel predavanja v več kot 40 državah.
Vrstica 55 vsebuje COUCHBASE_URI, ki kaže na to storitev zbirke podatkov, ki je bila prav tako ustvarjena s konfiguracijsko datoteko Kubernetes. Če pogledate vrstico 2, lahko vidite: Storitev je storitev, ki jo ustvarjam in se imenuje couchbase-service, isto ime pa je navedeno v vrstici 4. Spodaj je nekaj vrat.
Ključni vrstici sta 6 in 7. V službi rečem: "Hej, to so oznake, ki jih iščem!", In te oznake niso nič drugega kot imena parov spremenljivk, vrstica 7 pa kaže na moj couchbase-rs-pod aplikacija. V nadaljevanju so vrata, ki omogočajo dostop do istih oznak.
V vrstici 19 ustvarim nov tip ReplicaSet, vrstica 31 vsebuje ime slike, vrstice 24-27 pa kažejo na metapodatke, povezane z mojim podom. To je točno tisto, kar storitev išče in na kar se je treba povezati. Na koncu datoteke je nekakšna povezava med vrsticami 55-56 in 4, ki pravi: "uporabi to storitev!"
Svojo storitev torej zaženem, ko obstaja nabor replik, in ker ima vsak nabor replik svoja vrata z ustrezno oznako, je vključen v storitev. Z vidika razvijalca preprosto pokličete storitev, ki nato uporabi nabor replik, ki jih potrebujete.
Posledično imam pod WildFly, ki komunicira z zaledjem baze podatkov prek storitve Couchbase. Čelni del lahko uporabljam z več podi WildFly, ki prav tako komunicirajo z zaledjem couchbase prek storitve couchbase.
Kasneje bomo pogledali, kako storitev, ki se nahaja zunaj gruče, prek svojega naslova IP komunicira z elementi, ki se nahajajo znotraj gruče in imajo notranji naslov IP.
Vsebniki brez stanja so torej odlični, toda kako dobro je uporabljati vsebnike s stanjem? Oglejmo si sistemske nastavitve za vsebnike s stanjem ali trajne vsebnike. V Dockerju obstajajo 4 različni pristopi k postavitvi shranjevanja podatkov, na katere morate biti pozorni. Prvi je Implicitni Per-Container, kar pomeni, da se pri uporabi couchbase, MySQL ali MyDB satateful vsebnikov vsi začnejo s privzetim peskovnikom. To pomeni, da je vse, kar je shranjeno v bazi podatkov, shranjeno v samem vsebniku. Če vsebnik izgine, z njim izginejo tudi podatki.
Drugi je Explicit Per-Container, ko ustvarite določeno shrambo z ukazom docker volume create in vanj shranite podatke. Tretji pristop na gostitelja je povezan s preslikavo shranjevanja, ko se vse, kar je shranjeno v vsebniku, hkrati podvoji na gostitelju. Če vsebnik odpove, bodo podatki ostali na gostitelju. Slednje je uporaba večih Multi-Host gostiteljev, kar je priporočljivo v fazi izdelave različnih rešitev. Recimo, da se vaši vsebniki z vašimi aplikacijami izvajajo na gostitelju, vendar želite svoje podatke shraniti nekje na internetu in za to uporabite samodejno preslikavo za porazdeljene sisteme.
Vsaka od teh metod uporablja določeno lokacijo za shranjevanje. Implicitni in eksplicitni na vsebnik shranjujejo podatke na gostitelju na /var/lib/docker/volumes. Pri uporabi metode Per-Host je shramba nameščena znotraj vsebnika, sam vsebnik pa je nameščen na gostitelju. Za večgostitelje se lahko uporabljajo rešitve, kot so Ceph, ClusterFS, NFS itd.
Če trajni vsebnik odpove, postane imenik za shranjevanje v prvih dveh primerih nedostopen, v zadnjih dveh primerih pa se dostop ohrani. Vendar pa lahko v prvem primeru do repozitorija dostopate prek gostitelja Docker, ki deluje na virtualnem računalniku. V drugem primeru tudi podatki ne bodo izgubljeni, ker ste ustvarili eksplicitno shrambo.
Če gostitelj odpove, imenik pomnilnika v prvih treh primerih ni na voljo, v zadnjem primeru povezava s pomnilnikom ni prekinjena. Končno je skupna funkcija v prvem primeru popolnoma izključena za shranjevanje, v ostalih pa je mogoča. V drugem primeru lahko prostor za shranjevanje delite glede na to, ali vaša zbirka podatkov podpira porazdeljeno shranjevanje ali ne. V primeru Per-Host je distribucija podatkov mogoča samo na danem gostitelju, za več gostiteljev pa je zagotovljena z razširitvijo gruče.
To je treba upoštevati pri ustvarjanju vsebnikov s stanjem. Drugo uporabno orodje Docker je vtičnik Volume, ki deluje po principu »baterije so prisotne, vendar jih je treba zamenjati«. Ko zaženete vsebnik Docker, piše: "Hej, ko zaženete vsebnik z bazo podatkov, lahko shranite svoje podatke v ta vsebnik!" To je privzeta funkcija, vendar jo lahko spremenite. Ta vtičnik vam omogoča uporabo omrežnega pogona ali česa podobnega namesto baze podatkov vsebnika. Vključuje privzeti gonilnik za gostiteljsko shranjevanje in omogoča integracijo vsebnika z zunanjimi sistemi za shranjevanje, kot so Amazon EBS, Azure Storage in GCE Persistent diski.
Naslednji diapozitiv prikazuje arhitekturo vtičnika Docker Volume.
Modra barva predstavlja odjemalca Docker, povezanega z modrim gostiteljem Docker, ki ima mehanizem za lokalno shranjevanje, ki vam ponuja vsebnike za shranjevanje podatkov. Zelena označuje Plugin Client in Plugin Daemon, ki sta prav tako povezana z gostiteljem. Zagotavljajo možnost shranjevanja podatkov v omrežni shrambi vrste Storage Backend, ki jo potrebujete.
Vtičnik Docker Volume se lahko uporablja s shrambo Portworx. Modul PX-Dev je pravzaprav vsebnik, ki ga izvajate in se poveže z vašim gostiteljem Docker in vam omogoča enostavno shranjevanje podatkov na Amazon EBS.
Odjemalec Portworx vam omogoča spremljanje statusa različnih vsebnikov za shranjevanje, ki so povezani z vašim gostiteljem. Če obiščete moj blog, lahko preberete, kako kar najbolje izkoristiti Portworx z Dockerjem.
Koncept shranjevanja v Kubernetesu je podoben Dockerju in je predstavljen z imeniki, ki so dostopni vašemu vsebniku v podu. Neodvisni so od življenjske dobe katere koli posode. Najpogostejše vrste pomnilnika, ki so na voljo, so hostPath, nfs, awsElasticBlockStore in gsePersistentDisk. Oglejmo si, kako te trgovine delujejo v Kubernetesu. Običajno je postopek njihovega povezovanja sestavljen iz 3 korakov.
Prvi je, da vam nekdo na strani omrežja, običajno skrbnik, zagotovi trajno shranjevanje. Za to obstaja ustrezna konfiguracijska datoteka PersistentVolume. Nato razvijalec aplikacije napiše konfiguracijsko datoteko, imenovano PersistentVolumeClaim, ali zahtevo za shranjevanje PVC, ki pravi: »Imam 50 GB zagotovljenega porazdeljenega prostora za shranjevanje, a da bi tudi drugi ljudje lahko uporabljali njegovo zmogljivost, temu PVC-ju sporočam, da trenutno potrebujete le 10 GB". Nazadnje, tretji korak je, da se vaša zahteva namesti kot shramba in aplikacija, ki ima pod ali nabor replik ali kaj podobnega, to začne uporabljati. Pomembno si je zapomniti, da je ta postopek sestavljen iz treh omenjenih korakov in je prilagodljiv.
Naslednji diapozitiv prikazuje Kubernetes Persistence Container arhitekture AWS.
Znotraj rjavega pravokotnika, ki predstavlja gručo Kubernetes, sta eno glavno vozlišče in dve delovni vozlišči, označeni z rumeno. Eno od delovnih vozlišč vsebuje oranžni pod, shrambo, repliko krmilnika in zeleno posodo Docker Couchbase. Znotraj gruče, nad vozlišči, vijoličen pravokotnik označuje storitev, dostopno od zunaj. Ta arhitektura je priporočljiva za shranjevanje podatkov na sami napravi. Po potrebi lahko svoje podatke shranim v EBS zunaj gruče, kot je prikazano na naslednjem diapozitivu. To je tipičen model za skaliranje, vendar je pri njegovi uporabi treba upoštevati finančni vidik – shranjevanje podatkov nekje v omrežju je lahko dražje kot na gostitelju. Pri izbiri kontejnerskih rešitev je to eden tehtnih argumentov.
Tako kot pri Dockerju lahko tudi s Portworxom uporabljate obstojne vsebnike Kubernetes.
To je tisto, kar se v trenutni terminologiji Kubernetes 1.6 imenuje »StatefulSet« – način dela z aplikacijami Stateful, ki obdelujejo dogodke o zaustavitvi Poda in izvajanju Graceful Shutdown. V našem primeru so takšne aplikacije baze podatkov. V mojem blogu si lahko preberete, kako ustvariti StatefulSet v Kubernetesu s pomočjo Portworxa.
Pogovorimo se o razvojnem vidiku. Kot sem rekel, ima Docker 2 različici - CE in EE, v prvem primeru govorimo o stabilni različici Community Edition, ki se posodobi enkrat na 3 mesece, v nasprotju z mesečno posodobljeno različico EE. Docker lahko prenesete za Mac, Linux ali Windows. Po namestitvi se bo Docker samodejno posodobil in začeti je zelo enostavno.
Za Kubernetes imam raje različico Minikube – to je dober način za začetek uporabe platforme z ustvarjanjem gruče na enem vozlišču. Za ustvarjanje grozdov iz več vozlišč je izbira različic širša: to so kops, kube-aws (CoreOS+AWS), kube-up (zastarelo). Če želite uporabljati Kubernetes, ki temelji na AWS, vam priporočam, da se pridružite AWS SIG, ki se sestaja na spletu vsak petek in objavlja vrsto zanimivih gradiv o delu z AWS Kubernetes.
Poglejmo, kako se tekoča posodobitev izvaja na teh platformah. Če obstaja gruča več vozlišč, potem uporablja določeno različico slike, na primer WildFly:1. Tekoča posodobitev pomeni, da se različica slike zaporedno zamenja z novo na vsakem vozlišču, ena za drugo.
Za to uporabim ukaz docker service update (ime storitve), v katerem podam novo različico slike WildFly:2 in metodo posodobitve update-parallelism 2. Številka 2 pomeni, da bo sistem posodobil 2 sliki aplikacije hkrati, nato 10-sekundna zakasnitev posodobitve 10 s, po kateri bosta naslednji 2 sliki posodobljeni na dodatnih 2 vozliščih itd. Ta preprost tekoči mehanizem posodabljanja vam je na voljo kot del Dockerja.
V Kubernetesu tekoča posodobitev deluje takole. Replikacijski krmilnik rc ustvari nabor replik iste različice in vsak pod v tem webapp-rc ima oznako, ki se nahaja v etcd. Ko potrebujem pod, uporabim Application Service za dostop do repozitorija etcd, ki mi zagotovi pod s podano oznako.
V tem primeru imamo v krmilniku podvajanja 3 sklope, ki izvajajo aplikacijo WildFly različice 1. Pri posodabljanju v ozadju se ustvari drug krmilnik podvajanja z enakim imenom in indeksom na koncu - - xxxxx, kjer so x naključna števila in z enakimi oznakami. Zdaj ima Application Service tri pode s staro različico aplikacije in tri pode z novo različico v novem krmilniku replikacije. Po tem se stari podi izbrišejo, krmilnik replikacije z novimi podi se preimenuje in začne delovati.
Preidimo na spremljanje. Docker ima veliko vgrajenih nadzornih ukazov. Na primer, vmesnik ukazne vrstice docker container stats omogoča prikaz informacij o stanju vsebnikov na konzoli vsako sekundo – uporaba procesorja, uporaba diska, obremenitev omrežja. Orodje Docker Remote API zagotavlja podatke o tem, kako odjemalec komunicira s strežnikom. Uporablja preproste ukaze, vendar temelji na API-ju Docker REST. V tem primeru besede REST, Flash, Remote pomenijo isto stvar. Ko komunicirate z gostiteljem, je to API REST. Docker Remote API vam omogoča, da dobite več informacij o izvajanju vsebnikov. Moj blog opisuje podrobnosti uporabe tega nadzora s strežnikom Windows Server.
Spremljanje dogodkov docker sistema pri izvajanju gruče z več gostitelji omogoča pridobivanje podatkov o zrušitvi gostitelja ali zrušitvi vsebnika na določenem gostitelju, storitvah za skaliranje in podobno. Začenši z Dockerjem 1.20 vključuje Prometheus, ki vdela končne točke v obstoječe aplikacije. To vam omogoča prejemanje meritev prek HTTP in njihovo prikazovanje na nadzornih ploščah.
Druga funkcija spremljanja je cAdvisor (okrajšava za kontejnerskega svetovalca). Analizira in zagotavlja podatke o uporabi virov in zmogljivosti iz delujočih vsebnikov ter zagotavlja meritve Prometheus takoj po izdelavi. Posebnost tega orodja je, da zagotavlja samo podatke za zadnjih 60 sekund. Zato morate biti sposobni zbrati te podatke in jih vnesti v bazo podatkov, da boste lahko spremljali dolgoročen proces. Uporablja se lahko tudi za grafični prikaz meritev nadzorne plošče z uporabo Grafane ali Kibane. Moj blog ima podroben opis uporabe cAdvisorja za spremljanje kontejnerjev z nadzorno ploščo Kibana.
Naslednji diapozitiv prikazuje, kako izgleda izhod končne točke Prometheus in meritve, ki so na voljo za prikaz.
Spodaj levo vidite metrike za HTTP zahteve, odgovore itd., desno je njihov grafični prikaz.
Kubernetes vključuje tudi vgrajena orodja za spremljanje. Ta diapozitiv prikazuje tipično gručo, ki vsebuje eno glavno in tri delovna vozlišča.
Vsako od delovnih vozlišč vsebuje samodejno zagnan cSvetnik. Poleg tega obstaja Heapster, sistem za spremljanje zmogljivosti in zbiranje meritev, ki je združljiv z različico Kubernetes 1.0.6 in novejšo. Heapster vam omogoča zbiranje ne le meritev zmogljivosti delovnih obremenitev, podov in vsebnikov, temveč tudi dogodke in druge signale, ki jih ustvari celotna gruča. Za zbiranje podatkov se pogovarja s Kubeletom vsakega stroka, samodejno shrani informacije v bazo podatkov InfluxDB in jih kot metriko prikaže na nadzorni plošči Grafana. Vendar ne pozabite, da če uporabljate miniKube, ta funkcija privzeto ni na voljo, zato boste morali za spremljanje uporabiti dodatke. Vse je torej odvisno od tega, kje izvajate vsebnike in katera orodja za spremljanje lahko uporabljate privzeto in katera morate namestiti kot ločene dodatke.
Naslednji diapozitiv prikazuje nadzorne plošče Grafana, ki prikazujejo tekoče stanje mojih vsebnikov. Tukaj je kar nekaj zanimivih podatkov. Seveda obstaja veliko komercialnih orodij za spremljanje procesov Docker in Kubernetes, kot so SysDig, DataDog, NewRelic. Nekateri od njih imajo 30-letno brezplačno preskusno obdobje, tako da lahko poskusite in najdete tisto, ki vam najbolj ustreza. Osebno raje uporabljam SysDig in NewRelic, ki se dobro integrirata s Kubernetesom. Obstajajo orodja, ki se enako dobro integrirajo v platformo Docker in Kubernetes.
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com