Kaixo guztioi! Nire izena Pavel Agaletsky da. Taldeburu gisa lan egiten dut Lamoda entrega sistema garatzen duen talde batean. 2018an, HighLoad++ konferentzian hitz egin nuen, eta gaur nire txostenaren transkripzioa aurkeztu nahiko nuke.

Nire gaia gure konpainiak ingurune ezberdinetan sistemak eta zerbitzuak zabaltzean duen esperientziari eskainita dago. Gure historiaurreko garaietatik hasita, sistema guztiak zerbitzari birtual arruntetan zabaldu genituenean, Nomad-etik Kubernetes-en hedapenera pixkanaka igarotzean amaituz. Esango dizut zergatik egin dugun eta zein arazo izan ditugun prozesuan.

Aplikazioak VMra zabaltzea

Has gaitezen duela 3 urte konpainiaren sistema eta zerbitzu guztiak ohiko zerbitzari birtualetan zabaldu zirela. Teknikoki, gure sistemetako kode guztia muntaketa automatikoko tresnak erabiliz, jenkins erabiliz, biltegiratu eta muntatu zen moduan antolatu zen. Ansible erabiliz, gure bertsioak kontrolatzeko sistematik zerbitzari birtualetara zabaldu zen. Gainera, gure enpresak zeukan sistema bakoitza gutxienez 2 zerbitzaritan zabaldu zen: horietako bat buruan, bigarrena buztanean. Bi sistema hauek guztiz berdinak ziren euren ezarpen guztietan, potentzian, konfigurazioan, etab. Haien arteko desberdintasun bakarra buruak erabiltzaileen trafikoa jasotzen zuela izan zen, eta buztanak, berriz, inoiz ez zuen erabiltzaileen trafikoa jasotzen.

Zergatik egin zen hau?

Gure aplikazioaren bertsio berriak zabaldu genituenean, etengabeko hedapena bermatu nahi genuen, hau da, erabiltzaileentzat ondorio nabarmenik gabe. Hau lortu zen Ansible erabiliz konpilatutako hurrengo bertsioa buztanera zabaldu zelako. Bertan, hedapenean parte hartu zuten pertsonek dena ondo zegoela egiaztatu eta ziurtatu zuten: metrika, atal eta aplikazio guztiak lanean ari ziren; beharrezko scriptak abiarazten dira. Dena ondo zegoela konbentzitu ondoren, trafikoa aldatu egin zen. Lehen buztana zen zerbitzarira joaten hasi zen. Eta lehen burua zena erabiltzaile-trafikorik gabe geratu zen, oraindik gure aplikazioaren aurreko bertsioa gainean zuen bitartean.

Beraz, ezin hobea izan zen erabiltzaileentzat. Aldaketa berehalakoa delako, orekatzailea aldatzea besterik ez baita. Oso erraz itzuli dezakezu aurreko bertsiora orekatzailea atzera aldatuta. Erabiltzaileen trafikoa jaso aurretik ere aplikazioa ekoizteko gai zela egiaztatu ahal izan genuen, eta hori nahiko erosoa zen.

Zein abantaila ikusi genituen guzti honetan?

1. Lehenik eta behin, nahikoa da besterik ez du funtzionatzen. Denek ulertzen dute nola funtzionatzen duten inplementazio-eskema batek, jende gehienak ohiko zerbitzari birtualetan zabaldu duelako.
2. Hau nahikoa da fidagarri, hedatzeko teknologia sinplea denez, milaka enpresek probatua. Milioika zerbitzari zabaltzen dira horrela. Zaila da zerbait haustea.
3. Eta azkenean lor genezake inplementazio atomikoak. Erabiltzaileentzat aldi berean gertatzen diren inplementazioak, bertsio zaharraren eta berriaren artean aldatzeko etapa nabaririk gabe.

Baina honetan guztian hainbat hutsune ere ikusi genituen:

