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

Przyp. t\u0142um.<\/b>: na pocz\u0105tku sierpnia Red Hat publicznie og\u0142osi\u0142 rozwi\u0105zanie problem\u00f3w z dost\u0119pno\u015bci\u0105, kt\u00f3re wyst\u0119powa\u0142y w poprzednich miesi\u0105cach u u\u017cytkownik\u00f3w jego us\u0142ugi Quay.io<\/a><\/noindex> (jego podstaw\u0105 jest rejestr dla obraz\u00f3w kontener\u00f3w, kt\u00f3ry firma przej\u0119\u0142a wraz z zakupem CoreOS). Bez wzgl\u0119du na Twoje zainteresowanie t\u0105 us\u0142ug\u0105, sam proces, przez kt\u00f3ry przeszli in\u017cynierowie SRE firmy w celu diagnozowania i usuwania przyczyn awarii, jest pouczaj\u0105cy.<\/i><\/p>\n

\"Post
\n
\n19 maja, wczesnym rankiem (wed\u0142ug letniego czasu wschodnioameryka\u0144skiego, EDT), us\u0142uga quay.io uleg\u0142a awarii. Incydent dotkn\u0105\u0142 zar\u00f3wno u\u017cytkownik\u00f3w quay.io, jak i projekty Open Source, kt\u00f3re korzystaj\u0105 z quay.io jako platformy do budowy i dystrybucji oprogramowania. Red Hat ceni zaufanie zar\u00f3wno jednych, jak i drugich.<\/p>\n

Zesp\u00f3\u0142 in\u017cynier\u00f3w SRE natychmiast przyst\u0105pi\u0142 do pracy, staraj\u0105c si\u0119 jak najszybciej ustabilizowa\u0107 dzia\u0142anie us\u0142ugi Quay. Jednak w trakcie tych dzia\u0142a\u0144 klienci stracili mo\u017cliwo\u015b\u0107 przesy\u0142ania nowych obraz\u00f3w, a jedynie od czasu do czasu mogli pobiera\u0107 istniej\u0105ce. Z nieznanych powod\u00f3w baza danych quay.io blokowa\u0142a si\u0119 po skalowaniu us\u0142ugi do pe\u0142nej mocy.<\/a><\/noindex><\/p>\n

\u00abCo si\u0119 zmieni\u0142o?<\/b>\u00bb \u2014 to pierwsze pytanie, kt\u00f3re w takich przypadkach zazwyczaj si\u0119 stawia. Zauwa\u017cyli\u015bmy, \u017ce kr\u00f3tko przed problemem klaster OpenShift Dedicated (na kt\u00f3rym dzia\u0142a quay.io) zacz\u0105\u0142 aktualizacj\u0119 do wersji 4.3.19. Poniewa\u017c quay.io dzia\u0142a na Red Hat OpenShift Dedicated (OSD), regularne aktualizacje by\u0142y codzienno\u015bci\u0105 i nigdy nie prowadzi\u0142y do problem\u00f3w. Co wi\u0119cej, w ci\u0105gu ostatnich sze\u015bciu miesi\u0119cy kilka razy aktualizowali\u015bmy klastry Quay bez \u017cadnych przerw w dzia\u0142aniu.<\/p>\n

Podczas gdy pr\u00f3bowali\u015bmy przywr\u00f3ci\u0107 dzia\u0142anie us\u0142ugi, inni in\u017cynierowie zacz\u0119li przygotowywa\u0107 nowy klaster OSD z wcze\u015bniejsz\u0105 wersj\u0105 oprogramowania, aby w razie potrzeby uruchomi\u0107 wszystko na nim.<\/p>\n

Analiza przyczyn<\/h2>\n

