{"id":92073,"date":"2020-08-22T19:41:56","date_gmt":"2020-08-22T17:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io"},"modified":"2020-08-22T19:41:56","modified_gmt":"2020-08-22T17:41:56","slug":"post-mortem-po-nedostupnosti-quay-io","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Post Mortem p\u00ebr mosfunksionimin e Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sh\u00ebn. p\u00ebrk.<\/b>: n\u00eb fillim t\u00eb gushtit, Red Hat publikoi informacion n\u00eb lidhje me zgjidhjet p\u00ebr problemet e aksesit q\u00eb ishin paraqitur gjat\u00eb muajve t\u00eb fundit p\u00ebr p\u00ebrdoruesit e sh\u00ebrbimit t\u00eb saj Quay.io<\/a><\/noindex> (n\u00eb themel ka nj\u00eb regjist\u00ebr p\u00ebr imazhe kontejner\u00ebsh, i ardhur nga blerja e CoreOS). Pavar\u00ebsisht interesit tuaj p\u00ebr k\u00ebt\u00eb sh\u00ebrbim, rruga q\u00eb ndjekin inxhinier\u00ebt SRE t\u00eb kompanis\u00eb p\u00ebr diagnostikimin dhe zgjidhjen e shkaqeve t\u00eb aksidenteve \u00ebsht\u00eb edukative.<\/i><\/p>\n

\"Post
\n
\nM\u00eb 19 maj, n\u00eb m\u00ebngjesin e hersh\u00ebm (sip\u00ebr orarit veror t\u00eb Amerik\u00ebs Veriore, EDT), sh\u00ebrbimi quay.io ra. Aksidenti ndikoi si n\u00eb konsumator\u00ebt e quay.io, ashtu edhe n\u00eb projektet Open Source q\u00eb p\u00ebrdorin quay.io si platform\u00eb p\u00ebr nd\u00ebrtimin dhe shp\u00ebrndarjen e softuerit. Red Hat vler\u00ebson besimin e t\u00eb dyve.<\/p>\n

Skeda e inxhinier\u00ebve SRE u angazhua menj\u00ebher\u00eb dhe p\u00ebrpiqeshin t\u00eb stabilizonin sh\u00ebrbimin Quay sa m\u00eb shpejt t\u00eb ishte e mundur. Megjithat\u00eb, nd\u00ebrsa ishin n\u00eb k\u00ebt\u00eb proces, klient\u00ebt humb\u00ebn mund\u00ebsin\u00eb p\u00ebr t\u00eb d\u00ebrguar imazhe t\u00eb reja, dhe vet\u00ebm nganj\u00ebher\u00eb arrit\u00ebn t\u00eb t\u00ebrhiqnin t\u00eb ekzistueshmet. P\u00ebr shkak t\u00eb nj\u00eb shkaku t\u00eb panjohur, baza e t\u00eb dh\u00ebnave t\u00eb quay.io u bllokua pas shkall\u00ebzimit t\u00eb sh\u00ebrbimit n\u00eb kapacitet t\u00eb plot\u00eb.<\/a><\/noindex><\/p>\n

\u00ab\u00c7far\u00eb ndryshoi?<\/b>\u00bb \u2014 \u00ebsht\u00eb pyetja e par\u00eb q\u00eb pritet t\u00eb b\u00ebhet n\u00eb rastet e tilla. V\u00ebrejt\u00ebm se pak para problemeve, klasteri OpenShift Dedicated (ku funksionon quay.io) filloi t\u00eb p\u00ebrmir\u00ebsohej n\u00eb versionin 4.3.19. Meqen\u00ebse quay.io funksionon mbi Red Hat OpenShift Dedicated (OSD), p\u00ebrmir\u00ebsimet e rregullta kan\u00eb qen\u00eb nj\u00eb operacion i zakonsh\u00ebm dhe kurr\u00eb nuk kan\u00eb shkaktuar probleme. P\u00ebr m\u00eb tep\u00ebr, gjat\u00eb gjasht\u00eb muajve t\u00eb fundit kemi p\u00ebrmir\u00ebsuar disa her\u00eb klaster\u00ebt Quay pa ndonj\u00eb nd\u00ebrprerje n\u00eb sh\u00ebrbim.<\/p>\n

