Fitxategi lokalak aplikazio bat Kubernetesera migratzean
Kubernetes erabiliz CI/CD prozesu bat eraikitzean, batzuetan azpiegitura berriaren eskakizunen eta hara transferitzen ari den aplikazioaren arteko bateraezintasunaren arazoa sortzen da. Bereziki, aplikazioa eraikitzeko fasean garrantzitsua da lortzea bat erabiliko den irudia guztiak proiektu-inguruneak eta klusterrak. Printzipio honen oinarrian zuzena da Googleren arabera edukiontzien kudeaketa (horri buruz behin baino gehiagotan esan zuen eta gure sail teknikoa).
Hala ere, ez duzu inor ikusiko gunearen kodeak prest egindako marko bat erabiltzen duen egoeretan, eta horren erabilerak erabilera gehiagorako murrizketak ezartzen ditu. Eta "ingurune arruntean" horri aurre egiteko erraza den arren, Kubernetesen jokabide hori arazo bihur daiteke, batez ere lehenengo aldiz topatzen duzunean. Buru asmatzaile batek lehen begiratuan agerikoak eta onak diruditen azpiegitura irtenbideak sor ditzakeen arren... garrantzitsua da gogoratzea egoera gehienek egin dezaketela eta behar dutela. arkitektonikoki konponduko da.
Ikus ditzagun kluster bat funtzionatzerakoan ondorio desatseginak ekar ditzaketen fitxategiak gordetzeko konponbide konponbide ezagunak, eta bide zuzenagoa ere adierazi.
Biltegiratze estatikoa
Irudi, estilo eta beste gauza batzuk lortzeko sorgailu estatikoren bat erabiltzen duen web-aplikazio bat. Esate baterako, Yii PHP esparruak direktorio-izen esklusiboak sortzen dituen aktiboen kudeatzailea du. Horren arabera, irteera gune estatikorako bide multzo bat da, jakina, elkarren artean gurutzatzen ez direnak (hainbat arrazoirengatik egin zen, adibidez, bikoiztuak ezabatzeko osagai anitzek baliabide bera erabiltzen dutenean). Beraz, kaxatik kanpo, web-baliabideen modulu batera sartzen zaren lehen aldian, fitxategi estatikoak (izatez, maiz, esteka sinbolikoak, baina gehiago gehiago geroago) inplementazio honetarako bakarra den erro-direktorio komun batekin eratzen dira:
webroot/assets/2072c2df/css/β¦
webroot/assets/2072c2df/images/β¦
webroot/assets/2072c2df/js/β¦
Zer esan nahi du horrek kluster bati dagokionez?
Adibiderik errazena
Har dezagun nahiko ohikoa den kasu bat, PHP-k nginx-ek aurrea hartzen duenean datu estatikoak banatzeko eta eskaera sinpleak prozesatzeko. Modurik errazena - Inplementazio bi ontzirekin:
Webgunera lehen aldiz sartzen zarenean, aktiboak PHP edukiontzian agertzen dira. Baina pod bakarreko bi edukiontziren kasuan, nginx-ek ez daki ezer fitxategi estatiko horiei buruz, zeinak (konfigurazioaren arabera) eman behar zaizkien. Ondorioz, bezeroak 404 errore bat ikusiko du CSS eta JS fitxategietarako eskaera guztietan. Hemen irtenbiderik errazena edukiontzientzako direktorio komun bat antolatzea litzateke. Aukera primitiboa - orokorra emptyDir:
Orain edukiontzian sortutako fitxategi estatikoak nginx-ek behar bezala hornitzen ditu. Baina gogorarazten dizut hau irtenbide primitiboa dela, hau da, idealetik urrun dagoela eta bere Γ±abardura eta gabeziak dituela, jarraian eztabaidatzen direnak.
Biltegiratze aurreratuagoa
Orain imajinatu egoera bat non erabiltzaile batek gunea bisitatu, edukiontzian erabilgarri dauden estiloekin orrialde bat kargatu eta orrialde hau irakurtzen ari zen bitartean edukiontzia berriro zabaldu genuen. Aktiboen katalogoa hutsik geratu da eta PHP-ri eskaera egin behar zaio berriak sortzen hasteko. Hala ere, honen ondoren ere, estatika zaharretarako estekek ez dute garrantzirik izango, eta horrek akatsak ekarriko ditu estatikoak bistaratzeko.
Horrez gain, ziurrenik proiektu bat gehiago edo gutxiago kargatuta daukagu, eta horrek esan nahi du aplikazioaren kopia bat ez dela nahikoa izango:
Eskala dezagun Inplementazio gehienez bi erreplika.
Gunera lehen aldiz sartu zenean, aktiboak erreplika batean sortu ziren.
Noizbait, sarrerak erabaki zuen (karga orekatzeko helburuetarako) eskaera bat bidaltzea bigarren erreplikara, eta aktibo horiek oraindik ez zeuden. Edo agian ez daude jada erabiltzen dugulako RollingUpdate eta momentuz inplementazioa egiten ari gara.
Oro har, emaitza berriro akatsak dira.
Aktibo zaharrak ez galtzeko, alda dezakezu emptyDir on hostPath, kluster-nodo bati fisikoki estatikoa gehituz. Ikuspegi hau txarra da, benetan behar dugulako lotu kluster-nodo jakin batera zure aplikazioa, zeren - beste nodo batzuetara mugituz gero - direktorioak ez ditu beharrezko fitxategiak edukiko. Edo nodoen arteko atzeko planoko direktorioen sinkronizazio motaren bat beharrezkoa da.
Zeintzuk dira irtenbideak?
Hardwareak eta baliabideak ahalbidetzen badute, erabil dezakezu cephs behar estatikoetarako berdin irisgarria den direktorio bat antolatzeko. Dokumentazio ofiziala SSD unitateak, gutxienez hiru aldiz erreplikatzea eta kluster-nodoen arteko konexio "lodi" egonkorra gomendatzen du.
Ez hain zorrotza den aukera bat NFS zerbitzari bat antolatzea litzateke. Hala ere, orduan kontuan hartu behar duzu web zerbitzariaren eskaerak prozesatzeko erantzun-denbora izan daitekeen handitzea, eta akatsen tolerantzia asko utziko du. Porrotaren ondorioak hondamendiak dira: mendiaren galerak kumulua hiltzera kondenatzen du zerura lasterka doan LA kargaren presiopean.
Besteak beste, biltegiratze iraunkorra sortzeko aukera guztiek beharko dute hondo garbiketa denbora-tarte jakin batean pilatutako fitxategi multzo zaharkituak. PHP duten edukiontzien aurrean jarri dezakezu DaemonSet nginx cachingetik, aktiboen kopiak denbora mugatu batean gordeko dituena. Jokabide hau erraz konfigura daiteke erabiliz proxy_cache biltegiratze-sakonera egunetan edo gigabyte-ko diskoan.
Metodo hau goian aipatutako fitxategi-sistem banatuekin konbinatzeak irudimenerako eremu izugarria eskaintzen du, berau ezarri eta lagunduko dutenen aurrekontuak eta potentzial teknikoak soilik mugatuta. Esperientziaz, sistema zenbat eta sinpleagoa izan, orduan eta egonkorrago funtzionatzen duela esan dezakegu. Horrelako geruzak gehitzen direnean, askoz zailagoa da azpiegitura mantentzea, eta, aldi berean, akatsak diagnostikatzeko eta berreskuratzeko denbora handitzen da.
gomendio
Proposatutako biltegiratze-aukeren ezarpena ere justifikatu gabea iruditzen bazaizu (konplikatua, garestia...), orduan, merezi du egoera beste aldetik begiratzea. Hots, proiektuaren arkitekturan sakontzea eta konpondu arazoa kodean, irudiko datu-egitura estatiko batzuei lotuta, irudiaren muntaketa-fasean aktiboak "berotzeko" edo/eta aldez aurretik konpilatzeko edukien edo prozeduraren definizio argia. Horrela, guztiz aurreikus daitekeen portaera eta fitxategi-multzo berdina lortzen dugu exekutatzen ari den aplikazioaren ingurune eta errepliketarako.
Yii markoarekin adibide zehatzera itzultzen bagara eta bere egituran sakontzen ez badugu (artikuluaren xedea ez dena), nahikoa da bi ikuspegi ezagun seinalatzea:
Aldatu irudia sortzeko prozesua aktiboak kokapen aurreikusgarri batean kokatzeko. Hau bezalako luzapenetan iradokitzen/inplementatzen da yii2-static-assets.
Definitu hash espezifikoak aktiboen direktorioetarako, adibidez. aurkezpen hau (35. diapositibatik abiatuta). Bide batez, txostenaren egileak azken finean (eta ez arrazoirik gabe!) aholkatzen du aktiboak eraikitze-zerbitzarian muntatu ondoren, biltegiratze zentral batera igotzea (S3 bezalakoa), eta horren aurrean CDN bat jarri.
Deskarga daitezkeen fitxategiak
Aplikazio bat Kubernetes kluster batera migratzean behin betiko jokoan sartuko den beste kasu bat erabiltzaile-fitxategiak fitxategi-sisteman gordetzea da. Adibidez, PHP aplikazio bat dugu berriro kargatzeko formulario baten bidez fitxategiak onartzen dituena, haiekin zerbait egiten duen funtzionamenduan eta itzultzen dituena.
Kubernetesen, fitxategi hauek jarri behar diren kokapena aplikazioaren erreplika guztientzat komuna izan behar da. Aplikazioaren konplexutasunaren eta fitxategi horien iraupena antolatzeko beharraren arabera, aipatutako gailu partekatuen aukerak halako lekua izan daitezke, baina, ikusten dugunez, bere eragozpenak dituzte.
gomendio
Irtenbide bat da S3-rekin bateragarria den biltegiratzea erabiliz (nahiz eta minio bezalako auto-ostatatutako kategoria bat izan). S3ra aldatzeko aldaketak beharko dira kode mailan, eta edukia front end-ean nola emango den, badugu dagoeneko ΠΏΠΈΡΠ°Π»ΠΈ.
Erabiltzaileen saioak
Bereizita, nabarmentzekoa da erabiltzaileen saioak biltegiratzeko antolaketa. Askotan hauek ere diskoan dauden fitxategiak izaten dira, eta Kubernetesen testuinguruan erabiltzaileak etengabeko baimen-eskaerak ekarriko ditu bere eskaera beste edukiontzi batean amaitzen bada.
Arazoa neurri batean konpontzen da piztuz stickySessions sartzean (Eginbidea sarrera-kontrolatzaile ezagun guztietan onartzen da - xehetasun gehiagorako, ikus gure berrikuspena)erabiltzailea aplikazioarekin pod zehatz batera lotzeko:
Baina horrek ez ditu behin eta berriz inplementazioen arazoak kenduko.
gomendio
Modu zuzenagoa aplikazioa transferitzea izango litzateke saioak memcached, Redis eta antzeko soluzioetan gordetzea - Oro har, erabat utzi fitxategi-aukerak.
Ondorioa
Testuan aztertzen diren azpiegitura-irtenbideak aldi baterako "makuluen" formatuan soilik erabiltzekoak dira (ingelesez politagoa dena konponbide gisa). Aplikazio bat Kubernetesera migratzeko lehen faseetan garrantzitsuak izan daitezke, baina ez dute errotu behar.
Gomendatutako bide orokorra horiek kentzea da aplikazioaren aldaketa arkitektonikoaren alde, askorentzat ezaguna denaren arabera. 12-Factor aplikazioa. Hala ere, horrek -aplikazioa estaturik gabeko forma batera eramateak- ezinbestean esan nahi du kodean aldaketak egin beharko direla, eta hemen garrantzitsua da negozioaren gaitasun/eskakizunen eta aukeratutako bidea ezartzeko eta mantentzeko aukeren arteko oreka bilatzea. .