1. Ekoizpen-inguruneaz gain, garapen-inguruneaz gain, badira beste ingurune batzuk. Adibidez, qa eta aurreprodukzioa. Garai hartan zerbitzari asko eta 60 bat zerbitzu genituen. Horregatik beharrezkoa zen zerbitzu bakoitzeko, mantendu haren azken bertsioa makina birtuala. Gainera, liburutegiak eguneratu edo mendekotasun berriak instalatu nahi badituzu, ingurune guztietan egin behar duzu. Zure aplikazioaren hurrengo bertsio berria zabalduko duzun ordua ere sinkronizatu behar zenuen devops-ek beharrezko ingurune-ezarpenak egiten dituen denborarekin. Kasu honetan, erraza da gure ingurunea aldi berean ingurune guztietan zertxobait desberdina izango den egoera batera sartzea. Esaterako, QA ingurune batean liburutegien bertsio batzuk egongo dira, eta ekoizpen ingurune batean beste batzuk egongo dira, eta horrek arazoak ekarriko ditu.
2. Mendekotasunak eguneratzeko zailtasuna zure aplikazioa. Ez da zure araberakoa, beste taldearena baizik. Hots, zerbitzariak mantentzen dituen devops taldetik. Zeregin egoki bat eta egin nahi duzunaren deskribapena eman behar diezu.
3. Garai hartan, guk genituen monolito handi handiak zerbitzu txiki bereizietan banatu nahi genituen, gero eta gehiago izango zirela ulertzen baikenuen. Garai hartan, dagoeneko 100 baino gehiago genituen.Zerbitzu berri bakoitzeko, beharrezkoa zen makina birtual berri bat sortzea, eta hori ere mantendu eta zabaldu behar zen. Horrez gain, ez duzu auto bat behar, gutxienez bi baizik. Horri guztiari QA ingurunea gehitu zaio. Horrek arazoak sortzen ditu eta zailagoa egiten zaizu sistema berriak eraikitzea eta exekutatzeko. prozesu konplexua, garestia eta luzea.

Hori dela eta, erabaki genuen erosoagoa izango zela ohiko makina birtualak zabaltzetik gure aplikazioak docker edukiontzi batean zabaltzera pasatzea. Docker baduzu, aplikazioa kluster batean exekutatu dezakeen sistema bat behar duzu, ezin baita edukiontzi bat besterik altxatu. Normalean zenbat ontzi altxatzen diren kontrolatu nahi duzu automatikoki altxa daitezen. Hori dela eta, kontrol-sistema bat hautatu behar izan dugu.

Luzaroan pentsatu genuen zein hartu genezakeen. Kontua da garai hartan zerbitzari birtual arruntetan inplementazio pila hori zertxobait zaharkituta zegoela, ez baitzituzten sistema eragileen azken bertsioak. Noizbait, FreeBSD ere egon zen, ez zen oso erosoa onartzen. Ulertu genuen docker-era ahalik eta azkarren migratu behar genuela. Gure devopeek soluzio ezberdinekin duten esperientzia aztertu zuten eta Nomad bezalako sistema bat aukeratu zuten.

Aldatu Nomad-era

Nomad HashiCorp-en produktua da. Beste irtenbide batzuengatik ere ezagunak dira:

"Kontsula" zerbitzua aurkitzeko tresna bat da.

"Terraforma" - zerbitzariak kudeatzeko sistema bat, konfigurazioaren bidez konfiguratzeko aukera ematen duena, azpiegitura-kode gisa deritzona.

"Aldizkaria" makina birtualak lokalean edo hodeian hedatzeko aukera ematen du konfigurazio fitxategi espezifikoen bidez.

Nomad garai hartan nahiko konponbide sinplea zirudien, azpiegitura osoa aldatu gabe azkar alda zitekeena. Gainera, nahiko erraza da ikasteko. Horregatik aukeratu dugu gure edukiontziaren iragazketa sistema gisa.

Zer behar duzu zure sistema Nomad-en zabaltzeko?

1. Lehenik eta behin behar duzu docker irudia zure aplikazioa. Eraiki eta docker irudi biltegian jarri behar duzu. Gure kasuan, hau artifactory bat da, mota ezberdinetako hainbat artefaktu bertara bultzatzeko aukera ematen duen sistema. Artxiboak, docker irudiak, konpositore PHP paketeak, NPM paketeak eta abar gorde ditzake.
2. Beharrezkoa ere bai konfigurazio fitxategia, Nomad-i zer, non eta zein kantitatetan zabaldu nahi duzun esango diona.