Nd\u00ebrsa po p\u00ebrpiqeshim t\u00eb rikthenim sh\u00ebrbimin, inxhinier\u00eb t\u00eb tjer\u00eb filluan t\u00eb p\u00ebrgatisin nj\u00eb klaster t\u00eb ri OSD me versionin e m\u00ebparsh\u00ebm t\u00eb softuerit, p\u00ebr t'u implementuar n\u00eb rast nevoje.<\/p>\n

Analiza e shkakut t\u00eb par\u00eb<\/h2>\n

\nSimptoma kryesore e d\u00ebshtimit ishte nj\u00eb avalanxha e dhjet\u00ebra mij\u00ebra lidhjeve me baz\u00ebn e t\u00eb dh\u00ebnave, q\u00eb e b\u00ebri ekzemplarin MySQL n\u00eb fakt t\u00eb pap\u00ebrdorsh\u00ebm. P\u00ebr k\u00ebt\u00eb arsye, ishte e v\u00ebshtir\u00eb t\u00eb diagnostikohej problemi. Vendos\u00ebm nj\u00eb kufizim n\u00eb numrin maksimal t\u00eb lidhjeve nga klient\u00ebt, p\u00ebr t\u00eb ndihmuar ekipin SRE t\u00eb vler\u00ebsoj\u00eb problemin. Nuk v\u00ebrejt\u00ebm asnj\u00eb trafik t\u00eb pazakont\u00eb n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave: n\u00eb fakt, shumica e k\u00ebrkesave ishin p\u00ebr lexim, dhe vet\u00ebm disa p\u00ebr shk writing.<\/p>\n

Ne kemi tentuar gjithashtu t\u00eb zbulojm\u00eb nj\u00eb model n\u00eb trafikun e DB q\u00eb mund t\u00eb kishte shkaktuar k\u00ebt\u00eb p\u00ebrplasje. Megjithat\u00eb, nuk u gjet\u00ebn asnj\u00eb rregullsi n\u00eb log-et. N\u00eb pritje t\u00eb gatishm\u00ebris\u00eb s\u00eb klas\u00ebs s\u00eb re me OSD 4.3.18, ne vazhduam p\u00ebrpjekjet p\u00ebr t\u00eb nisur pod-\u00ebt quay.io. \u00c7do her\u00eb q\u00eb klasa arrinte kapacitetin maksimal, baza e t\u00eb dh\u00ebnave ngrinte. Kjo do t\u00eb thoshte se ishte e nevojshme t\u00eb rinisnim instance-n RDS p\u00ebrve\u00e7 t\u00eb gjith\u00eb pod-\u00ebve quay.io.<\/p>\n

N\u00eb mbr\u00ebmje, ne stabilizuam sh\u00ebrbimin n\u00eb modalitetin read-only dhe \u00e7uam jasht\u00eb maksimumin e funksioneve t\u00eb pavler\u00eb (p.sh., grumbullimin e mbetjeve n\u00eb hap\u00ebsir\u00ebn e emrave) p\u00ebr t\u00eb ulur ngarkes\u00ebn n\u00eb DB. Ngritjet u ndal\u00ebn, por shkaku nuk u gjet asnj\u00ebher\u00eb<\/b>. Klasa e re OSD ishte gati, dhe ne transferuam sh\u00ebrbimin, lidh\u00ebm trafikun dhe vazhduam monitorimin.<\/p>\n

