Docker Swarm, Kubernetes kaj Mesos estas la plej popularaj uj-instrumentadkadroj. En sia parolado, Arun Gupta komparas la sekvajn aspektojn de Docker, Swarm, kaj Kubernetes:
- Loka evoluo.
- Funkcioj de deplojo.
- Plurujo-aplikoj.
- Servo-malkovro.
- Skali la servon.
- Kuru-unufoje taskoj.
- Integriĝo kun Maven.
- "Ruliĝanta" ĝisdatigo.
- Kreante datumbazan areton de Couchbase.
Kiel rezulto, vi akiros klaran komprenon pri tio, kion ĉiu orkestra ilo devas oferti kaj lernos kiel uzi ĉi tiujn platformojn efike.
Arun Gupta estas la ĉefa teknologo por malfermfontaj produktoj ĉe Amazon Web Services, kiu disvolvis la programkomunumojn Sun, Oracle, Red Hat kaj Couchbase dum pli ol 10 jaroj. Havas ampleksan sperton laborante en gvidado de transfunkciaj teamoj evoluantaj kaj efektivigante strategion por merkataj kampanjoj kaj programoj. Li gvidis teamojn de Sun-inĝenieroj, estas unu el la fondintoj de la teamo Java EE kaj la kreinto de la usona branĉo de Devoxx4Kids. Arun Gupta estas aŭtoro de pli ol 2 mil afiŝoj en IT-blogoj kaj faris prelegojn en pli ol 40 landoj.
Linio 55 enhavas COUCHBASE_URI montrantan ĉi tiun datumbazan servon, kiu ankaŭ estis kreita per la agorda dosiero de Kubernetes. Se vi rigardas linion 2, vi povas vidi afablan: Servo estas la servo, kiun mi kreas, nomata couchbase-service, kaj la sama nomo estas listigita sur linio 4. Malsupre estas kelkaj havenoj.
La ŝlosilaj linioj estas 6 kaj 7. En servo mi diras: "He, ĉi tiuj estas la etikedoj, kiujn mi serĉas!", kaj ĉi tiuj etikedoj estas nenio pli ol ŝanĝiĝemaj parnomoj, kaj linio 7 montras al mia couchbase-rs-pod. aplikaĵo. La jenaj estas la havenoj kiuj disponigas aliron al ĉi tiuj samaj etikedoj.
Sur linio 19 mi kreas novan tipon ReplicaSet, linio 31 enhavas la nomon de la bildo, kaj linioj 24-27 montras al la metadatenoj asociitaj kun mia pod. Ĝuste ĉi tio serĉas la servon kaj al kio oni devas fari la konekton. Ĉe la fino de la dosiero estas ia konekto inter linioj 55-56 kaj 4, dirante: "uzu ĉi tiun servon!"
Do, mi komencas mian servon kiam ekzistas kopiaro, kaj ĉar ĉiu kopiaro havas sian propran havenon kun la responda etikedo, ĝi estas inkluzivita en la servo. El la vidpunkto de programisto, vi simple vokas la servon, kiu tiam uzas la aron de kopioj, kiujn vi bezonas.
Kiel rezulto, mi havas WildFly pod kiu komunikas kun la datumbaza backend per Couchbase Servo. Mi povas uzi la fasadon kun pluraj WildFly pods, kiu ankaŭ komunikas kun la couchbase backend per la couchbase servo.
Poste ni rigardos kiel servo situanta ekster la areto komunikas per sia IP-adreso kun elementoj, kiuj situas ene de la areto kaj havas internan IP-adreson.
Do, sennaciaj ujoj estas bonegaj, sed kiom bone estas uzi ŝtatajn ujojn? Ni rigardu la sistemajn agordojn por ŝtataj aŭ konstantaj ujoj. En Docker, ekzistas 4 malsamaj aliroj al datuma stokado-aranĝo, kiujn vi devus atenti. La unua estas Implicit Per-Container, kio signifas, ke kiam oni uzas couchbase, MySQL aŭ MyDB-stateplenajn ujojn, ili ĉiuj komenciĝas per la defaŭlta Sandbox. Tio estas, ĉio, kio estas konservita en la datumbazo, estas konservita en la ujo mem. Se la ujo malaperas, la datumoj malaperas kune kun ĝi.
La dua estas Eksplicita Per-Ujo, kiam vi kreas specifan stokadon per la docker-volumo, kreu komandon kaj konservu datumojn en ĝi. La tria Per-Gastiga aliro estas rilata al stokadmapado, kiam ĉio stokita en la ujo estas samtempe duobligita sur la gastiganto. Se la ujo malsukcesas, la datumoj restos sur la gastiganto. Ĉi-lasta estas la uzo de pluraj Multi-Host-gastigantoj, kio estas rekomendinda en la produktadstadio de diversaj solvoj. Ni diru, ke viaj ujoj kun viaj aplikaĵoj funkcias en la gastiganto, sed vi volas konservi viajn datumojn ie en la Interreto, kaj por tio vi uzas aŭtomatan mapadon por distribuitaj sistemoj.
Ĉiu el ĉi tiuj metodoj uzas specifan stokan lokon. Implicaj kaj Eksplicitaj Per-Ujo stokas datumojn pri la gastiganto ĉe /var/lib/docker/volumes. Kiam oni uzas la Per-Gastigan metodon, la stokado estas muntita ene de la ujo, kaj la ujo mem estas muntita sur la gastiganto. Por multgastigantoj, solvoj kiel Ceph, ClusterFS, NFS, ktp.
Se persista ujo malsukcesas, la stoka dosierujo fariĝas nealirebla en la unuaj du kazoj, sed en la lastaj du kazoj aliro estas konservita. Tamen, en la unua kazo, vi povas aliri la deponejon per Docker-gastiganto funkcianta sur virtuala maŝino. En la dua kazo, la datumoj ankaŭ ne estos perditaj, ĉar vi kreis Eksplicitan stokadon.
Se la gastiganto malsukcesas, la stokado dosierujo estas neatingebla en la unuaj tri kazoj; en la lasta kazo, la ligo kun la stokado ne estas interrompita. Fine, la komuna funkcio estas tute ekskludita por stokado en la unua kazo kaj eblas en la resto. En la dua kazo, vi povas dividi stokadon depende de ĉu via datumbazo subtenas distribuitan stokadon aŭ ne. En la kazo de Per-Gastiganto, datumdistribuo estas ebla nur sur antaŭfiksita gastiganto, kaj por multigastiganto ĝi estas disponigita per aretvastigo.
Ĉi tio estu konsiderata dum kreado de ŝtataj ujoj. Alia utila Docker-ilo estas la Volumo-kromaĵo, kiu funkcias laŭ la principo de "ĉeestantaj kuirilaroj, sed devas esti anstataŭigita." Kiam vi lanĉas Docker-ujon, ĝi diras: "He, kiam vi komencas ujon kun datumbazo, vi povas konservi viajn datumojn en ĉi tiu ujo!" Ĉi tio estas la defaŭlta funkcio, sed vi povas ŝanĝi ĝin. Ĉi tiu kromaĵo permesas uzi retan diskon aŭ ion similan anstataŭ ujan datumbazon. Ĝi inkluzivas defaŭltan ŝoforon por gastiganto-bazita stokado kaj permesas konteneran integriĝon kun eksteraj stokadsistemoj kiel Amazon EBS, Azure Storage kaj GCE Persistent-diskoj.
La sekva diapozitivo montras la arkitekturon de la kromaĵo Docker Volume.
La blua koloro reprezentas la Docker-klienton asociitan kun la blua Docker-gastiganto, kiu havas Lokan stokan motoron, kiu provizas al vi ujojn por stoki datumojn. Verda indikas la Kromprogramon-Kliento kaj Kromprogramo-Demono, kiuj ankaŭ estas konektitaj al la gastiganto. Ili donas la ŝancon stoki datumojn en retstokado de la speco de Stokado Backend, kiun vi bezonas.
La Docker Volume kromaĵo povas esti uzata kun Portworx-stokado. La modulo PX-Dev estas fakte ujo, kiun vi kuras, kiu konektas al via Docker-gastiganto kaj permesas vin facile stoki datumojn sur Amazon EBS.
La Portworx-kliento permesas vin kontroli la staton de diversaj stokujoj, kiuj estas konektitaj al via gastiganto. Se vi vizitas mian blogon, vi povas legi kiel utiligi Portworx kun Docker.
La koncepto de stokado en Kubernetes similas al Docker kaj estas reprezentita per dosierujoj, kiuj estas alireblaj por via ujo en pod. Ili estas sendependaj de la vivdaŭro de iu ajn ujo. La plej oftaj stokaj tipoj disponeblaj estas hostPath, nfs, awsElasticBlockStore kaj gsePersistentDisk. Ni rigardu kiel ĉi tiuj vendejoj funkcias en Kubernetes. Tipe, la procezo de ligado de ili konsistas el 3 paŝoj.
La unua estas, ke iu ĉe la reto, kutime administranto, provizas vin per konstanta stokado. Estas responda agorda dosiero de PersistentVolume por ĉi tio. Poste, la programisto de la aplikaĵo skribas agordan dosieron nomatan PersistentVolumeClaim, aŭ PVC-stokado-peto, kiu diras: "Mi havas 50GB da distribuata stokado provizitaj, sed por ke aliaj homoj ankaŭ uzu ĝian kapaciton, mi diras al ĉi tiu PVC, ke mi nuntempe. bezonas nur 10 GB". Fine, la tria paŝo estas, ke via peto estas muntita kiel stokado, kaj la aplikaĵo, kiu havas la pod, aŭ kopian aron, aŭ ion similan, komencas uzi ĝin. Gravas memori, ke ĉi tiu procezo konsistas el la 3 paŝoj menciitaj kaj estas skalebla.
La sekva diapozitivo montras la Kubernetes Persistence Container de la AWS-arkitekturo.
Ene de la bruna rektangulo, kiu reprezentas la Kubernetes-areton, estas unu majstra nodo kaj du labornodoj, indikitaj flava. Unu el la labornodoj enhavas oranĝan balgon, stokadon, kopiregilon, kaj verdan Docker Couchbase-ujon. Ene de la areto, super la nodoj, purpura rektangulo indikas la Servon alirebla de ekstere. Ĉi tiu arkitekturo estas rekomendita por stoki datumojn sur la aparato mem. Se necese, mi povas konservi miajn datumojn en EBS ekster la areto, kiel montrite en la sekva diapozitivo. Ĉi tio estas tipa modelo por skalo, sed estas financa aspekto por konsideri kiam oni uzas ĝin - stoki datumojn ie en la reto povas esti pli multekosta ol ĉe gastiganto. Kiam vi elektas kontenerigajn solvojn, ĉi tiu estas unu el la pezaj argumentoj.
Same kiel kun Docker, vi povas uzi konstantajn ujojn de Kubernetes kun Portworx.
Jen tio, kion en nuna Kubernetes 1.6 terminologio nomiĝas "StatefulSet" - maniero labori kun Stateful-aplikoj, kiu prilaboras eventojn pri haltigo de la Pod kaj plenumi Graceful Shutdown. En nia kazo, tiaj aplikoj estas datumbazoj. En mia blogo vi povas legi kiel krei StatefulSet en Kubernetes uzante Portworx.
Ni parolu pri la evolua aspekto. Kiel mi diris, Docker havas 2 versiojn - CE kaj EE, en la unua kazo ni parolas pri stabila versio de la Komunuma Eldono, kiu estas ĝisdatigita unufoje ĉiun 3 monatojn, kontraste al la monata ĝisdatigita versio de EE. Vi povas elŝuti Docker por Mac, Linukso aŭ Vindozo. Post instalite, Docker aŭtomate ĝisdatigos kaj estas tre facile komenci.
Por Kubernetes, mi preferas la Minikube-version - ĝi estas bona maniero komenci kun la platformo kreante areton sur ununura nodo. Por krei aretojn de pluraj nodoj, la elekto de versioj estas pli larĝa: ĉi tiuj estas kops, kube-aws (CoreOS+AWS), kube-up (malmoderna). Se vi serĉas uzi Kubernetes bazitan en AWS, mi rekomendas aliĝi al la AWS SIG, kiu kunvenas interrete ĉiun vendredon kaj publikigas diversajn interesajn materialojn pri laboro kun AWS Kubernetes.
Ni rigardu kiel Rolling Update estas farita sur ĉi tiuj platformoj. Se estas aro de pluraj nodoj, tiam ĝi uzas specifan version de la bildo, ekzemple WildFly:1. Ruliĝanta ĝisdatigo signifas, ke la bildoversio estas sinsekve anstataŭigita per nova sur ĉiu nodo, unu post la alia.
Por fari tion, mi uzas la docker-servan ĝisdatig-komandon (servonomo), en kiu mi specifas la novan version de la bildo WildFly:2 kaj la ĝisdatigmetodo ĝisdatigo-paralelismo 2. La numero 2 signifas, ke la sistemo ĝisdatigos 2 aplikajn bildojn. samtempe, tiam 10-sekunda ĝisdatigo prokrasto 10s, post kiu la sekvaj 2 bildoj estos ĝisdatigitaj sur 2 pliaj nodoj, ktp. Ĉi tiu simpla ruliĝanta ĝisdatiga mekanismo estas provizita al vi kiel parto de Docker.
En Kubernetes, ruliĝanta ĝisdatigo funkcias tiel. La replika regilo rc kreas aron da kopioj de la sama versio, kaj ĉiu pod en ĉi tiu webapp-rc estas provizita per etikedo situanta en etcd. Kiam mi bezonas pod, mi uzas la Aplikservon por aliri la etcd-deponejon, kiu provizas al mi la pod per la specifita etikedo.
En ĉi tiu kazo, ni havas 3 podojn en la Replica regilo kurante la WildFly-versio-aplikaĵon 1. Dum ĝisdatigo en la fono, alia replika regilo estas kreita kun la sama nomo kaj indekso ĉe la fino - - xxxxx, kie x estas hazardaj nombroj, kaj kun la samaj etikedoj. Nun Aplika Servo havas tri podojn kun la malnova versio de la aplikaĵo kaj tri podojn kun la nova versio en la nova Replica regilo. Post tio, la malnovaj podoj estas forigitaj, la replika regilo kun la novaj podoj estas renomita kaj metita en funkciado.
Ni transiru al monitorado. Docker havas multajn enkonstruitajn monitorajn komandojn. Ekzemple, la docker-ujo statistika komandlinia interfaco permesas vin montri informojn pri la stato de ujoj al la konzolo ĉiun sekundon - uzado de procesoro, uzado de disko, reta ŝarĝo. La Docker Remote API-ilo provizas datumojn pri kiel la kliento komunikas kun la servilo. Ĝi uzas simplajn komandojn, sed baziĝas sur la Docker REST API. En ĉi tiu kazo, la vortoj REST, Flash, Remote signifas la samon. Kiam vi komunikas kun la gastiganto, ĝi estas REST API. La Docker Remote API permesas vin akiri pliajn informojn pri funkciado de ujoj. Mia blogo skizas la detalojn pri uzado de ĉi tiu monitorado kun Windows Server.
Monitorado de docker-sistemo-okazaĵoj dum funkciado de mult-gastiga areto ebligas akiri datumojn pri gastiga kraŝo aŭ kontenera kraŝo sur specifa gastiganto, skalado de servoj kaj similaj. Komencante kun Docker 1.20, ĝi inkluzivas Prometheus, kiu enigas finpunktojn en ekzistantajn aplikojn. Ĉi tio permesas vin ricevi metrikojn per HTTP kaj montri ilin sur paneloj.
Alia monitora funkcio estas cAdvisor (mallongigo de kontenera konsilisto). Ĝi analizas kaj provizas datumojn pri uzado de rimedoj kaj rendimento de ujoj, provizante Prometheus-metrikojn tuj el la skatolo. La speciala afero pri ĉi tiu ilo estas, ke ĝi nur provizas datumojn por la lastaj 60 sekundoj. Sekve, vi devas povi kolekti ĉi tiujn datumojn kaj meti ĝin en datumbazon por ke vi povu monitori longtempan procezon. Ĝi ankaŭ povas esti uzata por montri grafike instrumentajn metrikojn uzante Grafana aŭ Kibana. Mia blogo havas detalan priskribon pri kiel uzi cAdvisor por kontroli ujojn per la panelo de Kibana.
La sekva diapozitivo montras kiel aspektas la eligo de Prometheus-finpunkto kaj la metrikoj disponeblaj por montri.
Maldekstre malsupre vi vidas metrikojn por HTTP-petoj, respondoj ktp., dekstre estas ilia grafika ekrano.
Kubernetes ankaŭ inkluzivas enkonstruitajn monitorajn ilojn. Ĉi tiu lumbildo montras tipan areton enhavantan unu majstran kaj tri labornodojn.
Ĉiu el la labornodoj enhavas aŭtomate lanĉitan cAdvisor. Krome, ekzistas Heapster, agado-monitorado kaj kalkulsistemo kongrua kun Kubernetes versio 1.0.6 kaj pli. Heapster ebligas vin kolekti ne nur rendimentajn metrikojn de laborkvantoj, podoj kaj ujoj, sed ankaŭ eventojn kaj aliajn signalojn generitaj de la tuta areto. Por kolekti datumojn, ĝi parolas kun la Kubelet de ĉiu pod, aŭtomate stokas la informojn en la datumbazo InfluxDB kaj eligas ĝin kiel metrikon al la Grafana panelo. Tamen, memoru, ke se vi uzas miniKube, ĉi tiu funkcio ne estas disponebla defaŭlte, do vi devos uzi aldonaĵojn por monitorado. Do ĉio dependas de kie vi kuras la ujojn kaj kiujn monitorajn ilojn vi povas uzi defaŭlte kaj kiujn vi devas instali kiel apartajn aldonaĵojn.
La sekva diapozitivo montras Grafana panelojn kiuj montras la funkciantan staton de miaj ujoj. Estas sufiĉe multe da interesaj datumoj ĉi tie. Kompreneble, ekzistas multaj komercaj iloj pri monitorado de procezoj de Docker kaj Kubernetes, kiel SysDig, DataDog, NewRelic. Kelkaj el ili havas 30-jaran senpagan provperiodon, do vi povas provi trovi tiun, kiu plej konvenas al vi. Persone, mi preferas uzi SysDig kaj NewRelic, kiuj bone integriĝas kun Kubernetes. Estas iloj, kiuj egale bone integriĝas en ambaŭ platformojn Docker kaj Kubernetes.
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com