Nomad-i buruz hitz egiten dugunean, HCL hizkuntza erabiltzen du informazio-fitxategi formatu gisa, hau da, hau da HashiCorp konfigurazio hizkuntza. Hau Yaml-ren supermultzo bat da, zure zerbitzua Nomad terminoetan deskribatzeko aukera ematen dizuna.

Zenbat edukiontzi zabaldu nahi dituzun esatea ahalbidetzen du, zein iruditatik pasatzeko hainbat parametro zabaltzean. Horrela, fitxategi hau Nomad-i elikatzen diozu, eta horren arabera ontziak ekoizten ditu.

Gure kasuan, konturatu ginen zerbitzu bakoitzerako HCL fitxategi guztiz berdinak idaztea ez zela oso erosoa izango, zerbitzu asko daudelako eta batzuetan eguneratu nahi dituzulako. Gertatzen da zerbitzu bat ez dela instantzia batean zabaltzen, baizik eta hainbatetan. Adibidez, ekoizpenean ditugun sistemetako batek 100 instantzia baino gehiago ditu ekoizpenean. Irudi berdinetatik exekutatzen dira, baina konfigurazio-ezarpenetan eta konfigurazio-fitxategietan desberdinak dira.

Hori dela eta, gure konfigurazio-fitxategi guztiak biltegi komun batean gordetzea erabaki genuen. Horrela ikusten ziren: mantentzen errazak ziren eta zer sistema genituen ikusi ahal izan genuen. Beharrezkoa bada, zerbait eguneratzea edo aldatzea ere erraza da. Sistema berri bat gehitzea ere ez da zaila - direktorio berriaren barruan konfigurazio fitxategi bat sortu besterik ez duzu behar. Haren barruan fitxategi hauek daude: service.hcl, gure zerbitzuaren deskribapena jasotzen duena, eta env fitxategi batzuk, produkzioan zabalduta dagoen zerbitzu hau konfiguratzeko aukera ematen dutenak.

Hala ere, gure sistema batzuk ekoizpenean ez dira kopia batean, aldi berean hainbatetan ezartzen. Hori dela eta, erabaki genuen komenigarria izango zitzaigula konfigurazioak ez bere forma hutsean gordetzea, baizik eta txantiloidun forman gordetzea. Eta guk aukeratu genuen jinja 2. Formatu honetan, zerbitzuaren beraren konfigurazioak eta horretarako behar diren env fitxategiak gordetzen ditugu.

Horrez gain, biltegian proiektu guztietan komuna den hedapen-script bat jarri dugu, eta horri esker, zure zerbitzua ekoizpenean abiarazteko eta zabaltzeko aukera ematen dizu, nahi duzun ingurunean, nahi den xedean. Gure HCL konfigurazioa txantiloi bihurtu genuenean, orduan HCL fitxategia, aurretik Nomad konfigurazio arrunta zena, kasu honetan apur bat desberdina izaten hasi zen.

Hau da, konfigurazio-kokapen-aldagai batzuk env fitxategietatik edo beste iturri batzuetatik hartutako txertatze aldagaiekin ordezkatu ditugu. Horrez gain, HCL fitxategiak modu dinamikoan biltzeko aukera izan dugu, hau da, aldagaien txertaketa arruntak ez ezik, erabil ditzakegu. Jinja-k begiztak eta baldintzak onartzen dituenez, konfigurazio-fitxategiak ere sor ditzakezu bertan, eta horiek aldatu egiten dira zure aplikazioak zehatz-mehatz zabaltzen dituzun tokiaren arabera.