\nG\u0142\u00f3wnym objawem awarii by\u0142a lawina dziesi\u0105tek tysi\u0119cy po\u0142\u0105cze\u0144 z baz\u0105 danych, co sprawi\u0142o, \u017ce instancja MySQL sta\u0142a si\u0119 de facto niezdolna do dzia\u0142ania. Utrudnia\u0142o to diagnostyk\u0119 problemu. Ustalili\u015bmy limit maksymalnej liczby po\u0142\u0105cze\u0144 od klient\u00f3w, aby pom\u00f3c zespo\u0142owi SRE oceni\u0107 problem. Nie zauwa\u017cono \u017cadnych nietypowych ruch\u00f3w do bazy danych: w rzeczywisto\u015bci wi\u0119kszo\u015b\u0107 zapyta\u0144 dotyczy\u0142a odczytu, a jedynie nieliczne \u2014 zapisu.<\/p>\n

Pr\u00f3bowali\u015bmy r\u00f3wnie\u017c zidentyfikowa\u0107 wz\u00f3r w ruchu bazy danych, kt\u00f3ry m\u00f3g\u0142by wywo\u0142a\u0107 t\u0119 awari\u0119. Jednak nie uda\u0142o si\u0119 znale\u017a\u0107 \u017cadnych prawid\u0142owo\u015bci w logach. Oczekuj\u0105c na gotowo\u015b\u0107 nowego klastra z OSD 4.3.18, kontynuowali\u015bmy pr\u00f3by uruchomienia pod\u00f3w quay.io. Za ka\u017cdym razem, gdy klaster osi\u0105ga\u0142 pe\u0142n\u0105 moc, baza danych zawiesza\u0142a si\u0119. Oznacza\u0142o to, \u017ce konieczne by\u0142o ponowne uruchomienie instancji RDS opr\u00f3cz wszystkich pod\u00f3w quay.io.<\/p>\n

Do wieczora ustabilizowali\u015bmy us\u0142ug\u0119 w trybie tylko do odczytu i wy\u0142\u0105czyli\u015bmy maksymalnie nieistotne funkcje (na przyk\u0142ad zbieranie \u015bmieci w przestrzeni nazw), aby zmniejszy\u0107 obci\u0105\u017cenie bazy danych. Zawieszenia usta\u0142y, ale przyczyna wci\u0105\u017c nie zosta\u0142a znaleziona<\/b>. Nowy klaster OSD by\u0142 gotowy, przenie\u015bli\u015bmy us\u0142ug\u0119, po\u0142\u0105czyli\u015bmy ruch i kontynuowali\u015bmy monitorowanie.<\/p>\n

Quay.io stabilnie dzia\u0142a\u0142o na nowym klastrze OSD, wi\u0119c wr\u00f3cili\u015bmy do log\u00f3w bazy danych, ale nie byli\u015bmy w stanie znale\u017a\u0107 korelacji wyja\u015bniaj\u0105cej blokady. In\u017cynierowie OpenShift wsp\u00f3\u0142pracowali z nami, pr\u00f3buj\u0105c zrozumie\u0107, czy zmiany w Red Hat OpenShift 4.3.19 mog\u0142y przyczyni\u0107 si\u0119 do problem\u00f3w z Quay. Jednak niczego nie odkryto, a nie uda\u0142o si\u0119 odtworzy\u0107 problemu w warunkach laboratoryjnych<\/b>.<\/p>\n

Druga awaria<\/h2>\n

\n28 maja, tu\u017c przed po\u0142udniem czasu EDT, quay.io ponownie si\u0119 zawiesi\u0142 z tymi samymi objawami: dzia\u0142anie bazy danych zosta\u0142o zablokowane. I znowu skupili\u015bmy wszystkie si\u0142y na dochodzeniu. Przede wszystkim konieczne by\u0142o przywr\u00f3cenie dzia\u0142ania us\u0142ugi. Jednak Tym razem ponowne uruchomienie RDS i restart pod\u00f3w quay.io nie przynios\u0142y skutku.<\/b>Quay jest napisane w Pythonie, a ka\u017cdy pod dzia\u0142a jako jednolity kontener monolityczny. W kontenerze jednocze\u015bnie wykonywanych jest wiele r\u00f3wnoleg\u0142ych zada\u0144. U\u017cywamy biblioteki<\/p>\n

