{"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\/cs\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Post Mortem dostupnosti Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pozn. p\u0159ek.<\/b>: na za\u010d\u00e1tku srpna Red Hat ve\u0159ejn\u011b informovala o \u0159e\u0161en\u00ed probl\u00e9m\u016f s dostupnost\u00ed, kter\u00e9 v p\u0159edchoz\u00edch m\u011bs\u00edc\u00edch br\u00e1nily u\u017eivatel\u016fm jej\u00ed slu\u017eby Quay.io<\/a><\/noindex> (z\u00e1kladem je registr obraz\u016f kontejner\u016f, kter\u00fd spole\u010dnost z\u00edskala s akvizic\u00ed CoreOS). Bez ohledu na va\u0161i z\u00e1jem o tuto slu\u017ebu, je pou\u010dn\u00e9 sledovat cestu, kterou SRE in\u017een\u00fd\u0159i spole\u010dnosti pro\u0161li p\u0159i diagnostice a odstran\u011bn\u00ed p\u0159\u00ed\u010din selh\u00e1n\u00ed.<\/i><\/p>\n

\"Post
\n
\n19. kv\u011btna, brzy r\u00e1no (podle letn\u00edho severoamerick\u00e9ho v\u00fdchodn\u00edho \u010dasu, EDT), slu\u017eba quay.io selhala. Selh\u00e1n\u00ed zas\u00e1hlo jak u\u017eivatele quay.io, tak open source projekty, kter\u00e9 pou\u017e\u00edvaj\u00ed quay.io jako platformu pro sestaven\u00ed a distribuci softwaru. Red Hat si v\u00e1\u017e\u00ed d\u016fv\u011bry obou skupin.<\/p>\n

T\u00fdm SRE in\u017een\u00fdr\u016f se okam\u017eit\u011b zapojil do pr\u00e1ce a sna\u017eil se co nejd\u0159\u00edve stabilizovat provoz slu\u017eby Quay. B\u011bhem t\u00e9to doby v\u0161ak klienti ztratili mo\u017enost pushovat nov\u00e9 obrazy a pouze ob\u010das se jim poda\u0159ilo pullovat existuj\u00edc\u00ed. Z nezn\u00e1m\u00e9ho d\u016fvodu se datab\u00e1ze quay.io blokovala po \u0161k\u00e1lov\u00e1n\u00ed slu\u017eby na pln\u00fd v\u00fdkon.<\/a><\/noindex><\/p>\n

\u00abCo se zm\u011bnilo?<\/b>\u00bb \u2014 to je prvn\u00ed ot\u00e1zka, kterou je b\u011b\u017en\u011b kladeno v podobn\u00fdch p\u0159\u00edpadech. V\u0161imli jsme si, \u017ee t\u011bsn\u011b p\u0159ed probl\u00e9mem za\u010dal cluster OpenShift Dedicated (na kter\u00e9m b\u011b\u017e\u00ed quay.io) aktualizaci na verzi 4.3.19. Proto\u017ee quay.io b\u011b\u017e\u00ed na Red Hat OpenShift Dedicated (OSD), pravideln\u00e9 aktualizace byly ka\u017edodenn\u00ed operac\u00ed a nikdy nezp\u016fsobily \u017e\u00e1dn\u00e9 probl\u00e9my. Nav\u00edc jsme v uplynul\u00fdch \u0161esti m\u011bs\u00edc\u00edch n\u011bkolikr\u00e1t aktualizovali clustery Quay bez jak\u00fdchkoli p\u0159eru\u0161en\u00ed v poskytov\u00e1n\u00ed slu\u017eeb.<\/p>\n

Zat\u00edmco jsme se sna\u017eili obnovit provoz slu\u017eby, jin\u00ed in\u017een\u00fd\u0159i za\u010dali p\u0159ipravovat nov\u00fd OSD cluster s p\u0159edchoz\u00ed verz\u00ed softwaru, aby v p\u0159\u00edpad\u011b pot\u0159eby mohli v\u0161echno rozd\u011blit na n\u011bm.<\/p>\n

Anal\u00fdza prvn\u00edch p\u0159\u00ed\u010din<\/h2>\n

\nHlavn\u00edm symptomem v\u00fdpadku byla lavina des\u00edtek tis\u00edc p\u0159ipojen\u00ed k DB, kv\u016fli kter\u00fdm byl instanci MySQL v podstat\u011b neschopn\u00e1. D\u00edky tomu bylo t\u011b\u017ek\u00e9 diagnostikovat probl\u00e9m. Stanovili jsme limit na maxim\u00e1ln\u00ed po\u010det p\u0159ipojen\u00ed od klient\u016f, aby t\u00fdm SRE mohl l\u00e9pe posoudit situaci. Nebyly zaznamen\u00e1ny \u017e\u00e1dn\u00e9 neobvykl\u00e9 provozy k datab\u00e1zi: ve skute\u010dnosti v\u011bt\u0161ina dotaz\u016f byla na \u010dten\u00ed a jen n\u011bkolik bylo na z\u00e1pis.<\/p>\n

Tak\u00e9 jsme se pokusili identifikovat vzor v provozu datab\u00e1ze, kter\u00fd by mohl zp\u016fsobit tuto lavinu. Nicm\u00e9n\u011b se n\u00e1m nepoda\u0159ilo naj\u00edt \u017e\u00e1dn\u00e9 vzorce v log\u00e1ch. \u010cekaj\u00edc na p\u0159ipravenost nov\u00e9ho clusteru s OSD 4.3.18, pokra\u010dovali jsme v pokusech o spu\u0161t\u011bn\u00ed pod\u016f quay.io. Ka\u017ed\u00fdkr\u00e1t, kdy\u017e cluster dos\u00e1hl pln\u00e9ho v\u00fdkonu, datab\u00e1ze zamrzla. To znamenalo, \u017ee bylo nutn\u00e9 restartovat instanci RDS vedle v\u0161ech pod\u016f quay.io.<\/p>\n

K ve\u010deru jsme stabilizovali slu\u017ebu v re\u017eimu read-only a deaktivovali maxim\u00e1ln\u00ed po\u010det nepodstatn\u00fdch funkc\u00ed (nap\u0159\u00edklad shroma\u017e\u010fov\u00e1n\u00ed odpadu v n\u00e1zvov\u00e9m prostoru), abychom sn\u00ed\u017eili z\u00e1t\u011b\u017e na DB. Zmrazen\u00ed se zastavilo, ale p\u0159\u00ed\u010dina nebyla st\u00e1le nalezena<\/b>. Nov\u00fd cluster OSD byl p\u0159ipraven, a my jsme p\u0159e\u0161li na slu\u017ebu, p\u0159ipojili provoz a pokra\u010dovali v monitorov\u00e1n\u00ed.<\/p>\n

Quay.io stabiln\u011b fungoval na nov\u00e9m OSD clusteru, a tak jsme se vr\u00e1tili k log\u016fm datab\u00e1ze, ale st\u00e1le se n\u00e1m nepoda\u0159ilo odhalit korelaci vysv\u011btluj\u00edc\u00ed z\u00e1mky. In\u017een\u00fd\u0159i OpenShift s n\u00e1mi spolupracovali, aby se pokusili pochopit, zda zm\u011bny v Red Hat OpenShift 4.3.19 mohly zp\u016fsobit probl\u00e9my s Quay. Nicm\u00e9n\u011b se nic neobjevilo, a nepoda\u0159ilo se reprodukovat probl\u00e9m v laboratorn\u00edch podm\u00ednk\u00e1ch<\/b>.<\/p>\n

Druh\u00fd v\u00fdpadek<\/h2>\n

\n28. kv\u011btna, kr\u00e1tce p\u0159ed polednem EDT, quay.io znovu spadl se stejn\u00fdmi symptomy: fungov\u00e1n\u00ed datab\u00e1ze bylo blokov\u00e1no. A znovu jsme nasadili v\u0161echny s\u00edly na vy\u0161et\u0159ov\u00e1n\u00ed. Nejd\u0159\u00edve bylo t\u0159eba obnovit provoz slu\u017eby. Nicm\u00e9n\u011b tentokr\u00e1t restart RDS a restart pod\u016f quay.io nep\u0159inesly \u017e\u00e1dn\u00e9 v\u00fdsledky<\/b>dal\u0161\u00ed lavina p\u0159ipojen\u00ed p\u0159ehnala datab\u00e1zi. Ale pro\u010d?<\/p>\n

Quay je naps\u00e1n v Pythonu a ka\u017ed\u00fd pod funguje jako jednotn\u00fd monolitn\u00ed kontejner. V prost\u0159ed\u00ed kontejneru b\u011b\u017e\u00ed sou\u010dasn\u011b mnoho paraleln\u00edch \u00faloh. Pou\u017e\u00edv\u00e1me knihovnu gevent<\/code> pod gunicorn<\/code> pro zpracov\u00e1n\u00ed webov\u00fdch po\u017eadavk\u016f. Kdy\u017e do Quay p\u0159ijde po\u017eadavek (p\u0159es na\u0161e vlastn\u00ed API nebo p\u0159es API Dockeru), p\u0159id\u011bl\u00ed se mu gevent worker. Obvykle tento worker mus\u00ed nav\u00e1zat spojen\u00ed s datab\u00e1z\u00ed. Po prvn\u00edm selh\u00e1n\u00ed jsme zjistili, \u017ee se gevent worke\u0159i p\u0159ipojovali k datab\u00e1zi pomoc\u00ed v\u00fdchoz\u00edch nastaven\u00ed.<\/p>\n

Vzhledem k zna\u010dn\u00e9mu po\u010dtu pod\u016f Quay a tis\u00edc\u016fm p\u0159\u00edchoz\u00edch po\u017eadavk\u016f za sekundu teoreticky mohlo velk\u00e9 mno\u017estv\u00ed p\u0159ipojen\u00ed k datab\u00e1zi p\u0159et\u00ed\u017eit instanci MySQL. D\u00edky monitorov\u00e1n\u00ed jsme v\u011bd\u011bli, \u017ee Quay pr\u016fm\u011brn\u011b zpracov\u00e1v\u00e1 5 tis\u00edc po\u017eadavk\u016f za sekundu. P\u0159ibli\u017en\u011b stejn\u00fd byl i po\u010det p\u0159ipojen\u00ed k datab\u00e1zi. 5 tis\u00edc p\u0159ipojen\u00ed s rezervou vyhovovalo schopnostem na\u0161\u00ed instance RDS (co\u017e nelze \u0159\u00edct o des\u00edtk\u00e1ch tis\u00edc). Z n\u011bjak\u00e9ho d\u016fvodu doch\u00e1zelo k neo\u010dek\u00e1van\u00fdm v\u00fdskyt\u016fm po\u010dtu p\u0159ipojen\u00ed<\/b>, ale nev\u0161imli jsme si \u017e\u00e1dn\u00e9 korelace s p\u0159ich\u00e1zej\u00edc\u00edmi po\u017eadavky.<\/p>\n

Tentokr\u00e1t jsme se pevn\u011b rozhodli naj\u00edt a odstranit zdroj probl\u00e9mu, m\u00edsto abychom se omezili na restartov\u00e1n\u00ed. Do k\u00f3du Quay byly provedeny zm\u011bny, kter\u00e9 omezily po\u010det p\u0159ipojen\u00ed k datab\u00e1zi pro ka\u017ed\u00e9ho workera<\/b> gevent. Tento po\u010det se stal parametrem v konfiguraci: bylo mo\u017en\u00e9 jej m\u011bnit \u201eza chodu\u201c, ani\u017e bychom museli sestavit nov\u00fd obraz kontejneru. Abychom zjistili, kolik p\u0159ipojen\u00ed je skute\u010dn\u011b mo\u017en\u00e9 zpracovat, provedli jsme n\u011bkolik test\u016f ve staging prost\u0159ed\u00ed, kde jsme nastavili r\u016fzn\u00e9 hodnoty, abychom zjistili, jak to ovlivn\u00ed sc\u00e9n\u00e1\u0159e z\u00e1t\u011b\u017eov\u00e9ho testov\u00e1n\u00ed. Nakonec se uk\u00e1zalo, \u017ee Quay za\u010d\u00edn\u00e1 vyhazovat chyby 502, kdy\u017e po\u010det p\u0159ipojen\u00ed p\u0159ekro\u010d\u00ed 10 tis\u00edc.<\/b><\/p>\n

Okam\u017eit\u011b jsme nasadili tuto novou verzi do produkce a za\u010dali sledovat graf p\u0159ipojen\u00ed k datab\u00e1zi. D\u0159\u00edve byla datab\u00e1ze blokov\u00e1na p\u0159ibli\u017en\u011b po 20 minut\u00e1ch. Po 30 bezprobl\u00e9mov\u00fdch minut\u00e1ch jsme m\u011bli nad\u011bji, a po hodin\u011b jsme byli p\u0159esv\u011bd\u010deni. Obnovili jsme provoz z\u00e1pisu na str\u00e1nk\u00e1ch a zah\u00e1jili postmortem anal\u00fdzu.<\/p>\n

Poda\u0159ilo se n\u00e1m obej\u00edt probl\u00e9m vedouc\u00ed k blokaci, ale nevyjasnili jsme jeho skute\u010dn\u00e9 p\u0159\u00ed\u010diny<\/b>. Potvrdilo se, \u017ee nesouvis\u00ed s jak\u00fdmiikoli zm\u011bnami v OpenShift 4.3.19, proto\u017ee to sam\u00e9 se stalo i na verzi 4.3.18, kter\u00e1 p\u0159edt\u00edm fungovala s Quay bez jak\u00fdchkoli probl\u00e9m\u016f.<\/p>\n

V clusteru se o\u010dividn\u011b skr\u00fdvalo n\u011bco dal\u0161\u00edho.<\/p>\n

Podrobn\u00e1 anal\u00fdza<\/h2>\n

\nQuay.io ji\u017e \u0161est let vyu\u017e\u00edv\u00e1 v\u00fdchoz\u00ed nastaven\u00ed pro p\u0159ipojen\u00ed k datab\u00e1zi bez jak\u00fdchkoli probl\u00e9m\u016f. Co se zm\u011bnilo? Je jasn\u00e9, \u017ee v pr\u016fb\u011bhu t\u00e9to doby neust\u00e1le rostl provoz na quay.io. V na\u0161em p\u0159\u00edpad\u011b to vypadalo, jako by bylo dosa\u017eeno ur\u010dit\u00e9ho prahov\u00e9ho bodu, kter\u00fd spustil lavinu p\u0159ipojen\u00ed. Pokra\u010dovali jsme ve zkoum\u00e1n\u00ed datab\u00e1zov\u00fdch log\u016f po druh\u00e9m v\u00fdpadku, ale nena\u0161li jsme \u017e\u00e1dn\u00e9 vzory nebo zjevn\u00e9 souvislosti.<\/p>\n

Mezit\u00edm se t\u00fdm SRE zab\u00fdval zlep\u0161en\u00edm sledov\u00e1n\u00ed po\u017eadavk\u016f v Quay a celkov\u00e9ho zdrav\u00ed slu\u017eby. Byly nasazeny nov\u00e9 metriky a panely pro monitorov\u00e1n\u00ed<\/b>, kter\u00e9 ukazuj\u00ed, kter\u00e9 \u010d\u00e1sti Quay maj\u00ed nejv\u011bt\u0161\u00ed z\u00e1jem ze strany z\u00e1kazn\u00edk\u016f.<\/p>\n

Quay.io spr\u00e1vn\u011b fungoval a\u017e do 9. \u010dervna. R\u00e1no (podle EDT) jsme op\u011bt byli sv\u011bdky v\u00fdznamn\u00e9ho n\u00e1r\u016fstu po\u010dtu p\u0159ipojen\u00ed k datab\u00e1zi. Tentokr\u00e1t k v\u00fdpadku nedo\u0161lo<\/b>, proto\u017ee nov\u00e1 konfigurace omezovala jejich po\u010det a br\u00e1nila p\u0159ekro\u010den\u00ed kapacity MySQL. Nicm\u00e9n\u011b p\u0159ibli\u017en\u011b po dobu p\u016fl hodiny mnoho u\u017eivatel\u016f hl\u00e1silo pomalou odezvu quay.io. Rychle jsme shrom\u00e1\u017edili v\u0161echny dostupn\u00e9 \u00fadaje pomoc\u00ed nov\u011b p\u0159idan\u00fdch monitorovac\u00edch n\u00e1stroj\u016f. N\u00e1hle se objevily vzory.<\/p>\n

P\u0159ed samotn\u00fdm n\u00e1r\u016fstem po\u010dtu p\u0159ipojen\u00ed p\u0159i\u0161lo velk\u00e9 mno\u017estv\u00ed po\u017eadavk\u016f na App Registry API<\/b>. App Registry je m\u00e1lo zn\u00e1m\u00e1 funkce quay.io. Umo\u017e\u0148uje uchov\u00e1vat takov\u00e9 v\u011bci, jako jsou Helm grafy a kontejnerov\u00e9 bohat\u00e9 (rich) metadata. V\u011bt\u0161ina u\u017eivatel\u016f quay.io s touto funkc\u00ed nepracuje, nicm\u00e9n\u011b je aktivn\u011b pou\u017e\u00edv\u00e1na Red Hat OpenShift. OperatorHub integrovan\u00fd v OpenShift uchov\u00e1v\u00e1 v\u0161echny oper\u00e1tory v App Registry. Tito oper\u00e1to\u0159i vytv\u00e1\u0159ej\u00ed z\u00e1klad pro ekosyst\u00e9m pracovn\u00edch z\u00e1t\u011b\u017e\u00ed OpenShift a provozn\u00ed model (v r\u00e1mci operac\u00ed \u201edruh\u00e9ho dne\u201c, Day 2), orientovan\u00fd na partnery.<\/p>\n

Ka\u017ed\u00fd cluster OpenShift 4 pou\u017e\u00edv\u00e1 oper\u00e1tory z integrovan\u00e9ho OperatorHubu k publikaci katalogu oper\u00e1tor\u016f dostupn\u00fdch pro instalaci a zaji\u0161t\u011bn\u00ed aktualizac\u00ed pro ji\u017e nainstalovan\u00e9. S rostouc\u00ed popularitou OpenShift 4 se zv\u00fd\u0161il i po\u010det cluster\u016f po cel\u00e9m sv\u011bt\u011b. Ka\u017ed\u00fd z t\u011bchto cluster\u016f na\u010d\u00edt\u00e1 obsah oper\u00e1tor\u016f, aby spustil integrovan\u00fd OperatorHub, pou\u017e\u00edvaj\u00edc\u00ed App Registry uvnit\u0159 quay.io jako backend. V hled\u00e1n\u00ed zdroje probl\u00e9mu jsme opomn\u011bli, \u017ee s postupn\u00fdm n\u00e1r\u016fstem popularity OpenShift nar\u016fstalo i zat\u00ed\u017een\u00ed jedn\u00e9 z m\u00e1lo vyu\u017e\u00edvan\u00fdch funkc\u00ed quay.io.<\/b>.<\/p>\n

Provedli jsme ur\u010ditou anal\u00fdzu provozu po\u017eadavk\u016f App Registry a nahl\u00e9dli do k\u00f3du registru. Okam\u017eit\u011b se uk\u00e1zaly nedostatky, kter\u00e9 zp\u016fsobovaly, \u017ee byly po\u017eadavky na datab\u00e1zi formulov\u00e1ny suboptim\u00e1ln\u011b. P\u0159i n\u00edzk\u00e9 z\u00e1t\u011b\u017ei nezp\u016fsobovaly \u017e\u00e1dn\u00e9 pot\u00ed\u017ee, ale s jej\u00edm zv\u00fd\u0161en\u00edm se st\u00e1valy zdrojem probl\u00e9m\u016f. App Registry m\u011bl dva problematick\u00e9 endpointy, kter\u00e9 \u0161patn\u011b reagovaly na zvy\u0161uj\u00edc\u00ed se z\u00e1t\u011b\u017e: prvn\u00ed vyd\u00e1val seznam v\u0161ech bal\u00ed\u010dk\u016f v repozit\u00e1\u0159i, druh\u00fd vracel v\u0161echny blob pro bal\u00ed\u010dek.<\/p>\n

Odstran\u011bn\u00ed p\u0159\u00ed\u010din<\/h2>\n

\nCel\u00fd n\u00e1sleduj\u00edc\u00ed t\u00fdden jsme se v\u011bnovali optimalizaci k\u00f3du samotn\u00e9ho registru aplikac\u00ed a jeho okol\u00ed. Byly p\u0159epracov\u00e1ny jasn\u011b neefektivn\u00ed SQL dotazy, odstran\u011bny zbyte\u010dn\u00e9 po\u017eadavky na p\u0159\u00edkaz tar<\/code> (spou\u0161t\u011bla se p\u0159i ka\u017ed\u00e9m vyta\u017een\u00ed blob\u016f), bylo p\u0159id\u00e1no mezipam\u011b\u0165 v\u0161ude, kde to bylo mo\u017en\u00e9. Pot\u00e9 bylo provedeno rozs\u00e1hl\u00e9 testov\u00e1n\u00ed v\u00fdkonu a srovn\u00e1n\u00ed rychlosti pr\u00e1ce App Registry p\u0159ed a po zm\u011bn\u00e1ch.<\/p>\n

API dotazy, kter\u00e9 d\u0159\u00edve trvaly a\u017e p\u016fl minuty, nyn\u00ed byly vykon\u00e1v\u00e1ny za milisekundy.<\/b>. V p\u0159\u00ed\u0161t\u00edm t\u00fddnu jsme nasadili zm\u011bny do produkce a od t\u00e9 doby quay.io funguje stabiln\u011b. B\u011bhem t\u00e9to doby jsme zaznamenali n\u011bkolik ostr\u00fdch n\u00e1r\u016fst\u016f provozu na endpointu App Registry, ale proveden\u00e1 vylep\u0161en\u00ed zabr\u00e1nila v\u00fdpadk\u016fm datab\u00e1ze.<\/p>\n

Co jsme se nau\u010dili?<\/h2>\n

\nJe jasn\u00e9, \u017ee ka\u017ed\u00fd servis se sna\u017e\u00ed vyhnout v\u00fdpadk\u016fm. V na\u0161em p\u0159\u00edpad\u011b v\u011b\u0159\u00edme, \u017ee ned\u00e1vn\u00e9 probl\u00e9my p\u0159isp\u011bly k tomu, aby quay.io bylo lep\u0161\u00edm. Z\u00edskali jsme n\u011bkolik z\u00e1kladn\u00edch lekc\u00ed, kter\u00e9 bychom cht\u011bli sd\u00edlet:<\/p>\n

    \n
  1. Informace o tom, kdo a jak pou\u017e\u00edv\u00e1 v\u00e1\u0161 servis, nejsou nikdy zbyte\u010dn\u00e9.<\/b>Jeliko\u017e Quay 'jednodu\u0161e fungoval', nikdy jsme nem\u011bli pot\u0159ebu tr\u00e1vit \u010das optimalizac\u00ed provozu a \u0159\u00edzen\u00edm z\u00e1t\u011b\u017ee. To v\u0161e vytvo\u0159ilo fale\u0161n\u00fd pocit bezpe\u010d\u00ed, \u017ee slu\u017eba m\u016f\u017ee \u0161k\u00e1lovat do nekone\u010dna.<\/li>\n
  2. Kdy\u017e slu\u017eba sel\u017ee, obnova jej\u00ed funk\u010dnosti je hlavn\u00ed prioritou.<\/b>. Vzhledem k tomu, \u017ee Quay nad\u00e1le trp\u011bl blokovanou datab\u00e1z\u00ed b\u011bhem prvn\u00edho v\u00fdpadku, na\u0161e standardn\u00ed postupy nem\u011bly o\u010dek\u00e1van\u00fd efekt a nemohli jsme obnovit provoz slu\u017eby s jejich pomoc\u00ed. To vedlo k situaci, kdy jsme museli str\u00e1vit \u010das anal\u00fdzou a shroma\u017e\u010fov\u00e1n\u00edm dat v nad\u011bji, \u017ee najdeme p\u0159\u00ed\u010dinu \u2014 m\u00edsto abychom ve\u0161ker\u00e9 \u00fasil\u00ed zam\u011b\u0159ili na obnoven\u00ed funk\u010dnosti.<\/li>\n
  3. Hodno\u0165te dopad ka\u017ed\u00e9 funkce slu\u017eby<\/b>. Klienti z\u0159\u00eddka pou\u017e\u00edvali App Registry, tak\u017ee nebyl prioritou pro n\u00e1\u0161 t\u00fdm. Kdy\u017e se n\u011bkter\u00e9 funkce produktu t\u00e9m\u011b\u0159 nepou\u017e\u00edvaj\u00ed, jejich chyby se 'vyno\u0159uj\u00ed' z\u0159\u00eddka a v\u00fdvoj\u00e1\u0159i p\u0159est\u00e1vaj\u00ed sledovat k\u00f3d. Snadno se m\u016f\u017eete st\u00e1t ob\u011bt\u00ed omylu, \u017ee to tak m\u00e1 b\u00fdt \u2014 a\u017e se tato funkce najednou ocitne v centru rozs\u00e1hl\u00e9ho incidentu.<\/li>\n<\/ol>\n

    <\/p>\n

    Co d\u00e1l?<\/h2>\n

    \nPr\u00e1ce na zaji\u0161t\u011bn\u00ed stability slu\u017eby nikdy nekon\u010d\u00ed a neust\u00e1le ji zlep\u0161ujeme. Objem provozu na quay.io nad\u00e1le roste a uv\u011bdomujeme si, \u017ee jsme povinni ud\u011blat v\u0161e pro to, abychom splnili d\u016fv\u011bru z\u00e1kazn\u00edk\u016f. Proto v sou\u010dasnosti pracujeme na n\u00e1sleduj\u00edc\u00edch \u00fakolech:<\/p>\n

      \n
    1. Nasazen\u00ed replik datab\u00e1z\u00ed pouze pro \u010dten\u00ed, aby pomohly slu\u017eb\u011b zpracov\u00e1vat p\u0159\u00edslu\u0161n\u00fd provoz v p\u0159\u00edpad\u011b probl\u00e9m\u016f s hlavn\u00edm exempl\u00e1\u0159em RDS.<\/li>\n
    2. Aktualizace exempl\u00e1\u0159e RDS. Aktu\u00e1ln\u00ed verze sama o sob\u011b nen\u00ed probl\u00e9m. Sp\u00ed\u0161e si jen p\u0159ejeme odstranit fale\u0161nou stopu (kterou jsme sledovali b\u011bhem v\u00fdpadku); udr\u017eov\u00e1n\u00ed softwaru v aktu\u00e1ln\u00edm stavu odstran\u00ed dal\u0161\u00ed faktor v p\u0159\u00edpad\u011b budouc\u00edch v\u00fdpadk\u016f.<\/li>\n
    3. Dal\u0161\u00ed mezipam\u011b\u0165 v cel\u00e9m klastru. Pokra\u010dujeme v hled\u00e1n\u00ed oblast\u00ed, kde by mezipam\u011b\u0165 mohla sn\u00ed\u017eit zat\u00ed\u017een\u00ed datab\u00e1ze.<\/li>\n
    4. P\u0159id\u00e1n\u00ed firewallu webov\u00fdch aplikac\u00ed (WAF), abychom vid\u011bli, kdo a pro\u010d se p\u0159ipojuje k quay.io.<\/li>\n
    5. Od p\u0159\u00ed\u0161t\u00edho vyd\u00e1n\u00ed se klastry Red Hat OpenShift vzdaj\u00ed App Registry ve prosp\u011bch katalog\u016f oper\u00e1tor\u016f (Operator Catalogs), kter\u00e9 jsou zalo\u017eeny na kontejnerech dostupn\u00fdch na quay.io.<\/li>\n
    6. Dlouhodobou n\u00e1hradou App Registry by mohla b\u00fdt podpora specifikac\u00ed artefakt\u016f Open Container Initiative (OCI). V sou\u010dasn\u00e9 dob\u011b je implementov\u00e1na jako nativn\u00ed funkce Quay a bude dostupn\u00e1 u\u017eivatel\u016fm, jakmile bude specifikace definitivn\u011b schv\u00e1lena.<\/li>\n<\/ol>\n

      \nV\u0161e v\u00fd\u0161e uveden\u00e9 je sou\u010d\u00e1st\u00ed pokra\u010duj\u00edc\u00edch investic spole\u010dnosti Red Hat do quay.io, jak p\u0159ech\u00e1z\u00edme od mal\u00e9 t\u00fdmu \u201eve stylu startupu\u201c k vysp\u011bl\u00e9 platform\u011b \u0159\u00edzen\u00e9 SRE. V\u00edme, \u017ee na quay.io se spol\u00e9h\u00e1 mnoho na\u0161ich z\u00e1kazn\u00edk\u016f (v\u010detn\u011b Red Hat!) a sna\u017e\u00edme se b\u00fdt co nejotev\u0159en\u011bj\u0161\u00ed ohledn\u011b ned\u00e1vn\u00fdch poruch a pokra\u010duj\u00edc\u00edch snah st\u00e1t se lep\u0161\u00edmi.<\/p>\n

      P.S. od p\u0159ekladatele<\/h2>\n

      \nP\u0159e\u010dt\u011bte si tak\u00e9 n\u00e1\u0161 blog:<\/p>\n