Adibidez, zure zerbitzua aurreprodukziora eta ekoizpenera zabaldu nahi duzu. Demagun aurreprodukzioan ez duzula cron scriptik exekutatu nahi, baizik eta zerbitzua domeinu bereizi batean ikusi nahi duzula funtzionatzen ari dela ziurtatzeko. Zerbitzua zabaltzen duen edonorentzat, prozesua oso sinplea eta gardena dirudi. Egin behar duzun guztia deploy.sh fitxategia exekutatu da, zehaztu zein zerbitzu zabaldu nahi duzun eta zein helburutara. Adibidez, sistema jakin bat Errusia, Bielorrusia edo Kazakhstanera zabaldu nahi duzu. Horretarako, parametroetako bat aldatu besterik ez duzu, eta konfigurazio fitxategi egokia izango duzu.

Nomad zerbitzua dagoeneko zure klusterean zabalduta dagoenean, itxura hau ematen du.

Lehenik eta behin, kanpoan orekatzeko moduko bat behar duzu, erabiltzaileen trafiko guztia jasoko duena. Kontsularekin batera lan egingo du eta bertatik jakingo du non, zein nodotan, zein IP helbidetan dagoen domeinu-izen jakin bati dagokion zerbitzu zehatz bat. Kontsulan zerbitzuak Nomad berarengandik datoz. Enpresa bereko produktuak direnez, nahiko erlazionatuta daude elkarren artean. Esan dezakegu Nomad-ek kutxatik kanpo bertan abiarazitako zerbitzu guztiak erregistratu ditzakeela Consul barruan.

Zure frontend karga-orekatzaileak trafikoa zein zerbitzutara bidali behar duen jakin ondoren, zure aplikazioarekin bat datozen edukiontzi egokira edo hainbat edukiontzira birbidaltzen du. Jakina, segurtasunari buruz ere pentsatu behar da. Nahiz eta zerbitzu guztiak edukiontzietan makina birtualetan exekutatu, normalean horrek edozein zerbitzuren doako sarbidea eragoztea eskatzen du. Hau segmentazioaren bidez lortu dugu. Zerbitzu bakoitza bere sare birtualean jarri zen abian, eta bideratze-arauak eta beste sistema eta zerbitzu batzuetarako sarbidea baimendu/ukatzeko arauak ezarri ziren. Kluster honen barruan zein kanpoan egon litezke. Adibidez, zerbitzu bat datu-base zehatz batera konektatzea eragotzi nahi baduzu, sare-mailako segmentazio bidez egin daiteke. Hau da, akatsez ere, ezin duzu ustekabean konektatu proba-ingurunetik zure produkzio datu-basera.

Zenbat kostatu zitzaigun trantsizioa giza baliabideei dagokienez?

Enpresa osoaren trantsizioa Nomadera 5-6 hilabete behar izan zuen gutxi gorabehera. Zerbitzuz zerbitzu mugitu ginen, baina nahiko erritmo bizian. Talde bakoitzak bere edukiontziak sortu behar zituen zerbitzuetarako.

Halako planteamendu bat hartu dugu, non talde bakoitza bere sistemen docker irudien arduraduna den modu independentean. DevOps-ek hedapenerako beharrezkoa den azpiegitura orokorra eskaintzen du, hau da, kluster beraren euskarria, CI sistemarako euskarria, etab. Eta garai hartan, 60 sistema baino gehiago eraman genituen Nomadera, 2 mila edukiontzi inguru.

Devops inplementazioarekin eta zerbitzariekin lotutako guztiaren azpiegitura orokorraz arduratzen da. Eta garapen-talde bakoitza, berriz, bere sistema espezifikorako edukiontziak ezartzeaz arduratzen da, edukiontzi jakin batean orokorrean zer behar duen dakien taldea baita.

Nomad uzteko arrazoiak

Zein abantaila lortu ditugu, besteak beste, Nomad eta docker erabiliz hedapenera aldatzeak?

