„Docker Swarm“, „Kubernetes“ ir „Mesos“ yra populiariausi konteinerių orkestravimo sistemos. Savo kalboje Arunas Gupta lygina šiuos Docker, Swarm ir Kubernetes aspektus:
- Vietinė plėtra.
- Diegimo funkcijos.
- Kelių konteinerių programos.
- Paslaugos atradimas.
- Paslaugos mastelio keitimas.
- Vieną kartą vykdomos užduotys.
- Integracija su Maven.
- „Rolling“ atnaujinimas.
- Couchbase duomenų bazės klasterio kūrimas.
Dėl to jūs aiškiai suprasite, ką gali pasiūlyti kiekvienas orkestravimo įrankis, ir išmoksite efektyviai naudoti šias platformas.
Arunas Gupta yra vyriausiasis „Amazon Web Services“ atvirojo kodo produktų technologas, kuris daugiau nei 10 metų kuria „Sun“, „Oracle“, „Red Hat“ ir „Couchbase“ kūrėjų bendruomenes. Turi didelę patirtį dirbant vadovaujančiose tarpfunkcinėse komandose, kuriant ir įgyvendinant rinkodaros kampanijų ir programų strategiją. Jis vadovavo Sun inžinierių komandoms, yra vienas iš Java EE komandos įkūrėjų ir JAV Devoxx4Kids filialo kūrėjas. Arūnas Gupta yra daugiau nei 2 tūkstančių pranešimų IT tinklaraščiuose autorius ir skaitė pranešimus daugiau nei 40 šalių.
55 eilutėje yra COUCHBASE_URI, nukreipiantis į šią duomenų bazės paslaugą, kuri taip pat buvo sukurta naudojant Kubernetes konfigūracijos failą. Jei pažvelgsite į 2 eilutę, pamatysite rūšį: Paslauga yra mano kuriama paslauga, vadinama couchbase-service, o tas pats pavadinimas yra nurodytas 4 eilutėje. Žemiau yra keletas prievadų.
Pagrindinės eilutės yra 6 ir 7. Tarnyboje sakau: „Ei, tai yra etiketės, kurių aš ieškau!“ Ir šios etiketės yra ne kas kita, kaip kintamųjų porų pavadinimai, o 7 eilutė nurodo mano couchbase-rs-pod taikymas. Toliau pateikiami prievadai, suteikiantys prieigą prie tų pačių etikečių.
19 eilutėje sukuriu naujo tipo ReplicaSet, 31 eilutėje yra vaizdo pavadinimas, o 24–27 eilutės nurodo metaduomenis, susietus su mano podeliu. Būtent to paslauga ieško ir prie ko reikia prisijungti. Failo pabaigoje yra tam tikras ryšys tarp 55–56 ir 4 eilučių, sakydamas: „Naudokitės šia paslauga!
Taigi, aš pradedu savo paslaugą, kai yra kopijų rinkinys, ir kadangi kiekvienas kopijų rinkinys turi savo prievadą su atitinkama etikete, jis įtrauktas į paslaugą. Kūrėjo požiūriu, jūs tiesiog paskambinkite tarnybai, kuri tada naudoja jums reikalingų kopijų rinkinį.
Dėl to turiu „WildFly“ priedą, kuris palaiko ryšį su duomenų bazės programa per „Couchbase Service“. Galiu naudoti priekinę dalį su keliais „WildFly“ priedais, kurios taip pat palaiko ryšį su „couchbase“ užpakaline sistema per „couchbase“ paslaugą.
Vėliau apžvelgsime, kaip paslauga, esanti už klasterio, per savo IP adresą bendrauja su elementais, esančiais klasterio viduje ir turinčiais vidinį IP adresą.
Taigi, konteineriai be būsenos yra puikūs, bet ar naudinga naudoti būseną turinčius konteinerius? Pažvelkime į būsenos arba nuolatinių konteinerių sistemos nustatymus. „Docker“ yra 4 skirtingi duomenų saugojimo išdėstymo būdai, į kuriuos turėtumėte atkreipti dėmesį. Pirmasis yra „Implicit Per-Container“, o tai reiškia, kad naudojant „couchbase“, „MySQL“ ar „MyDB“ sateful konteinerius, jie visi prasideda nuo numatytosios smėlio dėžės. Tai yra, viskas, kas saugoma duomenų bazėje, yra saugoma pačiame konteineryje. Jei konteineris dingsta, kartu su juo dingsta ir duomenys.
Antrasis yra „Explicit Per-Container“, kai sukuriate konkrečią saugyklą naudodami komandą „Docker volume create“ ir saugote joje duomenis. Trečiasis „Per-Host“ metodas yra susijęs su saugyklos atvaizdavimu, kai viskas, kas saugoma konteineryje, vienu metu dubliuojama pagrindiniame kompiuteryje. Jei konteineris sugenda, duomenys liks pagrindiniame kompiuteryje. Pastarasis yra kelių „Multi-Host“ kompiuterių naudojimas, o tai patartina įvairių sprendimų gamybos etape. Tarkime, jūsų konteineriai su jūsų programomis veikia pagrindiniame kompiuteryje, bet jūs norite saugoti savo duomenis kur nors internete ir tam naudojate automatinį paskirstytų sistemų atvaizdavimą.
Kiekvienas iš šių metodų naudoja tam tikrą saugojimo vietą. Implicit ir Explicit Per-Container saugo duomenis pagrindiniame kompiuteryje adresu /var/lib/docker/volumes. Naudojant Per-Host metodą, saugykla montuojama konteinerio viduje, o pats konteineris montuojamas ant pagrindinio kompiuterio. Kelių prieglobų atveju galima naudoti tokius sprendimus kaip Ceph, ClusterFS, NFS ir kt.
Jei nuolatinis konteineris sugenda, pirmaisiais dviem atvejais saugyklos katalogas tampa nepasiekiamas, tačiau paskutiniais dviem atvejais prieiga išlieka. Tačiau pirmuoju atveju saugyklą galite pasiekti naudodami „Docker“ pagrindinį kompiuterį, veikiantį virtualioje mašinoje. Antruoju atveju duomenys taip pat nebus prarasti, nes sukūrėte Explicit saugyklą.
Jei priegloba sugenda, pirmaisiais trimis atvejais saugojimo katalogas nepasiekiamas, paskutiniu atveju ryšys su saugykla nenutrūksta. Galiausiai, bendroji funkcija yra visiškai pašalinta iš saugojimo pirmuoju atveju, o likusiu atveju ji yra įmanoma. Antruoju atveju galite bendrinti saugyklą priklausomai nuo to, ar jūsų duomenų bazė palaiko paskirstytą saugyklą, ar ne. Per-Host atveju duomenų paskirstymas galimas tik tam tikrame pagrindiniame kompiuteryje, o daugialypiam kompiuteriui tai užtikrina klasterio išplėtimas.
Į tai reikia atsižvelgti kuriant būsenos talpyklas. Kitas naudingas „Docker“ įrankis yra „Volume“ papildinys, veikiantis principu „baterijos yra, bet turi būti pakeistos“. Kai paleidžiate „Docker“ konteinerį, jis sako: „Ei, kai paleisite konteinerį su duomenų baze, galėsite saugoti savo duomenis šiame konteineryje! Tai yra numatytoji funkcija, bet galite ją pakeisti. Šis papildinys leidžia vietoj konteinerių duomenų bazės naudoti tinklo diską ar kažką panašaus. Ji apima numatytąją pagrindinio kompiuterio saugyklos tvarkyklę ir leidžia integruoti konteinerius su išorinėmis saugojimo sistemomis, tokiomis kaip „Amazon EBS“, „Azure Storage“ ir „GCE Persistent Disk“.
Kitoje skaidrėje parodyta „Docker Volume“ papildinio architektūra.
Mėlyna spalva reiškia „Docker“ klientą, susietą su mėlynu „Docker“ pagrindiniu kompiuteriu, turinčiu vietinį saugojimo variklį, kuris suteikia jums duomenų saugojimo konteinerius. Žalia spalva nurodo įskiepio klientą ir papildinio demoną, kurie taip pat yra prijungti prie pagrindinio kompiuterio. Jie suteikia galimybę saugoti duomenis tokio tipo saugyklos tinklo saugykloje, kurios jums reikia.
„Docker Volume“ papildinį galima naudoti su „Portworx“ saugykla. PX-Dev modulis iš tikrųjų yra jūsų paleistas konteineris, kuris jungiasi prie „Docker“ pagrindinio kompiuterio ir leidžia lengvai saugoti duomenis „Amazon EBS“.
Portworx klientas leidžia stebėti įvairių saugojimo konteinerių, prijungtų prie jūsų pagrindinio kompiuterio, būseną. Jei apsilankysite mano tinklaraštyje, galite perskaityti, kaip išnaudoti visas Portworx galimybes su Docker.
„Kubernetes“ saugyklos sąvoka yra panaši į „Docker“ ir yra vaizduojama kataloguose, kuriuos galima pasiekti jūsų konteineryje. Jie nepriklauso nuo bet kokio konteinerio naudojimo trukmės. Dažniausiai galimi saugyklos tipai yra hostPath, nfs, awsElasticBlockStore ir gsePersistentDisk. Pažiūrėkime, kaip šios parduotuvės veikia Kubernetes. Paprastai jų sujungimo procesas susideda iš 3 žingsnių.
Pirma, kažkas iš tinklo pusės, paprastai administratorius, suteikia jums nuolatinę saugyklą. Tam yra atitinkamas „PersistentVolume“ konfigūracijos failas. Tada programos kūrėjas parašo konfigūracijos failą pavadinimu PersistentVolumeClaim arba PVC saugyklos užklausą, kurioje sakoma: „Turiu 50 GB paskirstytos saugyklos, bet kad kiti žmonės taip pat galėtų išnaudoti jos talpą, sakau šiam PVC, kad šiuo metu reikia tik 10 GB". Galiausiai, trečiasis veiksmas yra tai, kad jūsų užklausa yra įdiegta kaip saugykla, o programa, kurioje yra rinkinys, kopijos ar kažkas panašaus, pradeda ją naudoti. Svarbu atsiminti, kad šis procesas susideda iš 3 minėtų žingsnių ir yra keičiamas.
Kitoje skaidrėje rodomas AWS architektūros „Kubernetes Persistence Container“.
Rudame stačiakampyje, vaizduojančiame Kubernetes klasterį, yra vienas pagrindinis mazgas ir du darbiniai mazgai, pažymėti geltonai. Viename iš darbuotojo mazgų yra oranžinė dėžutė, saugykla, replikos valdiklis ir žalias Docker Couchbase konteineris. Klasterio viduje, virš mazgų, purpurinis stačiakampis rodo, kad paslauga pasiekiama iš išorės. Ši architektūra rekomenduojama duomenims saugoti pačiame įrenginyje. Jei reikia, galiu saugoti savo duomenis EBS už klasterio ribų, kaip parodyta kitoje skaidrėje. Tai yra tipiškas mastelio keitimo modelis, tačiau naudojant jį reikia atsižvelgti į finansinį aspektą – duomenų saugojimas kažkur tinkle gali būti brangesnis nei pagrindiniame kompiuteryje. Renkantis konteinerizavimo sprendimus, tai vienas svarių argumentų.
Kaip ir „Docker“, su „Portworx“ galite naudoti nuolatinius „Kubernetes“ konteinerius.
Tai, kas dabartinėje Kubernetes 1.6 terminologijoje vadinama „StatefulSet“ – tai būdas dirbti su „Stateful“ programomis, kurios apdoroja įvykius, susijusius su „Pod“ sustabdymu ir „Graceful Shutdown“ atlikimu. Mūsų atveju tokios programos yra duomenų bazės. Mano tinklaraštyje galite perskaityti, kaip sukurti „StatefulSet“ „Kubernetes“ naudojant „Portworx“.
Pakalbėkime apie kūrimo aspektą. Kaip jau minėjau, „Docker“ turi dvi versijas – CE ir EE. Pirmoji yra stabili bendruomenės versija, kuri atnaujinama kas tris mėnesius, o ne mėnesinė EE versija. Galite atsisiųsti „Docker for Mac“. Linux arba WindowsĮdiegus „Docker“, jis automatiškai atnaujins save, todėl pradėti jį naudoti labai paprasta.
„Kubernetes“ man labiau patinka „Minikube“ versija – tai geras būdas pradėti dirbti su platforma sukuriant klasterį viename mazge. Norint sukurti kelių mazgų grupes, versijų pasirinkimas yra platesnis: tai kops, kube-aws (CoreOS+AWS), kube-up (pasenusi). Jei norite naudoti AWS pagrįstą „Kubernetes“, rekomenduoju prisijungti prie AWS SIG, kuris kiekvieną penktadienį susitinka internete ir skelbia įvairią įdomią medžiagą apie darbą su AWS Kubernetes.
Pažiūrėkime, kaip šiose platformose vykdomas nuolatinis atnaujinimas. Jei yra kelių mazgų klasteris, tada naudojama konkreti vaizdo versija, pavyzdžiui, WildFly:1. Slenkantis naujinimas reiškia, kad vaizdo versija nuosekliai pakeičiama nauja kiekviename mazge, vienas po kito.
Tam naudoju docker service update komandą (paslaugos pavadinimą), kurioje nurodysiu naują WildFly:2 vaizdo versiją ir atnaujinimo metodą update-parallelism 2. Skaičius 2 reiškia, kad sistema atnaujins 2 programos vaizdus vienu metu, tada 10 sekundžių atnaujinimo delsa 10s, po kurio kiti 2 vaizdai bus atnaujinti dar 2 mazguose ir t.t. Šis paprastas nuolatinio atnaujinimo mechanizmas pateikiamas kaip „Docker“ dalis.
„Kubernetes“ nuolatinis atnaujinimas veikia taip. Replikacijos valdiklis rc sukuria tos pačios versijos kopijų rinkinį, o kiekvienas šios webapp-rc paketas yra su etikete, esančia etcd. Kai man reikia podelio, naudoju Application Service, kad galėčiau pasiekti etcd saugyklą, kuri man pateikia podėlį naudodama nurodytą etiketę.
Šiuo atveju turime 3 blokus replikacijos valdiklyje, kuriame veikia 1 versijos „WildFly“ programa. Atnaujinant fone sukuriamas kitas replikacijos valdiklis su tuo pačiu pavadinimu ir pabaigoje – xxxxx, kur x yra atsitiktiniai skaičiai ir. su tomis pačiomis etiketėmis. Dabar „Application Service“ turi tris priedus su senąja programos versija ir tris blokus su nauja versija naujajame replikacijos valdiklyje. Po to senieji blokai ištrinami, replikacijos valdiklis su naujais blokais pervadinamas ir pradedamas eksploatuoti.
Pereikime prie stebėjimo. „Docker“ turi daug integruotų stebėjimo komandų. Pavyzdžiui, komandinės eilutės sąsaja „docker container stats“ leidžia kas sekundę spausdinti konsolėje duomenis apie konteinerio būseną, įskaitant procesoriaus ir disko naudojimą bei tinklo apkrovą. „Docker Remote API“ įrankis teikia duomenis apie tai, kaip klientas bendrauja su serveriu. Jis naudoja paprastas komandas, tačiau yra pagrįstas „Docker REST API“. Šiuo atveju žodžiai REST, „Flash“ ir „Remote“ reiškia tą patį. Kai bendraujate su pagrindiniu kompiuteriu, tai yra REST API. „Docker Remote API“ leidžia gauti daugiau informacijos apie veikiančius konteinerius. Mano tinklaraščio įraše paaiškinama, kaip naudoti šį stebėjimo įrankį su... Windows Server.
Stebint doko sistemos įvykius, kai vykdomas kelių prieglobų klasteris, galima gauti duomenis apie pagrindinio kompiuterio gedimą arba konteinerio gedimą konkrečiame pagrindiniame kompiuteryje, mastelio keitimo paslaugas ir panašiai. Pradedant nuo „Docker 1.20“, joje yra „Prometheus“, kuris įterpia galutinius taškus į esamas programas. Tai leidžia gauti metrikas per HTTP ir rodyti juos prietaisų skydeliuose.
Kita stebėjimo funkcija yra cAdvisor (konteinerių patarėjas trumpinys). Ji analizuoja ir teikia išteklių naudojimo ir našumo duomenis iš veikiančių konteinerių, pateikdama Prometheus metriką iš karto. Ypatingas šio įrankio bruožas yra tas, kad jis pateikia tik paskutinių 60 sekundžių duomenis. Todėl turite mokėti rinkti šiuos duomenis ir sudėti į duomenų bazę, kad galėtumėte stebėti ilgalaikį procesą. Jis taip pat gali būti naudojamas norint grafiškai rodyti prietaisų skydelio metriką naudojant „Grafana“ arba „Kibana“. Mano tinklaraštyje yra išsamus aprašymas, kaip naudoti „cAdvisor“ konteineriams stebėti naudojant „Kibana“ prietaisų skydelį.
Kitoje skaidrėje parodyta, kaip atrodo Prometheus galutinio taško išvestis ir rodoma metrika.
Apačioje kairėje matote HTTP užklausų, atsakymų ir kt. metriką, dešinėje yra jų grafinis vaizdas.
„Kubernetes“ taip pat turi integruotus stebėjimo įrankius. Šioje skaidrėje rodomas tipiškas klasteris, kuriame yra vienas pagrindinis ir trys darbiniai mazgai.
Kiekviename darbiniame mazge yra automatiškai paleidžiamas cAdvisor. Be to, yra „Heapster“ – našumo stebėjimo ir metrikų rinkimo sistema, suderinama su „Kubernetes“ 1.0.6 ir naujesne versija. „Heapster“ leidžia rinkti ne tik darbo krūvių, rinkinių ir konteinerių našumo metrikas, bet ir įvykius bei kitus signalus, sugeneruotus viso klasterio. Kad rinktų duomenis, jis susisiekia su kiekvieno podėlio Kubelet, automatiškai išsaugo informaciją InfluxDB duomenų bazėje ir išveda ją kaip metriką į Grafana prietaisų skydelį. Tačiau atminkite, kad jei naudojate miniKube, ši funkcija pagal numatytuosius nustatymus nepasiekiama, todėl stebėjimui turėsite naudoti priedus. Taigi viskas priklauso nuo to, kur paleidžiate konteinerius ir kokius stebėjimo įrankius galite naudoti pagal numatytuosius nustatymus ir kuriuos turite įdiegti kaip atskirus priedus.
Kitoje skaidrėje rodomos „Grafana“ prietaisų skydeliai, kuriuose rodoma mano konteinerių veikimo būsena. Čia yra gana daug įdomių duomenų. Žinoma, yra daug komercinių Docker ir Kubernetes procesų stebėjimo įrankių, tokių kaip SysDig, DataDog, NewRelic. Kai kurie iš jų turi 30 metų nemokamą bandomąjį laikotarpį, todėl galite pabandyti ir rasti sau tinkamiausią. Asmeniškai aš norėčiau naudoti SysDig ir NewRelic, kurios gerai integruojasi su Kubernetes. Yra įrankių, kurie vienodai gerai integruojami tiek į Docker, tiek į Kubernetes platformas.
Kai kurie skelbimai 🙂
Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, , unikalus pradinio lygio serverių analogas, kurį mes sugalvojome jums: (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).
„Dell R730xd“ 2 kartus pigiau „Equinix Tier IV“ duomenų centre Amsterdame? Tik čia Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo 99 USD! Skaityti apie
Šaltinis: www.habr.com