gevent do<\/code> pod gunicorn<\/code> do obs\u0142ugi \u017c\u0105da\u0144 webowych. Gdy Quay otrzymuje \u017c\u0105danie (poprzez nasze API lub API Dockera), przypisywany jest mu worker gevent. Zazwyczaj ten worker powinien po\u0142\u0105czy\u0107 si\u0119 z baz\u0105 danych. Po pierwszej awarii odkryli\u015bmy, \u017ce workery gevent \u0142\u0105czy\u0142y si\u0119 z baz\u0105 danych, u\u017cywaj\u0105c ustawie\u0144 domy\u015blnych.<\/p>\n

Bior\u0105c pod uwag\u0119 znaczny numer pod\u00f3w Quay i tysi\u0105ce przychodz\u0105cych \u017c\u0105da\u0144 na sekund\u0119, du\u017ca liczba po\u0142\u0105cze\u0144 z baz\u0105 danych teoretycznie mog\u0142a przeci\u0105\u017cy\u0107 instancj\u0119 MySQL. Dzi\u0119ki monitorowaniu wiedzieli\u015bmy, \u017ce Quay \u015brednio obs\u0142uguje 5 tysi\u0119cy \u017c\u0105da\u0144 na sekund\u0119. Podobna by\u0142a liczba po\u0142\u0105cze\u0144 z baz\u0105 danych. 5 tysi\u0119cy po\u0142\u0105cze\u0144 w zapasie mie\u015bci\u0142o si\u0119 w mo\u017cliwo\u015bciach naszej instancji RDS (czego nie mo\u017cna powiedzie\u0107 o dziesi\u0105tkach tysi\u0119cy). Z jakiego\u015b powodu pojawia\u0142y si\u0119 nieoczekiwane wzrosty liczby po\u0142\u0105cze\u0144,<\/b>jednak nie zauwa\u017cali\u015bmy \u017cadnej korelacji z przychodz\u0105cymi zapytaniami.<\/p>\n

Tym razem zdecydowali\u015bmy si\u0119 znale\u017a\u0107 i usun\u0105\u0107 \u017ar\u00f3d\u0142o problemu, zamiast ogranicza\u0107 si\u0119 do ponownego uruchomienia. W kodzie \u017ar\u00f3d\u0142owym Quay wprowadzono zmiany ograniczaj\u0105ce liczb\u0119 po\u0142\u0105cze\u0144 z baz\u0105 danych dla ka\u017cdego workera.<\/b> gevent. Ta liczba sta\u0142a si\u0119 parametrem w konfiguracji: mo\u017cliwe sta\u0142o si\u0119 zmienianie jej \u201ew locie\u201d, bez potrzeby budowania nowego obrazu kontenera. Aby dowiedzie\u0107 si\u0119, jak\u0105 liczb\u0119 po\u0142\u0105cze\u0144 mo\u017cna rzeczywi\u015bcie obs\u0142u\u017cy\u0107, przeprowadzono kilka test\u00f3w w \u015brodowisku stagingowym, w kt\u00f3rych zadawano r\u00f3\u017cne warto\u015bci, aby sprawdzi\u0107, jak wp\u0142ynie to na scenariusze test\u00f3w obci\u0105\u017ceniowych. Ostatecznie odkryto, \u017ce Quay zaczyna generowa\u0107 b\u0142\u0119dy 502, gdy liczba po\u0142\u0105cze\u0144 przekroczy 10 tysi\u0119cy.<\/b><\/p>\n