1. Dugu baldintza berdinak emanda ingurune guztietarako. Garapenean, QA ingurunea, aurreprodukzioa, produkzioa, edukiontzi irudi berdinak erabiltzen dira, mendekotasun berdinekin. Ondorioz, ez duzu ia aukerarik produkzioan bukatzeko lehen tokian edo proba-ingurunean probatu zenuena ez izatea.
2. Nahikoa dela ere aurkitu dugu erraza da zerbitzu berri bat gehitzea. Inplementazioaren ikuspuntutik, edozein sistema berri oso erraz abiarazten da. Besterik gabe, joan konfigurazioak gordetzen dituen biltegira, gehitu beste konfigurazio bat zure sistemarako bertan, eta prest zaude. Zure sistema ekoizpenera inplementatu dezakezu devops-en ahalegin gehigarririk gabe.
3. Guztiak konfigurazio fitxategiak biltegi komun batean berrikusten ari zela agertu zen. Gure sistemak zerbitzari birtualak erabiliz zabaldu genituen garaian, Ansible erabili genuen, zeinetan konfigurazioak biltegi berean zeuden. Hala ere, garatzaile gehienentzat hau pixka bat zailagoa zen lan egitea. Hemen zerbitzua zabaltzeko gehitu behar dituzun konfigurazio eta kodearen bolumena askoz ere txikiagoa da. Gainera, devopentzat oso erraza da konpontzea edo aldatzea. Trantsizioen kasuan, adibidez, Nomad-en bertsio berri batera, leku berean dauden fitxategi eragile guztiak hartu eta eguneratu ditzakete.

Baina hainbat desabantaila ere topatu ditugu:

Agertu zen guk ezin izan dira inplementaziorik gabekoak lortu Nomad-en kasuan. Baldintza ezberdinetan edukiontziak zabaltzean, martxan egon liteke, eta Nomad-ek trafikoa jasotzeko prest dagoen edukiontzi gisa hautematen zuen. Hau barneko aplikazioak abiarazteko aukera izan aurretik gertatu zen. Hori dela eta, sistema 500 akats sortzen hasi zen denbora laburrean, trafikoa oraindik onartzeko prest ez zegoen edukiontzi batera joaten hasi zelako.

Batzuk topatu ditugu akatsak. Akats esanguratsuena da Nomad-ek ez duela kluster handi bat oso ondo kudeatzen sistema eta edukiontzi asko badituzu. Nomad klusterrean sartuta dagoen zerbitzarietako bat mantentze-lanetarako atera nahi duzunean, nahiko probabilitate handia dago klusterra oso ondo ez sentitzeko eta erortzeko. Edukiontzi batzuk, adibidez, erori eta ez igo daitezke; hori asko kostako zaizu geroago zure ekoizpen-sistema guztiak Nomad-ek kudeatutako kluster batean kokatzen badira.

Beraz, nora joan behar genuen pentsatzea erabaki genuen. Momentu horretan, askoz ere kontzientzia handiagoa hartu genuen lortu nahi genuenaz. Alegia: fidagarritasuna nahi dugu, Nomad-ek eskaintzen dituena baino funtzio apur bat gehiago eta sistema helduagoa eta egonkorragoa.

Zentzu honetan, gure aukera Kubernetesen geratu zen klusterrak abiarazteko plataforma ezagunena bezala. Batez ere gure ontzien tamaina eta kopurua nahikoa handia zela ikusita. Horretarako, Kubernetes iruditu zitzaigun sistemarik egokiena.

Kuberneteserako trantsizioa

Kubernetes-en oinarrizko kontzeptuak eta Nomad-ekin nola desberdintzen diren azalduko dizut.

Lehenik eta behin, Kubernetesen oinarrizko kontzeptua pod kontzeptua da. Pod beti batera ibiltzen den ontzi bat edo gehiagoz osatutako multzoa da. Eta zorrozki makina birtual batean bezala lan egiten dute beti. Elkarren artean eskuragarri daude IP 127.0.0.1 portu ezberdinetan.

Demagun nginx eta php-fpm-k osatutako PHP aplikazio bat duzula - eskema klasikoa. Seguruenik, nginx eta php-fpm edukiontziak elkarrekin mantendu nahi dituzu uneoro. Kubernetes-ek hori lortzeko aukera ematen dizu, pod komun gisa deskribatuz. Hau da Nomadekin lortu ezin genuena.

Bigarren kontzeptua da hedapena. Kontua da leka bera gauza iragankorra dela; hasi eta desagertzen da. Lehenik eta behin zure aurreko edukiontzi guztiak akabatu nahi dituzu, eta gero bertsio berriak aldi berean abiarazi nahi dituzu edo pixkanaka zabaldu nahi dituzu? Hau da hedapenaren kontzeptua arduratzen den prozesua. Zure lekak nola zabaltzen dituzun, zer kantitatetan eta nola eguneratu deskribatzen du.

