{"id":55467,"date":"2020-01-21T00:00:00","date_gmt":"2020-01-20T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya"},"modified":"2020-02-18T14:03:35","modified_gmt":"2020-02-18T11:03:35","slug":"postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-vtorek \u010d. 5: \u201ePostgreSQL a Kubernetes. CI\/CD. Automatiz\u00e1cia testovania\u201c.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-vtorek
\n
\nNa konci minul\u00e9ho roka sa uskuto\u010dnil \u010fal\u0161\u00ed \u017eiv\u00fd prenos rusk\u00e9ho PostgreSQL spolo\u010denstva #RuPostgres<\/a><\/noindex>, v r\u00e1mci ktor\u00e9ho jeho spoluzakladate\u013e Nikolaj Samochvalov hovoril s technick\u00fdm riadite\u013eom \u201eFlanta\u201c Dmitrijom Stoljarovom o tejto S\u00daDB v kontexte Kubernetes.<\/p>\n

Zverej\u0148ujeme z\u00e1znam hlavnej \u010dasti tejto diskusie, a na YouTube kan\u00e1li spolo\u010denstva<\/a><\/noindex> bola zverejnen\u00e1 kompletn\u00e1 video nahr\u00e1vka:<\/a><\/noindex><\/p>\n

\r\n \"Prehrajte\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Datab\u00e1zy a Kubernetes<\/h2>\n

\nNS<\/b>: Dnes nebudeme hovori\u0165 o VACUUM a CHECKPOINT, ale o Kubernetes. Viem, \u017ee m\u00e1\u0161 u\u017e ve\u013ea rokov sk\u00fasenost\u00ed. Pozeral som tvoje vide\u00e1 a niektor\u00e9 som si dokonca opakovane pozrel... Prejdime priamo k veci: pre\u010do vlastne Postgres alebo MySQL v K8s?<\/i><\/p>\n

DS<\/b>: Na t\u00fato ot\u00e1zku neexistuje jednozna\u010dn\u00e1 odpove\u010f, a ani nem\u00f4\u017ee existova\u0165. Ale vo v\u0161eobecnosti, je to jednoduchos\u0165 a pohodlie\u2026 potenci\u00e1lne. V\u0161etci chc\u00fa managed slu\u017eieb.<\/p>\n

NS<\/b>: Aby to bolo ako RDS<\/a><\/noindex>, len u seba?<\/i><\/p>\n

DS<\/b>: \u00c1no: aby to bolo ako RDS, len \u017ee kdeko\u013evek.<\/p>\n

NS<\/b>: \u201eKdeko\u013evek\u201c \u2014 to je dobr\u00e1 pozn\u00e1mka. Vo ve\u013ek\u00fdch firm\u00e1ch je v\u0161etko rozmiestnen\u00e9 na r\u00f4znych miestach. A pre\u010do, ak ide o ve\u013ek\u00fa spolo\u010dnos\u0165, nevyu\u017ei\u0165 hotov\u00e9 rie\u0161enie? Napr\u00edklad, Nutanix m\u00e1 svoje vlastn\u00e9 v\u00fdvojov\u00e9 rie\u0161enia, in\u00e9 spolo\u010dnosti (VMware\u2026) maj\u00fa tie\u017e \u201eRDS, len u seba\u201c.<\/i><\/p>\n

DS<\/b>: Ale to hovor\u00edme o konkr\u00e9tnej implement\u00e1cii, ktor\u00e1 bude fungova\u0165 iba za ur\u010dit\u00fdch podmienok. A ak ide o Kubernetes, tak tu je obrovsk\u00e1 rozmanitos\u0165 infra\u0161trukt\u00fary (ktor\u00e1 m\u00f4\u017ee by\u0165 v K8s). V podstate to je \u0161tandard pre API do cloudu\u2026<\/p>\n

NS<\/b>: E\u0161te aj zadarmo!<\/i><\/p>\n

DS<\/b>: To nie je tak d\u00f4le\u017eit\u00e9. Bezplatnos\u0165 je d\u00f4le\u017eit\u00e1 len pre relat\u00edvne mal\u00fd segment trhu. D\u00f4le\u017eitej\u0161ie je nie\u010do in\u00e9\u2026 Ur\u010dite si pam\u00e4t\u00e1\u0161 predn\u00e1\u0161ku \u201eDatab\u00e1zy a Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

NS<\/b>: \u00c1no.<\/i><\/p>\n

DS<\/b>: Pochopil som, \u017ee to bolo prijat\u00e9 ve\u013emi rozporuplne. Niektor\u00ed si mysleli, \u017ee hovor\u00edm: \u201eChlapci, po\u010fme s v\u0161etk\u00fdmi datab\u00e1zami do Kubernetes!\u201c, in\u00ed sa domnievali, \u017ee ide o hrozn\u00e9 bicykle. A ja som chcel poveda\u0165 vlastne nie\u010do in\u00e9: \u201ePozrite sa, \u010do sa deje, ak\u00e9 s\u00fa probl\u00e9my a ako ich m\u00f4\u017eeme rie\u0161i\u0165. Je teraz rozumn\u00e9 pou\u017e\u00edva\u0165 datab\u00e1zy v Kubernetes? Pre produkciu? Nu\u017e, len ak milujete... robi\u0165 ur\u010dit\u00e9 veci. Ale pokia\u013e ide o dev, m\u00f4\u017eem poveda\u0165, \u017ee odpor\u00fa\u010dam. Pre dev je ve\u013emi d\u00f4le\u017eit\u00e1 dynamickos\u0165 vytv\u00e1rania\/odstra\u0148ovania prostred\u00ed.\u201c<\/p>\n

NS: Pod dev m\u00e1\u0161 na mysli v\u0161etky prostredia, ktor\u00e9 nie s\u00fa prod? Staging, QA...<\/i><\/p>\n

DS<\/b>: Ak hovor\u00edme o perf-stendoch, tak u\u017e asi nie, preto\u017ee tam s\u00fa \u0161pecifick\u00e9 po\u017eiadavky. Ak hovor\u00edme o osobitn\u00fdch pr\u00edpadoch, kde je na stagingu potrebn\u00e1 ve\u013emi ve\u013ek\u00e1 DB, tak tie\u017e asi nie\u2026 Ak je to statick\u00e9 prostredie, dlhodob\u00e9, tak ak\u00fd je pr\u00ednos, \u017ee je datab\u00e1za umiestnen\u00e1 v K8s?<\/p>\n

NS<\/b>: \u017diadny. Ale kde vid\u00edme statick\u00e9 prostredia? Statick\u00e9 prostredie zastaralo u\u017e zajtra.<\/i><\/p>\n

DS<\/b>: Staging m\u00f4\u017ee by\u0165 statick\u00fd. M\u00e1me klientov...<\/p>\n

NS<\/b>: \u00c1no, aj ja m\u00e1m. Ve\u013ek\u00fd probl\u00e9m, ak m\u00e1\u0161 datab\u00e1zu na 10 TB, a staging \u2014 200 GB...<\/i><\/p>\n

DS<\/b>: M\u00e1m ve\u013emi zauj\u00edmav\u00fd pr\u00edpad! Na stagingu sa nach\u00e1dza produk\u010dn\u00e1 datab\u00e1za, do ktorej sa robia zmeny. A je tam tla\u010didlo: \u201enasadi\u0165 do produkcie\u201c. Tieto zmeny \u2014 delta \u2014 sa synchronizuj\u00fa (mysl\u00edm, \u017ee jednoducho cez API) do produkcie. To je ve\u013emi exotick\u00e1 varianta.<\/p>\n

