{"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 mbi munges\u00ebn e Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sh\u00ebn. p\u00ebrkth.<\/b>: n\u00eb fillim t\u00eb gushtit, Red Hat publikisht njoftoi p\u00ebr zgjidhjen e problemeve t\u00eb disponueshm\u00ebris\u00eb q\u00eb kishin ndodhur gjat\u00eb muajve t\u00eb kaluar p\u00ebr p\u00ebrdoruesit e sh\u00ebrbimit t\u00eb saj. Quay.io<\/a><\/noindex> (n\u00eb themel t\u00eb tij \u00ebsht\u00eb nj\u00eb regjist\u00ebr p\u00ebr imazhet e kontejner\u00ebve, q\u00eb i ka kaluar kompanis\u00eb me blerjen e CoreOS). Pavar\u00ebsisht interesit tuaj n\u00eb k\u00ebt\u00eb sh\u00ebrbim si i till\u00eb, rruga q\u00eb kan\u00eb ndjekur inxhinier\u00ebt SRE t\u00eb kompanis\u00eb p\u00ebr diagnostikimin dhe zgjidhjen e arsyeve t\u00eb aksidentit \u00ebsht\u00eb m\u00ebsuese.<\/i><\/p>\n

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

Ekipi i inxhinier\u00ebve SRE menj\u00ebher\u00eb u angazhua n\u00eb pun\u00eb dhe u p\u00ebrpoq t\u00eb stabilizonte sa m\u00eb shpejt sh\u00ebrbimin Quay. Megjithat\u00eb, derisa ata merreshin me k\u00ebt\u00eb, klient\u00ebt humb\u00ebn mund\u00ebsin\u00eb p\u00ebr t\u00eb push\u2019uar imazhe t\u00eb reja, dhe vet\u00ebm her\u00eb pas here u arrin t\u00eb pull\u2019ojn\u00eb ato ekzistuese. P\u00ebr nj\u00eb arsye 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 ka ndryshuar?<\/b>\u00bb \u2014 \u00ebsht\u00eb pyetja e par\u00eb q\u00eb pranohet t\u00eb b\u00ebhet n\u00eb raste t\u00eb tilla. V\u00ebrejt\u00ebm se disa koh\u00eb p\u00ebrpara problemit, klasteri OpenShift Dedicated (n\u00eb t\u00eb cilin funksionon quay.io) filloi t\u00eb p\u00ebrdit\u00ebsohej n\u00eb versionin 4.3.19. Duke qen\u00eb se quay.io funksionon n\u00eb Red Hat OpenShift Dedicated (OSD), p\u00ebrdit\u00ebsimet e rregullta ishin nj\u00eb operacion i zakonsh\u00ebm dhe kurr\u00eb nuk kishin sjell\u00eb probleme. P\u00ebr m\u00eb tep\u00ebr, gjat\u00eb gjasht\u00eb muajve t\u00eb kaluar kemi p\u00ebrdit\u00ebsuar disa her\u00eb klaster\u00ebt Quay pa pauses n\u00eb sh\u00ebrbim.<\/p>\n

Nd\u00ebrsa ne p\u00ebrpiqeshim t\u00eb rregullonim sh\u00ebrbimin, inxhinier\u00eb t\u00eb tjer\u00eb filluan t\u00eb p\u00ebrgatitin nj\u00eb klaster t\u00eb ri OSD me versionin e m\u00ebparsh\u00ebm t\u00eb softuerit, n\u00eb m\u00ebnyr\u00eb q\u00eb n\u00eb rast nevoje t\u00eb mund t\u00eb rikthenin gjith\u00e7ka aty.<\/p>\n

Analiza e arsyeve kryesore<\/h2>\n

\nSimptom\u00eb kryesore e d\u00ebshtimit ishte nj\u00eb val\u00eb e dhjet\u00ebra mij\u00ebra lidhjeve me DB, p\u00ebr shkak t\u00eb s\u00eb cil\u00ebs ekzemplari MySQL u b\u00eb praktikisht i paaft\u00eb. P\u00ebr k\u00ebt\u00eb shkak, ishte e v\u00ebshtir\u00eb t\u00eb diagnostikohej problemi. Ne 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 u vun\u00eb re ndonj\u00eb trafik t\u00eb pazakont\u00eb n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave: n\u00eb t\u00eb v\u00ebrtet\u00eb, shumica e k\u00ebrkesave ishin p\u00ebr lexim, nd\u00ebrsa vet\u00ebm disa p\u00ebr shkrim.<\/p>\n

Ne kemi provuar gjithashtu t\u00eb identifikojm\u00eb nj\u00eb model n\u00eb trafikun e DB-s\u00eb q\u00eb mund t\u00eb ket\u00eb shkaktuar k\u00ebt\u00eb lavin\u00eb. Megjithat\u00eb, nuk u gjet\u00ebn asnj\u00eb rregull grumbuj n\u00eb logje. Nd\u00ebrsa prisnim gatishm\u00ebrin\u00eb e grumbullit t\u00eb ri me OSD 4.3.18, vazhduam p\u00ebrpjekjet p\u00ebr t\u00eb nisur pod-\u00ebt quay.io. \u00c7do her\u00eb q\u00eb grumbulli arrinte kapacitetin e tij maksimal, baza e t\u00eb dh\u00ebnave ngjiste. Kjo do t\u00eb thoshte se ishte e nevojshme t\u00eb rihapej instanca RDS, p\u00ebrve\u00e7 t\u00eb gjith\u00eb pod-\u00ebve quay.io.<\/p>\n

M\u00eb n\u00eb fund, ne stabilizuam sh\u00ebrbimin n\u00eb modin read-only dhe \u00e7aktivizuam shumic\u00ebn e funksioneve jo t\u00eb r\u00ebnd\u00ebsishme (si\u00e7 \u00ebsht\u00eb mbledhja e mbetjeve n\u00eb hap\u00ebsir\u00ebn e emrave) p\u00ebr t\u00eb ulur ngarkes\u00ebn n\u00eb DB. Ngecjet ndaluan, por arsyeja as nuk u gjet<\/b>. Klasteri i ri OSD ishte gati, dhe ne e transferuam sh\u00ebrbimin, lidh\u00ebm trafikun dhe vazhduam monitorimin.<\/p>\n

Quay.io funksionoi stabilisht n\u00eb klasterin e ri OSD, k\u00ebshtu q\u00eb u kthyem n\u00eb log\u00ebt e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave, por s\u00ebrish nuk arrit\u00ebm t\u00eb zbulonim ndonj\u00eb korelacion q\u00eb shpjegonte bllokimet. Inxhinier\u00ebt e OpenShift punuan ngusht\u00eb me ne, duke p\u00ebrpiqur t\u00eb kuptonin n\u00ebse ndryshimet n\u00eb Red Hat OpenShift 4.3.19 mund t\u00eb ishin shkaku i problemeve me Quay. Sidoqoft\u00eb, nuk gjet\u00ebm asgj\u00eb dhe nuk arrit\u00ebm t\u00eb riprodhonim problemin n\u00eb kushte laboratorike<\/b>.<\/p>\n

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

\nM\u00eb 28 maj, pak para mesdit\u00ebs sipas EDT, quay.io s\u00ebrish ra me t\u00eb nj\u00ebjtin simptom\u00eb: funksionimi i baz\u00ebs s\u00eb t\u00eb dh\u00ebnave ishte bllokuar. Dhe s\u00ebrish hodh\u00ebm t\u00eb gjitha forcat tona n\u00eb hetim. Para s\u00eb gjithash, duhej t\u00eb rikthenim funksionimin e sh\u00ebrbimit. Megjithat\u00eb n\u00eb k\u00ebt\u00eb rast, rihapja e RDS dhe rihapja e pod-\u00ebve quay.io nuk t\u00eb \u00e7uan askund<\/b>: nj\u00eb tjet\u00ebr cunami 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 ambientin e funksionimit t\u00eb kontejnerit, shum\u00eb detyra p\u00ebrpar\u00ebsore ekzekutohen n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb. Ne p\u00ebrdorim bibliotek\u00ebn gevent<\/code> me gunicorn<\/code> p\u00ebr p\u00ebrpunimin e k\u00ebrkesave n\u00eb web. Kur Quay merr nj\u00eb k\u00ebrkes\u00eb (n\u00ebp\u00ebrmjet API ton\u00eb ose p\u00ebrmes API t\u00eb Dockers), i caktohet nj\u00eb pun\u00ebtor gevent. Zakonisht, ky pun\u00ebtor duhet t\u00eb lidhet me baz\u00ebn e t\u00eb dh\u00ebnave. Pas d\u00ebshtimit t\u00eb par\u00eb, zbuluam se pun\u00ebtor\u00ebt gevent lidhen me baz\u00ebn e t\u00eb dh\u00ebnave duke p\u00ebrdorur konfigurimet standarde.<\/p>\n

Duke marr\u00eb parasysh numrin e konsideruesh\u00ebm t\u00eb pod-\u00ebve Quay dhe mij\u00ebra k\u00ebrkesat q\u00eb vijn\u00eb n\u00eb sekond\u00eb, nj\u00eb num\u00ebr i madh lidhjesh me baz\u00ebn e t\u00eb dh\u00ebnave teorikisht mund ta ngarkonin instanc\u00ebn MySQL. P\u00ebrmes monitorimit, ishim t\u00eb vet\u00ebdijsh\u00ebm se Quay p\u00ebrpunon mesatarisht 5000 k\u00ebrkesa n\u00eb sekond\u00eb. Numri i lidhjeve me baz\u00ebn e t\u00eb dh\u00ebnave ishte af\u00ebrsisht po aq. 5000 lidhje ishin brenda kapaciteteve t\u00eb instanc\u00ebs son\u00eb RDS (gj\u00eb q\u00eb nuk mund t\u00eb themi p\u00ebr dhjet\u00ebra mij\u00ebra). P\u00ebr nj\u00eb arsye, ndodhnin shp\u00ebrthime t\u00eb papritura n\u00eb numrin e lidhjeve.<\/b>, megjithat\u00eb ne nuk v\u00ebzhguam ndonj\u00eb korelacion me k\u00ebrkesat e ardhshme.<\/p>\n

Tani, ne e vendos\u00ebm veten t\u00eb gjenim dhe t\u00eb eliminonim burimin e problemit, dhe jo t\u00eb mjaftoheshim me rindezjen. N\u00eb kodin e baz\u00ebs Quay u b\u00ebn\u00eb disa ndryshime q\u00eb kufizuan numrin e lidhjeve me DB p\u00ebr \u00e7do pun\u00ebtor<\/b> gevent. Ky num\u00ebr u b\u00eb nj\u00eb paramet\u00ebr n\u00eb konfigurim: tani ishte e mundur ta ndryshonim \"n\u00eb flak\u00eb\", pa nd\u00ebrtuar nj\u00eb imazh t\u00eb ri kontejneri. P\u00ebr t\u00eb m\u00ebsuar se sa lidhje mund t\u00eb trajtonte realisht, u zhvilluan disa teste me ambientin staging, ku u vendos\u00ebn vlera t\u00eb ndryshme p\u00ebr t\u00eb par\u00eb se si do t\u00eb p\u00ebrkonte me skenar\u00ebt e testeve t\u00eb ngarkes\u00ebs. N\u00eb fund u zbulua se Quay fillon t\u00eb jap\u00eb gabime 502 kur numri i lidhjeve kalon 10,000.<\/b><\/p>\n

Menj\u00ebher\u00eb e disa variant\u00eb e re e k\u00ebsaj versioni n\u00eb prodhim dhe filluam t\u00eb monitoronim grafik\u00ebn e lidhjeve me baz\u00ebn e t\u00eb dh\u00ebnave. N\u00eb t\u00eb kaluar\u00ebn, baza ishte bllokuar rreth 20 minuta. Pas 30 minutash pa probleme, kishim shpres\u00eb, dhe pas nj\u00eb ore \u2014 siguri. Rind\u00ebrtuam trafikun p\u00ebr shkrim n\u00eb sit dhe filluam analiz\u00ebn postmortem.<\/p>\n

Duke arritur t\u00eb anashkalojm\u00eb problemin q\u00eb shkaktonte bllokimin, ne nuk zbuluam shkaqet e saj t\u00eb v\u00ebrteta<\/b>. U konfirmua se nuk ishte e lidhur 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 kishte punuar me Quay pa ndonj\u00eb problem.<\/p>\n

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

Studimi i detajuar<\/h2>\n

\nQuay.io ka p\u00ebrdorur p\u00ebr gjasht\u00eb vjet cil\u00ebsimet e paracaktuara p\u00ebr t'u lidhur me DB pa asnj\u00eb problem. \u00c7far\u00eb ka ndryshuar? \u00cbsht\u00eb e qart\u00eb se gjat\u00eb gjith\u00eb k\u00ebtij koh\u00eb, trafiku n\u00eb quay.io \u00ebsht\u00eb rritur n\u00eb m\u00ebnyr\u00eb t\u00eb pand\u00ebrprer\u00eb. N\u00eb rastin ton\u00eb, gjith\u00e7ka dukej sikur ishte arritur nj\u00eb kuot\u00eb e caktuar, e cila sh\u00ebrbente si nxit\u00ebs p\u00ebr nj\u00eb val\u00eb lidhjesh. Ne vazhduam t\u00eb shqyrtonim log\u00ebt e DB pas d\u00ebshtimit t\u00eb dyt\u00eb, por nuk gjet\u00ebm asnj\u00eb model ose lidhje t\u00eb dukshme.<\/p>\n

Nd\u00ebrkoh\u00eb ekipi SRE ishte angazhuar n\u00eb p\u00ebrmir\u00ebsime n\u00eb fush\u00ebn e monitorimit t\u00eb k\u00ebrkesave n\u00eb Quay dhe sh\u00ebndetit t\u00eb p\u00ebrgjithsh\u00ebm t\u00eb sh\u00ebrbimit. Iu vendos\u00ebn metrika dhe panele t\u00eb reja monitorimi<\/b>, duke treguar se cilat pjes\u00eb t\u00eb Quay shfryt\u00ebzoheshin m\u00eb shum\u00eb nga klient\u00ebt.<\/p>\n

Quay.io ka punuar normalisht deri m\u00eb 9 qershor. N\u00eb m\u00ebngjes (sip\u00ebr EDT) ne p\u00ebrs\u00ebri ishim d\u00ebshmitar\u00eb t\u00eb nj\u00eb rritjeje t\u00eb konsiderueshme t\u00eb numrit t\u00eb lidhjeve me baz\u00ebn e t\u00eb dh\u00ebnave. K\u00ebt\u00eb her\u00eb nuk ndodhi asnj\u00eb nd\u00ebrprerje<\/b>, pasi parametri i ri kufizonte numrin e tyre dhe nuk lejonte t\u00eb kalonte kapacitetin e MySQL. Megjithat\u00eb, p\u00ebr nj\u00eb periudh\u00eb prej rreth gjysm\u00eb ore, shum\u00eb p\u00ebrdorues raportuan p\u00ebr ngarkes\u00eb t\u00eb ngadalta n\u00eb quay.io. Ne shpejt mblodh\u00ebm t\u00eb gjitha t\u00eb dh\u00ebnat e mundshme, duke shfryt\u00ebzuar mjetet e monitorimit t\u00eb shtuar. Papritmas, nj\u00eb model u b\u00eb i duksh\u00ebm.<\/p>\n

Para sakt\u00ebsisht shkarkimit t\u00eb numrit t\u00eb lidhjeve, nj\u00eb sasi e madhe k\u00ebrkesash kishte ardhur n\u00eb API-n\u00eb e Regjistrit t\u00eb Aplikacioneve<\/b>. Regjistri i Aplikacioneve \u00ebsht\u00eb nj\u00eb funksion pak i njohur n\u00eb quay.io. Ai lejon ruajtjen e gj\u00ebrave si grafikat Helm dhe kontejner\u00ebt me meta t\u00eb pasura. Shumica e p\u00ebrdoruesve t\u00eb quay.io nuk punojn\u00eb me k\u00ebt\u00eb funksion, megjithat\u00eb ai shfryt\u00ebzohet aktivisht nga Red Hat OpenShift. OperatorHub n\u00eb OpenShift ruan t\u00eb gjith\u00eb operator\u00ebt n\u00eb Regjistrin e Aplikacioneve. K\u00ebta operator\u00eb formojn\u00eb baz\u00ebn e ekosistemit t\u00eb ngarkesave t\u00eb pun\u00ebs OpenShift dhe modelit operativ (n\u00eb kuad\u00ebr t\u00eb operacioneve t\u00eb 'dit\u00ebs s\u00eb dyt\u00eb', Day 2), t\u00eb orientuar ndaj partner\u00ebve.<\/p>\n

\u00c7do grumbull OpenShift 4 p\u00ebrdor operatoret nga OperatorHub i integruar p\u00ebr t\u00eb publikuar katalogun e operatoreve q\u00eb jan\u00eb t\u00eb arritsh\u00ebm p\u00ebr instalim dhe p\u00ebr t\u00eb ofruar p\u00ebrdit\u00ebsime p\u00ebr ato q\u00eb jan\u00eb instaluar tashm\u00eb. Me rritjen e popullaritetit t\u00eb OpenShift 4, shkalla e grumbujve n\u00eb t\u00eb gjith\u00eb bot\u00ebn \u00ebsht\u00eb rritur gjithashtu. \u00c7do nga k\u00ebto grumbuj ngarkon p\u00ebrmbajtjen e operatoreve p\u00ebr t\u00eb nisur OperatorHub-in e integruar, duke p\u00ebrdorur App Registry brenda quay.io si backend. N\u00eb k\u00ebrkimin e burimit t\u00eb problemit, ne lam\u00eb pas at\u00eb q\u00eb, me rritjen e gradualshme t\u00eb popullaritetit t\u00eb OpenShift, rriteshin edhe ngarkesat n\u00eb nj\u00eb nga funksionet e rralla t\u00eb p\u00ebrdorura quay.io.<\/b>.<\/p>\n

Ne kemi b\u00ebr\u00eb disa analiza t\u00eb trafikut t\u00eb k\u00ebrkesave n\u00eb App Registry dhe kemi shikuar n\u00eb kodin e regjistrit. Menj\u00ebher\u00eb u zbuluan dob\u00ebsi q\u00eb b\u00ebn\u00eb q\u00eb k\u00ebrkesat p\u00ebr baz\u00ebn e t\u00eb dh\u00ebnave t\u00eb formoheshin n\u00eb m\u00ebnyr\u00eb jo optimale. N\u00ebn ngarkes\u00eb t\u00eb vog\u00ebl, ato nuk shkaktonin ndonj\u00eb shqet\u00ebsim, por me rritjen e ngarkes\u00ebs, ato b\u00ebheshin burim problemesh. App Registry kishte dy endpoint-e problematike q\u00eb nuk reagonin mir\u00eb ndaj rritjes s\u00eb ngarkes\u00ebs: e para jepte nj\u00eb list\u00eb t\u00eb t\u00eb gjitha pakove n\u00eb depo, e dyta ktheu t\u00eb gjith\u00eb blob-\u00ebt p\u00ebr nj\u00eb paket\u00eb.<\/p>\n

Eliminimi i shkakut<\/h2>\n

\nGjat\u00eb jav\u00ebs pasuese, ne u angazhuam n\u00eb optimizimin e kodit t\u00eb vet\u00eb App Registry dhe mjedisit t\u00eb tij. U rishikuan SQL-query-t\u00eb q\u00eb ishin qart\u00eb t\u00eb paefektshme, u hoq\u00ebn thirrjet e panevojshme t\u00eb komand\u00ebs tar<\/code> (ajo \u00ebsht\u00eb aktivizuar me \u00e7do nxjerrje t\u00eb blob'ave), \u00ebsht\u00eb shtuar caching kudo q\u00eb \u00ebsht\u00eb e mundur. M\u00eb pas \u00ebsht\u00eb kryer nj\u00eb testim i gjer\u00eb i performanc\u00ebs dhe \u00ebsht\u00eb krahasuar shpejt\u00ebsia e pun\u00ebs s\u00eb App Registry para dhe pas ndryshimeve.<\/p>\n

K\u00ebrkesat API, q\u00eb m\u00eb par\u00eb merrnin deri n\u00eb gjysm\u00eb minute, tani u ekzekutuan n\u00eb milisekonda.<\/b>. Jav\u00ebn e ardhshme ne do t\u00eb vendosim ndryshimet n\u00eb production, dhe q\u00eb nga ajo koh\u00eb quay.io ka funksionuar me stabilitet. Gjat\u00eb k\u00ebsaj periudhe, jan\u00eb v\u00ebn\u00eb re disa shp\u00ebrthime t\u00eb papritura n\u00eb trafik n\u00eb endpoint'in e App Registry, por p\u00ebrmir\u00ebsimet e b\u00ebra parandaluan nd\u00ebrprerjet n\u00eb funksionimin e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave.<\/p>\n

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

\n\u00cbsht\u00eb e qart\u00eb q\u00eb \u00e7dok\u00ebrkush mundohet t\u00eb shmang\u00eb ndalesat. N\u00eb rastin ton\u00eb, ne besojm\u00eb se prishjet e fundit ndihmuan n\u00eb p\u00ebrmir\u00ebsimin e quay.io. P\u00ebr vete nxor\u00ebm disa m\u00ebsime t\u00eb r\u00ebnd\u00ebsishme q\u00eb duam t\u00eb ndajm\u00eb:<\/p>\n

    \n
  1. T\u00eb dh\u00ebnat se kush dhe si p\u00ebrdor sh\u00ebrbimin tuaj nuk jan\u00eb kurr\u00eb t\u00eb panevojshme.<\/b>. Pasi Quay \"thjesht funksiononte\", kurr\u00eb nuk na erdhi n\u00eb mendje t\u00eb harxhonim koh\u00eb n\u00eb optimizimin e trafik\u00ebve dhe menaxhimin e ngarkes\u00ebs. E gjith\u00eb kjo krijoi nj\u00eb ndjenj\u00eb t\u00eb rreme t\u00eb siguris\u00eb, q\u00eb sh\u00ebrbimi mund t\u00eb shkall\u00ebzohej pafund\u00ebsisht.<\/li>\n
  2. Kur sh\u00ebrbimi bie, rikthimi n\u00eb funksionim \u00ebsht\u00eb prioriteti kryesor.<\/b>. Nd\u00ebrsa Quay vazhdoi t\u00eb vuaj\u00eb nga nj\u00eb baz\u00eb t\u00eb dh\u00ebnash t\u00eb bllokuar gjat\u00eb d\u00ebshtimit t\u00eb par\u00eb, procedurat tona standarde nuk kishin efektin e pritur dhe ne nuk arrit\u00ebm ta rikthejm\u00eb funksionimin e sh\u00ebrbimit me ndihm\u00ebn e tyre. Kjo \u00e7oi n\u00eb nj\u00eb situat\u00eb ku duhej t\u00eb harxhonim koh\u00eb n\u00eb analiz\u00eb dhe mbledhje t\u00eb t\u00eb dh\u00ebnave me shpres\u00ebn p\u00ebr t\u00eb gjetur shkakun themelor \u2014 n\u00eb vend q\u00eb t\u00eb p\u00ebrqendrohemi n\u00eb rikthimin e funksionalitetit.<\/li>\n
  3. Vler\u00ebsoni ndikimin e \u00e7do funksioni t\u00eb sh\u00ebrbimit<\/b>. Klient\u00ebt rrall\u00eb e p\u00ebrdornin Regjistrin e Aplikacioneve, k\u00ebshtu q\u00eb ai nuk ishte prioritet p\u00ebr ekipin ton\u00eb. Kur disa funksione t\u00eb produktit zakonisht nuk p\u00ebrdoren, defektet e tyre 'shfaqen' rrall\u00eb, dhe zhvilluesit ndalojn\u00eb s\u00eb mbik\u00ebqyruri kodin. \u00cbsht\u00eb e leht\u00eb t\u00eb b\u00ebhesh viktim\u00eb e nj\u00eb iluzioni se k\u00ebshtu duhet t\u00eb jet\u00eb \u2014 derisa papritmas ky funksion t\u00eb p\u00ebrfshihet n\u00eb nj\u00eb incident 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 nuk ndalon kurr\u00eb dhe ne po e p\u00ebrmir\u00ebsojm\u00eb vazhdimisht at\u00eb. Volumet 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 kemi si detyra:<\/p>\n

      \n
    1. Zhvillimi i replika t\u00eb bazave t\u00eb dh\u00ebnash vet\u00ebm p\u00ebr lexim, p\u00ebr t\u00eb ndihmuar sh\u00ebrbimin t\u00eb p\u00ebrballoj\u00eb trafikun p\u00ebrkat\u00ebs n\u00eb rast se ndodhin probleme me ekzemplar\u00ebt kryesor\u00eb t\u00eb RDS.<\/li>\n
    2. P\u00ebrdit\u00ebsimi i ekzemplarit RDS. Versioni aktual vet\u00eb nuk \u00ebsht\u00eb nj\u00eb problem. M\u00eb tep\u00ebr, thjesht duam t\u00eb heqim ndjekjen e rreme (n\u00eb t\u00eb cil\u00ebn shkuam gjat\u00eb d\u00ebshtimit); mbajtja e softuerit n\u00eb gjendje t\u00eb p\u00ebrdit\u00ebsuar do t\u00eb eliminoj\u00eb nj\u00eb tjet\u00ebr faktor n\u00eb rast t\u00eb \u00e7lirimeve t\u00eb ardhshme.<\/li>\n
    3. Caching t\u00eb shtuar n\u00eb t\u00eb gjith\u00eb klasterin. Ne vazhdojm\u00eb t\u00eb k\u00ebrkojm\u00eb fusha ku caching mund t\u00eb ndihmoj\u00eb p\u00ebr t\u00eb ulur ngarkes\u00ebn n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave.<\/li>\n
    4. Shtimi i nj\u00eb firewall-i p\u00ebr aplikacione web (WAF), p\u00ebr t\u00eb par\u00eb kush dhe pse lidhet me quay.io.<\/li>\n
    5. Nga rilizimi i ardhsh\u00ebm, klaster\u00ebt Red Hat OpenShift do t\u00eb p\u00ebrjashtojn\u00eb Regjistrin e Aplikacioneve n\u00eb favor t\u00eb katalog\u00ebve t\u00eb operator\u00ebve (Operator Catalogs), t\u00eb bazuar n\u00eb imazhe kontejner\u00ebsh t\u00eb disponueshme n\u00eb quay.io.<\/li>\n
    6. Z\u00ebvend\u00ebsimi afatgjat\u00eb i Regjistrit t\u00eb Aplikacioneve mund t\u00eb jet\u00eb mb\u00ebshtetja p\u00ebr specifikimet e artefakteve t\u00eb Iniciativ\u00ebs s\u00eb Kontejner\u00ebve Open (OCI). Aktualisht, kjo po realizohet si nj\u00eb funksionalitet vendas i Quay dhe do t\u00eb jet\u00eb n\u00eb dispozicion p\u00ebr p\u00ebrdoruesit, kur specifikimi vet\u00eb t\u00eb miratohet p\u00ebrfundimisht.<\/li>\n<\/ol>\n

      \nGjitha ato q\u00eb p\u00ebrmenden m\u00eb sip\u00ebr jan\u00eb pjes\u00eb e investimeve t\u00eb vazhdueshme t\u00eb Red Hat n\u00eb quay.io nd\u00ebrsa kalojm\u00eb nga nj\u00eb ekip i vog\u00ebl \"n\u00eb stilin e nj\u00eb startupi\" n\u00eb nj\u00eb platform\u00eb t\u00eb zhvilluar, t\u00eb menaxhuar nga SRE. 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 (p\u00ebrfshir\u00eb Red Hat!) dhe p\u00ebrpiqemi t\u00eb jemi sa m\u00eb t\u00eb hapur n\u00eb rrug\u00ebn ton\u00eb p\u00ebr t\u00eb adresuar \u00e7\u00ebshtjet e fundit dhe p\u00ebrpjekjet tona p\u00ebr t\u2019u b\u00ebr\u00eb m\u00eb t\u00eb mir\u00eb.<\/p>\n

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

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