Quay.io funksionoi stabilisht n\u00eb klas\u00ebn e re OSD, prandaj ne u kthyem n\u00eb log-et e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave, por nuk arrit\u00ebm t\u00eb zbulojm\u00eb nj\u00eb korelacion q\u00eb shpjegonte bllokime. Inxhinier\u00ebt e OpenShift punuan s\u00eb bashku me ne, duke u munduar t\u00eb kuptonin n\u00ebse ndryshimet n\u00eb Red Hat OpenShift 4.3.19 mund t\u00eb kishin sjell\u00eb probleme me Quay. Megjithat\u00eb, nuk u zbulua asgj\u00eb. nuk nuk arrit\u00ebm t\u00eb riprodhojm\u00eb problemin n\u00eb kushte laboratorik<\/b>.<\/p>\n

D\u00ebshtimi i dyt\u00eb<\/h2>\n

\nM\u00eb 28 maj, pak para mesdit\u00ebs sipas EDT, quay.io p\u00ebsoi s\u00ebrish r\u00ebnie me simptomat e nj\u00ebjta: funksionimi i baz\u00ebs s\u00eb t\u00eb dh\u00ebnave u bllokua. S\u00ebrish, ne vendos\u00ebm t\u00eb hedhim t\u00eb gjitha forcat n\u00eb hetim. E para, duhej t\u00eb rikthenim funksionimin e sh\u00ebrbimit. Sidoqoft\u00eb n\u00eb k\u00ebt\u00eb rast, rinisja e RDS dhe rikthimi i pod-ve t\u00eb quay.io nuk kishin asnj\u00eb efekt<\/b>: nj\u00eb val\u00eb tjet\u00ebr lidhjesh p\u00ebrmbyti baz\u00ebn. Por pse?<\/p>\n

Quay \u00ebsht\u00eb shkruar n\u00eb Python, dhe \u00e7do pod funksionon si nj\u00eb en\u00eb monolitike. N\u00eb mjedisin e ekzekutimit t\u00eb en\u00ebs, shum\u00eb detyra t\u00eb shumta ekzekutohen paralelisht. Ne p\u00ebrdorim bibliotek\u00ebn gevent<\/code> n\u00ebn gunicorn<\/code> p\u00ebr t\u00eb p\u00ebrpunuar k\u00ebrkesat web. Kur nj\u00eb k\u00ebrkes\u00eb arrin n\u00eb Quay (n\u00ebp\u00ebrmjet API ton\u00eb, ose n\u00ebp\u00ebrmjet API t\u00eb Docker-it), i caktohet nj\u00eb punonj\u00ebs gevent. Zakonisht, ky punonj\u00ebs duhet t\u00eb lidhet me baz\u00ebn e t\u00eb dh\u00ebnave. Pas d\u00ebshtimit t\u00eb par\u00eb, zbuluam se punonj\u00ebsit gevent po lidhen me baz\u00ebn e t\u00eb dh\u00ebnave duke p\u00ebrdorur cil\u00ebsimet e parazgjedhura.<\/p>\n

Duke parasysh numri t\u00eb konsideruesh\u00ebm t\u00eb pod-\u00ebve t\u00eb Quay dhe mij\u00ebra k\u00ebrkesave q\u00eb vijn\u00eb \u00e7do sekond\u00eb, nj\u00eb num\u00ebr i madh lidhjesh n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave teorikisht mund t\u00eb mbingarkonte instanc\u00ebn MySQL. Fal\u00eb monitorimit, ishte e njohur se Quay n\u00eb mesatare p\u00ebrpunon 5 mij\u00eb k\u00ebrkesa n\u00eb sekund\u00eb. Numri i lidhjeve me baz\u00ebn e t\u00eb dh\u00ebnave ishte af\u00ebrsisht po aq i lart\u00eb. 5 mij\u00eb lidhje ishin brenda kapacitetit t\u00eb instanc\u00ebs son\u00eb RDS (ndryshe nga dhjet\u00ebra mij\u00ebra). P\u00ebr nj\u00eb arsye t\u00eb caktuar ndodhnin shp\u00ebrthime t\u00eb papritura t\u00eb numrit t\u00eb lidhjeve<\/b>, megjithat\u00eb ne nuk v\u00ebm\u00eb re ndonj\u00eb korrelacion me k\u00ebrkesat q\u00eb arrinin.<\/p>\n