NS<\/b>: Vid\u011bl jsem startupy v Dolin\u011b, kter\u00e9 st\u00e1le sed\u00ed v RDS nebo dokonce v Heroku, co\u017e jsou p\u0159\u00edb\u011bhy star\u00e9 2-3 roky, a stahuj\u00ed si dumpy na sv\u00e9 notebooky. Proto\u017ee datab\u00e1ze m\u00e1 zat\u00edm pouze 80 GB, a na notebooku je m\u00edsto. Potom si koup\u00ed disky pro ka\u017ed\u00e9ho, aby m\u011bli 3 datab\u00e1ze a mohli vyv\u00edjet r\u016fzn\u00e9 projekty. I tak to b\u00fdv\u00e1. Tak\u00e9 jsem vid\u011bl, \u017ee se neboj\u00ed kop\u00edrovat prod do staging \u2014 velmi to z\u00e1vis\u00ed na firm\u011b. Ale vid\u011bl jsem tak\u00e9, \u017ee se boj\u00ed, a \u017ee \u010dasto nen\u00ed dost \u010dasu a lid\u00ed. Ale sk\u00f4r ako sa dostaneme k tejto t\u00e9me, chcel by som po\u010du\u0165 o Kubernetes. Rozumiem spr\u00e1vne, \u017ee v produkcii to zatia\u013e nikto nem\u00e1?<\/i><\/p>\n

DS<\/b>: M\u00e1me mal\u00e9 datab\u00e1zy v produkcii. Hovor\u00edme o objemoch v desiatkach gigabajtov a nekritick\u00fdch slu\u017eb\u00e1ch, pre ktor\u00e9 sa n\u00e1m neoplatilo robi\u0165 repliky (a ani neexistuje tak\u00e1 potreba). A za podmienky, \u017ee pod Kubernetes je norm\u00e1lne \u00falo\u017eisko. T\u00e1to datab\u00e1za pracovala na virtu\u00e1lnom stroji \u2014 podmiene\u010dne vo VMware, nad SAN. Umiestnili sme ju do PV<\/a><\/noindex> a teraz ju m\u00f4\u017eeme pren\u00e1\u0161a\u0165 z jedn\u00e9ho stroja na druh\u00fd.<\/p>\n

NS<\/b>: Datab\u00e1zy takej ve\u013ekosti, do 100 GB, na dobr\u00fdch diskoch a pri dobrej sieti m\u00f4\u017eeme aktualizova\u0165 za nieko\u013eko min\u00fat, spr\u00e1vne? R\u00fdchlos\u0165 1 GB za sekundu \u2014 to u\u017e nie je exotika.<\/i><\/p>\n

DS<\/b>: \u00c1no, pre line\u00e1rnu oper\u00e1ciu to nie je probl\u00e9m.<\/p>\n

NS<\/b>: Dobre, o produkcii mus\u00edme len prem\u00fd\u0161\u013ea\u0165. A ak zva\u017eujeme Kubernetes pre ne-prod prostredia \u2014 ako to robi\u0165? Vid\u00edm, \u017ee v Zalande robia oper\u00e1tora<\/a><\/noindex>, v Crunchy vyv\u00edjaj\u00fa<\/a><\/noindex>, s\u00fa aj nejak\u00e9 in\u00e9 mo\u017enosti. A existuje OnGres<\/a><\/noindex> \u2014 to je n\u00e1\u0161 dobr\u00fd priate\u013e Alvaro zo \u0160panielska: robia vlastne nie len oper\u00e1tor<\/a><\/noindex>, ale cel\u00fd distribu\u010dn\u00fd bal\u00edk (StackGres<\/a><\/noindex>), do ktor\u00e9ho okrem samotn\u00e9ho Postgres m\u00e1me e\u0161te aj z\u00e1lohu a proxy Envoy...<\/i><\/p>\n

DS<\/b>: Envoy na \u010do? Na vyva\u017eovanie prev\u00e1dzky presne Postgresu?<\/p>\n

NS<\/b>: \u00c1no. Teda oni to vidia tak, \u017ee ak vezmeme linuxov\u00fd distribu\u010dn\u00fd bal\u00edk a jadro, oby\u010dajn\u00fd PostgreSQL je to jadro, a oni chc\u00fa vyrobi\u0165 distrib\u00faciu, ktor\u00e1 bude priate\u013eskej\u0161ia k \u043e\u0431\u043b\u0430\u043a\u0430\u043c a be\u017ea\u0165 na Kubernetes. Spojuj\u00fa komponenty (z\u00e1lohy a pod.) a ladenia, aby dobre fungovali.<\/i><\/p>\n

DS<\/b>: Ve\u013emi skvel\u00e9! V podstate je to softv\u00e9r, ktor\u00fd vytvor\u00ed vlastn\u00fd spravovan\u00fd Postgres.<\/p>\n

NS<\/b>: Linuxov\u00e9 distrib\u00facie maj\u00fa ve\u010dn\u00e9 probl\u00e9my: ako robi\u0165 ovl\u00e1da\u010de, aby bolo podporovan\u00e9 v\u0161etko hardv\u00e9rov\u00e9. A ich my\u0161lienka je, \u017ee bud\u00fa fungova\u0165 na Kubernetes. Viem, \u017ee v oper\u00e1torovi Zalando sme ned\u00e1vno videli prepojenie na AWS a to u\u017e nie je ve\u013emi dobr\u00e9. Nemalo by to by\u0165 prepojen\u00e9 na konkr\u00e9tnu infra\u0161trukt\u00faru \u2014 ak\u00fd je potom zmysel?<\/i><\/p>\n

DS<\/b>: Neviem, v akej situ\u00e1cii sa konkr\u00e9tne Zalando prepojilo, ale v Kubernetes je teraz storage urobene tak, \u017ee nie je mo\u017en\u00e9 be\u017ene urobi\u0165 diskov\u00fa z\u00e1lohu. Ned\u00e1vno v \u0161tandarde \u2014 v poslednej verzii \u0161pecifik\u00e1cie CSI<\/a><\/noindex> \u2014 bola pridan\u00e1 mo\u017enos\u0165 snapshotov, ale kde to bolo implementovan\u00e9? \u00daprimne, st\u00e1le to nie je dostato\u010dne zrel\u00e9\u2026 Sk\u00fa\u0161ame CSI nad AWS, GCE, Azure, vSphere, ale hne\u010f ako za\u010dnete pou\u017e\u00edva\u0165, je jasn\u00e9, \u017ee to e\u0161te nie je pripraven\u00e9.<\/p>\n

NS<\/b>: Preto je ob\u010das potrebn\u00e9 prepoji\u0165 sa na infra\u0161trukt\u00faru. Mysl\u00edm, \u017ee st\u00e1le prebiehaj\u00fa po\u010diato\u010dn\u00e9 f\u00e1zy \u2014 probl\u00e9my s rastom. Ot\u00e1zka: \u010do by si odporu\u010dil nov\u00e1\u010dikom, ktor\u00ed chc\u00fa vysk\u00fa\u0161a\u0165 PgSQL na K8s? Ak\u00fd oper\u00e1tor, mo\u017eno?<\/i><\/p>\n