Hirugarren kontzeptua da zerbitzua. Zure zerbitzua zure sistema da benetan, trafiko pixka bat jasotzen duena eta gero zure zerbitzuari dagozkion pod batera edo gehiagotara birbidaltzen duena. Hau da, halako eta halako izena duen zerbitzu batera sartzen den trafiko guztia pods zehatz horietara bidali behar dela esatea ahalbidetzen du. Eta, aldi berean, trafikoaren oreka eskaintzen dizu. Hau da, zure aplikazioaren bi pod abiarazi ditzakezu, eta sarrerako trafiko guztia berdin orekatuko da zerbitzu honekin lotutako poden artean.

Eta laugarren oinarrizko kontzeptua da Ingress. Kubernetes kluster batean exekutatzen den zerbitzua da. Eskaera guztiak hartzen dituen kanpoko karga-orekatzaile gisa jokatzen du. Kubernetes APIa erabiliz, Ingress-ek eskaera horiek nora bidali behar diren zehaztu dezake. Gainera, hori oso malgutasunez egiten du. Ostalari honi egindako eskaera guztiak eta halako URLak zerbitzu honetara bidaltzen direla esan dezakezu. Eta ostalari honetara eta beste URL batera iristen diren eskaera hauek beste zerbitzu batera bidaltzen dira.

Aplikazio bat garatzen duenaren ikuspuntutik gauzarik politena da zuk zeuk kudeatzeko gai zarela. Ingress konfigurazioa ezarrita, halako eta halako API batera datorren trafiko guztia bidali dezakezu, adibidez, Go-n idatzitako edukiontzi bereiztera. Baina trafiko hori, domeinu berera datorrena, baina URL ezberdin batera, PHPn idatzitako edukiontzietara bidali behar da, non logika asko dagoen, baina ez dira oso azkarrak.

Kontzeptu hauek guztiak Nomadekin alderatzen baditugu, lehenengo hiru kontzeptuak guztiak batera Zerbitzua direla esan dezakegu. Eta azken kontzeptua ez dago Nomadan bertan. Kanpoko orekatzaile bat erabili dugu: haproxy, nginx, nginx+ eta abar izan liteke. Kubo baten kasuan, ez duzu kontzeptu osagarri hau bereizita sartu behar. Hala ere, Ingress barrutik begiratuz gero, nginx, haproxy edo traefik da, baina Kubernetesen barneratua.

Deskribatu ditudan kontzeptu guztiak, hain zuzen ere, Kubernetes kluster baten barruan dauden baliabideak dira. Kuboan deskribatzeko, yaml formatua erabiltzen da, Nomad-en kasuan HCL fitxategiak baino irakurgarriagoa eta ezagunagoa dena. Baina egitura aldetik gauza bera deskribatzen dute, adibidez, podaren kasuan. Esaten dute - halako eta halako lekak han zabaldu nahi ditut, halako eta halako irudiekin, halako eta halako kantitateetan.

Horrez gain, konturatu ginen ez genuela baliabide bakoitza eskuz sortu nahi: hedapena, zerbitzuak, Ingress, etab. Horren ordez, gure sistema bakoitza Kubernetes-en arabera deskribatu nahi izan dugu inplementazioan zehar, beharrezkoak diren baliabideen mendekotasun guztiak ordena egokian eskuz birsortu beharko ez genituzkeen. Helm aukeratu zen hori egiteko aukera eman zigun sistema gisa.

Helm-en oinarrizko kontzeptuak