K\u00ebt\u00eb her\u00eb ne vendos\u00ebm t\u00eb gjejm\u00eb dhe eliminojm\u00eb burimin e problemit, dhe jo thjesht t\u00eb kufizohemi me rindezjen. N\u00eb kodin baz\u00eb t\u00eb Quay u b\u00ebn\u00eb ndryshime, q\u00eb kufizojn\u00eb numrin e lidhjeve me Baza e t\u00eb Dh\u00ebnave p\u00ebr \u00e7do pun\u00ebtor\u00eb.<\/b> gevent. Ky ky\u00e7 u b\u00eb nj\u00eb paramet\u00ebr n\u00eb konfigurim: tani ishte e mundur ta ndryshonit \"n\u00eb fluks\", pa nd\u00ebrtuar nj\u00eb imazh t\u00eb ri t\u00eb konteinerit. P\u00ebr t\u00eb m\u00ebsuar se sa lidhje mund t\u00eb trajtohen n\u00eb t\u00eb v\u00ebrtet\u00eb, u zhvilluan disa eksperimente me ambientin staging, ku u caktuan vlera t\u00eb ndryshme p\u00ebr t\u00eb par\u00eb se si do t\u00eb ndikonte n\u00eb skenar\u00ebt e testimit t\u00eb ngarkes\u00ebs. Si rezultat, u zbulua se Quay fillon t\u00eb jep\u00eb gabime 502 kur numri i lidhjeve kalon 10 mij\u00eb.<\/b><\/p>\n

Ne menj\u00ebher\u00eb e zgjodh\u00ebm k\u00ebt\u00eb version t\u00eb ri n\u00eb production dhe filluam t\u00eb ndiqnim grafik\u00ebn e lidhjeve me baz\u00ebn e t\u00eb dh\u00ebnave. N\u00eb t\u00eb kaluar\u00ebn, baza u bllokua af\u00ebrsisht pas 20 minutash. Pas 30 minutash pa probleme, kishim shpres\u00eb, dhe pas nj\u00eb ore \u2013 siguri. Ne rikthyem trafikun p\u00ebr shkruar n\u00eb faqen e internetit dhe filluam analiz\u00ebn postmortem.<\/p>\n

Duke arritur t\u00eb shmangim problemin q\u00eb \u00e7onte n\u00eb bllokim, nuk zbuluam shkaqet e v\u00ebrteta t\u00eb tij<\/b>. U konfirmua se ajo nuk kishte lidhje me ndonj\u00eb ndryshim n\u00eb OpenShift 4.3.19, pasi e nj\u00ebjta gj\u00eb ndodhi edhe n\u00eb versionin 4.3.18, i cili deri at\u00ebher\u00eb kishte funksionuar me Quay pa ndonj\u00eb problem.<\/p>\n

N\u00eb klaster kishte di\u00e7ka tjet\u00ebr t\u00eb fshehur.<\/p>\n

Hetimi i holl\u00ebsish\u00ebm<\/h2>\n

\nQuay.io p\u00ebrdori p\u00ebr gjasht\u00eb vjet\u00eb parametrat e paracaktuar p\u00ebr lidhjen me DB pa ndonj\u00eb problem. \u00c7far\u00eb ka ndryshuar? E qart\u00eb, gjat\u00eb gjith\u00eb k\u00ebtij koh\u00eb, trafiku n\u00eb quay.io ka vazhduar t\u00eb rritet. N\u00eb rastin ton\u00eb, gjith\u00e7ka dukej si t\u00eb kishte arritur nj\u00eb pik\u00eb prag q\u00eb sh\u00ebrbeu si nj\u00eb triger p\u00ebr nj\u00eb lavin\u00eb lidhjesh. Ne vazhduam t\u00eb shqyrtonim log\u00ebt e DB pas d\u00ebshtimit t\u00eb dyt\u00eb, por nuk gjet\u00ebm ndonj\u00eb t\u00eb dh\u00ebn\u00eb ose lidhje t\u00eb dukshme.<\/p>\n

