Docker Swarm, Kubernetes ja Mesos on kõige populaarsemad konteinerite orkestreerimisraamistikud. Arun Gupta võrdleb oma kõnes Dockeri, Swarmi ja Kubernetese järgmisi aspekte:
- Kohalik areng.
- Kasutuselevõtu funktsioonid.
- Mitme konteineri rakendused.
- Teenuse avastamine.
- Teenuse skaleerimine.
- Ühekordsed ülesanded.
- Integratsioon Maveniga.
- "Rolling" värskendus.
- Couchbase'i andmebaasi klastri loomine.
Selle tulemusel saate selgelt aru, mida igal orkestreerimistööriistal on pakkuda, ja saate teada, kuidas neid platvorme tõhusalt kasutada.
Arun Gupta on Amazon Web Servicesi avatud lähtekoodiga toodete peatehnoloog, kes on Suni, Oracle'i, Red Hati ja Couchbase'i arendajate kogukondi arendanud üle 10 aasta. Omab laialdast töökogemust erinevate funktsionaalsete meeskondade juhtimisel, kes arendavad ja rakendavad turunduskampaaniate ja -programmide strateegiat. Ta juhtis Suni inseneride meeskondi, on Java EE meeskonna üks asutajatest ja Devoxx4Kidsi USA filiaali looja. Arun Gupta on IT-blogides enam kui 2 tuhande postituse autor ja esinenud enam kui 40 riigis.
Rida 55 sisaldab COUCHBASE_URI, mis osutab sellele andmebaasiteenusele, mis loodi samuti Kubernetese konfiguratsioonifaili abil. Kui vaatate rida 2, näete sellist: Teenus on minu loodud teenus, mille nimi on couchbase-service, ja sama nimi on loetletud real 4. Allpool on mõned pordid.
Võtmeread on 6 ja 7. Teenuses ütlen: "Hei, need on sildid, mida ma otsin!", ja need sildid pole muud kui muutujapaaride nimed ja rida 7 osutab minu couchbase-rs-podile. rakendus. Järgmised pordid pakuvad juurdepääsu samadele siltidele.
Real 19 loon uut tüüpi ReplicaSet, rida 31 sisaldab pildi nime ja read 24-27 osutavad minu podiga seotud metaandmetele. See on täpselt see, mida teenus otsib ja millega tuleks ühendus luua. Faili lõpus on ridade 55-56 ja 4 vahel mingi seos, mis ütleb: "kasuta seda teenust!"
Niisiis, ma käivitan oma teenuse siis, kui on olemas koopiakomplekt ja kuna igal koopiakomplektil on oma port koos vastava märgistusega, on see teenuses kaasatud. Arendaja seisukohast helistate lihtsalt teenusele, mis seejärel kasutab teile vajalikke koopiaid.
Selle tulemusena on mul WildFly pod, mis suhtleb andmebaasi taustaprogrammiga Couchbase Service'i kaudu. Saan kasutada frontendit mitme WildFly podiga, mis suhtleb couchbase'i teenuse kaudu ka couchbase'i taustaprogrammiga.
Hiljem vaatame, kuidas väljaspool klastrit asuv teenus suhtleb oma IP-aadressi kaudu elementidega, mis asuvad klastri sees ja millel on sisemine IP-aadress.
Niisiis, kodakondsuseta konteinerid on suurepärased, kuid kui hea on olekuga konteinereid kasutada? Vaatame olekuga või püsivate konteinerite süsteemiseadeid. Dockeris on andmesalvestuse paigutusel neli erinevat lähenemisviisi, millele peaksite tähelepanu pöörama. Esimene on Implicit Per-Container, mis tähendab, et kui kasutada couchbase'i, MySQL-i või MyDB satateful konteinereid, algavad need kõik vaikimisi liivakastist. See tähendab, et kõik, mis on andmebaasis salvestatud, salvestatakse konteinerisse endasse. Kui konteiner kaob, kaovad koos sellega ka andmed.
Teine on Explicit Per-Container, kui loote dockeri helitugevuse loomise käsuga konkreetse salvestusruumi ja talletate sellesse andmeid. Kolmas hostipõhine lähenemine on seotud salvestusruumi kaardistamisega, kui kõik konteinerisse salvestatud andmed dubleeritakse samaaegselt hostis. Kui konteiner ebaõnnestub, jäävad andmed hosti. Viimane on mitme Multi-Host hosti kasutamine, mis on soovitatav erinevate lahenduste tootmisetapis. Oletame, et teie konteinerid teie rakendustega töötavad hostis, kuid soovite salvestada oma andmed kuhugi Internetti ja selleks kasutate hajutatud süsteemide automaatset kaardistamist.
Kõik need meetodid kasutavad kindlat salvestuskohta. Kaudne ja selgesõnaline konteineripõhine salvestab andmeid hostis aadressil /var/lib/docker/volumes. Per-Host meetodi kasutamisel paigaldatakse salvestusruum konteineri sisse ja konteiner ise hosti külge. Mitme hosti puhul saab kasutada selliseid lahendusi nagu Ceph, ClusterFS, NFS jne.
Kui püsikonteiner ebaõnnestub, muutub salvestuskataloog kahel esimesel juhul ligipääsmatuks, kuid kahel viimasel juhul juurdepääs säilib. Kuid esimesel juhul pääsete hoidlale ligi virtuaalmasinas töötava Dockeri hosti kaudu. Teisel juhul ei lähe andmed kaotsi, kuna olete loonud Explicit salvestusruumi.
Kui host ebaõnnestub, pole salvestuskataloog esimesel kolmel juhul saadaval, viimasel juhul ühendus salvestusruumiga ei katke. Lõpuks on jagatud funktsioon salvestamiseks esimesel juhul täielikult välistatud ja ülejäänud puhul on see võimalik. Teisel juhul saate salvestusruumi jagada olenevalt sellest, kas teie andmebaas toetab hajutatud salvestusruumi või mitte. Per-Host puhul on andmete levitamine võimalik ainult antud hostis ja mitme hosti puhul tagab selle klastri laiendamine.
Seda tuleks olekuga konteinerite loomisel arvesse võtta. Veel üks kasulik Dockeri tööriist on Volume'i pistikprogramm, mis töötab põhimõttel "patareid on olemas, kuid need tuleb välja vahetada". Kui käivitate Dockeri konteineri, ütleb see: "Hei, kui käivitate andmebaasiga konteineri, saate oma andmed sellesse konteinerisse salvestada!" See on vaikefunktsioon, kuid saate seda muuta. See pistikprogramm võimaldab konteineri andmebaasi asemel kasutada võrgudraivi või midagi sarnast. See sisaldab hostipõhise salvestusruumi vaikedraiverit ja võimaldab konteinerite integreerimist väliste salvestussüsteemidega, nagu Amazon EBS, Azure Storage ja GCE püsivad kettad.
Järgmine slaid näitab Docker Volume'i pistikprogrammi arhitektuuri.
Sinine värv tähistab Dockeri klienti, mis on seotud sinise Dockeri hostiga, millel on kohalik salvestusmootor, mis pakub teile andmete salvestamiseks konteinereid. Roheline tähistab Plugin Client ja Plugin Deemon, mis on samuti ühendatud hostiga. Need annavad võimaluse salvestada andmeid vajaliku salvestusruumi taustasüsteemi tüüpi võrgumällu.
Docker Volume'i pistikprogrammi saab kasutada koos Portworxi salvestusruumiga. PX-Dev moodul on tegelikult teie käitatav konteiner, mis ühendub teie Dockeri hostiga ja võimaldab teil hõlpsasti andmeid Amazon EBS-is salvestada.
Portworxi klient võimaldab teil jälgida erinevate teie hostiga ühendatud salvestuskonteinerite olekut. Kui külastate minu ajaveebi, saate lugeda, kuidas Portworxi Dockeriga maksimaalselt ära kasutada.
Kubernetese salvestuskontseptsioon sarnaneb Dockeriga ja seda esindavad kataloogid, millele pääseb juurde teie konteinerisse kaustas. Need ei sõltu ühegi konteineri elueast. Levinuimad saadaolevad salvestustüübid on hostPath, nfs, awsElasticBlockStore ja gsePersistentDisk. Vaatame, kuidas need poed Kubernetesis töötavad. Tavaliselt koosneb nende ühendamise protsess 3 etapist.
Esimene on see, et keegi võrgu poolel, tavaliselt administraator, pakub teile püsivat salvestusruumi. Selle jaoks on olemas vastav PersistentVolume konfiguratsioonifail. Järgmiseks kirjutab rakenduse arendaja konfiguratsioonifaili nimega PersistentVolumeClaim ehk PVC-salvestustaotluse, mis ütleb: „Mul on 50 GB hajutatud salvestusruumi, kuid et ka teised inimesed saaksid selle mahtu kasutada, ütlen sellele PVC-le, et ma praegu vaja ainult 10 GB". Lõpuks, kolmas samm on see, et teie taotlus ühendatakse salvestusruumina ja rakendus, millel on pod, koopiakomplekt või midagi sarnast, hakkab seda kasutama. Oluline on meeles pidada, et see protsess koosneb kolmest mainitud etapist ja on skaleeritav.
Järgmine slaid näitab AWS-i arhitektuuri Kubernetese püsivuskonteinerit.
Kubernetese klastrit tähistava pruuni ristküliku sees on üks põhisõlm ja kaks töötaja sõlme, mis on tähistatud kollasega. Üks töötaja sõlmedest sisaldab oranži kausta, salvestusruumi, koopiakontrollerit ja rohelist Docker Couchbase'i konteinerit. Klastris, sõlmede kohal, näitab lilla ristkülik väljastpoolt ligipääsetavat teenust. Seda arhitektuuri soovitatakse andmete salvestamiseks seadmesse endasse. Vajadusel saan salvestada oma andmed EBS-is väljaspool klastrit, nagu on näidatud järgmisel slaidil. See on tüüpiline skaleerimise mudel, kuid selle kasutamisel tuleb arvestada ka rahalise aspektiga – andmete salvestamine kuskile võrku võib olla kallim kui hostis. Konteinerilahenduste valikul on see üks kaalukaid argumente.
Nii nagu Dockeri puhul, saate ka Portworxiga kasutada püsivaid Kubernetese konteinereid.
Seda nimetatakse praeguses Kubernetes 1.6 terminoloogias "StatefulSetiks" – olekuga rakendustega töötamise viis, mis töötleb Podi peatamise ja Graceful Shutdowni teostamisega seotud sündmusi. Meie puhul on sellisteks rakendusteks andmebaasid. Minu ajaveebis saate lugeda, kuidas luua Portworxi abil Kubernetesis StatefulSet.
Räägime arengu aspektist. Nagu ma ütlesin, on Dockeril 2 versiooni - CE ja EE, esimesel juhul räägime Community Editioni stabiilsest versioonist, mida uuendatakse kord 3 kuu jooksul, erinevalt igakuiselt uuendatavast EE versioonist. Saate alla laadida Dockeri Maci, Linuxi või Windowsi jaoks. Pärast installimist värskendatakse Dockerit automaatselt ja seda on väga lihtne alustada.
Kubernetese jaoks eelistan Minikube'i versiooni – see on hea viis platvormiga alustamiseks, luues ühele sõlmele klastri. Mitme sõlme klastrite loomiseks on versioonide valik laiem: need on kops, kube-aws (CoreOS+AWS), kube-up (aegunud). Kui soovite kasutada AWS-põhist Kubernetesi, soovitan liituda AWS SIG-ga, mis kohtub veebis igal reedel ja avaldab mitmesuguseid huvitavaid materjale AWS Kubernetesiga töötamise kohta.
Vaatame, kuidas Rolling Update nendel platvormidel toimub. Kui on mitmest sõlmest koosnev klaster, kasutab see pildi konkreetset versiooni, näiteks WildFly:1. Jooksev värskendus tähendab, et pildiversioon asendatakse igas sõlmes üksteise järel järjestikku uuega.
Selleks kasutan docker service update käsku (teenuse nimi), milles määran WildFly:2 pildi uue versiooni ja uuendusmeetodi update-parallelism 2. Number 2 tähendab, et süsteem uuendab 2 rakenduse pilti samaaegselt, siis 10-sekundiline uuendusviivitus 10s, mille järel uuendatakse 2 järgmist pilti veel 2 sõlmel jne. Seda lihtsat jooksvat värskendusmehhanismi pakutakse teile Dockeri osana.
Kubernetesis töötab jooksev värskendus nii. Replikatsioonikontroller rc loob sama versiooni koopiate komplekti ja iga selle webapp-rc pod on varustatud sildiga, mis asub failis etcd. Kui mul on vaja podi, kasutan rakendusteenust, et pääseda juurde etcd hoidlasse, mis pakub mulle määratud silti kasutades podi.
Sel juhul on meil WildFly versiooni 3 rakendust jooksutavas replikatsioonikontrolleris 1 podi. Taustal värskendamisel luuakse teine replikatsioonikontroller sama nime ja indeksiga lõpus - - xxxxx, kus x on juhuslikud arvud ja samade siltidega. Nüüd on Application Service'il kolm kausta rakenduse vana versiooniga ja kolm kausta uue versiooniga uues replikatsioonikontrolleris. Pärast seda vanad kaustad kustutatakse, replikatsioonikontroller koos uute kaustadega nimetatakse ümber ja pannakse tööle.
Liigume edasi jälgimise juurde. Dockeril on palju sisseehitatud jälgimiskäske. Näiteks Dockeri konteineri statistika käsurealiides võimaldab kuvada iga sekundi järel konsooli infot konteinerite oleku kohta – protsessori kasutus, kettakasutus, võrgu koormus. Docker Remote API tööriist pakub andmeid selle kohta, kuidas klient suhtleb serveriga. See kasutab lihtsaid käske, kuid põhineb Dockeri REST API-l. Sel juhul tähendavad sõnad REST, Flash, Remote sama asja. Kui suhtlete hostiga, on see REST API. Docker Remote API võimaldab teil saada rohkem teavet konteinerite käitamise kohta. Minu ajaveebis kirjeldatakse selle jälgimise üksikasju Windows Serveriga.
Dockeri süsteemi sündmuste jälgimine mitme hosti klastri käitamisel võimaldab hankida andmeid konkreetse hosti masina krahhi või konteineri krahhi, skaleerimisteenuste ja muu sarnase kohta. Alates versioonist Docker 1.20 sisaldab see Prometheust, mis manustab lõpp-punktid olemasolevatesse rakendustesse. See võimaldab teil HTTP kaudu mõõdikuid vastu võtta ja neid armatuurlaudadel kuvada.
Teine jälgimisfunktsioon on cAdvisor (lühend sõnadest konteinerinõustaja). See analüüsib ja pakub töötavate konteinerite ressursside kasutus- ja jõudlusandmeid, pakkudes Prometheuse mõõdikuid kohe karbist välja. Selle tööriista eripära on see, et see annab andmeid ainult viimase 60 sekundi kohta. Seetõttu peate suutma neid andmeid koguda ja andmebaasi panna, et saaksite jälgida pikaajalist protsessi. Seda saab kasutada ka armatuurlaua mõõdikute graafiliseks kuvamiseks Grafana või Kibana abil. Minu blogis on üksikasjalik kirjeldus selle kohta, kuidas kasutada cAdvisorit konteinerite jälgimiseks Kibana armatuurlaua abil.
Järgmine slaid näitab, kuidas Prometheuse lõpp-punkti väljund välja näeb ja kuvamiseks saadaolevaid mõõdikuid.
Vasakpoolses allnurgas näete HTTP-päringute, vastuste jms mõõdikuid, paremal on nende graafiline kuva.
Kubernetes sisaldab ka sisseehitatud jälgimistööriistu. See slaid näitab tüüpilist klastrit, mis sisaldab ühte juht- ja kolme töösõlme.
Iga töösõlm sisaldab automaatselt käivitatavat cAdvisorit. Lisaks on olemas Heapster, jõudluse jälgimise ja mõõdikute kogumise süsteem, mis ühildub Kubernetese versiooniga 1.0.6 ja uuemate versioonidega. Heapster võimaldab teil koguda mitte ainult töökoormuste, kaustade ja konteinerite jõudlusmõõdikuid, vaid ka kogu klastri genereeritud sündmusi ja muid signaale. Andmete kogumiseks suhtleb see iga kausta Kubeletiga, salvestab teabe automaatselt InfluxDB andmebaasi ja väljastab selle mõõdikutena Grafana armatuurlauale. Kuid pidage meeles, et kui kasutate miniKube'i, pole see funktsioon vaikimisi saadaval, seega peate jälgimiseks kasutama lisandmooduleid. Seega oleneb kõik sellest, kus konteinereid kasutate ja milliseid jälgimistööriistu saate vaikimisi kasutada ning millised on vaja eraldi lisandmoodulitena installida.
Järgmisel slaidil kuvatakse Grafana armatuurlauad, mis näitavad minu konteinerite tööolekut. Siin on päris palju huvitavaid andmeid. Muidugi on palju kaubanduslikke Dockeri ja Kubernetese protsesside jälgimise tööriistu, nagu SysDig, DataDog, NewRelic. Mõnel neist on 30-aastane tasuta prooviperiood, nii et saate proovida ja leida endale sobivaima. Isiklikult eelistan kasutada SysDigi ja NewRelicit, mis integreeruvad hästi Kubernetesiga. On tööriistu, mis integreeruvad võrdselt hästi nii Dockeri kui ka Kubernetese platvormidega.
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com