Natychmiast wdro\u017cyli\u015bmy t\u0119 now\u0105 wersj\u0119 w produkcji i zacz\u0119li\u015bmy monitorowa\u0107 wykres po\u0142\u0105cze\u0144 z baz\u0105 danych. W przesz\u0142o\u015bci baza blokowa\u0142a si\u0119 mniej wi\u0119cej po 20 minutach. Po 30 minutach bez problem\u00f3w mieli\u015bmy nadziej\u0119, a po godzinie \u2014 pewno\u015b\u0107. Przywr\u00f3cili\u015bmy ruch zapisu na stronie i przyst\u0105pili\u015bmy do analizy postmortem.<\/p>\n

Sukcesem w obej\u015bciu problemu, kt\u00f3ry prowadzi\u0142 do zablokowania, nie ustalili\u015bmy jego prawdziwych przyczyn,<\/b>Potwierdzono, \u017ce nie ma on zwi\u0105zku z \u017cadnymi zmianami w OpenShift 4.3.19, poniewa\u017c to samo zdarzy\u0142o si\u0119 w wersji 4.3.18, kt\u00f3ra wcze\u015bniej dzia\u0142a\u0142a z Quay bez \u017cadnych problem\u00f3w.<\/p>\n

W klastrze niew\u0105tpliwie skrywa\u0142o si\u0119 co\u015b jeszcze.<\/p>\n

Szczeg\u00f3\u0142owa analiza<\/h2>\n

\nQuay.io przez sze\u015b\u0107 lat korzysta\u0142 z domy\u015blnych ustawie\u0144 do pod\u0142\u0105czenia do bazy danych bez \u017cadnych problem\u00f3w. Co si\u0119 zmieni\u0142o? Jasne jest, \u017ce w tym czasie ruch na quay.io nieustannie r\u00f3s\u0142. W naszym przypadku wygl\u0105da\u0142o to tak, jakby osi\u0105gni\u0119to pewien pr\u00f3g, kt\u00f3ry sta\u0142 si\u0119 impulsem do lawiny po\u0142\u0105cze\u0144. Kontynuowali\u015bmy analizowanie log\u00f3w bazy danych po drugim awarii, ale nie znale\u017ali\u015bmy \u017cadnych wzorc\u00f3w ani oczywistych powi\u0105za\u0144.<\/p>\n

W mi\u0119dzyczasie zesp\u00f3\u0142 SRE pracowa\u0142 nad ulepszeniami w zakresie obserwowalno\u015bci zapyta\u0144 w Quay oraz og\u00f3lnego stanu us\u0142ugi. Wdro\u017cono nowe metryki i panele monitorowania<\/b>, pokazuj\u0105ce, kt\u00f3re cz\u0119\u015bci Quay ciesz\u0105 si\u0119 najwi\u0119kszym zainteresowaniem ze strony klient\u00f3w.<\/p>\n

Quay.io dzia\u0142a\u0142o normalnie do 9 czerwca. Rano (czasu EDT) ponownie byli\u015bmy \u015bwiadkami znacznego wzrostu liczby po\u0142\u0105cze\u0144 z baz\u0105 danych. Tym razem nie dosz\u0142o do przestoju<\/b>, poniewa\u017c nowy parametr ogranicza\u0142 ich liczb\u0119 i nie pozwala\u0142 na przekroczenie przepustowo\u015bci MySQL. Jednak przez oko\u0142o p\u00f3\u0142 godziny wielu u\u017cytkownik\u00f3w zg\u0142asza\u0142o spowolnienie dzia\u0142ania quay.io. Szybko zebrali\u015bmy wszystkie dost\u0119pne dane, korzystaj\u0105c z dodanych narz\u0119dzi do monitorowania. Nagle zacz\u0119\u0142a si\u0119 ujawnia\u0107 pewna zasada.<\/p>\n