Nd\u00ebrkoh\u00eb, ekipi SRE ishte duke u angazhuar n\u00eb p\u00ebrmir\u00ebsime n\u00eb fush\u00ebn e v\u00ebzhgueshm\u00ebris\u00eb s\u00eb k\u00ebrkesave n\u00eb Quay dhe sh\u00ebndetit t\u00eb p\u00ebrgjithsh\u00ebm t\u00eb sh\u00ebrbimit. U implementuan metrika t\u00eb reja dhe panele monitorimi<\/b>, q\u00eb tregojn\u00eb se cilat pjes\u00eb t\u00eb Quay po k\u00ebrkohen m\u00eb shum\u00eb nga klient\u00ebt.<\/p>\n

Quay.io funksionoi normal deri m\u00eb 9 Qershor. N\u00eb m\u00ebngjes (sip\u00ebr EDT) s\u00ebrish u p\u00ebrball\u00ebm me nj\u00eb rritje t\u00eb konsiderueshme t\u00eb numrit t\u00eb lidhjeve n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave. K\u00ebt\u00eb her\u00eb nuk kishte ndonj\u00eb nd\u00ebrprerje<\/b>, pasi parametri i ri kufizonte numrin e tyre dhe nuk lejonte tejkalimin e kapacitetit t\u00eb MySQL. Megjithat\u00eb, p\u00ebr rreth nj\u00eb gjysm\u00eb ore shum\u00eb p\u00ebrdorues raportuan ngadal\u00ebsimin e pun\u00ebs s\u00eb quay.io. Ne mbledh\u00ebm shpejt t\u00eb gjitha t\u00eb dh\u00ebnat e mundshme, duke p\u00ebrdorur mjetet e reja t\u00eb monitorimit. Papritur u shfaq nj\u00eb model.<\/p>\n

Para shpejtimit t\u00eb numrit t\u00eb lidhjeve, nj\u00eb num\u00ebr i madh k\u00ebrkesash mb\u00ebrriti n\u00eb App Registry API<\/b>. App Registry \u00ebsht\u00eb nj\u00eb funksion i panjohur shum\u00eb n\u00eb quay.io. Ai lejon ruajtjen e gj\u00ebrave si chartet Helm dhe kontejner\u00ebt me metadatat e pasura. Shumica e p\u00ebrdoruesve t\u00eb quay.io nuk punojn\u00eb me k\u00ebt\u00eb funksion, megjithat\u00eb, ajo p\u00ebrdoret gjer\u00ebsisht nga Red Hat OpenShift. OperatorHub n\u00eb kuad\u00ebr t\u00eb OpenShift ruan t\u00eb gjith\u00eb operator\u00ebt n\u00eb App Registry. K\u00ebta operator\u00eb formojn\u00eb baz\u00ebn p\u00ebr ekosistemin e ngarkesave t\u00eb pun\u00ebs OpenShift dhe modelin operativ (n\u00eb kuad\u00ebr t\u00eb operacioneve \u201ct\u00eb dit\u00ebs s\u00eb dyt\u00eb\u201d, Day 2) t\u00eb orientuar nga partner\u00ebt.<\/p>\n