DS<\/b>: Probl\u00e9m je v tom, \u017ee Postgres pre n\u00e1s predstavuje iba 3%. M\u00e1me ve\u013emi dlh\u00fd zoznam r\u00f4zneho softv\u00e9ru v Kubernetes, nebudem ani v\u0161etko vymenov\u00e1va\u0165. Napr\u00edklad Elasticsearch. Oper\u00e1torov je ve\u013ea: niektor\u00ed sa akt\u00edvne vyv\u00edjaj\u00fa, in\u00ed nie. Sformulovali sme si po\u017eiadavky, \u010do by malo by\u0165 v oper\u00e1torovi, aby sme ho brali v\u00e1\u017ene. Oper\u00e1tor pre Kubernetes \u2014 nie \u201eoper\u00e1tor na nie\u010do v podmienkach Amazonu\u201c... V skuto\u010dnosti pomerne mas\u00edvne (= takmer v\u0161etci klienti) pou\u017e\u00edvame jedin\u00e9ho oper\u00e1tora \u2014 pre Redis<\/a><\/noindex> (\u010doskoro zverejn\u00edme aj \u010dl\u00e1nok o \u0148om)<\/i>.<\/p>\n

NS<\/b>: A pre MySQL tie\u017e nie? Viem, \u017ee Percona\u2026 ke\u010f\u017ee sa teraz zaoberaj\u00fa aj MySQL, aj MongoDB, aj Postgres, musia vyrobi\u0165 nejak\u00fd univerz\u00e1lny syst\u00e9m: pre v\u0161etky datab\u00e1zy, pre v\u0161etk\u00fdch cloudov\u00fdch poskytovate\u013eov.<\/i><\/p>\n

DS<\/b>: E\u0161te sme nemali \u010das pozrie\u0165 sa na oper\u00e1tory pre MySQL. Pre n\u00e1s to teraz nie je hlavn\u00fd fokus. MySQL funguje v standalone re\u017eime. Pre\u010do potrebova\u0165 oper\u00e1tora, ak m\u00f4\u017ee\u0161 jednoducho spusti\u0165 DB... M\u00f4\u017ee\u0161 spusti\u0165 Docker kontajner s Postrges, alebo ho spusti\u0165 jednoducho.<\/p>\n

NS<\/b>: O tomto bola tie\u017e ot\u00e1zka. \u00daplne bez oper\u00e1tora?<\/i><\/p>\n

DS<\/b>: \u00c1no, v 100% m\u00e1me PostgreSQL spusten\u00fd bez oper\u00e1tora. Zatia\u013e to tak je. Akt\u00edvne pou\u017e\u00edvame oper\u00e1tora pre Prometheus, pre Redis. M\u00e1me v pl\u00e1ne n\u00e1js\u0165 oper\u00e1tora pre Elasticsearch - ten najviac \u201ehor\u00ed\u201c, preto\u017ee ho chceme ma\u0165 v 100% pr\u00edpadoch nain\u0161talovan\u00fd v Kubernetes. Rovnako, ako chceme pr\u00eds\u0165 k tomu, aby sme MongoDB tie\u017e v\u017edy in\u0161talovali v Kubernetes. Tu sa objavuj\u00fa ur\u010dit\u00e9 po\u017eiadavky - m\u00e1me pocit, \u017ee v t\u00fdchto pr\u00edpadoch mo\u017eno nie\u010do spravi\u0165. O Postgres sme sa dokonca ani nepozreli. Samozrejme, vieme o existencii r\u00f4znych variantov, ale v skuto\u010dnosti m\u00e1me standalone.<\/p>\n

DB na testovanie v Kubernetes<\/h2>\n

\nNS<\/b>: Po\u010fme prejs\u0165 k t\u00e9me testovania. Ako nasadzova\u0165 zmeny v datab\u00e1ze - z poh\u013eadu DevOps perspekt\u00edvy. Existuj\u00fa mikroservisy, ve\u013ea datab\u00e1z, neust\u00e1le sa niekde nie\u010do men\u00ed. Ako zabezpe\u010di\u0165 norm\u00e1lny CI\/CD, aby z poh\u013eadu DB bolo v\u0161etko v poriadku. Ak\u00fd m\u00e1\u0161 pr\u00edstup?<\/i><\/p>\n

DS<\/b>: Nem\u00f4\u017ee by\u0165 jednozna\u010dn\u00e1 odpove\u010f. Existuje viacero parametrov. Prv\u00fd - to je ve\u013ekos\u0165 datab\u00e1zy, ktor\u00fa chceme nasadi\u0165. S\u00e1m si spomenul, \u017ee v spolo\u010dnostiach existuj\u00fa r\u00f4zne pr\u00edstupy k tomu, aby existovala k\u00f3pia prod datab\u00e1zy na dev a stage.<\/p>\n

NS<\/b>: A v podmienkach GDPR, mysl\u00edm, \u017ee sa k tomu stavaj\u00fa \u010doraz opatrnej\u0161ie... M\u00f4\u017eem poveda\u0165, \u017ee v Eur\u00f3pe u\u017e za\u010dali pokutova\u0165.<\/i><\/p>\n

DS<\/b>: Ale \u010dasto m\u00f4\u017eete nap\u00edsa\u0165 softv\u00e9r, ktor\u00fd rob\u00ed dump z produkcie a obfuskuje ho. Vznikaj\u00fa produk\u010dn\u00e9 d\u00e1ta (snapshot, dump, bin\u00e1rna k\u00f3pia...), ale s\u00fa anonymizovan\u00e9. Namiesto toho m\u00f4\u017eu by\u0165 aj generovacie skripty: m\u00f4\u017eu to by\u0165 fixtures alebo jednoducho skript, ktor\u00fd generuje ve\u013ek\u00fa datab\u00e1zu. Probl\u00e9ma je akur\u00e1t v tom, ko\u013eko \u010dasu trv\u00e1 vytvorenie z\u00e1kladn\u00e9ho obrazu? A ko\u013eko trv\u00e1 jeho nasadenie na po\u017eadovanom prostred\u00ed?<\/p>\n

Dospeli sme k sch\u00e9me: ak m\u00e1 klient fixt\u00farny s\u00fabor d\u00e1t (minim\u00e1lna verzia datab\u00e1zy), tak ich pou\u017e\u00edvame ako predvolen\u00e9. Ak ide o review prostredie, ke\u010f sme vytvorili branch, m\u00e1me nasaden\u00fa in\u0161tanciu aplik\u00e1cie - tam nasadzujeme mal\u00fa datab\u00e1zu. Ale dopadlo to dobre a variantu<\/a><\/noindex>, ke\u010f z produkcie raz za de\u0148 (v noci) rob\u00edme dump a na jeho z\u00e1klade zostavujeme Docker kontajner s PostgreSQL a MySQL s t\u00fdmito nahrat\u00fdmi d\u00e1tami. Ak z tohto obrazu treba 50-kr\u00e1t nasadi\u0165 datab\u00e1zu, rob\u00ed sa to pomerne jednoducho a r\u00fdchlo.<\/p>\n

NS<\/b>: Jednoduch\u00fdm kop\u00edrovan\u00edm?<\/i><\/p>\n

