Docker Swarm, Kubernetes a Mesos sú najobľúbenejšie rámce na orchestráciu kontajnerov. Arun Gupta vo svojej prednáške porovnáva nasledujúce aspekty Docker, Swarm a Kubernetes:
- Miestny rozvoj.
- Funkcie nasadenia.
- Aplikácie s viacerými kontajnermi.
- Objavenie služby.
- Škálovanie služby.
- Jednorazové úlohy.
- Integrácia s Maven.
- "Rolling" aktualizácia.
- Vytvorenie databázového klastra Couchbase.
V dôsledku toho získate jasnú predstavu o tom, čo každý nástroj na orchestráciu ponúka, a naučíte sa, ako tieto platformy efektívne používať.
Arun Gupta je hlavným technológom pre open-source produkty v Amazon Web Services, ktorý už viac ako 10 rokov vyvíja komunity vývojárov Sun, Oracle, Red Hat a Couchbase. Má rozsiahle skúsenosti s prácou vo vedení medzifunkčných tímov vyvíjajúcich a implementujúcich stratégiu marketingových kampaní a programov. Viedol tímy inžinierov Sun, je jedným zo zakladateľov tímu Java EE a tvorcom americkej pobočky Devoxx4Kids. Arun Gupta je autorom viac ako 2 tisíc príspevkov v IT blogoch a prednášal vo viac ako 40 krajinách.
Riadok 55 obsahuje COUCHBASE_URI ukazujúci na túto databázovú službu, ktorá bola tiež vytvorená pomocou konfiguračného súboru Kubernetes. Ak sa pozriete na riadok 2, môžete vidieť druh: Služba je služba, ktorú vytváram, nazývaná couchbase-service a rovnaký názov je uvedený v riadku 4. Nižšie sú uvedené niektoré porty.
Kľúčové riadky sú 6 a 7. V službe hovorím: „Hej, toto sú štítky, ktoré hľadám!“ a tieto štítky nie sú nič iné ako názvy premenných párov a riadok 7 ukazuje na môj couchbase-rs-pod aplikácie. Nasledujú porty, ktoré poskytujú prístup k rovnakým štítkom.
V riadku 19 vytvorím nový typ ReplicaSet, riadok 31 obsahuje názov obrázka a riadky 24 až 27 ukazujú na metadáta spojené s mojím modulom. To je presne to, čo služba hľadá a k čomu by sa malo pripojiť. Na konci súboru je nejaké spojenie medzi riadkami 55-56 a 4, ktoré hovorí: „použite túto službu!“
Svoju službu teda spustím, keď existuje sada replík, a keďže každá sada replík má svoj vlastný port s príslušným označením, je súčasťou služby. Z pohľadu vývojára jednoducho zavoláte službu, ktorá potom použije sadu replík, ktoré potrebujete.
Výsledkom je, že mám modul WildFly, ktorý komunikuje s backendom databázy prostredníctvom služby Couchbase. Môžem použiť frontend s niekoľkými WildFly podmi, ktorý tiež komunikuje s backendom couchbase cez službu couchbase.
Neskôr sa pozrieme na to, ako služba umiestnená mimo klastra komunikuje prostredníctvom svojej IP adresy s prvkami, ktoré sa nachádzajú vo vnútri klastra a majú internú IP adresu.
Bezstavové kontajnery sú teda skvelé, ale aké dobré je používať bezstavové kontajnery? Pozrime sa na systémové nastavenia pre stavové alebo trvalé kontajnery. V Dockeri existujú 4 rôzne prístupy k usporiadaniu ukladania údajov, ktorým by ste mali venovať pozornosť. Prvým je Implicit Per-Container, čo znamená, že pri použití couchbase, MySQL alebo MyDB satateful kontajnerov všetky začínajú s predvoleným Sandboxom. To znamená, že všetko, čo je uložené v databáze, je uložené v samotnom kontajneri. Ak kontajner zmizne, spolu s ním zmiznú aj údaje.
Druhým je Explicit Per-Container, keď vytvoríte špecifické úložisko pomocou príkazu na vytvorenie zväzku docker a uložíte do neho údaje. Tretí prístup typu Per-Host je spojený s mapovaním úložiska, keď sa všetko uložené v kontajneri súčasne duplikuje na hostiteľovi. Ak kontajner zlyhá, údaje zostanú na hostiteľovi. Posledným z nich je použitie niekoľkých hostiteľov Multi-Host, čo sa odporúča vo fáze výroby rôznych riešení. Povedzme, že vaše kontajnery s vašimi aplikáciami bežia na hostiteľovi, ale chcete svoje údaje uložiť niekde na internete a na to používate automatické mapovanie pre distribuované systémy.
Každá z týchto metód využíva špecifické miesto uloženia. Implicitné a explicitné kontajnery ukladajú údaje na hostiteľovi na /var/lib/docker/volumes. Pri použití metódy Per-Host je úložisko namontované vo vnútri kontajnera a samotný kontajner je namontovaný na hostiteľovi. Pre multihosts je možné použiť riešenia ako Ceph, ClusterFS, NFS atď.
Ak trvalý kontajner zlyhá, úložný adresár sa v prvých dvoch prípadoch stane nedostupným, ale v posledných dvoch prípadoch zostane prístup zachovaný. V prvom prípade však môžete pristupovať k úložisku prostredníctvom hostiteľa Docker spusteného na virtuálnom počítači. V druhom prípade nedôjde ani k strate údajov, pretože máte vytvorené Explicitné úložisko.
Ak hostiteľ zlyhá, adresár úložiska je v prvých troch prípadoch nedostupný, v poslednom prípade sa spojenie s úložiskom nepreruší. Nakoniec je zdieľaná funkcia v prvom prípade úplne vylúčená z uloženia a v ostatných prípadoch je možná. V druhom prípade môžete zdieľať úložisko v závislosti od toho, či vaša databáza podporuje distribuované úložisko alebo nie. V prípade Per-Host je distribúcia dát možná len na danom hostiteľovi a pre multihostiteľa je zabezpečená expanziou klastra.
Toto by sa malo brať do úvahy pri vytváraní stavových kontajnerov. Ďalším užitočným nástrojom Docker je zásuvný modul Volume, ktorý funguje na princípe „batérie sú prítomné, ale musia sa vymeniť“. Keď spustíte kontajner Docker, povie: „Hej, keď spustíte kontajner s databázou, môžete do tohto kontajnera uložiť svoje údaje!“ Toto je predvolená funkcia, ale môžete ju zmeniť. Tento plugin vám umožňuje použiť namiesto kontajnerovej databázy sieťový disk alebo niečo podobné. Zahŕňa predvolený ovládač pre úložisko založené na hostiteľovi a umožňuje integráciu kontajnerov s externými úložnými systémami, ako sú Amazon EBS, Azure Storage a GCE Persistent disky.
Ďalšia snímka zobrazuje architektúru doplnku Docker Volume.
Modrá farba predstavuje klienta Docker spojeného s modrým hostiteľom Docker, ktorý má lokálny ukladací mechanizmus, ktorý vám poskytuje kontajnery na ukladanie údajov. Zelená označuje Plugin Client a Plugin Daemon, ktoré sú tiež pripojené k hostiteľovi. Poskytujú možnosť ukladať dáta do sieťového úložiska typu Storage Backend, ktorý potrebujete.
Doplnok Docker Volume je možné použiť s úložiskom Portworx. Modul PX-Dev je vlastne kontajner, ktorý spustíte a ktorý sa pripojí k vášmu hostiteľovi Docker a umožní vám jednoducho ukladať dáta na Amazon EBS.
Klient Portworx vám umožňuje sledovať stav rôznych úložných kontajnerov, ktoré sú pripojené k vášmu hostiteľovi. Ak navštívite môj blog, môžete si prečítať, ako čo najlepšie využiť Portworx s Dockerom.
Koncept úložiska v Kubernetes je podobný ako Docker a je reprezentovaný adresármi, ktoré sú prístupné vášmu kontajneru v pod. Sú nezávislé od životnosti akéhokoľvek kontajnera. Najbežnejšie dostupné typy úložiska sú hostPath, nfs, awsElasticBlockStore a gsePersistentDisk. Poďme sa pozrieť, ako tieto obchody fungujú v Kubernetes. Proces ich pripojenia zvyčajne pozostáva z 3 krokov.
Prvým je, že niekto na strane siete, zvyčajne správca, vám poskytne trvalé úložisko. Na to existuje zodpovedajúci konfiguračný súbor PersistentVolume. Ďalej vývojár aplikácie napíše konfiguračný súbor s názvom PersistentVolumeClaim alebo žiadosť o úložisko PVC, ktorá hovorí: „Mám poskytnutých 50 GB distribuovaného úložiska, ale aby jeho kapacitu mohli využívať aj iní ľudia, hovorím tomuto PVC, že momentálne potrebuje len 10 GB“. Nakoniec, tretím krokom je, že vaša požiadavka je pripojená ako úložisko a aplikácia, ktorá má modul alebo sadu replík alebo niečo podobné, ho začne používať. Je dôležité si zapamätať, že tento proces pozostáva zo spomínaných 3 krokov a je škálovateľný.
Ďalšia snímka zobrazuje kontajner Kubernetes Persistence Container architektúry AWS.
Vo vnútri hnedého obdĺžnika, ktorý predstavuje klaster Kubernetes, sa nachádza jeden hlavný uzol a dva pracovné uzly, označené žltou farbou. Jeden z pracovných uzlov obsahuje oranžový modul, úložisko, repliku ovládača a zelený kontajner Docker Couchbase. Vo vnútri klastra nad uzlami fialový obdĺžnik označuje službu prístupnú zvonku. Táto architektúra sa odporúča na ukladanie údajov na samotnom zariadení. V prípade potreby môžem svoje údaje uložiť v EBS mimo klastra, ako je znázornené na ďalšej snímke. Toto je typický model pre škálovanie, ale pri jeho používaní je potrebné zvážiť finančný aspekt – ukladanie údajov niekde v sieti môže byť drahšie ako na hostiteľovi. Pri výbere kontajnerových riešení je to jeden z vážnych argumentov.
Rovnako ako v prípade Docker, aj s Portworx môžete používať trvalé kontajnery Kubernetes.
To je to, čo sa v súčasnej terminológii Kubernetes 1.6 nazýva „StatefulSet“ – spôsob práce so stavovými aplikáciami, ktoré spracovávajú udalosti týkajúce sa zastavenia modulu a vykonania elegantného vypnutia. V našom prípade sú takými aplikáciami databázy. V mojom blogu si môžete prečítať, ako vytvoriť StatefulSet v Kubernetes pomocou Portworx.
Poďme sa baviť o aspekte rozvoja. Ako som povedal, Docker má 2 verzie – CE a EE, v prvom prípade hovoríme o stabilnej verzii Community Edition, ktorá sa aktualizuje raz za 3 mesiace, na rozdiel od mesačnej aktualizovanej verzie EE. Môžete si stiahnuť Docker pre Mac, Linux alebo Windows. Po nainštalovaní sa Docker automaticky aktualizuje a začať je veľmi jednoduché.
Pre Kubernetes preferujem verziu Minikube – je to dobrý spôsob, ako začať s platformou vytvorením klastra na jednom uzle. Na vytvorenie zhlukov viacerých uzlov je výber verzií širší: ide o kopy, kube-aws (CoreOS+AWS), kube-up (zastarané). Ak chcete používať Kubernetes založené na AWS, odporúčam vám pripojiť sa k AWS SIG, ktorá sa stretáva online každý piatok a publikuje rôzne zaujímavé materiály o práci s AWS Kubernetes.
Pozrime sa, ako sa Rolling Update vykonáva na týchto platformách. Ak existuje zhluk niekoľkých uzlov, potom používa špecifickú verziu obrázka, napríklad WildFly:1. Postupná aktualizácia znamená, že verzia obrázka sa postupne nahrádza novou v každom uzle, jedna po druhej.
Používam na to príkaz docker service update (názov služby), v ktorom určím novú verziu obrázku WildFly:2 a metódu aktualizácie update-paralelizmus 2. Číslo 2 znamená, že systém aktualizuje 2 obrázky aplikácie v rovnakom čase, potom 10-sekundové oneskorenie aktualizácie 10s, po ktorom budú ďalšie 2 obrázky aktualizované na 2 ďalších uzloch atď. Tento jednoduchý mechanizmus priebežnej aktualizácie vám poskytujeme ako súčasť Dockeru.
V Kubernetes funguje priebežná aktualizácia takto. Kontrolér replikácie rc vytvorí sadu replík rovnakej verzie a každá pod v tejto webovej aplikácii-rc je vybavená štítkom umiestneným v etcd. Keď potrebujem modul, používam aplikačnú službu na prístup k úložisku etcd, ktoré mi poskytuje modul pomocou špecifikovaného označenia.
V tomto prípade máme 3 moduly v kontroléri Replication, na ktorom beží aplikácia WildFly verzie 1. Pri aktualizácii na pozadí sa vytvorí ďalší kontrolér replikácie s rovnakým názvom a indexom na konci - - xxxxx, kde x sú náhodné čísla a s rovnakými štítkami. Aplikačná služba má teraz tri moduly so starou verziou aplikácie a tri moduly s novou verziou v novom ovládači replikácie. Potom sa staré moduly vymažú, kontrolér replikácie s novými modulmi sa premenuje a uvedie do prevádzky.
Prejdime k monitorovaniu. Docker má mnoho vstavaných monitorovacích príkazov. Napríklad rozhranie príkazového riadka so štatistikami kontajnerov docker vám umožňuje každú sekundu zobraziť informácie o stave kontajnerov na konzole - využitie procesora, využitie disku, zaťaženie siete. Nástroj Docker Remote API poskytuje údaje o tom, ako klient komunikuje so serverom. Používa jednoduché príkazy, no je založený na Docker REST API. V tomto prípade slová REST, Flash, Remote znamenajú to isté. Keď komunikujete s hostiteľom, je to REST API. Docker Remote API vám umožňuje získať viac informácií o spustených kontajneroch. Môj blog načrtáva podrobnosti používania tohto monitorovania so systémom Windows Server.
Monitorovanie udalostí docker systému pri spustení multihostiteľského klastra umožňuje získať údaje o havárii hostiteľa alebo o havárii kontajnera na konkrétnom hostiteľovi, škálovacích službách a podobne. Počnúc Dockerom 1.20 zahŕňa Prometheus, ktorý vkladá koncové body do existujúcich aplikácií. To vám umožňuje prijímať metriky prostredníctvom protokolu HTTP a zobrazovať ich na informačných paneloch.
Ďalšou monitorovacou funkciou je cAdvisor (skratka pre kontajnerový poradca). Analyzuje a poskytuje údaje o využívaní zdrojov a výkone zo spustených kontajnerov a poskytuje metriky Prometheus hneď po vybalení. Zvláštnosťou tohto nástroja je, že poskytuje údaje len za posledných 60 sekúnd. Preto musíte byť schopní zbierať tieto údaje a vkladať ich do databázy, aby ste mohli sledovať dlhodobý proces. Dá sa použiť aj na grafické zobrazenie metrík palubnej dosky pomocou Grafana alebo Kibana. Môj blog obsahuje podrobný popis toho, ako používať cAdvisor na monitorovanie kontajnerov pomocou dashboardu Kibana.
Ďalšia snímka ukazuje, ako vyzerá výstup koncového bodu Prometheus a dostupné metriky na zobrazenie.
Vľavo dole vidíte metriky HTTP požiadaviek, odpovedí atď., vpravo je ich grafické zobrazenie.
Kubernetes tiež obsahuje vstavané monitorovacie nástroje. Táto snímka zobrazuje typický klaster obsahujúci jeden hlavný a tri pracovné uzly.
Každý z pracovných uzlov obsahuje automaticky spustený cAdvisor. Okrem toho je tu Heapster, systém sledovania výkonu a zberu metrík kompatibilný s Kubernetes verzie 1.0.6 a vyššej. Heapster vám umožňuje zhromažďovať nielen výkonnostné metriky pracovných záťaží, modulov a kontajnerov, ale aj udalosti a ďalšie signály generované celým klastrom. Na zhromažďovanie údajov sa rozpráva s Kubeletom každého modulu, automaticky ukladá informácie do databázy InfluxDB a vydáva ich ako metriky na dashboard Grafana. Majte však na pamäti, že ak používate miniKube, táto funkcia nie je štandardne dostupná, takže na monitorovanie budete musieť použiť doplnky. Všetko teda závisí od toho, kde spúšťate kontajnery a ktoré monitorovacie nástroje môžete štandardne používať a ktoré musíte nainštalovať ako samostatné doplnky.
Na ďalšej snímke sú zobrazené ovládacie panely Grafana, ktoré zobrazujú stav prevádzky mojich kontajnerov. Je tu pomerne veľa zaujímavých údajov. Samozrejme, existuje veľa komerčných nástrojov na monitorovanie procesov Docker a Kubernetes, ako napríklad SysDig, DataDog, NewRelic. Niektoré z nich majú 30-ročné bezplatné skúšobné obdobie, takže si môžete vyskúšať a nájsť ten, ktorý vám najviac vyhovuje. Osobne preferujem použitie SysDig a NewRelic, ktoré sa dobre integrujú s Kubernetes. Existujú nástroje, ktoré sa rovnako dobre integrujú do platforiem Docker aj Kubernetes.
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com