Tu\u017c przed nag\u0142ym wzrostem liczby po\u0142\u0105cze\u0144 du\u017ca liczba zapyta\u0144 wp\u0142yn\u0119\u0142a do App Registry API<\/b>. App Registry to ma\u0142o znana funkcja quay.io. Umo\u017cliwia przechowywanie takich rzeczy jak wykresy Helm i kontenery z bogatymi metadanymi. Wi\u0119kszo\u015b\u0107 u\u017cytkownik\u00f3w quay.io nie korzysta z tej funkcji, jednak intensywnie wykorzystuje j\u0105 Red Hat OpenShift. OperatorHub w OpenShift przechowuje wszystkie operatory w App Registry. Ci operatorzy stanowi\u0105 podstaw\u0119 ekosystemu obci\u0105\u017ce\u0144 OpenShift oraz modelu operacyjnego (w ramach operacji \u201edrugiego dnia\u201d, Day 2), ukierunkowanego na partner\u00f3w.<\/p>\n

Ka\u017cdy klaster OpenShift 4 wykorzystuje operator\u00f3w z wbudowanego OperatorHub do publikowania katalogu operator\u00f3w dost\u0119pnych do zainstalowania oraz dostarczania aktualizacji dla ju\u017c zainstalowanych. Wraz z rosn\u0105c\u0105 popularno\u015bci\u0105 OpenShift 4 wzros\u0142a liczba klastr\u00f3w na ca\u0142ym \u015bwiecie. Ka\u017cdy z tych klastr\u00f3w \u0142aduje tre\u015bci operator\u00f3w, aby uruchomi\u0107 wbudowany OperatorHub, korzystaj\u0105c z App Registry w quay.io jako zaplecza. W poszukiwaniu \u017ar\u00f3d\u0142a problemu przegapili\u015bmy to, \u017ce wraz z rosn\u0105c\u0105 popularno\u015bci\u0105 OpenShift zwi\u0119ksza\u0142o si\u0119 r\u00f3wnie\u017c obci\u0105\u017cenie jednej z rzadko u\u017cywanych funkcji quay.io.<\/b>.<\/p>\n

Przeprowadzili\u015bmy pewn\u0105 analiz\u0119 ruchu \u017c\u0105da\u0144 App Registry i zajrzeli\u015bmy w kod rejestru. Natychmiast ujawni\u0142y si\u0119 wady, kt\u00f3re powodowa\u0142y, \u017ce \u017c\u0105dania do bazy danych by\u0142y formu\u0142owane nieoptymalnie. Przy niewielkim obci\u0105\u017ceniu nie sprawia\u0142y problem\u00f3w, jednak przy jego wzro\u015bcie stawa\u0142y si\u0119 \u017ar\u00f3d\u0142em k\u0142opot\u00f3w. Okaza\u0142o si\u0119, \u017ce App Registry ma dwa problematyczne endpointy, kt\u00f3re \u017ale reaguj\u0105 na wzrost obci\u0105\u017cenia: pierwszy zwraca\u0142 list\u0119 wszystkich pakiet\u00f3w w repozytorium, a drugi \u2014 wszystkie bloby dla pakietu.<\/p>\n

Usuwanie przyczyn<\/h2>\n