DS<\/b>: D\u00e1tov\u00e9 s\u00fabory s\u00fa ulo\u017een\u00e9 priamo v Docker obraze. T.j. m\u00e1me hotov\u00fd obraz, povedzme na 100 GB. V\u010faka vrstv\u00e1m v Dockeri m\u00f4\u017eeme r\u00fdchlo rozprestrie\u0165 tento obraz to\u013ekokr\u00e1t, ko\u013ekokr\u00e1t potrebujeme. Sp\u00f4sob je primit\u00edvny, ale funguje celkom dobre.<\/p>\n

NS<\/b>: \u010ealej, ke\u010f testujete, v\u0161etko sa men\u00ed priamo vo vn\u00fatri Dockeru, \u017ee? Copy-on-write v Dockeri \u2014 vyhod\u00edme a znova ideme, v\u0161etko je v poriadku. Super! A u\u017e to naplno vyu\u017e\u00edvate?<\/i><\/p>\n

DS<\/b>: U\u017e dos\u0165 dlho.<\/p>\n

NS<\/b>: Zh\u00e1\u0148ame sa po ve\u013emi podobn\u00fdch z\u00e1le\u017eitostiach. Len my nepou\u017e\u00edvame Dockerovsk\u00fd copy-on-write, ale nie\u010do in\u00e9.<\/i><\/p>\n

DS<\/b>: Nie je to generick\u00e9. Ale Dockerovsk\u00fd funguje v\u0161ade.<\/p>\n

NS<\/b>: Teoreticky \u00e1no. Ale aj u n\u00e1s s\u00fa moduly, m\u00f4\u017eeme vytvori\u0165 r\u00f4zne moduly a pracova\u0165 s r\u00f4znymi s\u00faborov\u00fdmi syst\u00e9mami. Tu je ten moment. Z poh\u013eadu PostgreSQL sa na to pozer\u00e1me inak. Teraz som sa pozrel z poh\u013eadu Dockera a videl, \u017ee v\u0161etko funguje. Ale ak je datab\u00e1za obrovsk\u00e1, napr\u00edklad 1 TB, tak to u\u017e trv\u00e1 dlho: a oper\u00e1cie v noci, a natla\u010di\u0165 v\u0161etko do Dockera... A ak by sa do Dockera natla\u010dilo 5 TB... Alebo je v\u0161etko v poriadku?<\/i><\/p>\n

DS<\/b>: Ak\u00fd je rozdiel: rob\u00edte to cez dump a restore?<\/p>\n

NS<\/b>: V\u00f4bec nie je nevyhnutn\u00e9. Sp\u00f4sobov na generovanie tohto obrazu m\u00f4\u017ee by\u0165 viac.<\/i><\/p>\n

DS<\/b>: Pre niektor\u00fdch klientov sme urobili tak, \u017ee namiesto pravidelnej gener\u00e1cie z\u00e1kladn\u00e9ho obrazu, ho neust\u00e1le udr\u017eiavame aktu\u00e1lny. V podstate je to replika, ale d\u00e1ta nez\u00edskava priamo z majstra, ale cez arch\u00edv. Binarov\u00fd arch\u00edv, do ktor\u00e9ho sa ka\u017edodenne ukladaj\u00fa WAL, tam sa robia aj z\u00e1lohy\u2026 Tieto WAL sa potom dostan\u00fa \u2014 s mal\u00fdm oneskoren\u00edm (doslova 1-2 sekundy) \u2014 do z\u00e1kladn\u00e9ho obrazu. Z neho klonujeme ak\u00fdmko\u013evek sp\u00f4sobom \u2014 aktu\u00e1lne m\u00e1me predvolene ZFS.<\/p>\n

NS<\/b>: Pre niektor\u00fdch klientov sme urobili to, \u017ee namiesto pravidelnej gener\u00e1cie z\u00e1kladn\u00e9ho obrazu ho neust\u00e1le udr\u017eiavame v aktu\u00e1lnom stave. V podstate ide o repliku, ale d\u00e1ta neberie priamo z hlavn\u00e9ho zdroja, ale prostredn\u00edctvom arch\u00edvu. Binarne arch\u00edv, kam sa WAL’y nahr\u00e1vaj\u00fa ka\u017ed\u00fd de\u0148, tam s\u00fa aj z\u00e1lohy... Tieto WAL’y sa potom dostan\u00fa \u2014 s mal\u00fdm oneskoren\u00edm (doslova 1-2 sekundy) \u2014 na z\u00e1kladn\u00fd obraz. Z neho klonujeme ak\u00fdmko\u013evek sp\u00f4sobom \u2014 teraz m\u00e1me predvolene ZFS.<\/i><\/p>\n

DS<\/b>: \u00c1no. Ale ZFS m\u00e1 aj \u010darovn\u00fd<\/p>\n

NS<\/b>: s n\u00edm m\u00f4\u017eete posla\u0165 snapshot a dokonca (e\u0161te som to ve\u013emi netestoval, ale\u2026) m\u00f4\u017eete posla\u0165 delta medzi dvoma rovnak\u00e9 jednoduch\u00e9. Najprv zap\u00ed\u0161eme v\u0161etky nov\u00e9 z\u00e1znamy zahrnut\u00e9 v pr\u00fade<\/a><\/noindex>. V skuto\u010dnosti m\u00e1me e\u0161te jeden n\u00e1stroj, ktor\u00fd sme pre tieto \u00falohy pr\u00edli\u0161 nesk\u00famali. V PostgreSQL je PGDATA<\/code>pg_rewind pg_rewind<\/a><\/noindex>, funguj\u00faci ako \u201einteligentn\u00fd\u201c rsync, ktor\u00fd presko\u010d\u00ed mnoh\u00e9 veci, na ktor\u00e9 nie je potrebn\u00e9 sa pozera\u0165, preto\u017ee sa tam ni\u010d nezmenilo. M\u00f4\u017eeme r\u00fdchlo synchronizova\u0165 medzi dvoma servermi a vr\u00e1ti\u0165 sa presne sp\u00e4\u0165.<\/i><\/p>\n

Tak\u017ee sa sna\u017e\u00edme z tejto, viac DBA’nej, str\u00e1nky vytvori\u0165 n\u00e1stroj, ktor\u00fd umo\u017en\u00ed robi\u0165 to ist\u00e9, o \u010dom si hovoril: m\u00e1me jednu datab\u00e1zu, ale chceme 50-kr\u00e1t nie\u010do otestova\u0165, takmer s\u00fa\u010dasne.<\/i><\/p>\n

DS<\/b>: 50-kr\u00e1t znamen\u00e1, \u017ee mus\u00edte objedna\u0165 50 Spot’ov\u00fdch in\u0161tanci\u00ed.<\/p>\n

NS<\/b>: Nie, rob\u00edme to na jednom stroji.<\/i><\/p>\n

DS<\/b>: Ale ako nasad\u00edte 50-kr\u00e1t, ak je t\u00e1 jedna datab\u00e1za, povedzme, terabajtov\u00e1. Pravdepodobne potrebuje pribli\u017ene 256 GB RAM?<\/p>\n

NS<\/b>: \u00c1no, pam\u00e4ti niekedy treba ve\u013ea \u2014 to je norm\u00e1lne. Ale tak\u00fdto pr\u00edklad z praxe. Na produk\u010dnom stroji 96 jadier a 600 GB. Z toho pre datab\u00e1zu pou\u017e\u00edvame 32 jadier (u\u017e aj 16 jadier niekedy) a pam\u00e4ti 100-120 GB.<\/i><\/p>\n

DS<\/b>: A zmest\u00ed sa tam 50 k\u00f3pi\u00ed?<\/p>\n