\u00c7do kluster OpenShift 4 p\u00ebrdor operator\u00ebt nga OperatorHub i nd\u00ebrtuar p\u00ebr publikimin e katalogut t\u00eb operator\u00ebve, t\u00eb cil\u00ebt jan\u00eb t\u00eb disponuesh\u00ebm p\u00ebr instalim, dhe ofrimin e p\u00ebrdit\u00ebsimeve p\u00ebr ata q\u00eb jan\u00eb tashm\u00eb t\u00eb instaluar. Me rritjen e popullaritetit t\u00eb OpenShift 4, \u00ebsht\u00eb rritur gjithashtu numri i klustereve q\u00eb e p\u00ebrdorin at\u00eb n\u00eb t\u00eb gjith\u00eb bot\u00ebn. \u00c7do nga k\u00ebto klustere ngarkon p\u00ebrmbajtjen e operator\u00ebve p\u00ebr t\u00eb aktivizuar OperatorHub-in e nd\u00ebrtuar, duke p\u00ebrdorur App Registry brenda quay.io si backend. N\u00eb k\u00ebrkim t\u00eb burimit t\u00eb problemit ne humb\u00ebm faktin se me rritjen graduale t\u00eb popullaritetit t\u00eb OpenShift, po rritej gjithashtu edhe ngarkesa n\u00eb nj\u00eb nga funksionet e p\u00ebrdorura rrall\u00eb n\u00eb quay.io.<\/b>.<\/p>\n

Ne kemi b\u00ebr\u00eb nj\u00eb analiz\u00eb t\u00eb trafikut t\u00eb k\u00ebrkesave t\u00eb App Registry dhe kemi hedhur nj\u00eb v\u00ebshtrim n\u00eb kodin e registrit. Menj\u00ebher\u00eb u zbuluan mang\u00ebsi, p\u00ebr shkak t\u00eb t\u00eb cilave k\u00ebrkesat e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave formoheshin n\u00eb m\u00ebnyr\u00eb jo optimale. N\u00ebn nj\u00eb ngarkes\u00eb t\u00eb vog\u00ebl ato nuk shkaktonin ndonj\u00eb problem, megjithat\u00eb me rritjen e saj, ato b\u00ebheshin burim problemesh. App Registry kishte dy endpoint-e problematik\u00eb, q\u00eb nuk reagonin mir\u00eb ndaj rritjes s\u00eb ngarkes\u00ebs: i pari jepte nj\u00eb list\u00eb t\u00eb t\u00eb gjith\u00eb pacaketeve n\u00eb depo, nd\u00ebrsa i dyti ktheu t\u00eb gjitha blob-et p\u00ebr paket\u00ebn.<\/p>\n

Eliminimi i shkakut<\/h2>\n

\nGjat\u00eb jav\u00ebs s\u00eb ardhshme ne punuam n\u00eb optimizimin e kodit t\u00eb App Registry dhe ambientit t\u00eb tij. U rishikuan qartazi t\u00eb pasuksesshme SQL k\u00ebrkesat, u eliminuan thirrjet e tep\u00ebrta t\u00eb komand\u00ebs (ajo aktivizohej me \u00e7do nxjerrje blob\u2019esh), dhe u shtua caching kudo q\u00eb ishte e mundur. tar<\/code> Pas k\u00ebsaj, u kryen teste masive p\u00ebr performanc\u00ebn dhe u krahasua shpejt\u00ebsia e pun\u00ebs s\u00eb App Registry para dhe pas ndryshimeve.<\/p>\n

K\u00ebrkesat API, q\u00eb m\u00eb par\u00eb zinin deri n\u00eb gjysm\u00ebminute, tani p\u00ebrfundonin p\u00ebr milisekonda.<\/b>N\u00eb jav\u00ebn e ardhshme, ne vendos\u00ebm ndryshimet n\u00eb production, dhe q\u00eb at\u00ebher\u00eb quay.io funksionon stabilisht. Gjat\u00eb k\u00ebsaj kohe, pat\u00ebm disa shp\u00ebrthime t\u00eb forta t\u00eb trafikut n\u00eb endpoint\u2019in e App Registry, por p\u00ebrmir\u00ebsimet e b\u00ebra parandaluan nd\u00ebrprerje n\u00eb funksionimin e databaz\u00ebs.<\/p>\n

\u00c7far\u00eb m\u00ebsuam?<\/h2>\n

