Docker Swarm, Kubernetes i Mesos najpopularniji su okviri za orkestraciju spremnika. U svom govoru Arun Gupta uspoređuje sljedeće aspekte Dockera, Swarma i Kubernetesa:
- Lokalni razvoj.
- Funkcije raspoređivanja.
- Aplikacije s više spremnika.
- Otkrivanje usluge.
- Skaliranje usluge.
- Jednokratni zadaci.
- Integracija s Mavenom.
- "Tekuće" ažuriranje.
- Stvaranje Couchbase klastera baze podataka.
Kao rezultat toga, steći ćete jasno razumijevanje onoga što svaki alat za orkestraciju nudi i naučiti kako učinkovito koristiti te platforme.
Arun Gupta je glavni tehnolog za proizvode otvorenog koda u Amazon Web Services, koji već više od 10 godina razvija zajednice programera Sun, Oracle, Red Hat i Couchbase. Ima veliko iskustvo rada u vođenju višefunkcionalnih timova koji razvijaju i implementiraju strategiju za marketinške kampanje i programe. Vodio je timove Sun inženjera, jedan je od osnivača Java EE tima i tvorac američke podružnice Devoxx4Kids. Arun Gupta je autor više od 2 tisuće postova na IT blogovima i održao je predavanja u više od 40 zemalja.
Redak 55 sadrži COUCHBASE_URI koji pokazuje na ovu uslugu baze podataka, koja je također stvorena pomoću Kubernetes konfiguracijske datoteke. Ako pogledate redak 2, možete vidjeti sljedeće: Usluga je usluga koju stvaram pod nazivom couchbase-service, a isti naziv je naveden u retku 4. Ispod su neki priključci.
Ključne linije su 6 i 7. U servisu kažem, "Hej, ovo su oznake koje tražim!", a te oznake nisu ništa više od naziva parova varijabli, a linija 7 pokazuje na moj couchbase-rs-pod primjena. Sljedeći su priključci koji omogućuju pristup tim istim oznakama.
U retku 19 stvaram novi tip ReplicaSet, redak 31 sadrži naziv slike, a redovi 24-27 ukazuju na metapodatke povezane s mojim modulom. To je upravo ono što servis traži i na što se treba povezati. Na kraju datoteke postoji neka vrsta poveznice između redaka 55-56 i 4, koja kaže: "koristi ovu uslugu!"
Dakle, pokrećem svoju uslugu kada postoji skup replika, a budući da svaki skup replika ima svoj port s odgovarajućom oznakom, uključen je u uslugu. Sa stajališta razvojnog programera, jednostavno pozovete uslugu, koja zatim koristi skup replika koje trebate.
Kao rezultat toga, imam WildFly pod koji komunicira s pozadinom baze podataka putem usluge Couchbase. Mogu koristiti sučelje s nekoliko WildFly podova, koji također komuniciraju s pozadinom couchbase putem usluge couchbase.
Kasnije ćemo pogledati kako servis koji se nalazi izvan klastera komunicira putem svoje IP adrese s elementima koji se nalaze unutar klastera i imaju internu IP adresu.
Dakle, spremnici bez statusa su izvrsni, ali koliko je dobro koristiti spremnike s statusom? Pogledajmo postavke sustava za statusne ili trajne spremnike. U Dockeru postoje 4 različita pristupa rasporedu pohrane podataka na koje biste trebali obratiti pozornost. Prvi je Implicitni per-kontejner, što znači da kada koristite couchbase, MySQL ili MyDB satateful spremnike, svi počinju sa zadanim Sandboxom. Odnosno, sve što je pohranjeno u bazi pohranjeno je u samom spremniku. Ako spremnik nestane, podaci nestaju zajedno s njim.
Drugi je eksplicitni per-kontejner, kada stvorite određenu pohranu pomoću naredbe za stvaranje docker volumena i pohranite podatke u nju. Treći pristup po hostu povezan je s mapiranjem pohrane, kada se sve što je pohranjeno u spremniku istovremeno duplicira na hostu. Ako spremnik zakaže, podaci će ostati na glavnom računalu. Potonji je korištenje nekoliko Multi-Host hostova, što je preporučljivo u fazi proizvodnje različitih rješenja. Recimo da se vaši spremnici s vašim aplikacijama izvode na glavnom računalu, ali želite svoje podatke pohraniti negdje na internetu, a za to koristite automatsko mapiranje za distribuirane sustave.
Svaka od ovih metoda koristi određeno mjesto za pohranu. Implicitni i eksplicitni per-kontejner pohranjuju podatke na glavnom računalu u /var/lib/docker/volumes. Kada koristite metodu Per-Host, pohrana se montira unutar spremnika, a sam spremnik se montira na glavno računalo. Za multihostove mogu se koristiti rješenja kao što su Ceph, ClusterFS, NFS itd.
Ako trajni spremnik ne uspije, direktorij za pohranu postaje nedostupan u prva dva slučaja, ali u posljednja dva slučaja pristup se održava. Međutim, u prvom slučaju možete pristupiti repozitoriju preko Docker hosta koji radi na virtualnom računalu. U drugom slučaju, podaci također neće biti izgubljeni, jer ste stvorili eksplicitnu pohranu.
Ako host zakaže, direktorij za pohranu je nedostupan u prva tri slučaja; u posljednjem slučaju veza sa pohranom nije prekinuta. Konačno, zajednička je funkcija potpuno isključena za pohranu u prvom slučaju, a moguća je u ostalima. U drugom slučaju, možete dijeliti pohranu ovisno o tome podržava li vaša baza podataka distribuiranu pohranu ili ne. U slučaju Per-Host-a, distribucija podataka je moguća samo na određenom hostu, a za multihost je osigurana proširenjem klastera.
To treba uzeti u obzir pri izradi spremnika s praćenjem stanja. Još jedan koristan Docker alat je Volume plugin, koji radi na principu "baterije prisutne, ali moraju se zamijeniti." Kada pokrenete Docker spremnik, on kaže: "Hej, nakon što pokrenete spremnik s bazom podataka, možete pohraniti svoje podatke u ovaj spremnik!" Ovo je zadana značajka, ali je možete promijeniti. Ovaj vam dodatak omogućuje korištenje mrežnog pogona ili nečeg sličnog umjesto spremnika baze podataka. Uključuje zadani upravljački program za pohranu temeljenu na hostu i omogućuje integraciju spremnika s vanjskim sustavima za pohranu kao što su Amazon EBS, Azure Storage i GCE Persistent diskovi.
Sljedeći slajd prikazuje arhitekturu dodatka Docker Volume.
Plava boja predstavlja Docker klijenta povezanog s plavim Docker hostom, koji ima lokalni mehanizam za pohranu koji vam pruža spremnike za pohranu podataka. Zeleno označava Plugin Client i Plugin Daemon, koji su također povezani s hostom. Oni pružaju mogućnost pohranjivanja podataka u mrežnu pohranu vrste pozadine za pohranu koja vam je potrebna.
Dodatak Docker Volume može se koristiti s Portworx pohranom. PX-Dev modul zapravo je spremnik koji pokrećete i povezuje se s vašim Docker hostom i omogućuje vam jednostavno pohranjivanje podataka na Amazon EBS.
Portworx klijent vam omogućuje praćenje statusa različitih spremnika za pohranu koji su povezani s vašim hostom. Ako posjetite moj blog, možete pročitati kako maksimalno iskoristiti Portworx s Dockerom.
Koncept pohrane u Kubernetesu sličan je Dockeru i predstavljen je direktorijima koji su dostupni vašem spremniku u podu. Oni su neovisni o životnom vijeku bilo kojeg spremnika. Najčešće dostupne vrste pohrane su hostPath, nfs, awsElasticBlockStore i gsePersistentDisk. Pogledajmo kako te trgovine rade u Kubernetesu. Obično se postupak njihovog povezivanja sastoji od 3 koraka.
Prvi je da vam netko na mrežnoj strani, obično administrator, osigura stalnu pohranu. Za to postoji odgovarajuća konfiguracijska datoteka PersistentVolume. Zatim, razvojni programer aplikacije piše konfiguracijsku datoteku pod nazivom PersistentVolumeClaim ili PVC zahtjev za pohranu, koji kaže: "Imam 50 GB distribuirane pohrane osigurane, ali kako bi i drugi ljudi mogli koristiti njen kapacitet, ovom PVC-u govorim da trenutno treba samo 10 GB". Konačno, treći korak je da se vaš zahtjev montira kao pohrana, a aplikacija koja ima pod, ili set replika, ili nešto slično, počinje ga koristiti. Važno je zapamtiti da se ovaj proces sastoji od 3 spomenuta koraka i da je skalabilan.
Sljedeći slajd prikazuje Kubernetes Persistence Container AWS arhitekture.
Unutar smeđeg pravokutnika koji predstavlja Kubernetes klaster, nalazi se jedan glavni čvor i dva radnička čvora, označeni žutom bojom. Jedan od radnih čvorova sadrži narančastu mahunu, pohranu, repliku kontrolera i zeleni spremnik Docker Couchbase. Unutar klastera, iznad čvorova, ljubičasti pravokutnik označava uslugu pristupačnu izvana. Ova se arhitektura preporučuje za pohranu podataka na samom uređaju. Ako je potrebno, mogu pohraniti svoje podatke u EBS izvan klastera, kao što je prikazano na sljedećem slajdu. Ovo je tipičan model za skaliranje, ali postoji financijski aspekt koji treba uzeti u obzir prilikom njegove upotrebe - pohranjivanje podataka negdje na mreži može biti skuplje nego na glavnom računalu. Pri odabiru rješenja za kontejnerizaciju ovo je jedan od važnih argumenata.
Baš kao i s Dockerom, možete koristiti trajne Kubernetes spremnike s Portworxom.
To je ono što se u trenutnoj terminologiji Kubernetesa 1.6 naziva "StatefulSet" - način rada s Stateful aplikacijama koje obrađuju događaje o zaustavljanju Poda i izvođenju Graceful Shutdown. U našem slučaju takve aplikacije su baze podataka. U mom blogu možete pročitati kako stvoriti StatefulSet u Kubernetesu koristeći Portworx.
Razgovarajmo o razvojnom aspektu. Kao što rekoh, Docker ima 2 verzije - CE i EE, u prvom slučaju govorimo o stabilnoj verziji Community Edition, koja se ažurira jednom svaka 3 mjeseca, za razliku od verzije EE koja se ažurira mjesečno. Docker možete preuzeti za Mac, Linux ili Windows. Jednom instaliran, Docker će se automatski ažurirati i vrlo je jednostavno započeti.
Za Kubernetes preferiram Minikube verziju - to je dobar način za početak rada s platformom stvaranjem klastera na jednom čvoru. Za stvaranje klastera od nekoliko čvorova, izbor verzija je širi: to su kops, kube-aws (CoreOS+AWS), kube-up (zastarjelo). Ako želite koristiti Kubernetes temeljen na AWS-u, preporučujem da se pridružite AWS SIG-u, koji se sastaje online svakog petka i objavljuje niz zanimljivih materijala o radu s AWS Kubernetesom.
Pogledajmo kako se Rolling Update izvodi na ovim platformama. Ako postoji klaster od nekoliko čvorova, tada koristi određenu verziju slike, na primjer, WildFly:1. Tekuće ažuriranje znači da se verzija slike uzastopno zamjenjuje novom na svakom čvoru, jedna za drugom.
Da bih to učinio, koristim naredbu docker service update (service name), u kojoj specificiram novu verziju slike WildFly:2 i metodu ažuriranja update-parallelism 2. Broj 2 znači da će sustav ažurirati 2 slike aplikacije u isto vrijeme, zatim odgoda ažuriranja od 10 sekundi od 10 s, nakon čega će se sljedeće 2 slike ažurirati na još 2 čvora, itd. Ovaj jednostavan mehanizam tekućeg ažuriranja dostupan vam je kao dio Dockera.
U Kubernetesu, tekuće ažuriranje funkcionira ovako. Replikacijski kontroler rc stvara skup replika iste verzije, a svaki pod u ovom webapp-rc-u ima oznaku koja se nalazi u etcd. Kada trebam pod, koristim Application Service za pristup etcd repozitoriju, koji mi daje pod pomoću navedene oznake.
U ovom slučaju imamo 3 modula u kontroleru replikacije koji pokreću aplikaciju WildFly verzije 1. Prilikom ažuriranja u pozadini, stvara se drugi kontroler replikacije s istim imenom i indeksom na kraju - - xxxxx, gdje su x nasumični brojevi, a s istim oznakama. Sada Application Service ima tri modula sa starom verzijom aplikacije i tri modula s novom verzijom u novom kontroleru replikacije. Nakon toga, stari podovi se brišu, replikacijski kontroler s novim podovima se preimenuje i stavlja u rad.
Prijeđimo na praćenje. Docker ima mnogo ugrađenih naredbi za nadzor. Na primjer, sučelje naredbenog retka docker container stats omogućuje prikaz informacija o stanju spremnika na konzoli svake sekunde - korištenje procesora, korištenje diska, opterećenje mreže. Alat Docker Remote API pruža podatke o tome kako klijent komunicira s poslužiteljem. Koristi jednostavne naredbe, ali se temelji na Docker REST API-ju. U ovom slučaju riječi REST, Flash, Remote znače isto. Kada komunicirate s hostom, to je REST API. Docker Remote API omogućuje vam da dobijete više informacija o pokretanju spremnika. Moj blog opisuje detalje korištenja ovog nadzora sa sustavom Windows Server.
Praćenje događaja docker sustava prilikom pokretanja klastera s više računala omogućuje dobivanje podataka o padu hosta ili kontejnera na određenom hostu, uslugama skaliranja i slično. Počevši od Dockera 1.20, uključuje Prometheus, koji ugrađuje krajnje točke u postojeće aplikacije. To vam omogućuje primanje metričkih podataka putem HTTP-a i njihov prikaz na nadzornim pločama.
Još jedna značajka nadzora je cAdvisor (skraćenica za kontejnerski savjetnik). Analizira i pruža podatke o korištenju resursa i performansama iz pokrenutih spremnika, pružajući Prometheus metriku odmah po izlasku iz kutije. Posebnost ovog alata je da daje podatke samo za zadnjih 60 sekundi. Stoga morate biti u mogućnosti prikupiti te podatke i staviti ih u bazu podataka kako biste mogli pratiti dugoročni proces. Također se može koristiti za grafički prikaz metrike nadzorne ploče pomoću Grafane ili Kibane. Moj blog ima detaljan opis kako koristiti cAdvisor za nadzor spremnika pomoću nadzorne ploče Kibana.
Sljedeći slajd prikazuje kako izgleda krajnja točka Prometheusa i metrika dostupna za prikaz.
Dolje lijevo vidite metriku za HTTP zahtjeve, odgovore itd., desno je njihov grafički prikaz.
Kubernetes također uključuje ugrađene alate za nadzor. Ovaj slajd prikazuje tipični klaster koji sadrži jedan glavni i tri radnička čvora.
Svaki od radnih čvorova sadrži automatski pokrenuti cAdvisor. Osim toga, tu je i Heapster, sustav za praćenje performansi i prikupljanje metričkih podataka kompatibilan s Kubernetes verzijom 1.0.6 i novijim. Heapster vam omogućuje prikupljanje ne samo metrike performansi radnih opterećenja, podova i spremnika, već i događaja i drugih signala koje generira cijeli klaster. Kako bi prikupio podatke, razgovara s Kubeletom svake jedinice, automatski pohranjuje informacije u bazu podataka InfluxDB i šalje ih kao metriku na nadzornu ploču Grafana. Međutim, imajte na umu da ako koristite miniKube, ova značajka nije dostupna prema zadanim postavkama, pa ćete morati koristiti dodatke za nadzor. Dakle, sve ovisi o tome gdje pokrećete spremnike i koje alate za nadzor možete koristiti prema zadanim postavkama, a koje trebate instalirati kao zasebne dodatke.
Sljedeći slajd prikazuje Grafana nadzorne ploče koje prikazuju status rada mojih spremnika. Ovdje ima dosta zanimljivih podataka. Naravno, postoje mnogi komercijalni Docker i Kubernetes alati za praćenje procesa, kao što su SysDig, DataDog, NewRelic. Neki od njih imaju besplatno probno razdoblje od 30 godina pa možete isprobati i pronaći onaj koji vam najviše odgovara. Osobno radije koristim SysDig i NewRelic, koji se dobro integriraju s Kubernetesom. Postoje alati koji se jednako dobro integriraju u Docker i Kubernetes platforme.
Neki oglasi 🙂
Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, , jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o
Izvor: www.habr.com