NS<\/b>: Tak k\u00f3pia je jedna, \u010falej funguje copy-on-write (ZFS’n\u00fd)\u2026 Povedal by som podrobnej\u0161ie.<\/i><\/p>\n

Napr\u00edklad m\u00e1me datab\u00e1zu na 10 TB. Disk pre \u0148u bol vytvoren\u00fd, ZFS jej zmen\u0161il ve\u013ekos\u0165 o 30-40%. Ke\u010f\u017ee nerob\u00edme z\u00e1\u0165a\u017eov\u00e9 testovanie, presn\u00e1 doba odozvy nie je pre n\u00e1s d\u00f4le\u017eit\u00e1: nech je o 2-kr\u00e1t pomal\u0161ia \u2014 to je v poriadku.<\/i><\/p>\n

D\u00e1vame mo\u017enos\u0165 program\u00e1torom, QA, DBA at\u010f. vykon\u00e1va\u0165 testovanie v 1-2 tokom. Napr\u00edklad m\u00f4\u017eu spusti\u0165 nejak\u00fa migr\u00e1ciu. Nevy\u017eaduje hne\u010f 10 jadier \u2014 potrebuje 1 backend Postgres’a, 1 jadro. Migr\u00e1cia sa spust\u00ed \u2014 mo\u017eno, autovacuum<\/a><\/noindex> e\u0161te sa spust\u00ed, potom sa zapne druh\u00e9 jadro. M\u00e1me vyhraden\u00e9 16-32 jadier, tak\u017ee 10 \u013eud\u00ed m\u00f4\u017ee pracova\u0165 s\u00fa\u010dasne, nijak\u00e9 probl\u00e9my nie s\u00fa.<\/i><\/p>\n

Ke\u010f\u017ee fyzicky PGDATA<\/code> rovnak\u00e1, vyjde to tak, \u017ee vlastne klameme Postgres. Finta je v tom: spust\u00ed sa napr\u00edklad 10 Postgres’ov s\u00fa\u010dasne. Ak\u00fd je zvy\u010dajne probl\u00e9m? Vytv\u00e1raj\u00fa shared_buffers<\/a><\/noindex>, povedzme, na 25%. Tak\u017ee to je 200 GB. Viac ako tri u\u017e nespust\u00edte, preto\u017ee pam\u00e4\u0165 sa minie.<\/i><\/p>\n

Ale v istom momente sme si uvedomili, \u017ee to nie je potrebn\u00e9: nastavujeme shared_buffers na 2 GB. PostgreSQL m\u00e1 effective_cache_size<\/a><\/noindex>, a v skuto\u010dnosti ovplyv\u0148uje iba pl\u00e1ny<\/a><\/noindex>. Ten nastavujeme na 0,5 TB. A ani nie je d\u00f4le\u017eit\u00e9, \u017ee ich v skuto\u010dnosti nie je: vytv\u00e1ra pl\u00e1ny, akoby boli.<\/i><\/p>\n

Pod\u013ea toho, ke\u010f testujeme nejak\u00fa migr\u00e1ciu, m\u00f4\u017eeme zozbiera\u0165 v\u0161etky pl\u00e1ny \u2014 uvid\u00edme, ako to bude prebieha\u0165 na production. Sekundy tam bud\u00fa in\u00e9 (spomalen\u00e9), ale d\u00e1ta, ktor\u00e9 skuto\u010dne \u010d\u00edtame, a samotn\u00e9 pl\u00e1ny (ak\u00e9 tam s\u00fa JOIN’y at\u010f.) vych\u00e1dzaj\u00fa presne tie ist\u00e9, ako na production. A s\u00fa\u010dasne m\u00f4\u017eeme spusti\u0165 mno\u017estvo tak\u00fdchto kontrol na jednom zariaden\u00ed.<\/i><\/p>\n

DS<\/b>: Nemysl\u00ed\u0161, \u017ee tu je nieko\u013eko probl\u00e9mov? Prv\u00fd \u2014 je to rie\u0161enie, ktor\u00e9 funguje iba na PostgreSQL. Tak\u00fdto pr\u00edstup je ve\u013emi \u0161pecifick\u00fd, nie je generick\u00fd. Druh\u00fd \u2014 Kubernetes (a v\u0161etko, kam teraz smeruj\u00fa cloudov\u00e9 technol\u00f3gie) predpoklad\u00e1 mno\u017estvo uzlov, a tieto uzly s\u00fa efem\u00e9rne. A vo tvojom pr\u00edpade je to stateful, perzistentn\u00fd uzol. Tieto veci vo mne vyvol\u00e1vaj\u00fa rozpory.<\/p>\n

NS<\/b>: Prv\u00e9 \u2014 s\u00fahlas\u00edm, to je \u010disto Postgres’ov\u00e1 z\u00e1le\u017eitos\u0165. Mysl\u00edm, ak m\u00e1me nejak\u00fd direct IO a vyrovn\u00e1vaciu pam\u00e4\u0165 takmer pod celou pam\u00e4\u0165ou, tak\u00fdto pr\u00edstup nebude fungova\u0165 \u2014 pl\u00e1ny bud\u00fa in\u00e9. Ale zatia\u013e pracujeme iba s Postgres’om, o in\u00fdch neuva\u017eujeme.<\/i><\/p>\n

O Kubernetes. Ve\u010f s\u00e1m v\u0161ade hovor\u00ed\u0161, \u017ee na\u0161a datab\u00e1za je perzistentn\u00e1. Ak in\u0161tancia spadne, hlavn\u00e9 je zachova\u0165 disk. Na\u0161a cel\u00e1 platforma je tie\u017e v Kubernetes, a komponent s Postgresom je oddelen\u00fd (aj ke\u010f aj on tam raz bude). Preto je to tak: in\u0161tancia spadne, ale my sme jej PV zachovali a jednoducho sme ho pripojili k inej (novej) in\u0161tancii, akoby sa ni\u010d nestalo.<\/i><\/p>\n

DS<\/b>: Z m\u00f4jho poh\u013eadu vytv\u00e1rame pod’y v Kubernetes. K8s \u2014 elastick\u00fd: uzly sa objedn\u00e1vaj\u00fa sam\u00e9 pod\u013ea potreby. \u00daloha \u2014 vytvori\u0165 jednoducho pod a poveda\u0165 mu, \u017ee potrebuje X zdrojov, a \u010falej sa K8s sam\u00e9 postar\u00e1. Ale podpora \u00falo\u017e\u00edsk v Kubernetes je st\u00e1le nestabiln\u00e1: v 1.16<\/a><\/noindex>, v 1.17<\/a><\/noindex> (tento release vy\u0161iel pred t\u00fd\u017ed\u0148om) tieto funkcie sa st\u00e1vaj\u00fa len beta.<\/i> O pol roka a\u017e rok \u2014 to by malo by\u0165 viac-menej stabiln\u00e9, alebo aspo\u0148 bude vyhl\u00e1sen\u00e9 za tak\u00e9. Potom mo\u017enos\u0165 snapshotov a resize-u u\u017e \u00faplne vyrie\u0161i va\u0161u \u00falohu. Preto\u017ee m\u00e1te datab\u00e1zu. \u00c1no, nemus\u00ed by\u0165 ve\u013emi r\u00fdchla, ale r\u00fdchlos\u0165 z\u00e1vis\u00ed od toho, \u010do je \u201epod kapotou\u201c, preto\u017ee niektor\u00e9 implement\u00e1cie zvl\u00e1daj\u00fa kop\u00edrovanie a copy-on-write na \u00farovni diskovej subsyst\u00e9my.<\/p>\n

