{"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\/cs\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-\u00fater\u00fd \u010d. 5: \"PostgreSQL a Kubernetes. CI\/CD. Automatizace testov\u00e1n\u00ed\"","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-\u00fater\u00fd
\n
\nNa konci minul\u00e9ho roku prob\u011bhlo dal\u0161\u00ed \u017eiv\u00e9 vys\u00edl\u00e1n\u00ed rusk\u00e9 komunity PostgreSQL, #RuPostgres<\/a><\/noindex>, b\u011bhem n\u011bho\u017e jeho spoluzakladatel Nikolaj Samochvalov hovo\u0159il s technick\u00fdm \u0159editelem spole\u010dnosti \u201eFlant\u201c Dmitrijem Stolyarovem o t\u00e9to DBMS v kontextu Kubernetes.<\/p>\n

Publikujeme p\u0159epis hlavn\u00ed \u010d\u00e1sti t\u00e9to diskuse, a na YouTube kan\u00e1lu komunity<\/a><\/noindex> byl zve\u0159ejn\u011bn kompletn\u00ed videoz\u00e1znam:<\/a><\/noindex><\/p>\n

\r\n \"P\u0159ehr\u00e1t\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

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

\nNS<\/b>: Dnes se nebudeme bavit o VACUUM a CHECKPOINTech. Chceme mluvit o Kubernetes. V\u00edm, \u017ee u\u017e m\u00e1\u0161 mnoho let zku\u0161enost\u00ed. D\u00edval jsem se na tvoje videa a n\u011bkter\u00e9 jsem dokonce proch\u00e1zel po \u010d\u00e1stech... Poj\u010fme rovnou na v\u011bc: pro\u010d v\u016fbec pou\u017e\u00edvat Postgres nebo MySQL v K8s?<\/i><\/p>\n

DS<\/b>: Na tuto ot\u00e1zku nen\u00ed jednozna\u010dn\u00e1 odpov\u011b\u010f a ani nem\u016f\u017ee b\u00fdt. Ale obecn\u011b to jsou jednoduchost a pohodlnost\u2026 potenci\u00e1ln\u00ed. V\u0161ichni cht\u011bj\u00ed managed slu\u017eby.<\/p>\n

NS<\/b>: Aby to bylo RDS<\/a><\/noindex>, jen u sebe?<\/i><\/p>\n

DS<\/b>: Ano: aby to bylo jako RDS, jen kdekoli.<\/p>\n

NS<\/b>: \u201eKdekoli\u201c \u2014 to je dobr\u00e1 pozn\u00e1mka. Ve velk\u00fdch firm\u00e1ch je v\u0161e rozm\u00edst\u011bno na r\u016fzn\u00fdch m\u00edstech. A pro\u010d tedy, pokud je to velk\u00e1 firma, nevz\u00edt hotov\u00e9 \u0159e\u0161en\u00ed? Nap\u0159\u00edklad Nutanix m\u00e1 sv\u00e9 vlastn\u00ed v\u00fdvoje, u jin\u00fdch spole\u010dnost\u00ed (VMware\u2026) je to stejn\u00e9 \u201eRDS, jen u sebe\u201c.<\/i><\/p>\n

DS<\/b>: Ale mluv\u00edme o konkr\u00e9tn\u00ed implementaci, kter\u00e1 bude fungovat pouze za ur\u010dit\u00fdch podm\u00ednek. A pokud jde o Kubernetes, existuje obrovsk\u00e1 rozmanitost infrastruktury (kter\u00e1 m\u016f\u017ee b\u00fdt v K8s). V podstat\u011b je to standard pro API k cloudu\u2026<\/p>\n

NS<\/b>: A nav\u00edc zdarma!<\/i><\/p>\n

DS<\/b>: To nen\u00ed tak d\u016fle\u017eit\u00e9. Bezplatnost je d\u016fle\u017eit\u00e1 pro velmi mal\u00fd segment trhu. D\u016fle\u017eit\u00e9 je n\u011bco jin\u00e9ho\u2026 Ur\u010dit\u011b si vzpom\u00edn\u00e1\u0161 na m\u016fj p\u0159\u00edsp\u011bvek \u201eDatab\u00e1ze a Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

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

DS<\/b>: Pochopil jsem, \u017ee to bylo vn\u00edm\u00e1no velmi rozporupln\u011b. N\u011bkte\u0159\u00ed lid\u00e9 si mysleli, \u017ee \u0159\u00edk\u00e1m: \u201eHele, poj\u010fme s v\u0161emi datab\u00e1zemi do Kubernetes!\u201c, jin\u00ed usoudili, \u017ee to jsou hrozn\u00e9 bicykly. A j\u00e1 jsem cht\u011bl \u0159\u00edct n\u011bco \u00fapln\u011b jin\u00e9ho: \u201ePod\u00edvejte se, co se d\u011bje, jak\u00e9 jsou probl\u00e9my a jak je lze \u0159e\u0161it. Je te\u010f vhodn\u00e9 m\u00edt datab\u00e1ze v Kubernetes? V produkci? No, jen pokud m\u00e1te r\u00e1di... d\u011blat ur\u010dit\u00e9 v\u011bci. Ale pro v\u00fdvojov\u00e9 prost\u0159ed\u00ed \u2014 mohu \u0159\u00edct, \u017ee doporu\u010duji. Pro v\u00fdvoj je velmi d\u016fle\u017eit\u00e1 dynamika vytv\u00e1\u0159en\u00ed\/maz\u00e1n\u00ed prost\u0159ed\u00ed.<\/p>\n

NS: Mysl\u00ed\u0161 t\u00edm pod v\u00fdvojem v\u0161echna prost\u0159ed\u00ed, kter\u00e1 nejsou prod? Staging, QA\u2026<\/i><\/p>\n

DS<\/b>: Kdy\u017e mluv\u00edme o perf-standech, tak u\u017e asi ne, proto\u017ee tam jsou specifick\u00e9 po\u017eadavky. Pokud mluv\u00edme o zvl\u00e1\u0161tn\u00edch p\u0159\u00edpadech, kde je na staging pot\u0159eba velmi velk\u00e1 DB, tak tak\u00e9 asi ne... Pokud je to statick\u00e9 prost\u0159ed\u00ed, kter\u00e9 dlouho \u017eije, jak\u00fd m\u00e1 smysl, \u017ee je datab\u00e1ze um\u00edst\u011bna v K8s?<\/p>\n

NS<\/b>: \u017d\u00e1dn\u00fd. Ale kde vid\u00edme statick\u00e1 prost\u0159ed\u00ed? Statick\u00e9 prost\u0159ed\u00ed je u\u017e z\u00edtra zastaral\u00e9.<\/i><\/p>\n

DS<\/b>: Staging m\u016f\u017ee b\u00fdt statick\u00fd. M\u00e1me klienty...<\/p>\n

NS<\/b>: Ano, j\u00e1 tak\u00e9. Je to velk\u00fd probl\u00e9m, pokud m\u00e1te datab\u00e1zi o velikosti 10 TB a staging \u2014 200 GB...<\/i><\/p>\n

DS<\/b>: M\u00e1m velmi zaj\u00edmav\u00fd p\u0159\u00edpad! Na staggingu je produk\u010dn\u00ed datab\u00e1ze, do kter\u00e9 se prov\u00e1d\u011bj\u00ed zm\u011bny. A je tu tla\u010d\u00edtko: \u201enasadit do produkce\u201c. Tyto zm\u011bny \u2014 delta \u2014 se dol\u00e9vaj\u00ed (mysl\u00edm, \u017ee se jednodu\u0161e synchronizuj\u00ed p\u0159es API) do produkce. To je velmi exotick\u00e1 varianta.<\/p>\n

NS<\/b>: Vid\u011bl jsem startupy v Dole, kter\u00e9 je\u0161t\u011b b\u011b\u017e\u00ed na RDS nebo dokonce na Heroku \u2014 to jsou p\u0159\u00edb\u011bhy 2-3 let star\u00e9, \u2014 a stahuj\u00ed si dump na sv\u016fj laptop. Proto\u017ee datab\u00e1ze m\u00e1 zat\u00edm pouze 80 GB a na laptopu je dost m\u00edsta. Pot\u00e9 nakupuj\u00ed disky pro ka\u017ed\u00e9ho, aby m\u011bly 3 datab\u00e1ze pro r\u016fzn\u00e9 v\u00fdvoje. I to se n\u011bkdy st\u00e1v\u00e1. Tak\u00e9 jsem vid\u011bl, \u017ee se neboj\u00ed kop\u00edrovat prod do staggingu \u2014 hodn\u011b to z\u00e1vis\u00ed na spole\u010dnosti. Ale tak\u00e9 jsem vid\u011bl, \u017ee se velmi boj\u00ed a \u017ee \u010dasto nen\u00ed dost \u010dasu a lid\u00ed. Ale ne\u017e p\u0159ejdeme k tomuto t\u00e9matu, chci sly\u0161et o Kubernetes. Rozum\u00edm spr\u00e1vn\u011b, \u017ee v produkci zat\u00edm nikdo nem\u00e1?<\/i><\/p>\n

DS<\/b>: M\u00e1me men\u0161\u00ed datab\u00e1ze v produkci. \u0158e\u010d je o objemech v des\u00edtk\u00e1ch gigabajt\u016f a nekritick\u00fdch slu\u017eb\u00e1ch, pro kter\u00e9 se necht\u011blo vytv\u00e1\u0159et repliky (a ani nen\u00ed takov\u00e1 pot\u0159eba). A za podm\u00ednky, \u017ee pod Kubernetes je norm\u00e1ln\u00ed \u00falo\u017ei\u0161t\u011b. Tato datab\u00e1ze pracovala na virtu\u00e1ln\u00edm stroji \u2014 tak\u0159\u00edkaj\u00edc v VMware, nad \u00falo\u017ei\u0161t\u011bm. Um\u00edstili jsme ji do PV<\/a><\/noindex> a te\u010f ji m\u016f\u017eeme p\u0159esouvat z jedn\u00e9 ma\u0161iny na druhou.<\/p>\n

NS<\/b>: Datab\u00e1ze takov\u00e9 velikosti, do 100 GB, na kvalitn\u00edch disc\u00edch a p\u0159i dobr\u00e9 s\u00edti lze rozvinout za n\u011bkolik minut, je to spr\u00e1vn\u011b? Rychlost 1 GB za sekundu \u2014 to u\u017e nen\u00ed exotika.<\/i><\/p>\n

DS<\/b>: Ano, pro line\u00e1rn\u00ed operaci to nen\u00ed probl\u00e9m.<\/p>\n

NS<\/b>: Dob\u0159e, o produktech mus\u00edme pouze p\u0159em\u00fd\u0161let. A pokud uva\u017eujeme o Kubernetes pro ne-prod prost\u0159ed\u00ed \u2014 jak to ud\u011blat? Vid\u00edm, \u017ee v Zalando d\u011blaj\u00ed oper\u00e1tor<\/a><\/noindex>, v Crunchy vytv\u00e1\u0159ej\u00ed<\/a><\/noindex>, existuj\u00ed je\u0161t\u011b n\u011bjak\u00e9 varianty. A je zde OnGres<\/a><\/noindex> \u2014 to je n\u00e1\u0161 dobr\u00fd zn\u00e1m\u00fd Alvaro ze \u0160pan\u011blska: oni d\u011blaj\u00ed v podstat\u011b nejen oper\u00e1tor<\/a><\/noindex>, ale celou distribuci (StackGres<\/a><\/noindex>), do kter\u00e9ho krom\u011b samotn\u00e9ho Postgresu je\u0161t\u011b um\u00edst\u00edme z\u00e1lohu, proxy Envoy\u2026<\/i><\/p>\n

DS<\/b>: Envoy k \u010demu? K vyva\u017eov\u00e1n\u00ed pr\u00e1v\u011b provozu Postgresu?<\/p>\n

NS<\/b>: Ano. To znamen\u00e1, \u017ee to vid\u00ed takto: pokud vezmeme linuxovou distribuci a j\u00e1dro, tak obvykl\u00fd PostgreSQL je j\u00e1dro, a oni cht\u011bj\u00ed vytvo\u0159it distribuci, kter\u00e1 bude p\u0159\u00edv\u011btiv\u00e1 pro cloud a pob\u011b\u017e\u00ed v Kubernetes. Spojuj\u00ed komponenty (z\u00e1lohy apod.) a lad\u00ed je, aby dob\u0159e pracovaly.<\/i><\/p>\n

DS<\/b>: Velmi zaj\u00edmav\u00e9! V podstat\u011b je to software pro vytvo\u0159en\u00ed vlastn\u00edho spravovan\u00e9ho Postgresu.<\/p>\n

NS<\/b>: U linuxov\u00fdch distribuc\u00ed jsou v\u011b\u010dn\u00e9 probl\u00e9my: jak vyrobit ovlada\u010de, aby byla podporov\u00e1na ve\u0161ker\u00e1 hardware. A jejich my\u0161lenka je, \u017ee budou fungovat v Kubernetes. V\u00edm, \u017ee v oper\u00e1toru Zalando jsme ned\u00e1vno vid\u011bli vazbu na AWS a to u\u017e nen\u00ed p\u0159\u00edli\u0161 dobr\u00e9. Nem\u011bla by b\u00fdt vazba na konkr\u00e9tn\u00ed infrastrukturu \u2014 v \u010dem je pak smysl?<\/i><\/p>\n

DS<\/b>: Nev\u00edm, v jak\u00e9 situaci se konkr\u00e9tn\u011b Zalando dostalo do vazby, ale v Kubernetes je nyn\u00ed storage ud\u011bl\u00e1no tak, \u017ee nelze m\u00edt generick\u00fd zp\u016fsob, jak ud\u011blat diskovou z\u00e1lohu. Ned\u00e1vno bylo v posledn\u00ed verzi standardu \u2014 specifikace CSI<\/a><\/noindex> \u2014 p\u0159edstavena mo\u017enost sn\u00edmk\u016f, ale kde je realizov\u00e1na? \u010cestn\u011b, st\u00e1le je to tak nedokon\u010den\u00e9\u2026 Zkou\u0161\u00edme CSI nad AWS, GCE, Azure, vSphere, ale sotva za\u010dnete pou\u017e\u00edvat, je jasn\u00e9, \u017ee to je\u0161t\u011b nen\u00ed p\u0159ipraven\u00e9.<\/p>\n

NS<\/b>: Proto se n\u011bkdy mus\u00edte vazat na infrastrukturu. Mysl\u00edm, \u017ee st\u00e1le pokra\u010duje ran\u00e1 f\u00e1ze \u2014 probl\u00e9my s r\u016fstem. Ot\u00e1zka: co bys doporu\u010dil nov\u00e1\u010dk\u016fm, kte\u0159\u00ed cht\u011bj\u00ed vyzkou\u0161et PgSQL v K8s? Jak\u00fd oper\u00e1tor, mo\u017en\u00e1?<\/i><\/p>\n

DS<\/b>: Probl\u00e9m je v tom, \u017ee pro n\u00e1s je Postgres pouze 3 %. M\u00e1me tak\u00e9 velmi dlouh\u00fd seznam r\u016fzn\u00fdch softwar\u016f v Kubernetes, ani to nebudu v\u0161echno vyjmenov\u00e1vat. Nap\u0159\u00edklad Elasticsearch. Oper\u00e1tor\u016f je cel\u00e1 \u0159ada: n\u011bkte\u0159\u00ed se aktivn\u011b vyv\u00edjej\u00ed, jin\u00ed ne. Stanovili jsme si po\u017eadavky, co by m\u011bl oper\u00e1tor m\u00edt, abychom ho brali v\u00e1\u017en\u011b. V oper\u00e1toru pro Kubernetes \u2014 nikoli \u201eoper\u00e1torovi pro n\u011bco v podm\u00ednk\u00e1ch Amazonu\u201c\u2026 Ve skute\u010dnosti dost \u0161iroce (= t\u00e9m\u011b\u0159 u v\u0161ech klient\u016f) pou\u017e\u00edv\u00e1me jen jednoho oper\u00e1tora \u2014 pro Redis<\/a><\/noindex> (brzy zve\u0159ejn\u00edme \u010dl\u00e1nek i o n\u011bm)<\/i>.<\/p>\n

NS<\/b>: A pro MySQL tak\u00e9 nen\u00ed? V\u00edm, \u017ee Percona\u2026 proto\u017ee se te\u010f v\u011bnuj\u00ed jak MySQL, tak MongoDB a Postgres, mus\u00ed vyvinout n\u011bjakou univerz\u00e1ln\u00ed variantu: pro v\u0161echny datab\u00e1ze, pro v\u0161echny cloudov\u00e9 poskytovatele.<\/i><\/p>\n

DS<\/b>: Nestihli jsme se pod\u00edvat na oper\u00e1tory pro MySQL. To nen\u00ed v sou\u010dasnosti n\u00e1\u0161 hlavn\u00ed fokus. MySQL funguje norm\u00e1ln\u011b v standalone. Pro\u010d pot\u0159ebovat oper\u00e1tora, kdy\u017e m\u016f\u017ee\u0161 prost\u011b spustit datab\u00e1zi\u2026 M\u016f\u017ee\u0161 spustit Docker kontejner s PostgreSQL, nebo to ud\u011blat jednodu\u0161e.<\/p>\n

NS<\/b>: O tom byla taky ot\u00e1zka. Opravdu bez oper\u00e1tora?<\/i><\/p>\n

DS<\/b>: Ano, 100% m\u00e1me PostgreSQL spu\u0161t\u011bn\u00fd bez oper\u00e1tora. Zat\u00edm to tak je. Aktivn\u011b pou\u017e\u00edv\u00e1me oper\u00e1tora pro Prometheus a Redis. Pl\u00e1nujeme naj\u00edt oper\u00e1tora pro Elasticsearch \u2013 ten je nejv\u00edc \u201enal\u00e9hav\u00fd\u201c, proto\u017ee ho chceme v\u017edy roz\u0161i\u0159ovat v Kubernetes. Tak\u00e9 se sna\u017e\u00edme nastavit MongoDB v\u017edy v Kubernetes. Objevil se tady ur\u010dit\u00fd z\u00e1jem \u2013 zd\u00e1 se, \u017ee v t\u011bchto p\u0159\u00edpadech lze n\u011bco ud\u011blat. A ohledn\u011b Postgresu jsme se ani ned\u00edvali. Samoz\u0159ejm\u011b v\u00edme o r\u016fzn\u00fdch variant\u00e1ch, ale ve skute\u010dnosti m\u00e1me standalone.<\/p>\n

DB pro testov\u00e1n\u00ed v Kubernetes<\/h2>\n

\nNS<\/b>: Poj\u010fme se p\u0159esunout na t\u00e9ma testov\u00e1n\u00ed. Jak nasazovat zm\u011bny v datab\u00e1zi \u2013 z pohledu DevOps. Jsou tu mikroservisy, hodn\u011b datab\u00e1z\u00ed, po\u0159\u00e1d n\u011bkde n\u011bco m\u011bn\u00ed. Jak zajistit norm\u00e1ln\u00ed CI\/CD, aby z pohledu DB bylo v\u0161echno v po\u0159\u00e1dku. Jak\u00fd m\u00e1\u0161 p\u0159\u00edstup?<\/i><\/p>\n

DS<\/b>: Nem\u016f\u017ee existovat jedin\u00e9 odpov\u011bdi. Je tu n\u011bkolik parametr\u016f. Prvn\u00ed \u2013 to je velikost datab\u00e1ze, kterou chceme nasadit. S\u00e1m jsi zm\u00ednil, \u017ee spole\u010dnosti se r\u016fzn\u011b stav\u00ed k tomu, aby kopie produk\u010dn\u00ed datab\u00e1ze byla na dev a staging.<\/p>\n

NS<\/b>: A v kontextu GDPR, mysl\u00edm, \u017ee se k tomu stav\u00ed \u010d\u00edm d\u00e1l opatrn\u011bji\u2026 M\u016f\u017eu \u0159\u00edct, \u017ee v Evrop\u011b u\u017e za\u010dali s t\u00edm penalizovat.<\/i><\/p>\n

DS<\/b>: Ale \u010dasto je mo\u017en\u00e9 napsat software, kter\u00fd provede dump z produkce a obfuskuje ho. V\u00fdsledkem jsou produk\u010dn\u00ed data (snapshot, dump, bin\u00e1rn\u00ed kopie\u2026), ale anonymizovan\u00e1. M\u00edsto toho mohou b\u00fdt tak\u00e9 skripty pro generaci: mohou to b\u00fdt fixture nebo jednodu\u0161e skript, kter\u00fd generuje velkou datab\u00e1zi. Probl\u00e9m je ten, kolik \u010dasu zabere vytvo\u0159en\u00ed z\u00e1kladn\u00edho obrazu? A kolik \u010dasu na jeho nasazen\u00ed v po\u017eadovan\u00e9m prost\u0159ed\u00ed?<\/p>\n

Dosp\u011bli jsme k sch\u00e9matu: pokud m\u00e1 klient sadu fixture dat (minim\u00e1ln\u00ed verzi datab\u00e1ze), tak defaultn\u011b pou\u017e\u00edv\u00e1me je. Pokud jde o review prost\u0159ed\u00ed, kdy\u017e jsme vytvo\u0159ili branch, rozeb\u011bhl se n\u00e1m instance aplikace - tam nasazujeme malou datab\u00e1zi. Ale vy\u0161lo to dob\u0159e i tak. varianta<\/a><\/noindex>, kdy\u017e z produkce provedeme dump jednou denn\u011b (v noci) a na jeho z\u00e1klad\u011b sestav\u00edme Docker kontejner s PostgreSQL a MySQL s t\u011bmito nahran\u00fdmi daty. Pokud je t\u0159eba tento obraz 50kr\u00e1t nasadit, d\u00e1 se to ud\u011blat dost jednodu\u0161e a rychle.<\/p>\n

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

DS<\/b>: Data jsou ulo\u017eena p\u0159\u00edmo v Docker obraze. Tedy m\u00e1me hotov\u00fd obraz, dejme tomu 100 GB. D\u00edky vrstv\u00e1m v Dockeru m\u016f\u017eeme rychle nasazovat tento obraz pot\u0159ebn\u00fd po\u010detkr\u00e1t. Zp\u016fsob je primitivn\u00ed, ale funguje dob\u0159e.<\/p>\n

NS<\/b>: D\u00e1le, kdy\u017e testujete, m\u011bn\u00ed se to p\u0159\u00edmo uvnit\u0159 Dockeru, \u017ee? Copy-on-write uvnit\u0159 Dockeru \u2014 vyhod\u00edme a znovu za\u010dneme, v\u0161echno je v po\u0159\u00e1dku. Skv\u011bl\u00e9! A u\u017e to intenzivn\u011b pou\u017e\u00edv\u00e1te?<\/i><\/p>\n

DS<\/b>: U\u017e dlouho.<\/p>\n

NS<\/b>: Zaj\u00edm\u00e1me se o velmi podobn\u00e9 v\u011bci. Jen my nepou\u017e\u00edv\u00e1me Dockerovsk\u00fd copy-on-write, ale n\u011bco jin\u00e9ho.<\/i><\/p>\n

DS<\/b>: Nen\u00ed to generic. Ale Dockerovsk\u00fd funguje na v\u0161ude.<\/p>\n

NS<\/b>: V z\u00e1sad\u011b ano. Ale m\u00e1me tak\u00e9 moduly, je mo\u017en\u00e9 vytvo\u0159it r\u016fzn\u00e9 moduly a pracovat s r\u016fzn\u00fdmi souborov\u00fdmi syst\u00e9my. Tady je jedna v\u011bc. Na Postgres se na to d\u00edv\u00e1me jinak. Te\u010f jsem se pod\u00edval z pohledu Dockeru a vid\u011bl jsem, \u017ee v\u0161echno funguje. Ale pokud je datab\u00e1ze obrovsk\u00e1, nap\u0159\u00edklad 1 TB, tak u\u017e to zabere hodn\u011b \u010dasu: jak operace v noci, tak nap\u011bchovat to v\u0161e do Dockeru\u2026 A pokud by se do Dockeru nacpalo 5 TB\u2026 Nebo je to v po\u0159\u00e1dku?<\/i><\/p>\n

DS<\/b>: Jak\u00fd je rozd\u00edl: to jsou p\u0159ece blobov\u00e9 objekty, prost\u011b bity a bajty.<\/p>\n

NS<\/b>: Rozd\u00edl je v tom, \u017ee to d\u011bl\u00e1te p\u0159es dump a restore?<\/i><\/p>\n

DS<\/b>: V\u016fbec to nen\u00ed nutn\u00e9. Metody generov\u00e1n\u00ed tohoto obrazu mohou b\u00fdt r\u016fzn\u00e9.<\/p>\n

NS<\/b>: Pro n\u011bkter\u00e9 klienty jsme to ud\u011blali tak, \u017ee m\u00edsto pravideln\u00e9ho generov\u00e1n\u00ed z\u00e1kladn\u00edho obrazu jej neust\u00e1le udr\u017eujeme aktu\u00e1ln\u00ed. V podstat\u011b se jedn\u00e1 o repliku, ale data nepoch\u00e1zej\u00ed p\u0159\u00edmo z masteru, n\u00fdbr\u017e p\u0159es archiv. Binarni archiv, kam jsou WALy ka\u017ed\u00fd den zapisov\u00e1ny, se stejn\u00fdm zp\u016fsobem z\u00e1lohuje... Tyto WALy pak doraz\u00ed \u2014 s mal\u00fdm zpo\u017ed\u011bn\u00edm (doslova 1-2 sekundy) \u2014 k z\u00e1kladn\u00edmu obrazu. Z n\u011bho clon\u00edme jak\u00fdmkoliv zp\u016fsobem \u2014 nyn\u00ed m\u00e1me jako v\u00fdchoz\u00ed ZFS.<\/i><\/p>\n

DS<\/b>: Ale u ZFS jste omezeni jedn\u00edm uzlem.<\/p>\n

NS<\/b>: Ano. Ale ZFS m\u00e1 tak\u00e9 kouzeln\u00fd send<\/a><\/noindex>: s n\u00edm m\u016f\u017eete poslat snapshot a dokonce (to jsem je\u0161t\u011b moc netestoval, ale\u2026) lze pos\u00edlat delta mezi dv\u011bma PGDATA<\/code>. Ve skute\u010dnosti m\u00e1me je\u0161t\u011b jeden n\u00e1stroj, kter\u00fd jsme neprov\u011b\u0159ovali pro takov\u00e9 \u00fakoly. V PostgreSQL je pg_rewind<\/a><\/noindex>, funguj\u00edc\u00ed jako \u201einteligentn\u00ed\u201c rsync, kter\u00fd vynech\u00e1v\u00e1 mnoho z toho, co nen\u00ed pot\u0159eba sledovat, proto\u017ee se tam ur\u010dit\u011b nic nezm\u011bnilo. M\u016f\u017eeme prov\u00e9st rychlou synchronizaci mezi dv\u011bma servery a vr\u00e1tit se zp\u011bt stejn\u00fdm zp\u016fsobem.<\/i><\/p>\n

Sna\u017e\u00edme se tedy z t\u00e9to, v\u00edce DBA perspektivy, vytvo\u0159it n\u00e1stroj, kter\u00fd umo\u017e\u0148uje ud\u011blat to, o \u010dem jsi mluvil: m\u00e1me jednu datab\u00e1zi, ale chceme n\u011bco testovat 50kr\u00e1t, t\u00e9m\u011b\u0159 sou\u010dasn\u011b.<\/i><\/p>\n

DS<\/b>: 50kr\u00e1t znamen\u00e1, \u017ee pot\u0159ebujete objednat 50 Spot instanc\u00ed.<\/p>\n

NS<\/b>: Ne, v\u0161echno d\u011bl\u00e1me na jednom stroji.<\/i><\/p>\n

DS<\/b>: Jak ale nasad\u00edte 50kr\u00e1t, pokud je ta jedna datab\u00e1ze nap\u0159\u00edklad terabajtov\u00e1. Pravd\u011bpodobn\u011b pot\u0159ebuje zhruba 256 GB RAM?<\/p>\n

NS<\/b>: Ano, pam\u011bti je ob\u010das pot\u0159eba hodn\u011b \u2014 to je norm\u00e1ln\u00ed. Ale takov\u00fd p\u0159\u00edklad z praxe. Na produk\u010dn\u00edm stroji m\u00e1me 96 jader a 600 GB. P\u0159itom pro datab\u00e1zi pou\u017e\u00edv\u00e1me 32 jader (dokonce nyn\u00ed n\u011bkdy 16 jader) a pam\u011b\u0165 100-120 GB.<\/i><\/p>\n

DS<\/b>: A tam se vejde 50 kopi\u00ed?<\/p>\n

NS<\/b>: Tak\u017ee kopie je jedna, d\u00e1le operuje copy-on-write (ZFS)... Podrobn\u011bji to vysv\u011btl\u00edm.<\/i><\/p>\n

M\u00e1me nap\u0159\u00edklad datab\u00e1zi o velikosti 10 TB. Disk pro ni jsme ud\u011blali, ZFS ji je\u0161t\u011b zkomprimoval o 30-40%. Proto\u017ee ned\u011bl\u00e1me z\u00e1t\u011b\u017eov\u00e9 testov\u00e1n\u00ed, nen\u00ed pro n\u00e1s p\u0159esn\u00fd \u010das odezvy d\u016fle\u017eit\u00fd: m\u016f\u017ee to b\u00fdt dvakr\u00e1t pomalej\u0161\u00ed \u2014 to je v po\u0159\u00e1dku.<\/i><\/p>\n

Nab\u00edz\u00edme mo\u017enost program\u00e1tor\u016fm, QA, DBA atd. prov\u00e1d\u011bt testov\u00e1n\u00ed ve 1-2 vl\u00e1knech. Nap\u0159\u00edklad mohou spustit n\u011bjakou migraci. Ta nevy\u017eaduje najednou 10 jader \u2014 pot\u0159ebuje 1 backend Postgresu, 1 j\u00e1dro. Migrace se uvede do chodu \u2014 mo\u017en\u00e1, autovacuum<\/a><\/noindex> je\u0161t\u011b se spust\u00ed, potom se vyu\u017eije druh\u00e9 j\u00e1dro. M\u00e1me vyhrazeno 16-32 jader, tak\u017ee 10 lid\u00ed m\u016f\u017ee pracovat sou\u010dasn\u011b, \u017e\u00e1dn\u00e9 probl\u00e9my nejsou.<\/i><\/p>\n

Proto\u017ee fyzicky PGDATA<\/code> se ukazuje, \u017ee ve skute\u010dnosti podv\u00e1d\u00edme Postgres. Pointa je v tom, \u017ee nap\u0159\u00edklad spust\u00edme 10 Postgres\u016f sou\u010dasn\u011b. Jak\u00fd je obvykle probl\u00e9m? Instaluj\u00ed shared_buffers<\/a><\/noindex>, dejme tomu 25%. Odpov\u00edd\u00e1 to tedy 200 GB. V\u00edce ne\u017e t\u0159i z nich u\u017e nespust\u00edte, proto\u017ee pam\u011b\u0165 dojde.<\/i><\/p>\n

Ale v n\u011bjak\u00e9m okam\u017eiku jsme pochopili, \u017ee to nen\u00ed nutn\u00e9: nastavujeme shared_buffers na 2 GB. PostgreSQL m\u00e1 effective_cache_size<\/a><\/noindex>, a ve skute\u010dnosti ovliv\u0148uje pouze on pl\u00e1ny<\/a><\/noindex>. Ten nastavujeme na 0,5 TB. A ani nez\u00e1le\u017e\u00ed na tom, \u017ee ve skute\u010dnosti nejsou: stav\u00ed pl\u00e1ny, jako by byly.<\/i><\/p>\n

Kdy\u017e testujeme n\u011bjakou migraci, m\u016f\u017eeme shrom\u00e1\u017edit v\u0161echny pl\u00e1ny \u2014 uvid\u00edme, jak to prob\u011bhne na produkci. Sekundy tam budou jin\u00e9 (pomalej\u0161\u00ed), ale data, kter\u00e1 skute\u010dn\u011b \u010dteme, a samotn\u00e9 pl\u00e1ny (jak\u00e9 tam jsou JOINy atd.) vych\u00e1z\u00ed p\u0159esn\u011b takov\u00e9 jak na produkci. A sou\u010dasn\u011b lze spustit mnoho takov\u00fdch kontrol na jednom stroji.<\/i><\/p>\n

DS<\/b>: Nemysl\u00ed\u0161, \u017ee tu jsou n\u011bkter\u00e9 probl\u00e9my? Za prv\u00e9 \u2014 je to \u0159e\u0161en\u00ed, kter\u00e9 funguje pouze na PostgreSQL. Takov\u00fd p\u0159\u00edstup je velmi specifick\u00fd, nen\u00ed univerz\u00e1ln\u00ed. Za druh\u00e9 \u2014 Kubernetes (a v\u0161e, kam nyn\u00ed sm\u011b\u0159uj\u00ed cloudov\u00e9 technologie) p\u0159edpokl\u00e1d\u00e1 v\u00edce uzl\u016f, a tyto uzly jsou efem\u00e9rn\u00ed. A ve tv\u00e9m p\u0159\u00edpad\u011b se jedn\u00e1 o stateful, perzistentn\u00ed uzel. Tyto v\u011bci ve mn\u011b vzbuzuj\u00ed rozpory.<\/p>\n

NS<\/b>: Prvn\u00ed \u2014 souhlas\u00edm, to je \u010dist\u011b p\u0159\u00edb\u011bh Postgresu. Mysl\u00edm, \u017ee pokud m\u00e1me n\u011bjak\u00fd direct IO a buffer pool t\u00e9m\u011b\u0159 cel\u00e9 pam\u011bti, tento p\u0159\u00edstup nebude fungovat \u2014 pl\u00e1ny budou jin\u00e9. Ale zat\u00edm pracujeme pouze s Postgres a o ostatn\u00edch nep\u0159em\u00fd\u0161l\u00edme.<\/i><\/p>\n

Co se t\u00fd\u010de Kubernetes. V\u0161ude \u0159\u00edk\u00e1\u0161, \u017ee na\u0161e datab\u00e1ze je perzistentn\u00ed. Pokud instance spadne, hlavn\u00ed je zachovat disk. My m\u00e1me tak\u00e9 celou platformu v Kubernetes, a komponent s Postgres je odd\u011blen\u011b (i kdy\u017e tam jednou bude). Tak\u017ee to funguje takto: instance spadla, ale zachovali jsme jej\u00ed PV a jednodu\u0161e p\u0159ipojili k jin\u00e9 (nov\u00e9) instanci, jako by se nic nestalo.<\/i><\/p>\n

DS<\/b>: Z m\u00e9ho pohledu vytv\u00e1\u0159\u00edme pody v Kubernetes. K8s \u2014 elastick\u00fd: uzly se objedn\u00e1vaj\u00ed samy podle pot\u0159eby. \u00dakolem je jednodu\u0161e vytvo\u0159it pod a \u0159\u00edct, jak\u00e9 pot\u0159ebuje zdroje X, a d\u00e1le si s t\u00edm K8s porad\u00ed. Ale podpora \u00falo\u017ei\u0161\u0165 v Kubernetes je st\u00e1le nestabiln\u00ed: v 1.16<\/a><\/noindex>, v 1.17<\/a><\/noindex> (tato verze vy\u0161la p\u0159ed t\u00fddnem<\/i> ) tyto funkce se teprve st\u00e1vaj\u00ed betou.<\/p>\n

Za p\u016fl roku a\u017e rok se to stane v\u00edce m\u00e9n\u011b stabiln\u00edm, nebo to alespo\u0148 tak bude inzerov\u00e1no. Pak mo\u017enost snapshot\u016f a resize ji\u017e pln\u011b \u0159e\u0161\u00ed v\u00e1\u0161 probl\u00e9m. Proto\u017ee m\u00e1te datab\u00e1zi. Ano, m\u016f\u017ee b\u00fdt ne tak rychl\u00e1, ale rychlost z\u00e1vis\u00ed na tom, co je \"pod kapotou\", proto\u017ee n\u011bkter\u00e9 implementace dovedou kop\u00edrovat a copy-on-write na \u00farovni diskov\u00e9ho subsyst\u00e9mu.<\/p>\n

NS<\/b>: Je tak\u00e9 pot\u0159eba, aby v\u0161echny motory (Amazon, Google\u2026) stihly za\u010d\u00edt podporovat tuto verzi \u2014 to p\u0159ece tak\u00e9 n\u011bjak\u00fd \u010das trv\u00e1.<\/i><\/p>\n

DS<\/b>: Zat\u00edm je nepou\u017e\u00edv\u00e1me. Pou\u017e\u00edv\u00e1me sv\u00e9 vlastn\u00ed.<\/p>\n

M\u00edstn\u00ed v\u00fdvoj pod Kubernetes<\/h2>\n

\nNS<\/b>: Setkal jsi se n\u011bkdy s takovou pot\u0159ebou, kdy je pot\u0159eba na jednom stroji zprovoznit v\u0161echny pod’y a prov\u00e9st n\u011bjak\u00e9 mal\u00e9 testov\u00e1n\u00ed? Abychom rychle z\u00edskali proof of concept, pod\u00edvali se, \u017ee aplikace funguje v Kubernetes, ani\u017e bychom pro to museli vyhradit hromadu stroj\u016f. Je tu Minikube, \u017ee?<\/i><\/p>\n

DS<\/b>: Mysl\u00edm, \u017ee tento p\u0159\u00edpad \u2014 nasazen\u00ed na jednom uzlu \u2014 se t\u00fdk\u00e1 v\u00fdhradn\u011b m\u00edstn\u00edho v\u00fdvoje. Nebo n\u011bkter\u00e9 projevy takov\u00e9ho vzoru. Existuje Minikube<\/a><\/noindex>, existuje k3s<\/a><\/noindex>, (Kubernetes IN Docker) a<\/a><\/noindex>. Jdeme k tomu, \u017ee budeme pou\u017e\u00edvat Kubernetes ve Dockeru. Te\u010f jsme za\u010dali s n\u00edm pracovat na testy.<\/p>\n

NS<\/b>: D\u0159\u00edve jsem si myslel, \u017ee je to pokus zabalit v\u0161echny pod’y do jednoho Docker obrazu. Ale uk\u00e1zalo se, \u017ee je to \u00fapln\u011b o n\u011b\u010dem jin\u00e9m. I tak tam jsou jednotliv\u00e9 kontejnery, jednotliv\u00e9 pod’y \u2014 prost\u011b v Dockeru.<\/i><\/p>\n

DS<\/b>: Ano. A tam je ud\u011bl\u00e1na docela zaj\u00edmav\u00e1 simulace, ale smysl je takov\u00fd\u2026 M\u00e1me utilitu pro nasazen\u00ed \u2014 werf<\/a><\/noindex>. Chceme v n\u00ed ud\u011blat re\u017eim \u2014 tak posledn\u011b werf up<\/code>: \u201eZvedni mi lok\u00e1ln\u00ed Kubernetes\u201c. A pot\u00e9 spustit n\u011bjak\u00fd werf follow<\/code>. Takto bude moci v\u00fdvoj\u00e1\u0159 upravovat v IDE, zat\u00edmco v syst\u00e9mu pob\u011b\u017e\u00ed proces, kter\u00fd sleduje zm\u011bny a rebuild\u00ed obrazy, redeployuje je do lok\u00e1ln\u00edho K8s. Takto se chceme pokusit vy\u0159e\u0161it probl\u00e9m m\u00edstn\u00edho v\u00fdvoje.<\/p>\n

Sn\u00edmky a klonov\u00e1n\u00ed datab\u00e1z\u00ed v realit\u011b K8s<\/h2>\n

\nNS<\/b>: Pokud se vr\u00e1t\u00edme k copy-on-write. V\u0161iml jsem si, \u017ee i cloudov\u00e9 slu\u017eby maj\u00ed snapshoty. Funguj\u00ed r\u016fzn\u011b. Nap\u0159\u00edklad v GCP: m\u00e1\u0161 na v\u00fdchodn\u00edm pob\u0159e\u017e\u00ed USA v\u00edce ne\u017e terabajtov\u00fd instance. Periodicky d\u011bl\u00e1\u0161 snapshoty. Zvedne\u0161 kopii disku ze snapshotu na z\u00e1padn\u00edm pob\u0159e\u017e\u00ed \u2014 za p\u00e1r minut je v\u0161e hotovo, funguje to velmi rychle, jen je pot\u0159eba naplnit cache v pam\u011bti. Ale tyto klony (snapshoty) jsou pro rychl\u00e9 provisionov\u00e1n\u00ed nov\u00e9ho svazku. Je to skv\u011bl\u00e9, kdy\u017e pot\u0159ebuje\u0161 vytvo\u0159it spoustu instanc\u00ed.<\/i><\/p>\n

A pro testy se mi zd\u00e1, \u017ee snapshoty, o kter\u00fdch mluv\u00ed\u0161 v Dockeru, nebo j\u00e1 mluv\u00edm v ZFS, btrfs a dokonce LVM\u2026 \u2014 ty umo\u017e\u0148uj\u00ed na jednom stroji re\u00e1ln\u011b ned\u011blat nov\u00e1 data. V cloudu za n\u011b je\u0161t\u011b bude\u0161 ka\u017ed\u00fd \u010das platit a \u010dekat u\u017e ne sekundy, ale minuty (a v p\u0159\u00edpad\u011b lazy load’u<\/a><\/noindex>, mo\u017en\u00e1 i hodiny).<\/i><\/p>\n

M\u00edsto toho m\u016f\u017ee\u0161 za sekundu-dv\u011b z\u00edskat tato data, spustit test a vyhodit je. Tyto sn\u00edmky \u0159e\u0161\u00ed r\u016fzn\u00e9 \u00fakoly. V prvn\u00edm p\u0159\u00edpad\u011b \u2014 aby se roz\u0161\u00ed\u0159il a z\u00edskal nov\u00e9 repliky, a ve druh\u00e9m \u2014 pro testy.<\/i><\/p>\n

DS<\/b>: Nesouhlas\u00edm. Spr\u00e1vn\u011b prov\u00e9st klonov\u00e1n\u00ed objem\u016f je \u00fakol pro cloud. Nezkoumal jsem jejich realizaci, ale v\u00edm, jak to d\u011bl\u00e1me my na hardwaru. M\u00e1me Ceph, kde m\u016f\u017eeme jak\u00e9mukoli fyzick\u00e9mu objemu (RBD<\/a><\/noindex>) \u0159\u00edct clone<\/i> a z\u00edskat b\u011bhem des\u00edtek milisekund druh\u00fd objem se stejn\u00fdmi vlastnostmi, IOPS<\/a><\/noindex>‘ a tak d\u00e1le. Je t\u0159eba ch\u00e1pat, \u017ee uvnit\u0159 je chytr\u00fd copy-on-write. Pro\u010d by cloud nemohl d\u011blat to sam\u00e9? Jsem si jist\u00fd, \u017ee se to tak \u010di onak sna\u017e\u00ed ud\u011blat.<\/p>\n

NS<\/b>: Ale i tak jim to zabere sekundy, des\u00edtky sekund, ne\u017e zvednou instanci, p\u0159inesou tam Docker atd.<\/i><\/p>\n

DS<\/b>: Pro\u010d nutn\u011b zvedat celou instanci? My m\u00e1me instanci na 32 jader, na 16... a do n\u00ed se vejde ur\u010dit\u00e9 mno\u017estv\u00ed \u2014 nap\u0159\u00edklad \u010dty\u0159i. Kdy\u017e objedn\u00e1v\u00e1me p\u00e1tou, u\u017e se instanci zvedne, a pak se odstran\u00ed.<\/p>\n

NS<\/b>: Ano, zaj\u00edmav\u00e9, v Kubernetes to byl jin\u00fd p\u0159\u00edb\u011bh. Na\u0161e DB nen\u00ed v K8s a m\u00e1me jen jednu instanci. P\u0159esto na klonov\u00e1n\u00ed mnohaterrabytov\u00e9 datab\u00e1ze netrv\u00e1 v\u00edce ne\u017e dv\u011b sekundy.<\/i><\/p>\n

DS<\/b>: To je skv\u011bl\u00e9. Ale m\u016fj p\u016fvodn\u00ed z\u00e1m\u011br je, \u017ee to nen\u00ed generic-\u0159e\u0161en\u00ed. Ano, je to skv\u011bl\u00e9, ale hod\u00ed se pouze pro Postgres a pouze na jednom uzlu.<\/p>\n

NS<\/b>: Nehod\u00ed se to jen pro Postgres: to, co popisuji, bude fungovat takto pouze v n\u011bm. Ale pokud se nebudeme zab\u00fdvat pl\u00e1ny a pot\u0159ebujeme jen v\u0161echny \u00fadaje pro funk\u010dn\u00ed testov\u00e1n\u00ed, pak to bude vyhovovat jak\u00e9koli DBMS.<\/i><\/p>\n

DS<\/b>: P\u0159ed mnoha lety jsme n\u011bco podobn\u00e9ho d\u011blali na LVM snapshot. To je klasika. Tento p\u0159\u00edstup byl velmi aktivn\u011b pou\u017e\u00edv\u00e1n. Jen\u017ee stateful uzly \u2014 to je probl\u00e9m. Proto\u017ee je nesm\u00edte shazovat, mus\u00edte je m\u00edt neust\u00e1le na pam\u011bti\u2026<\/p>\n

NS<\/b>: Nevid\u00ed\u0161 zde n\u011bjakou mo\u017enost hybridu? Dejme tomu, stateful \u2014 to je n\u011bjak\u00fd pod, funguje na v\u00edce lidech (mnoho tester\u016f). M\u00e1me jeden objem, ale d\u00edky souborov\u00e9mu syst\u00e9mu jsou klony \u2014 m\u00edstn\u00ed. Pokud pod spadne, disk z\u016fstane \u2014 pod se zvedne, informace o v\u0161ech clonech se na\u010dtou, v\u0161echno se vr\u00e1t\u00ed zp\u011bt a \u0159ekne: \u201eTady jsou va\u0161e klony spu\u0161t\u011bny na t\u011bchto portech, pracujte s nimi d\u00e1l.\u201c<\/i><\/p>\n

DS<\/b>: Technicky to znamen\u00e1, \u017ee v r\u00e1mci Kubernetes je to jeden pod, uvnit\u0159 kter\u00e9ho spou\u0161t\u00edme mnoho Postgres’\u016f.<\/p>\n

NS<\/b>: Ano. M\u00e1 to limit: dejme tomu, sou\u010dasn\u011b s n\u00edm pracuje maxim\u00e1ln\u011b 10 lid\u00ed. Pokud pot\u0159ebujeme 20 \u2014 spust\u00edme druh\u00fd takov\u00fd pod. \u00dapln\u011b re\u00e1ln\u011b ho zklonujeme a dostaneme druh\u00fd kompletn\u00ed objem, na n\u011bm budou stejn\u00e9 10 \u201etenk\u00fdch\u201c klon\u016f. Nevid\u00ed\u0161 takovou mo\u017enost?<\/i><\/p>\n

DS<\/b>: Je t\u0159eba p\u0159idat sem ot\u00e1zky zabezpe\u010den\u00ed. Tato varianta organizace p\u0159edpokl\u00e1d\u00e1, \u017ee tento pod m\u00e1 vysok\u00e1 opr\u00e1vn\u011bn\u00ed (capabilities), proto\u017ee m\u016f\u017ee prov\u00e1d\u011bt nestandardn\u00ed operace se souborov\u00fdm syst\u00e9mem\u2026 Ale znovu opakuji: domn\u00edv\u00e1m se, \u017ee v kr\u00e1tkodob\u00e9m horizontu Kubernetes oprav\u00ed storage, v oblac\u00edch oprav\u00ed celou historii s objemy \u2014 v\u0161e bude \u00abjednodu\u0161e fungovat\u00bb. Bude resize, klonov\u00e1n\u00ed\u2026 Je objem \u2014 \u0159\u00edk\u00e1me: \u00abVytvo\u0159 nov\u00fd na z\u00e1klad\u011b toho\u00bb, \u2014 a za p\u016fl druh\u00e9 sekundy dostaneme, co pot\u0159ebujeme.<\/p>\n

NS<\/b>: Nev\u00edm, jestli v\u011b\u0159\u00edm v sekundu a p\u016fl pro mnoh\u00e1 terabajty. Na Ceph to d\u011bl\u00e1\u0161 s\u00e1m, a ty mluv\u00ed\u0161 o cloudech. Jdi do cloudu, na EC2 ud\u011blej klon objemu EBS mnoha terabajt\u016f a pod\u00edvej se, jak\u00e1 bude v\u00fdkonnost. To nezabere n\u011bkolik sekund. Velmi m\u011b zaj\u00edm\u00e1, kdy k takov\u00e9mu v\u00fdkonu dosp\u011bj\u00ed. Rozum\u00edm, o \u010dem mluv\u00ed\u0161, ale dovol\u00edm si nesouhlasit.<\/i><\/p>\n

DS<\/b>: Dob\u0159e, ale \u0159\u00edkal jsem, \u017ee ve st\u0159edn\u011bdob\u00e9m horizontu, ne kr\u00e1tkodob\u00e9m. V pr\u016fb\u011bhu n\u011bkolika let.<\/p>\n

O operatoru pro PostgreSQL od Zalando<\/h2>\n

\nVe st\u0159edn\u00ed \u010d\u00e1sti t\u00e9to sch\u016fzky se k n\u00ed p\u0159ipojil tak\u00e9 Alexey Klyukin, b\u00fdval\u00fd v\u00fdvoj\u00e1\u0159 z firmy Zalando, kter\u00fd pov\u011bd\u011bl o historii operatora PostgreSQL:<\/p>\n

Je skv\u011bl\u00e9, \u017ee se v\u016fbec toto t\u00e9ma dotklo: a Postgres, a Kubernetes. Kdy\u017e jsme za\u010d\u00ednali tuto v\u011bc d\u011blat v Zalando v roce 2017, bylo to takov\u00e9 t\u00e9ma, kter\u00e9mu cht\u011bl ka\u017ed\u00fd v\u011bnovat, ale nikdo to ned\u011blal. V\u0161ichni u\u017e m\u011bli Kubernetes, ale kdy\u017e se ptali, co s datab\u00e1zemi, tak i takov\u00ed lid\u00e9 jako Kelsey Hightower<\/a><\/noindex>, kte\u0159\u00ed hl\u00e1sali K8s, \u0159\u00edkali zhruba toto:<\/p>\n

\u201eJd\u011bte do managed slu\u017eeb a pou\u017e\u00edvejte je, nespou\u0161t\u011bjte DB v Kubernetes. Jinak v\u00e1\u0161 K8s rozhodne, nap\u0159\u00edklad, prov\u00e9st upgrade, vypne v\u0161echny uzly a va\u0161e data polet\u00ed daleko, daleko.\u201c<\/i><\/p>\n

Rozhodli jsme se ud\u011blat operatora, kter\u00fd bude, navzdory t\u00e9to rad\u011b, spou\u0161t\u011bt DB Postgres v Kubernetes. A m\u011bli jsme dobr\u00fd z\u00e1klad \u2014 Patroni<\/a><\/noindex>. To je automatick\u00fd failover pro PostgreSQL, proveden\u00fd spr\u00e1vn\u011b, t.j. vyu\u017e\u00edvaj\u00edc\u00ed etcd, consul nebo ZooKeeper jako \u00falo\u017ei\u0161t\u011b informac\u00ed o clusteru. Takov\u00e9ho \u00falo\u017ei\u0161t\u011b, kter\u00e9 bude vyd\u00e1vat v\u0161em, kte\u0159\u00ed se ptaj\u00ed, nap\u0159\u00edklad, kdo je nyn\u00ed l\u00edder, stejnou informaci \u2014 a\u010dkoliv m\u00e1me v\u0161e rozd\u011blen\u00e9 \u2014 aby nedo\u0161lo k split brainu. Nav\u00edc, m\u011bli jsme Docker obraz<\/a><\/noindex> pro n\u011bj.<\/p>\n

Vlastn\u011b pot\u0159eba auto failoveru se spole\u010dnosti objevila po migraci z intern\u00edho \u017eelezn\u00e9ho datacentra do cloudu. Cloud byl zalo\u017een na vlastn\u00edm \u0159e\u0161en\u00ed PaaS (Platform-as-a-Service). Bylo to Open Source, ale abychom ho zprovoznili, museli jsme se hodn\u011b sna\u017eit. Jmenovalo se STUPS<\/a><\/noindex>.<\/p>\n

P\u016fvodn\u011b \u017e\u00e1dn\u00fd Kubernetes nebyl. P\u0159esn\u011bji \u0159e\u010deno, kdy\u017e se zav\u00e1d\u011blo vlastn\u00ed \u0159e\u0161en\u00ed, K8s u\u017e existoval, ale byl tak syrov\u00fd, \u017ee se do produkce nehodil. Bylo to, mysl\u00edm, v roce 2015 nebo 2016. Do roku 2017 se Kubernetes stal v\u00edce \u010di m\u00e9n\u011b zral\u00fdm \u2014 objevila se pot\u0159eba migrace tam.<\/p>\n

A u\u017e jsme m\u011bli Docker kontejner. M\u011bli jsme PaaS, kter\u00e1 pou\u017e\u00edvala Docker. Pro\u010d to nezkusit s K8s? Pro\u010d nenapsat sv\u00e9ho oper\u00e1tora? Murat Kabilov, kter\u00fd k n\u00e1m p\u0159i\u0161el z Avita, za\u010dal s t\u00edmto projektem na vlastn\u00ed iniciativu \u2014 'pohr\u00e1t si' \u2014 a projekt 'vzlet\u011bl'.<\/p>\n

Ale vlastn\u011b jsem cht\u011bl mluvit o AWS. Pro\u010d tam byl historicky k\u00f3d spojen\u00fd s AWS\u2026<\/p>\n

Kdy\u017e spou\u0161t\u00edte cokoli v Kubernetes, mus\u00edte ch\u00e1pat, \u017ee K8s je tak trochu work in progress. St\u00e1le se vyv\u00edj\u00ed, zlep\u0161uje a ob\u010das se i rozbije. Je t\u0159eba pe\u010dliv\u011b sledovat v\u0161echny zm\u011bny v Kubernetes, b\u00fdt p\u0159ipraven, v p\u0159\u00edpad\u011b pot\u0159eby se do toho pono\u0159it a zjistit, jak to funguje do detailu \u2014 mo\u017en\u00e1 v\u00edce, ne\u017e byste cht\u011bli. To plat\u00ed vlastn\u011b pro jakoukoli platformu, na kter\u00e9 spou\u0161t\u00edte sv\u00e9 DB\u2026<\/p>\n

Tak\u017ee, kdy\u017e jsme d\u011blali oper\u00e1tora, m\u011bli jsme Postgres, kter\u00fd pracoval s extern\u00edm svazkem (v tomto p\u0159\u00edpad\u011b EBS, proto\u017ee jsme pracovali v AWS). Datab\u00e1ze rostla, v ur\u010dit\u00e9m okam\u017eiku bylo pot\u0159eba prov\u00e9st resize: nap\u0159\u00edklad p\u016fvodn\u00ed velikost EBS byla 100 TB, datab\u00e1ze se k tomu dostala, te\u010f chceme ud\u011blat EBS na 200 TB. Jak? M\u016f\u017eete ud\u011blat dump\/restore na nov\u00fd instanci, ale to je \u010dasov\u011b n\u00e1ro\u010dn\u00e9 a zpo\u017ed\u011bn\u00e9.<\/p>\n

Proto jsme cht\u011bli takov\u00fd resize, kter\u00fd zv\u00fd\u0161\u00ed odd\u00edl EBS a pak \u0159ekne souborov\u00e9mu syst\u00e9mu, aby vyu\u017eil nov\u00e9 m\u00edsto. A to jsme ud\u011blali, ale tehdy Kubernetes nem\u011bl \u017e\u00e1dn\u00e9 API pro operaci resize. Proto\u017ee jsme pracovali na AWS, napsali jsme k\u00f3d pro jeho API.<\/p>\n

Nikdo nebr\u00e1n\u00ed ud\u011blat tot\u00e9\u017e pro jin\u00e9 platformy. V oper\u00e1toru nen\u00ed \u017e\u00e1dn\u00e9 z\u00e1vislost, \u017ee by mohl b\u011b\u017eet pouze na AWS, a na v\u0161em ostatn\u00edm by nefungoval. Celkov\u011b je to open source projekt: pokud n\u011bkdo chce urychlit pou\u017eit\u00ed nov\u00e9ho API \u2014 v\u00edtejte. GitHub<\/a><\/noindex>, pull-requests \u2013 t\u00fdm Zalando se sna\u017e\u00ed na n\u011b reagovat pom\u011brn\u011b rychle a propagovat oper\u00e1tora. Jak v\u00edm, projekt se pod\u00edlel<\/a><\/noindex> na Google Summer of Code a dal\u0161\u00edch podobn\u00fdch iniciativ\u00e1ch. Zalando na n\u011bm pracuje velmi aktivn\u011b.\n<\/p><\/blockquote>\n

<\/p>\n

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

\nPokud v\u00e1s zaj\u00edm\u00e1 t\u00e9ma PostgreSQL a Kubernetes, v\u011bnujte pros\u00edm pozornost tomu, \u017ee minul\u00fd t\u00fdden prob\u011bhl dal\u0161\u00ed Postgres-\u00fater\u00fd, kde s Nikolajem diskutoval Alexander Kukushkin ze Zalando<\/b>. Video z n\u011bj je k dispozici zde<\/a><\/noindex>.<\/p>\n

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

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