Docker Swarm, Kubernetes eta Mesos dira edukiontzien orkestrazio esparru ezagunenak. Bere hitzaldian, Arun Guptak Docker, Swarm eta Kubernetes-en alderdi hauek alderatzen ditu:
- Tokiko garapena.
- Inplementazio-funtzioak.
- Edukiontzi anitzeko aplikazioak.
- Zerbitzuaren aurkikuntza.
- Zerbitzua eskalatzea.
- Exekutatu behin-behineko zereginak.
- Maven-ekin integratzea.
- "Ibilgarri" eguneratzea.
- Couchbase datu-baseen kluster bat sortzea.
Ondorioz, orkestrazio tresna bakoitzak zer eskaintzen duen argi ulertuko duzu eta plataforma hauek modu eraginkorrean erabiltzen ikasiko duzu.
Arun Gupta Amazon Web Services-en kode irekiko produktuen teknologo nagusia da, Sun, Oracle, Red Hat eta Couchbase garatzaileen komunitateak garatzen aritu dena 10 urte baino gehiagoz. Esperientzia handia du funtzio gurutzatuen taldeen lidergoan lanean, marketin-kanpainak eta programetarako estrategia garatzen eta ezartzen. Sun ingeniarien taldeak zuzendu zituen, Java EE taldearen sortzaileetako bat da eta AEBetako Devoxx4Kids-en adarraren sortzailea. Arun Gupta informatikako blogetan 2 mila mezu baino gehiagoren egilea da eta 40 herrialde baino gehiagotan eman ditu hitzaldiak.
55. lerroak datu-base-zerbitzu hau seinalatzen duen COUCHASE_URI bat dauka, Kubernetes konfigurazio fitxategia erabiliz ere sortu zena. 2. lerroan begiratuz gero, mota ikus dezakezu: Zerbitzua sortzen ari naizen zerbitzua da, couchbase-service izenekoa, eta izen bera 4. lerroan ageri da. Jarraian portu batzuk daude.
Gako-lerroak 6 eta 7 dira. Zerbitzuan esaten dut: "Aizu, hauek dira bilatzen ari naizen etiketak!", eta etiketa hauek bikote aldagaien izenak baino ez dira, eta 7. lerroak nire couchbase-rs-pod-era seinalatzen du. aplikazio. Honako hauek dira etiketa horietarako sarbidea ematen duten atakak.
19. lerroan ReplicaSet mota berri bat sortzen dut, 31. lerroak irudiaren izena dauka eta 24-27 lerroek nire podarekin lotutako metadatuak adierazten dituzte. Horixe da zerbitzuaren bila ari dena eta zer konexio egin behar den. Fitxategiaren amaieran nolabaiteko konexioa dago 55-56 eta 4. lerroen artean, esaten duena: βerabil ezazu zerbitzu hau!β.
Beraz, erreplika multzo bat dagoenean hasten dut nire zerbitzua, eta erreplika multzo bakoitzak dagokion etiketa duen ataka propioa duenez, zerbitzuan sartzen da. Garatzaile baten ikuspuntutik, zerbitzura deitu besterik ez duzu, eta, ondoren, behar duzun erreplika multzoa erabiltzen du.
Ondorioz, Couchbase Zerbitzuaren bidez datu-basearen backendarekin komunikatzen den WildFly pod bat daukat. Frontend-a hainbat WildFly podrekin erabil dezaket, eta hori ere couchbase backendarekin komunikatzen da couchbase zerbitzuaren bidez.
Aurrerago ikusiko dugu nola komunikatzen den klusteretik kanpo kokatutako zerbitzu batek bere IP helbidearen bidez kluster barruan dauden eta barne IP helbidea duten elementuekin.
Beraz, estaturik gabeko edukiontziak bikainak dira, baina zein ona da egoeradun edukiontziak erabiltzea? Ikus ditzagun edukiontzi egoeran edo iraunkorren sistemaren ezarpenak. Docker-en, arreta jarri beharko zenukeen datuak biltegiratzeko diseinuaren 4 ikuspegi desberdin daude. Lehenengoa Inplicito Per-Container da, hau da, couchbase, MySQL edo MyDB satateful edukiontziak erabiltzean, guztiak Sandbox lehenetsiarekin hasten dira. Hau da, datu-basean gordetzen den guztia edukiontzian bertan gordetzen da. Edukiontzia desagertzen bada, harekin batera desagertzen dira datuak.
Bigarrena Explicit Per-Container da, docker bolumenarekin biltegiratze zehatz bat sortzen duzunean sortu komandoa eta gorde datuak bertan. Ostalari bakoitzeko hirugarren ikuspegia biltegiratze-mapearekin lotuta dago, edukiontzian gordetako guztia aldi berean ostalarian bikoizten denean. Edukiontziek huts egiten badute, datuak ostalarian geratuko dira. Azken hau Multi-Ostalari hainbat ostalari erabiltzea da, eta hori komenigarria da hainbat irtenbideren ekoizpen-fasean. Demagun zure aplikazioak dituzten edukiontziak ostalarian exekutatzen ari direla, baina zure datuak Interneten nonbait gorde nahi dituzula, eta horretarako sistema banatuen mapaketa automatikoa erabiltzen duzula.
Metodo horietako bakoitzak biltegiratze-kokapen zehatz bat erabiltzen du. Edukiontzi bakoitzeko datu inplizituak eta esplizituak gordetzeko ostalarian /var/lib/docker/volumes helbidean. Per-Host metodoa erabiltzean, biltegiratzea edukiontziaren barruan muntatzen da, eta edukiontzia bera ostalarian muntatzen da. Ostalari anitzeko, Ceph, ClusterFS, NFS eta abar bezalako soluzioak erabil daitezke.
Edukiontzi iraunkor batek huts egiten badu, biltegiratze-direktorioa eskuraezin bihurtzen da lehenengo bi kasuetan, baina azken bi kasuetan sarbidea mantentzen da. Hala ere, lehenengo kasuan, biltegira sar zaitezke makina birtual batean exekutatzen den Docker ostalari baten bidez. Bigarren kasuan, datuak ere ez dira galduko, biltegiratze esplizitua sortu duzulako.
Ostalariak huts egiten badu, biltegiratze-direktorioa ez dago erabilgarri lehen hiru kasuetan; azken kasuan, biltegiratze-konexioa ez da eteten. Azkenik, partekatutako funtzioa guztiz baztertuta dago lehen kasuan biltegiratzeko eta posible da gainerakoetan. Bigarren kasuan, biltegiratzea partekatu dezakezu zure datu-baseak biltegiratze banatua onartzen duen ala ez. Per-Host-en kasuan, datu-banaketa posible da ostalari jakin batean bakarrik, eta multihost baterako kluster hedapenaren bidez ematen da.
Hori kontuan izan behar da egoera-edukiontziak sortzerakoan. Docker tresna erabilgarri bat Bolumen plugina da, "pilak dauden, baina ordezkatu behar diren" printzipioaren arabera funtzionatzen duena. Docker edukiontzi bat abiarazten duzunean, honela dio: "Aizu, datu-base batekin edukiontzi bat hasten duzunean, zure datuak edukiontzi honetan gorde ditzakezu!" Hau da funtzio lehenetsia, baina alda dezakezu. Plugin honek sareko unitate bat edo antzeko zerbait erabil dezakezu edukiontzien datu-basearen ordez. Ostalarietan oinarritutako biltegiratzeko kontrolatzaile lehenetsi bat barne hartzen du eta edukiontzien integrazioa ahalbidetzen du kanpoko biltegiratze sistemekin, hala nola Amazon EBS, Azure Storage eta GCE Persistent diskoekin.
Hurrengo diapositibak Docker Volume pluginaren arkitektura erakusten du.
Kolore urdinak Docker ostalari urdinarekin lotutako Docker bezeroa adierazten du, eta datuak gordetzeko edukiontziak eskaintzen dizkizuen Biltegiratze lokaleko motorra dauka. Berdeak Plugin Bezeroa eta Plugin Daemon adierazten ditu, hauek ere ostalariarekin konektatuta dauden. Behar duzun biltegiratze backend motako sareko biltegian datuak gordetzeko aukera eskaintzen dute.
Docker Volume plugina Portworx biltegiarekin erabil daiteke. PX-Dev modulua zure Docker ostalariarekin konektatzen den exekutatzen duzun edukiontzi bat da eta Amazon EBSn datuak erraz gordetzeko aukera ematen dizu.
Portworx bezeroak zure ostalariarekin konektatuta dauden biltegiratze-ontzien egoera kontrolatzeko aukera ematen du. Nire bloga bisitatzen baduzu, Portworx-i nola aprobetxatu Docker-ekin irakur dezakezu.
Kubernetes-en biltegiratze-kontzeptua Docker-en antzekoa da eta zure edukiontzira ontzi batean eskuragarri dauden direktorioek adierazten dute. Edozein edukiontziren iraupenetik independenteak dira. Biltegiratze mota ohikoenak hostPath, nfs, awsElasticBlockStore eta gsePersistentDisk dira. Ikus dezagun nola funtzionatzen duten denda hauek Kubernetesen. Normalean, horiek konektatzeko prozesuak 3 urrats ditu.
Lehenengoa sareko norbaitek, normalean administratzaileak, biltegiratze iraunkorra eskaintzen dizu. Dagokion PersistentVolume konfigurazio fitxategi bat dago horretarako. Jarraian, aplikazioaren garatzaileak PersistentVolumeClaim izeneko konfigurazio-fitxategi bat idazten du, edo PVC biltegiratze-eskaera bat, hauxe dio: β50 GB banatutako biltegiratze hornituta daukat, baina beste pertsona batzuek ere bere ahalmena erabil dezaten, PVC honi esaten ari naiz une honetan. 10 GB bakarrik behar dira". Azkenik, hirugarren urratsa zure eskaera biltegiratze gisa muntatzen dela eta poda edo erreplika multzoa edo horrelako zerbait erabiltzen hastea da. Garrantzitsua da gogoratzea prozesu hau aipatutako 3 urratsez osatuta dagoela eta eskalagarria dela.
Hurrengo diapositibak AWS arkitekturako Kubernetes Persistence Container erakusten du.
Kubernetes klusterra adierazten duen laukizuzen marroiaren barruan, nodo nagusi bat eta bi lan-nodo daude, horiz adierazita. Langile-nodoetako batek leka laranja bat, biltegiratzea, erreplika kontrolagailu bat eta Docker Couchbase edukiontzi berdea ditu. Kluster barruan, nodoen gainean, laukizuzen more batek kanpotik eskuragarri dagoen Zerbitzua adierazten du. Arkitektura hau datuak gailuan bertan gordetzeko gomendatzen da. Beharrezkoa izanez gero, nire datuak EBSn gorde ditzaket klusteretik kanpo, hurrengo diapositiban erakusten den moduan. Hau eskalatzeko eredu tipikoa da, baina erabiltzerakoan kontuan hartu beharreko alderdi ekonomiko bat dago: datuak sarean nonbait gordetzea ostalari batean baino garestiagoa izan daiteke. Edukiontzien konponbideak aukeratzerakoan, hau da pisuzko argumentuetako bat.
Dockerrekin bezala, Portworx-ekin Kubernetes edukiontzi iraunkorrak erabil ditzakezu.
Hau da egungo Kubernetes 1.6 terminologian "StatefulSet" deitzen dena: Pod-a geldiarazteko eta Graceful Shutdown egiteari buruzko gertaerak prozesatzen dituen Stateful aplikazioekin lan egiteko modu bat da. Gure kasuan, horrelako aplikazioak datu-baseak dira. Nire blogean StatefulSet bat nola sortu Kubernetesen Portworx erabiliz irakur dezakezu.
Hitz egin dezagun garapenaren alderdiari buruz. Esan bezala, Docker-ek 2 bertsio ditu - CE eta EE, lehen kasuan Community Edition-ren bertsio egonkor bati buruz ari gara, 3 hilabetean behin eguneratzen dena, EEren hilero eguneratutako bertsioaren aldean. Docker Mac, Linux edo Windows-erako deskarga dezakezu. Instalatu ondoren, Docker automatikoki eguneratuko da eta oso erraza da hastea.
Kubernetesentzat, Minikube bertsioa nahiago dut; plataformarekin hasteko modu ona da nodo bakarrean kluster bat sortuz. Hainbat nodotako clusterrak sortzeko, bertsioen aukera zabalagoa da: kops, kube-aws (CoreOS+AWS), kube-up (zaharkitua) dira. AWS-n oinarritutako Kubernetes erabili nahi baduzu, ostiralero sarean elkartzen den eta AWS Kubernetes-ekin lan egiteko hainbat material interesgarri argitaratzen dituen AWS SIG-era sartzea gomendatzen dizut.
Ikus dezagun nola egiten den Rolling Update plataforma hauetan. Hainbat nodoko multzo bat badago, irudiaren bertsio zehatz bat erabiltzen du, adibidez, WildFly:1. Eguneratze iraunkor batek esan nahi du irudiaren bertsioa sekuentzialki ordezkatzen dela nodo bakoitzean, bata bestearen atzetik.
Horretarako, docker service update (zerbitzuaren izena) komandoa erabiltzen dut, eta bertan WildFly:2 irudiaren bertsio berria eta eguneratze metodoa update-paralelism 2 zehazten dut. 2 zenbakiak esan nahi du sistemak 2 aplikazio irudi eguneratuko dituela. aldi berean, gero 10 segundoko eguneratze-atzerapena 10s, ondoren hurrengo 2 irudiak 2 nodo gehiagotan eguneratuko dira, etab. Eguneratze-mekanismo sinple hau Dockerren zati gisa eskaintzen dizu.
Kubernetesen, etengabeko eguneratze batek horrela funtzionatzen du. Erreplika-kontrolatzaileak rc bertsio bereko erreplika multzo bat sortzen du, eta webapp-rc honetako pod bakoitza etiketa batekin hornitzen da etcd-en. Pod bat behar dudanean, aplikazio-zerbitzua erabiltzen dut etcd biltegira sartzeko, eta horrek pod-a ematen dit zehaztutako etiketa erabiliz.
Kasu honetan, WildFly bertsioa 3 aplikazioa exekutatzen duen Erreplika-kontrolatzailean 1 pod ditugu. Atzeko planoan eguneratzean, beste erreplika-kontrolagailu bat sortzen da amaieran izen eta indize berdinarekin - - xxxxx, non x ausazko zenbakiak diren, eta etiketa berdinekin. Orain Aplikazio Zerbitzuak hiru ontzi ditu aplikazioaren bertsio zaharrarekin eta hiru ontzi ditu Replication kontrolagailu berrian bertsio berriarekin. Horren ondoren, pod zaharrak ezabatu egiten dira, pod berriekin erreplika-kontrolatzailea izena aldatu eta martxan jartzen da.
Jarrai gaitezen monitorizaziora. Docker-ek monitorizazio komando asko ditu. Adibidez, docker container stats komando-lerroko interfazeak edukiontzien egoerari buruzko informazioa segundoro bistaratzeko aukera ematen dizu kontsolan: prozesadorearen erabilera, diskoaren erabilera, sarearen karga. Docker Remote API tresnak bezeroa zerbitzariarekin nola komunikatzen den buruzko datuak eskaintzen ditu. Komando sinpleak erabiltzen ditu, baina Docker REST APIan oinarritzen da. Kasu honetan, REST, Flash, Remote hitzek gauza bera esan nahi dute. Ostalariarekin komunikatzen zarenean, REST API bat da. Docker Remote API-k edukiontziak martxan jartzeari buruzko informazio gehiago lortzeko aukera ematen du. Nire blogak monitorizazio hau Windows Server-ekin erabiltzeko xehetasunak azaltzen ditu.
Ostalari anitzeko kluster bat exekutatzen denean docker-sistemako gertaerak monitorizatzeak ostalariaren hutsegiteari edo edukiontzien hutsegiteari buruzko datuak eskuratzea ahalbidetzen du, ostalari jakin batean, zerbitzuak eskalatu eta antzekoak. Docker 1.20-tik hasita, Prometheus barne hartzen du, lehendik dauden aplikazioetan amaiera-puntuak txertatzen dituena. Honi esker, neurketak HTTP bidez jaso eta aginte-paneletan bistaratu ditzakezu.
Jarraipen-eginbide bat cAdvisor da (edukiontzien aholkulariaren laburpena). Martxan dauden edukiontzietatik baliabideen erabilera eta errendimendu datuak aztertzen eta eskaintzen ditu, Prometheus-en neurketak lehenbailehen emanez. Tresna honen berezitasuna azken 60 segundoetako datuak soilik ematen dituela da. Hori dela eta, datu horiek bildu eta datu-base batean sartu ahal izan behar dituzu, epe luzeko prozesu baten jarraipena egin ahal izateko. Grafana edo Kibana erabiliz aginte-panelaren neurketak grafikoki bistaratzeko ere erabil daiteke. Nire blogak cAdvisor nola erabili behar den deskribapen zehatza du Kibana aginte-panela erabiliz edukiontziak kontrolatzeko.
Hurrengo diapositibak Prometheus-en amaierako irteera nolakoa den eta bistaratzeko dauden neurketak erakusten ditu.
Beheko ezkerrean HTTP eskaerak, erantzunak eta abarrentzako neurketak ikusten dituzu, eskuinaldean haien pantaila grafikoa.
Kubernetes-ek monitorizazio-tresnak ere barne hartzen ditu. Diapositiba honek maisu bat eta hiru langile nodo dituen kluster tipiko bat erakusten du.
Lan-nodo bakoitzak automatikoki abiarazitako cAdvisor bat dauka. Horrez gain, Heapster dago, Kubernetes 1.0.6 bertsioarekin eta bertsio berriagoarekin bateragarria den errendimenduaren jarraipena eta neurketak biltzeko sistema bat. Heapster-ek lan-karga, ontzi eta edukiontzien errendimendu-neurriak ez ezik, kluster osoak sortutako gertaerak eta bestelako seinaleak ere bil ditzakezu. Datuak biltzeko, pod bakoitzaren Kubelet-ekin hitz egiten du, informazioa automatikoki gordetzen du InfluxDB datu-basean eta neurgailu gisa ateratzen du Grafana panelera. Hala ere, kontuan izan miniKube erabiltzen ari bazara, funtzio hau ez dagoela lehenespenez erabilgarri, beraz, gehigarriak erabili beharko dituzula monitorizazioa egiteko. Beraz, edukiontziak non exekutatzen dituzun eta lehenespenez zein monitorizazio tresna erabil ditzakezun eta gehigarri bereizi gisa instalatu behar dituzunaren araberakoa da.
Hurrengo diapositibak Grafana aginte-panelak erakusten ditu, nire edukiontziak martxan dauden egoera erakusten dutenak. Datu interesgarri asko daude hemen. Jakina, Docker eta Kubernetes prozesuak monitorizatzeko tresna komertzial asko daude, hala nola SysDig, DataDog, NewRelic. Horietako batzuek 30 urteko doako proba-epea dute, eta, beraz, saiatu zaitezke gehien egokitzen zaizuna aurkitzeko. Pertsonalki, nahiago dut SysDig eta NewRelic erabili, hauek Kubernetesekin ondo integratzen direnak. Docker zein Kubernetes plataformetan berdin integratzen diren tresnak daude.
Iragarki batzuk π
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com