Prejde polrok a\u017e rok \u2014 stane sa to viac-menej stabiln\u00fdm, alebo aspo\u0148 to bude takto deklarovan\u00e9. Vtedy mo\u017enos\u0165 snapshotov a resize u\u017e \u00faplne rie\u0161i va\u0161u \u00falohu. Preto\u017ee m\u00e1te datab\u00e1zu. \u00c1no, nemus\u00ed by\u0165 ve\u013emi r\u00fdchla, ale r\u00fdchlos\u0165 z\u00e1vis\u00ed od toho, \u010do je \u201epod kapotou\u201c, preto\u017ee niektor\u00e9 implement\u00e1cie zvl\u00e1daj\u00fa kop\u00edrovanie a copy-on-write na \u00farovni diskov\u00e9ho subsyst\u00e9mu.<\/p>\n

NS<\/b>: Zatia\u013e ich nepou\u017e\u00edvame. Pou\u017e\u00edvame svoje.<\/i><\/p>\n

DS<\/b>Lok\u00e1lna v\u00fdvojov\u00e1 pr\u00e1ca pod Kubernetes<\/p>\n

Lok\u00e1lny v\u00fdvoj pre Kubernetes<\/h2>\n

\nNS<\/b>: Stretol si sa niekedy s takouto po\u017eiadavkou, ke\u010f je potrebn\u00e9 na jednom stroji spusti\u0165 v\u0161etky pod a urobi\u0165 mal\u00e9 testovanie. Aby si r\u00fdchlo z\u00edskal proof of concept, uvidel, \u017ee aplik\u00e1cia funguje v Kubernetes, bez potreby vyhradi\u0165 na to hromadu strojov. Je tu Minikube, v\u0161ak?<\/i><\/p>\n

DS<\/b>: Mysl\u00edm, \u017ee tento pr\u00edpad - rozbehn\u00fa\u0165 to na jednom uzle - sa t\u00fdka v\u00fdlu\u010dne lok\u00e1lneho v\u00fdvoja. Alebo nejak\u00e9 prejavy tak\u00e9ho vzoru. Existuje Minikube<\/a><\/noindex>, je k3s<\/a><\/noindex>, KIND<\/a><\/noindex>. Ideme k tomu, \u017ee budeme pou\u017e\u00edva\u0165 Kubernetes IN Docker. Teraz sme za\u010dali pracova\u0165 s t\u00fdm na testy.<\/p>\n

NS<\/b>: Predt\u00fdm som si myslel, \u017ee je to pokus zabali\u0165 v\u0161etky pod do jedn\u00e9ho Docker obrazu. Ale uk\u00e1zalo sa, \u017ee je to \u00faplne o nie\u010dom inom. Rovnako tam s\u00fa samostatn\u00e9 kontajnery, samostatn\u00e9 pod \u2014 jednoducho v Dockeri.<\/i><\/p>\n

DS<\/b>: \u00c1no. A tam je dos\u0165 z\u00e1bavn\u00e1 imit\u00e1cia, ale zmysel je tak\u00fd... M\u00e1me n\u00e1stroj na nasadenie - werf<\/a><\/noindex>. Chceme v \u0148om spravi\u0165 re\u017eim - povedzme werf up<\/code>: \u201eZdvihni mi lok\u00e1lny Kubernetes\u201c. A potom spusti\u0165 tam podmiene\u010dn\u00fd werf follow<\/code>. Potom bude ma\u0165 v\u00fdvoj\u00e1r mo\u017enos\u0165 upravova\u0165 v IDE, zatia\u013e \u010do v syst\u00e9me be\u017e\u00ed proces, ktor\u00fd vid\u00ed zmeny a prekompilov\u00e1va obrazy, znova nasadzuje ich do lok\u00e1lneho K8s. Tak chceme sk\u00fasi\u0165 vyrie\u0161i\u0165 probl\u00e9m lok\u00e1lneho v\u00fdvoja.<\/p>\n

Snapshoty a klonovanie DB v realite K8s<\/h2>\n

\nNS<\/b>: Ak sa vr\u00e1time k copy-on-write. V\u0161imol som si, \u017ee aj cloudov\u00e9 slu\u017eby maj\u00fa snapshoty. Funguj\u00fa r\u00f4zne. Napr\u00edklad v GCP: m\u00e1\u0161 na v\u00fdchodnom pobre\u017e\u00ed USA multiterabajtov\u00fd in\u0161tanc. Rob\u00ed\u0161 pravidelne snapshoty. Vybuduje\u0161 z snapshotu k\u00f3piu disku na z\u00e1padnom pobre\u017e\u00ed \u2014 za p\u00e1r min\u00fat u\u017e je v\u0161etko pripraven\u00e9, pracuje to ve\u013emi r\u00fdchlo, len je potrebn\u00e9 naplni\u0165 cache v pam\u00e4ti. Ale tieto klony (snapshoty) s\u00fa na to, aby si \u201eprovisionoval\u201c nov\u00fd objem. Je to skvel\u00e9, ke\u010f potrebuje\u0161 vytvori\u0165 ve\u013ea in\u0161tanci\u00ed.<\/i><\/p>\n

Ale na testy sa mi zd\u00e1, \u017ee snapshoty, o ktor\u00fdch hovor\u00ed\u0161 v Dockeri alebo o ktor\u00fdch hovor\u00edm ja v ZFS, btrfs a dokonca LVM\u2026 \u2014 umo\u017e\u0148uj\u00fa v podstate na jednom stroji nevytv\u00e1ra\u0165 nov\u00e9 d\u00e1ta. V cloude za ne bude\u0161 musie\u0165 zaka\u017ed\u00fdm plati\u0165 a u\u017e ne\u010dak\u00e1\u0161 sekundy, ale min\u00faty (a v pr\u00edpade lazy load’u<\/a><\/noindex>, mo\u017eno aj hodiny).<\/i><\/p>\n

Namiesto toho m\u00f4\u017ee\u0161 za sekundu-dve z\u00edska\u0165 tieto d\u00e1ta, spravi\u0165 test a zahodi\u0165. Tieto snapshoty rie\u0161ia r\u00f4zne \u00falohy. V prvom pr\u00edpade - aby si sa mohol \u0161k\u00e1lova\u0165 a z\u00edska\u0165 nov\u00e9 repliky, a v druhom - na testy.<\/i><\/p>\n

DS<\/b>: Nes\u00fahlas\u00edm. Zrealizova\u0165 spr\u00e1vne klonovanie objemov je \u00faloha pre cloud. Nevidel som ich implement\u00e1ciu, ale viem, ako to rob\u00edme my na hardv\u00e9ri. M\u00e1me Ceph, v ktorom m\u00f4\u017eeme ak\u00e9muko\u013evek fyzick\u00e9mu objemu (RBD<\/a><\/noindex>) poveda\u0165 klon<\/i> a za desiatky milisek\u00fand dosta\u0165 druh\u00fd objem s rovnak\u00fdmi vlastnos\u0165ami, IOPS<\/a><\/noindex>a t\u00fdm podobne. Treba ch\u00e1pa\u0165, \u017ee tam vn\u00fatorn\u00fd mechanizmus je inteligentn\u00fd copy-on-write. Pre\u010do by cloud nemohol fungova\u0165 rovnako? Som si ist\u00fd, \u017ee sa to nejak\u00fdm sp\u00f4sobom sna\u017eia dosiahnu\u0165.<\/p>\n