\nPrzez ca\u0142y nast\u0119pny tydzie\u0144 zajmowali\u015bmy si\u0119 optymalizacj\u0105 kodu samego App Registry i jego otoczenia. Przeredagowywane by\u0142y wyra\u017anie nieskuteczne zapytania SQL, usuni\u0119to zb\u0119dne wywo\u0142ania komendy (uruchamia\u0142a si\u0119 przy ka\u017cdym pobieraniu blob'\u00f3w), dodano cachowanie wsz\u0119dzie tam, gdzie to mo\u017cliwe. Nast\u0119pnie przeprowadzono rozbudowane testy wydajno\u015bci i por\u00f3wnano pr\u0119dko\u015b\u0107 dzia\u0142ania App Registry przed i po zmianach. tar<\/code> (By\u0142a uruchamiana przy ka\u017cdym pobraniu blob\u00f3w), dodano pami\u0119\u0107 podr\u0119czn\u0105 wsz\u0119dzie, gdzie to mo\u017cliwe. Nast\u0119pnie przeprowadzono obszerne testy wydajno\u015bci i por\u00f3wnano pr\u0119dko\u015b\u0107 dzia\u0142ania App Registry przed i po wprowadzeniu zmian.<\/p>\n

. W nast\u0119pnym tygodniu wdro\u017cyli\u015bmy zmiany w \u015brodowisku produkcyjnym i od tego czasu quay.io dzia\u0142a stabilnie. W tym czasie zaobserwowano kilka gwa\u0142townych wzrost\u00f3w ruchu na punkcie ko\u0144cowym App Registry, ale wprowadzone usprawnienia zapobieg\u0142y zak\u0142\u00f3ceniom w pracy bazy danych.<\/b>. W przysz\u0142ym tygodniu wdro\u017cymy zmiany w produkcji, a od tego czasu quay.io dzia\u0142a stabilnie. W tym czasie zaobserwowano kilka gwa\u0142townych szczyt\u00f3w ruchu na punkcie ko\u0144cowym App Registry, ale wprowadzone usprawnienia zapobieg\u0142y przerwom w dzia\u0142aniu bazy danych.<\/p>\n

Jasne jest, \u017ce ka\u017cdy serwis stara si\u0119 unika\u0107 przestoj\u00f3w. W naszym przypadku wierzymy, \u017ce ostatnie awarie pomog\u0142y uczyni\u0107 quay.io lepszym. Wyci\u0105gn\u0119li\u015bmy kilka g\u0142\u00f3wnych lekcji, kt\u00f3rymi chcemy si\u0119 podzieli\u0107:<\/h2>\n

\nDane na temat tego, kto i jak korzysta z Twojego serwisu, nigdy nie s\u0105 zb\u0119dne.<\/p>\n

    \n
  1. . Poniewa\u017c Quay \u00abpo prostu dzia\u0142a\u0142\u00bb, nigdy nie mieli\u015bmy potrzeby traci\u0107 czasu na optymalizacj\u0119 ruchu i zarz\u0105dzanie obci\u0105\u017ceniem. To wszystko stworzy\u0142o fa\u0142szywe poczucie bezpiecze\u0144stwa, \u017ce serwis mo\u017ce skalowa\u0107 si\u0119 w niesko\u0144czono\u015b\u0107.<\/b>Kiedy serwis si\u0119 awariuje,<\/li>\n
  2. przywr\u00f3cenie jego dzia\u0142ania staje si\u0119 najwy\u017cszym priorytetem. przywr\u00f3cenie jego dzia\u0142ania to priorytet<\/b>. Poniewa\u017c Quay nadal cierpia\u0142 na zablokowan\u0105 baz\u0119 danych podczas pierwszej awarii, nasze standardowe procedury nie przynios\u0142y zamierzonego efektu i nie mogli\u015bmy przywr\u00f3ci\u0107 dzia\u0142ania us\u0142ugi za ich pomoc\u0105. Doprowadzi\u0142o to do sytuacji, w kt\u00f3rej musieli\u015bmy po\u015bwi\u0119ci\u0107 czas na analiz\u0119 i zbieranie danych w nadziei na znalezienie przyczyny \u2014 zamiast kierowa\u0107 wszystkie wysi\u0142ki na przywr\u00f3cenie sprawno\u015bci.<\/li>\n
  3. Oce\u0144 wp\u0142yw ka\u017cdej z funkcji us\u0142ugi<\/b>. Klienci rzadko korzystali z App Registry, wi\u0119c nie by\u0142 on priorytetem dla naszego zespo\u0142u. Kiedy niekt\u00f3re funkcje produktu s\u0105 rzadko u\u017cywane, ich b\u0142\u0119dy pojawiaj\u0105 si\u0119 rzadko, a programi\u015bci przestaj\u0105 \u015bledzi\u0107 kod. \u0141atwo jest sta\u0107 si\u0119 ofiar\u0105 z\u0142udzenia, \u017ce tak powinno by\u0107 \u2014 a\u017c nagle ta funkcja nieoczekiwanie staje si\u0119 centrum du\u017cego incydentu.<\/li>\n<\/ol>\n

    <\/p>\n

    Co dalej?<\/h2>\n

    \nPrace nad zapewnieniem stabilno\u015bci us\u0142ugi nigdy si\u0119 nie ko\u0144cz\u0105 i nieustannie j\u0105 poprawiamy. Ruch na quay.io nadal ro\u015bnie i zdajemy sobie spraw\u0119, \u017ce musimy zrobi\u0107 wszystko, co w naszej mocy, aby zas\u0142u\u017cy\u0107 na zaufanie klient\u00f3w. Dlatego obecnie pracujemy nad nast\u0119puj\u0105cymi zadaniami:<\/p>\n

      \n
    1. Wdro\u017cenie replik baz danych tylko do odczytu, aby pom\u00f3c us\u0142udze obs\u0142ugiwa\u0107 odpowiedni ruch w przypadku problem\u00f3w z g\u0142\u00f3wnym wyst\u0105pieniem RDS.<\/li>\n
    2. Aktualizacja wyst\u0105pienia RDS. Obecna wersja sama w sobie nie jest problemem. Raczej chcemy po prostu usun\u0105\u0107 fa\u0142szywy \u015blad (kt\u00f3rym pod\u0105\u017cyli\u015bmy podczas awarii); utrzymanie oprogramowania w aktualnym stanie pozwoli wyeliminowa\u0107 jeszcze jeden czynnik w przypadku przysz\u0142ych awarii.<\/li>\n
    3. Dodatkowe buforowanie w ca\u0142ym klastrze. Nadal poszukujemy obszar\u00f3w, w kt\u00f3rych buforowanie mo\u017ce zmniejszy\u0107 obci\u0105\u017cenie bazy danych.<\/li>\n
    4. Dodanie zapory aplikacji internetowych (WAF), aby zobaczy\u0107, kto i dlaczego \u0142\u0105czy si\u0119 z quay.io.<\/li>\n
    5. Pocz\u0105wszy od nast\u0119pnej wersji, klastry Red Hat OpenShift rezygnuj\u0105 z App Registry na rzecz katalog\u00f3w operator\u00f3w (Operator Catalogs) opartych na obrazach kontener\u00f3w dost\u0119pnych na quay.io.<\/li>\n
    6. D\u0142ugoterminowym zast\u0105pieniem App Registry mo\u017ce by\u0107 wsparcie specyfikacji artefakt\u00f3w Open Container Initiative (OCI). Obecnie jest to realizowane w postaci natywnej funkcjonalno\u015bci Quay i b\u0119dzie dost\u0119pne dla u\u017cytkownik\u00f3w, gdy specyfikacja zostanie ostatecznie zatwierdzona.<\/li>\n<\/ol>\n

      \nWszystko, co wymienione powy\u017cej, jest cz\u0119\u015bci\u0105 trwaj\u0105cych inwestycji Red Hat w quay.io, podczas gdy przechodzimy od ma\u0142ego zespo\u0142u \u201estart-upowego\u201d do dojrza\u0142ej platformy zarz\u0105dzanej przez SRE. Wiemy, \u017ce wielu naszych klient\u00f3w polega na quay.io w swojej codziennej pracy (w tym Red Hat!) i staramy si\u0119 by\u0107 jak najbardziej otwarci na temat niedawnych awarii i trwaj\u0105cych wysi\u0142k\u00f3w, aby sta\u0107 si\u0119 lepszymi.<\/p>\n

      P.S. od t\u0142umacza<\/h2>\n

      \nPrzeczytaj tak\u017ce na naszym blogu:<\/p>\n