\n\u00cbsht\u00eb e qart\u00eb se \u00e7do sh\u00ebrbim p\u00ebrpiqet t\u00eb shmang\u00eb ndalesat. N\u00eb rastin ton\u00eb, besojm\u00eb se defektet e fundit ndihmuan p\u00ebr ta b\u00ebr\u00eb quay.io m\u00eb t\u00eb mir\u00eb. Ne nxorr\u00ebm disa m\u00ebsime t\u00eb r\u00ebnd\u00ebsishme q\u00eb d\u00ebshirojm\u00eb t'i ndajm\u00eb:<\/p>\n

    \n
  1. T\u00eb dh\u00ebnat mbi se kush dhe si e p\u00ebrdor sh\u00ebrbimin tuaj kurr\u00eb nuk jan\u00eb t\u00eb tep\u00ebrta.<\/b>. Duke qen\u00eb se Quay \u201cthjesht funksiononte\u201d, ne kurr\u00eb nuk pat\u00ebm nevoj\u00eb t\u00eb shpenzonim koh\u00eb p\u00ebr optimizimin e trafikut dhe menaxhimin e ngarkes\u00ebs. E gjith\u00eb kjo krijoi nj\u00eb ndjenj\u00eb t\u00eb rreme sigurie se sh\u00ebrbimi mund t\u00eb shkall\u00ebzohej pafund\u00ebsisht.<\/li>\n
  2. Kur sh\u00ebrbimi bie, rikthimi tij n\u00eb funksion \u2014 \u00ebsht\u00eb p\u00ebrpar\u00ebsia kryesore<\/b>. Duke qen\u00eb se Quay vazhdoi t\u00eb vuante nga nj\u00eb baz\u00eb t\u00eb dh\u00ebnash t\u00eb bllokuar gjat\u00eb r\u00ebnies s\u00eb par\u00eb, procedurat tona standarde nuk pat\u00ebn efektin e pritur dhe ne nuk arrit\u00ebm ta rikthenim sh\u00ebrbimin me ndihm\u00ebn e tyre. Kjo \u00e7oi n\u00eb nj\u00eb situat\u00eb ku duhet t\u00eb shpenzonim koh\u00eb p\u00ebr analiz\u00ebn dhe mbledhjen e t\u00eb dh\u00ebnave n\u00eb shpres\u00ebn se do t\u00eb gjenim shkakun e par\u00eb \u2014 n\u00eb vend q\u00eb t\u00eb p\u00ebrqendronim t\u00eb gjitha p\u00ebrpjekjet n\u00eb rikthimin e funksionalitetit.<\/li>\n
  3. Vler\u00ebsoni ndikimin e secil\u00ebs nga funksionet e sh\u00ebrbimit<\/b>. Klient\u00ebt rrall\u00eb p\u00ebrdor\u00ebn App Registry, prandaj ai nuk ishte prioritet p\u00ebr ekipin ton\u00eb. Kur disa funksione t\u00eb produktit p\u00ebrdoren shum\u00eb pak, defektet e tyre dalin rrall\u00eb, dhe zhvilluesit ndalojn\u00eb s\u00eb ndjekuri kodin. \u00cbsht\u00eb e leht\u00eb t\u00eb b\u00ebhesh viktim\u00eb e keqkuptimit se kjo \u00ebsht\u00eb normale - derisa papritmas ky funksion t\u00eb dal\u00eb n\u00eb qend\u00ebr t\u00eb nj\u00eb incidenti t\u00eb madh.<\/li>\n<\/ol>\n

    <\/p>\n

    \u00c7far\u00eb ndodh m\u00eb tej?<\/h2>\n

    \nPuna p\u00ebr t\u00eb siguruar stabilitetin e sh\u00ebrbimit kurr\u00eb nuk ndalon dhe ne vazhdimisht e p\u00ebrmir\u00ebsojm\u00eb at\u00eb. Volume e trafikut n\u00eb quay.io vazhdojn\u00eb t\u00eb rriten, dhe ne e kuptojm\u00eb se jemi t\u00eb detyruar t\u00eb b\u00ebjm\u00eb gjith\u00e7ka t\u00eb mundshme p\u00ebr t\u00eb justifikuar besimin e klient\u00ebve. Prandaj, aktualisht po punojm\u00eb n\u00eb detyrat e m\u00ebposhtme:<\/p>\n

      \n
    1. Implementimi i replikave t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave vet\u00ebm p\u00ebr lexim, p\u00ebr t\u00eb ndihmuar sh\u00ebrbimin t\u00eb p\u00ebrballoj\u00eb trafikun p\u00ebrkat\u00ebs n\u00eb rast t\u00eb problemeve me shembullin kryesor RDS.<\/li>\n
    2. P\u00ebrdit\u00ebsimi i shembullit RDS. Versioni aktual nuk \u00ebsht\u00eb nj\u00eb problem n\u00eb vetvete. P\u00ebrkundrazi, ne thjesht duam t\u00eb eliminojm\u00eb nj\u00eb gjurm\u00eb false (n\u00eb t\u00eb cil\u00ebn pat\u00ebm kaluar gjat\u00eb nd\u00ebrprerjes); mbajtja e softuerit n\u00eb gjendje t\u00eb p\u00ebrdit\u00ebsuar do t\u00eb ndihmoj\u00eb p\u00ebr t\u00eb eliminuar nj\u00eb tjet\u00ebr faktor n\u00eb rast t\u00eb nd\u00ebrprerjeve t\u00eb ardhshme.<\/li>\n
    3. Kastrimi shtes\u00eb n\u00eb t\u00eb gjith\u00eb klasterin. Ne vazhdojm\u00eb t\u00eb k\u00ebrkojm\u00eb fusha ku caching mund t\u00eb reduktoj\u00eb ngarkes\u00ebn n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave.<\/li>\n
    4. Shtimi i firewall-it p\u00ebr aplikacionet web (WAF) p\u00ebr t\u00eb par\u00eb kush dhe p\u00ebrse lidhet me quay.io.<\/li>\n
    5. Duke filluar nga versioni i ardhsh\u00ebm, klasteret Red Hat OpenShift do t\u00eb braktisin App Registry n\u00eb favor t\u00eb katalog\u00ebve t\u00eb operator\u00ebve (Operator Catalogs), t\u00eb bazuar n\u00eb imazhet e kontejner\u00ebve t\u00eb disponueshme n\u00eb quay.io.<\/li>\n
    6. Z\u00ebvend\u00ebsimi afatgjat\u00eb i App Registry mund t\u00eb jet\u00eb mb\u00ebshtetje p\u00ebr specifikimet e artefakteve Open Container Initiative (OCI). Ajo aktualisht realizohet si funksionalitet natyror i Quay dhe do t\u00eb jet\u00eb e disponueshme p\u00ebr p\u00ebrdoruesit kur specifikimi p\u00ebrfundimisht t\u00eb miratohet.<\/li>\n<\/ol>\n

      \nT\u00eb gjitha t\u00eb m\u00ebsip\u00ebrmet jan\u00eb pjes\u00eb e investimeve t\u00eb vazhdueshme t\u00eb Red Hat n\u00eb quay.io nd\u00ebrsa ne kalojm\u00eb nga nj\u00eb ekip i vog\u00ebl 'n\u00eb stil start-up' n\u00eb nj\u00eb platform\u00eb t\u00eb pjekur, t\u00eb menaxhuar nga SRE. Ne e dim\u00eb se shum\u00eb nga klient\u00ebt tan\u00eb mb\u00ebshteten n\u00eb quay.io p\u00ebr pun\u00ebn e tyre t\u00eb p\u00ebrditshme (duke p\u00ebrfshir\u00eb Red Hat!) dhe po b\u00ebjm\u00eb p\u00ebrpjekje maksimale p\u00ebr t\u00eb qen\u00eb t\u00eb hapur n\u00eb lidhje me d\u00ebshtimet e fundit dhe p\u00ebrpjekjet e vazhdueshme p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar.<\/p>\n

      P.S. nga p\u00ebrkthyesi<\/h2>\n

      \nLexoni gjithashtu n\u00eb blogun ton\u00eb:<\/p>\n