NS<\/b>: Ale aj tak im to zaberie sekundy, desiatky sek\u00fand, k\u00fdm spustia in\u0161tanciu, dostan\u00fa tam Docker at\u010f.<\/i><\/p>\n

DS<\/b>: Pre\u010do mus\u00ed by\u0165 nutne cel\u00e1 in\u0161tancia spusten\u00e1? Ve\u010f m\u00e1me in\u0161tanciu na 32 jadier, na 16\u2026 a do jej kapacity sa vmest\u00ed ur\u010dit\u00fd po\u010det \u2014 napr\u00edklad \u0161tyri. Ke\u010f si objedn\u00e1me piatu, u\u017e sa spust\u00ed in\u0161tancia, a potom sa odstr\u00e1ni.<\/p>\n

NS<\/b>: \u00c1no, zauj\u00edmav\u00e9, v Kubernetes to vyzer\u00e1 inak. Na\u0161a datab\u00e1za nie je v K8s a m\u00e1me len jednu in\u0161tanciu. Ale na klonovanie viac terabajtovej datab\u00e1zy netrv\u00e1 viac ako dve sekundy.<\/i><\/p>\n

DS<\/b>: To je super. Ale m\u00f4j po\u010diato\u010dn\u00fd n\u00e1zor je ten, \u017ee to nie je generick\u00e9 rie\u0161enie. \u00c1no, je to skvel\u00e9, ale vyhovuje to len Postgresu a len na jednom uzle.<\/p>\n

NS<\/b>: Nepatronuje to len Pre Postgres: tieto pl\u00e1ny, ako som pop\u00edsal, bud\u00fa fungova\u0165 takto len v \u0148om. Ale ak neprihliadame na pl\u00e1ny a jednoducho potrebujeme v\u0161etky d\u00e1ta na funk\u010dn\u00e9 testovanie, potom to bude fungova\u0165 pre ak\u00fako\u013evek DBMS.<\/i><\/p>\n

DS<\/b>: Pred mnoh\u00fdmi rokmi sme robili nie\u010do podobn\u00e9 na LVM snapshot-och. To je klasika. Tento pr\u00edstup bol ve\u013emi akt\u00edvne pou\u017e\u00edvan\u00fd. Proste stateful uzly s\u00fa probl\u00e9m. Preto\u017ee ich treba nezr\u00fatnu\u0165, v\u017edy na ne pam\u00e4ta\u0165...<\/p>\n

NS<\/b>: Nevid\u00ed\u0161 tu nejak\u00fa mo\u017enos\u0165 hybridu? Povedzme, \u017ee stateful je nejak\u00fd pod, ktor\u00fd pracuje pre viacero \u013eud\u00ed (mnoho testerov). Objem m\u00e1me jeden, ale v\u010faka s\u00faborov\u00e9mu syst\u00e9mu s\u00fa klony miestne. Ak padne pod, disk ostane \u2014 znovu sa spust\u00ed pod, naberie inform\u00e1cie o v\u0161etk\u00fdch klonoch, v\u0161etko vr\u00e1ti sp\u00e4\u0165 a povie: 'Tu s\u00fa va\u0161e klony na t\u00fdchto portoch spusten\u00e9, pracujte s nimi \u010falej.'<\/i><\/p>\n

DS<\/b>: Technicky to znamen\u00e1, \u017ee v r\u00e1mci Kubernetes je to jeden pod, v ktorom sp\u00fa\u0161\u0165ame ve\u013ea Postgresov.<\/p>\n

NS<\/b>: \u00c1no. M\u00e1 svoje obmedzenie: povedzme, \u017ee s n\u00edm pracuje s\u00fa\u010dasne najviac 10 \u013eud\u00ed. Ak potrebujeme 20 \u2014 spust\u00edme druh\u00fd tak\u00fd pod. \u00daplne realisticky m\u00f4\u017eeme jeho sklonova\u0165, \u010d\u00edm z\u00edskame druh\u00fd pln\u00fd objem, na ktorom bud\u00fa rovnak\u00e9 10 'tenk\u00fdch' klonov. Nevid\u00ed\u0161 tak\u00fato mo\u017enos\u0165?<\/i><\/p>\n

DS<\/b>: Mus\u00edme sem prida\u0165 ot\u00e1zky bezpe\u010dnosti. Tento syst\u00e9m predpoklad\u00e1, \u017ee tento pod m\u00e1 vysok\u00e9 privil\u00e9gi\u00e1 (capabilities), preto\u017ee m\u00f4\u017ee vykon\u00e1va\u0165 nestandardn\u00e9 oper\u00e1cie s pod (FILE) syst\u00e9mom... Ale opakujem: domnievam sa, \u017ee v strednodobom horizonte Kubernetes oprav\u00ed storage, v cloudu opravia v\u0161etko okolo objemov \u2014 v\u0161etko za\u010dne \u201ejednoducho fungova\u0165\u201c. Bude resize, klonovanie... Ak existuje objem \u2014 hovor\u00edme: \u201eVytvor nov\u00fd na z\u00e1klade tohto\u201c, \u2014 a za sekundu a pol dostaneme, \u010do potrebujeme.<\/p>\n

NS<\/b>: Never\u00edm v sekundy pre mnoh\u00e9 terabajty. Na Ceph to rob\u00ed\u0161 s\u00e1m, a hovor\u00ed\u0161 o cloude. Cho\u010f do cloudu, na EC2 urob klon objemu EBS mnoh\u00fdch terabajtov a pozri sa, ak\u00fd v\u00fdkon bude. To nezaberie nieko\u013eko sek\u00fand. Zauj\u00edma ma, kedy sa dostan\u00fa na tak\u00fdto \u00fadaj. Rozumiem, o \u010dom hovor\u00ed\u0161, ale dovo\u013eujem si nes\u00fahlasi\u0165.<\/i><\/p>\n

DS<\/b>: Oki, ale povedal som, \u017ee v strednodobom horizonte, nie kr\u00e1tkodobom. V priebehu nieko\u013ek\u00fdch rokov.<\/p>\n

O oper\u00e1torovi pre PostgreSQL od Zalando<\/h2>\n

\nV strede tejto porady sa k nej tie\u017e pripojil Alexej Klyukin, b\u00fdval\u00fd \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a z firmy Zalando, ktor\u00fd povedal o hist\u00f3rii oper\u00e1tora PostgreSQL:<\/p>\n

Je skvel\u00e9, \u017ee sa t\u00e1to t\u00e9ma v\u00f4bec dotkla: a Postgres, a Kubernetes. Ke\u010f sme to za\u010d\u00ednali robi\u0165 v Zalando v roku 2017, bola to tak\u00e1 t\u00e9ma, ktorou sa v\u0161etci chceli zaobera\u0165, ale nikto to nerobil. V\u0161etci u\u017e mali Kubernetes, ale ke\u010f sa p\u00fdtali, ako na to s datab\u00e1zami, tak aj tak\u00ed \u013eudia ako Kelsey Hightower<\/a><\/noindex>, ktor\u00ed k\u00e1zali o K8s, hovorili pribli\u017ene toto:<\/p>\n