Helm da paketeen kudeatzailea Kubernetesentzat. Programazio lengoaietako paketeen kudeatzaileek funtzionatzen dutenaren oso antzekoa da. Esaterako, deployment nginx, inplement php-fpm, config for Ingress, configmaps (env eta beste parametroak zure sistemarako ezartzeko aukera ematen duen entitate bat da) gordetzeko aukera ematen dute. taulak izenekoak. Aldi berean Helm Kubernetesen gainean doa. Hau da, hau ez da alboan gelditzen den sistema bat, kuboaren barruan abiarazitako beste zerbitzu bat baizik. Harekin elkarreragin egiten duzu bere APIaren bidez kontsolaren komando baten bidez. Bere erosotasuna eta edertasuna zera da: helm-a hautsi edo klusterretik kentzen baduzu ere, zure zerbitzuak ez dira desagertuko, helm-ek funtsean sistema abiarazteko soilik balio baitu. Kubernetes bera da orduan zerbitzuen errendimenduaren eta egoeraren arduraduna.

Horretaz ere konturatu ginen txantiloia, gure konfigurazioetan jinja sartuz gure buruak egitera behartuta geunden, helm-en ezaugarri nagusietako bat da. Zure sistemetarako sortzen dituzun konfigurazio guztiak helm-en gordetzen dira txantiloi moduan, jinjaren antzeko apur bat, baina, hain zuzen ere, Go hizkuntzaren txantiloiak erabiliz, zeinetan helm idazten den, Kubernetes bezala.

Helmek kontzeptu batzuk gehitzen dizkigu.

Grafikoa - hau zure zerbitzuaren deskribapena da. Beste pakete-kudeatzaile batzuetan pakete, sorta edo antzeko zerbait deituko litzateke. Hemen diagrama deitzen zaio.

Balioak zure konfigurazioak txantiloietatik eraikitzeko erabili nahi dituzun aldagaiak dira.

Askatu. Helm erabiliz zabaltzen den zerbitzu batek bertsioaren gehikuntza-bertsio bat jasotzen duen bakoitzean. Helm-ek aurreko bertsioan zerbitzuaren konfigurazioa zein zen gogoratzen du, aurreko bertsioa eta abar. Hori dela eta, atzera egin behar baduzu, exekutatu helm callback komandoa, aurreko bertsiora zuzenduz. Nahiz eta zure biltegian dagokion konfigurazioa erabilgarri ez egon atzera egiteko unean, Helm-ek oraindik zer zen gogoratuko du eta zure sistema aurreko bertsioan zegoen egoerara itzuliko du.

Helm erabiltzen dugunean, Kubernetes-en konfigurazio arruntak txantiloietan ere bilakatzen dira, zeinetan aldagaiak, funtzioak eta baldintzazko adierazpenak aplika daitezkeen. Horrela zure zerbitzuaren konfigurazioa bildu dezakezu ingurunearen arabera.

Praktikan, gauzak Nomad-ekin baino apur bat ezberdinean egitea erabaki genuen. Nomad-en gure zerbitzua zabaltzeko beharrezkoak ziren inplementazio-konfigurazioak eta n aldagaiak biltegi batean gordetzen baziren, hemen bi biltegi bereizitan banatzea erabaki genuen. "Inplementatu" biltegiak inplementatzeko behar diren n aldagaiak soilik gordetzen ditu, eta "helm" biltegiak konfigurazioak edo diagramak gordetzen ditu.

Zer eman digu honek?

Konfigurazio fitxategietan berez datu sentikorrik gordetzen ez dugun arren. Adibidez, datu-baseetarako pasahitzak. Kubernetesen sekretu gisa gordetzen dira, baina, hala ere, badaude oraindik denei sarbidea eman nahi ez dizkiegun zenbait gauza. Beraz, "inplementatu" biltegirako sarbidea mugatuagoa da, eta "helm" biltegiak zerbitzuaren deskribapena besterik ez du jasotzen. Hori dela eta, jende ugari sar daiteke modu seguruan.

Ekoizpena ez ezik, beste ingurune batzuk ere baditugu, bereizketa honi esker gure lema-diagramak berrerabili ditzakegu zerbitzuak ekoizpenean ez ezik, QA ingurune batean ere, adibidez. Baita lokalean erabiltzeko ere Minikube - Kubernetes lokalean exekutatzeko gauza bat da.