\"Cho\u010fte do managed-slu\u017eieb a pou\u017e\u00edvajte ich, nesp\u00fa\u0161\u0165ajte DB v Kubernetes. Inak v\u00e1\u0161 K8s rozhodne, napr\u00edklad, urobi\u0165 upgrade, vypne v\u0161etky uzly a va\u0161e d\u00e1ta odletia \u010faleko-daleko.\"<\/i><\/p>\n

Rozhodli sme sa urobi\u0165 oper\u00e1tora, ktor\u00fd, v rozpore s touto radou, spust\u00ed datab\u00e1zu Postgres v Kubernetes. A mali sme dobr\u00fd z\u00e1klad \u2014 Patroni<\/a><\/noindex>. Toto je automatick\u00fd failover pre PostgreSQL, spr\u00e1vne nastaven\u00fd, t.j. vyu\u017e\u00edvaj\u00faci etcd, consul alebo ZooKeeper ako \u00falo\u017eisko inform\u00e1ci\u00ed o klastri. Tak\u00e9to \u00falo\u017eisko, ktor\u00e9 bude poskytova\u0165 v\u0161etk\u00fdm, ktor\u00ed sa p\u00fdtaj\u00fa, napr\u00edklad, kto je teraz l\u00edder, rovnak\u00e9 inform\u00e1cie \u2014 aj ke\u010f je v\u0161etko rozdelen\u00e9, \u2014 aby sa predi\u0161lo split brain'u. Plus, mali sme Docker-image<\/a><\/noindex> pre\u0148.<\/p>\n

Vlastne, potreba auto failoveru sa u spolo\u010dnosti objavila po migr\u00e1cii z interne spravovanej d\u00e1tov\u00e9ho centra do cloudu. Cloud bol zalo\u017een\u00fd na vlastnom PaaS (Platform-as-a-Service) rie\u0161en\u00ed. Bolo Open Source, ale na to, aby sme ho spustili, bolo potrebn\u00e9 vynalo\u017ei\u0165 ve\u013ek\u00e9 \u00fasilie. Volalo sa STUPS<\/a><\/noindex>.<\/p>\n

P\u00f4vodne neexistoval \u017eiadny Kubernetes. Presnej\u0161ie, ke\u010f sa nasadzovalo vlastn\u00e9 rie\u0161enie, K8s u\u017e existoval, ale bol tak\u00fd nedokonal\u00fd, \u017ee na produk\u010dn\u00e9 pou\u017eitie nebol vhodn\u00fd. Pod\u013ea m\u0148a to bol rok 2015 alebo 2016. Do roku 2017 sa Kubernetes stal viac-menej zrel\u00fdm \u2014 objavila sa potreba migr\u00e1cie tam.<\/p>\n

A u\u017e sme mali Docker kontajner. Bol tu PaaS, ktor\u00fd pou\u017e\u00edval Docker. Pre\u010do nevyu\u017ei\u0165 K8s? Pre\u010do nenap\u00edsa\u0165 svojho oper\u00e1tora? Murat Kabilov, ktor\u00fd k n\u00e1m pri\u0161iel z Avita, za\u010dal tento projekt na vlastn\u00fa iniciat\u00edvu \u2014 \"pohr\u00e1va\u0165 sa\" \u2014 a projekt \"vzlietol\".<\/p>\n

Ale vlastne som chcel rozpr\u00e1va\u0165 o AWS. Pre\u010do tam bol historicky k\u00f3d t\u00fdkaj\u00faci sa AWS...<\/p>\n

Ke\u010f sp\u00fa\u0161\u0165ate \u010doko\u013evek v Kubernetes, treba si uvedomi\u0165, \u017ee K8s je st\u00e1le v procese v\u00fdvoja. Neust\u00e1le sa vyv\u00edja, zlep\u0161uje a ob\u010das sa aj rozbije. Je potrebn\u00e9 pozorne sledova\u0165 v\u0161etky zmeny v Kubernetes, by\u0165 pripraven\u00fd ponori\u0165 sa do toho a zisti\u0165, ako to funguje v detailoch \u2014 mo\u017eno viac, ako by ste chceli. Toto plat\u00ed v podstate pre ka\u017ed\u00fa platformu, na ktorej sp\u00fa\u0161\u0165ate svoje datab\u00e1zy...<\/p>\n

Tak\u017ee, ke\u010f sme robili oper\u00e1tora, mali sme Postgres, ktor\u00fd pracoval s extern\u00fdm zv\u00e4zkom (v tomto pr\u00edpade EBS, ke\u010f\u017ee sme pracovali v AWS). Datab\u00e1za r\u00e1stla, v ur\u010ditom momente bolo potrebn\u00e9 urobi\u0165 resize: napr\u00edklad p\u00f4vodn\u00e1 ve\u013ekos\u0165 EBS bola 100 TB, datab\u00e1za ju dosiahla a teraz chceme zv\u00e4\u010d\u0161i\u0165 EBS na 200 TB. Ako? Predpokladajme, \u017ee je mo\u017en\u00e9 urobi\u0165 dump\/restore na nov\u00fa in\u0161tanciu, ale to trv\u00e1 dlho a sp\u00f4sobuje prestoj.<\/p>\n

Preto sme chceli tak\u00fd resize, ktor\u00fd by zv\u00e4\u010d\u0161oval oddiel EBS a potom by hovoril s\u00faborov\u00e9mu syst\u00e9mu, aby vyu\u017e\u00edval nov\u00fd priestor. A to sme urobili, ale v tom \u010dase Kubernetes nemal \u017eiadne API na oper\u00e1ciu resize. Ke\u010f\u017ee sme pracovali na AWS, nap\u00edsali sme k\u00f3d pre jeho API.<\/p>\n

Nikto nebr\u00e1ni tomu, aby sa to ist\u00e9 urobilo pre in\u00e9 platformy. V oper\u00e1torovi nie je viazanos\u0165, \u017ee ho mo\u017eno spusti\u0165 len na AWS, a na v\u0161etkom ostatnom nebude fungova\u0165. V podstate ide o Open Source projekt: ak niekto chce ur\u00fdchli\u0165 zavedenie nov\u00e9ho API \u2014 ste v\u00edtan\u00ed. Existuje GitHub<\/a><\/noindex>, pull-requesty \u2014 t\u00edm Zalando sa sna\u017e\u00ed celkom promptne na ne reagova\u0165 a pos\u00fava\u0165 oper\u00e1tora. Ako viem, projekt sa z\u00fa\u010dastnil<\/a><\/noindex> v Google Summer of Code a v niektor\u00fdch in\u00fdch podobn\u00fdch iniciat\u00edvach. Zalando na \u0148om ve\u013emi akt\u00edvne pracuje.\n<\/p><\/blockquote>\n

<\/p>\n

P.S. Bonus!<\/h2>\n

\nAk v\u00e1s zauj\u00edma t\u00e9ma PostgreSQL a Kubernetes, upozor\u0148ujeme, \u017ee minul\u00fd t\u00fd\u017ede\u0148 sa konal nasleduj\u00faci Postgres-utork, kde sa s Nikolaiom rozpr\u00e1val Alexander Kuku\u0161kin zo Zalando<\/b>. Video z neho je dostupn\u00e9 tu<\/a><\/noindex>.<\/p>\n

P.P.S.<\/h2>\n

\nPre\u010d\u00edtajte si tie\u017e na na\u0161om blogu:<\/p>\n