Biltegi bakoitzaren barruan, zerbitzu bakoitzerako direktorio bereizietan zatiketa bat utzi genuen. Hau da, direktorio bakoitzaren barruan dagozkion grafikoarekin lotutako txantiloiak daude eta gure sistema abiarazteko zabaldu behar diren baliabideak deskribatzen dituzte. "Deploy" biltegian envs bakarrik utzi ditugu. Kasu honetan, ez dugu jinja erabiliz txantiloiak erabili, Helm-ek berak txantiloiak eskaintzen dituelako kaxatik kanpo - hau da bere funtzio nagusietako bat.

Inplementazio-script bat utzi dugu - deploy.sh, hedapenerako abiaraztearen abiarazte sinplifikatu eta estandarizatu egiten duena helm erabiliz. Beraz, zabaldu nahi duen edonorentzat, inplementazio-interfazeak Nomad bidez zabaltzean zuen itxura berdina du. Deploy.sh bera, zure zerbitzuaren izena eta non zabaldu nahi duzun. Honek lema barnetik abiaraztea eragiten du. Era berean, txantiloietako konfigurazioak biltzen ditu, beharrezko balio-fitxategiak txertatzen ditu haietan, gero zabaltzen ditu, Kubernetesen abiaraziz.

Findings

Kubernetes zerbitzua Nomad baino konplexuagoa dela dirudi.

Hemen irteerako trafikoa Ingress-era iristen da. Hau aurreko kontrolatzailea besterik ez da, eskaera guztiak bere gain hartzen dituena eta, ondoren, eskaeraren datuei dagozkien zerbitzuetara bidaltzen dituena. Helm-en zure aplikazioaren deskribapenaren parte diren eta garatzaileek beren kabuz ezartzen dituzten konfigurazioetan oinarrituta zehazten ditu. Zerbitzuak eskaerak bidaltzen ditu bere ontzietara, hau da, edukiontzi zehatzetara, zerbitzu honetako edukiontzi guztien artean sarrerako trafikoa orekatuz. Eta, noski, ez dugu ahaztu behar ez dugula inora joan behar sare mailan segurtasunetik. Hori dela eta, segmentazioak Kubernetes kluster batean funtzionatzen du, etiketan oinarritzen dena. Zerbitzu guztiek etiketa jakin batzuk dituzte eta kluster barruan edo kanpoan dauden kanpoko/barneko baliabide batzuetarako zerbitzuek atzitzeko eskubideak lotzen zaizkie.

Trantsizioa egin ahala, Kubernetes-ek Nomad-en gaitasun guztiak zituela ikusi genuen, aurretik erabili genituenak, eta gauza berri asko ere gehitu zituen. Pluginen bidez zabaldu daiteke, eta, hain zuzen ere, baliabide mota pertsonalizatuen bidez. Hau da, Kubernetes-ekin datorren zerbait erabiltzeko aukera ez ezik, zure baliabidea irakurriko duen zure baliabidea eta zerbitzua sortzeko aukera duzu. Honek aukera gehigarriak ematen dizkizu zure sistema zabaltzeko Kubernetes berriro instalatu beharrik gabe eta aldaketarik beharrik gabe.

Erabilera horren adibide bat Prometheus da, gure Kubernetes kluster barruan exekutatzen dena. Zerbitzu jakin bateko neurketak biltzen hasteko, zerbitzuaren deskribapenean baliabide mota gehigarri bat gehitu behar dugu, zerbitzu-monitorea deritzona. Prometheus, Kubernetesen abiarazten denean baliabide mota pertsonalizatu bat irakur dezakeelako, automatikoki hasten da sistema berriko neurketak biltzen. Nahiko erosoa da.

Kubernetesen egin genuen lehen hedapena 2018ko martxoan izan zen. Eta denbora horretan ez dugu inoiz arazorik izan. Nahiko egonkor funtzionatzen du akats handirik gabe. Horrez gain, gehiago zabaldu dezakegu. Gaur egun dituen gaitasunekin nahikoa dugu, eta asko gustatzen zaigu Kubernetesen garapen-erritmoa. Gaur egun, 3000 edukiontzi baino gehiago daude Kubernetesen. Klusterrak hainbat Nodo hartzen ditu. Aldi berean, erabilgarri, egonkorra eta oso kontrolagarria da.

Iturria: www.habr.com