{"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\/lv\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres otrdiena Nr. 5: \"PostgreSQL un Kubernetes. CI\/CD. Automatiz\u0101cija test\u0113\u0161an\u0101\"","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres
\n
\nPag\u0101ju\u0161\u0101 gada beig\u0101s notika k\u0101rt\u0113jais tie\u0161ais p\u0101rraides Krievijas PostgreSQL kopienai #RuPostgres<\/a><\/noindex>, kur\u0101s t\u0101s l\u012bdzautore Nikolajs Samohvalovs sarun\u0101j\u0101s ar tehnisko direktoru \"Flanta\" Dimitriju Stolj\u0101rovu par \u0161o DBMS kontekst\u0101 ar Kubernetes.<\/p>\n

M\u0113s public\u0113jam \u0161\u012bs diskusijas galven\u0101s da\u013cas stenogrammu, bet YouTube kan\u0101l\u0101 kopiena<\/a><\/noindex> public\u0113ta pilna videoieraksts:<\/a><\/noindex><\/p>\n

\r\n \"Atska\u0146ot\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Datu b\u0101zes un Kubernetes<\/h2>\n

\nNS<\/b>: \u0160odien m\u0113s nerun\u0101sim par VACUUM un CHECKPOINT. V\u0113lamies run\u0101t par Kubernetes. Zinu, ka tev jau ir daudz gadu pieredzes. Esmu skat\u012bjies tavus video un da\u017eus pat atkal p\u0101rskat\u012bjis... Apskat\u012bsim situ\u0101ciju: k\u0101p\u0113c visp\u0101r Postgres vai MySQL K8s?<\/i><\/p>\n

DS<\/b>: Uz \u0161o jaut\u0101jumu nav viennoz\u012bm\u012bgas atbildes un nevar b\u016bt. Bet visp\u0101r \u2013 t\u0101 ir vienk\u0101r\u0161\u012bba un \u0113rt\u012bba... potenci\u0101li. Ikvienam ta\u010du gribas managed pakalpojumus.<\/p>\n

NS<\/b>: Lai k\u0101 RDS<\/a><\/noindex>, tikai pie sevis?<\/i><\/p>\n

DS<\/b>: J\u0101: lai k\u0101 RDS, tikai jebkur.<\/p>\n

NS<\/b>: \"Jebkur\" \u2014 tas ir labs nov\u0113rojums. Liel\u0101s komp\u0101nij\u0101s viss ir izvietots da\u017e\u0101d\u0101s viet\u0101s. Un k\u0101p\u0113c tad, ja t\u0101 ir liela komp\u0101nija, neizmantot gatavu risin\u0101jumu? Piem\u0113ram, Nutanix ir savi izstr\u0101d\u0101jumi, cit\u0101m komp\u0101nij\u0101m (VMware\u2026) ir tas pats \"RDS, tikai pie sevis\".<\/i><\/p>\n

DS<\/b>: Bet m\u0113s run\u0101jam par atsevi\u0161\u0137u ievie\u0161anu, kas darbosies tikai noteiktos apst\u0101k\u013cos. Bet ja run\u0101jam par Kubernetes, tad \u0161eit ir milz\u012bga infrastrukt\u016bras daudzveid\u012bba (kas var b\u016bt K8s). Paties\u012bb\u0101 t\u0101 ir standarts API uz m\u0101ko\u0146a...<\/p>\n

NS<\/b>: V\u0113l ar\u012b bez maksas!<\/i><\/p>\n

DS<\/b>: Tas nav tik svar\u012bgi. Bezmaksas ir svar\u012bgi ne \u013coti lielai tirgus da\u013cai. Svar\u012bg\u0101ks ir cits jaut\u0101jums... Tu, iesp\u0113jams, atceries zi\u0146ojumu \"Datu b\u0101zes un Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

NS<\/b>: J\u0101.<\/i><\/p>\n

DS<\/b>: Sapratu, ka to uztv\u0113ra \u013coti pretrun\u012bgi. Da\u013ca cilv\u0113ku dom\u0101ja, ka saku: \u201eCilv\u0113ki, braucam ar vis\u0101m DB uz Kubernetes!\u201d, \u2014 bet citi nol\u0113ma, ka t\u0101 ir briesm\u012bga rite\u0146u izgudro\u0161ana. Bet es v\u0113l\u0113jos run\u0101t par ko citu: \u201eSkatieties, kas notiek, k\u0101das ir probl\u0113mas un k\u0101 t\u0101s var risin\u0101t. Tagad braukt ar datub\u0101z\u0113m uz Kubernetes? Produkcij\u0101? Nu, tikai ja jums pat\u012bk... nodarboties ar noteikt\u0101m liet\u0101m. Bet devam \u2014 varu teikt, ka iesaku. Devam ir \u013coti svar\u012bga vides izveido\u0161anas\/dz\u0113\u0161anas dinamikas esam\u012bba.<\/p>\n

NS: Ar dev tu dom\u0101 visus apst\u0101k\u013cus, kas nav produkcij\u0101? Staging, QA...<\/i><\/p>\n

DS<\/b>: Ja, run\u0101jot par perf-stendiem, dro\u0161i vien, ka n\u0113, jo tur pras\u012bbas ir specifiskas. Ja run\u0101jam par \u012bpa\u0161iem gad\u012bjumiem, kur staging nepiecie\u0161ama \u013coti liela DB, tad ar\u012b dro\u0161i vien, ka n\u0113\u2026 Ja tas ir statisks vid\u0113, ilgsto\u0161s, tad k\u0101da ir ieguvums, ka datu b\u0101ze atrodas K8s?<\/p>\n

NS<\/b>: Necita. Bet kur m\u0113s redzam statiskus vid\u0113? Statisk\u0101 vide ir novecojusi jau r\u012bt.<\/i><\/p>\n

DS<\/b>: Staging var b\u016bt statisks. Mums ir klienti\u2026<\/p>\n

NS<\/b>: J\u0101, man ar\u012b ir. Liela probl\u0113ma, ja tev ir datu b\u0101ze uz 10 TB, bet staging \u2014 200 GB\u2026<\/i><\/p>\n

DS<\/b>: Man ir \u013coti for\u0161s gad\u012bjums! Staging ir produkcijas datub\u0101ze, kur\u0101s notiek izmai\u0146as. Un ir paredz\u0113ta poga: \u201eizlaist produkcij\u0101\u201d. \u0160\u012bs izmai\u0146as \u2014 deltas \u2014 tiek pievienotas (\u0161\u0137iet, vienk\u0101r\u0161i sinhroniz\u0113jot pa API) produkcij\u0101. Tas ir \u013coti eksotisks variants.<\/p>\n

NS<\/b>: Esmu redz\u0113jis start-up uz\u0146\u0113mumus ielej\u0101, kuri s\u0113\u017e RDS vai pat Heroku v\u0113l \u2014 t\u0101s ir 2-3 gadu vecas st\u0101sti, \u2014 un vi\u0146i lejupiel\u0101d\u0113 datu b\u0101zes dumpu sav\u0101 portat\u012bvaj\u0101 dator\u0101. Jo datub\u0101ze pagaid\u0101m ir tikai 80 Gb, un portat\u012bvaj\u0101 datori ir vieta. P\u0113c tam vi\u0146i katram ieg\u0101d\u0101jas diskus, lai var\u0113tu tur\u0113t 3 datub\u0101zes un att\u012bst\u012bt da\u017e\u0101dus projektus. T\u0101 ar\u012b notiek. T\u0101pat redz\u0113ju, ka nebaid\u0101s kop\u0113t produkciju uz staging \u2014 tas \u013coti atkar\u012bgs no uz\u0146\u0113muma. Bet ar\u012b redz\u0113ju, ka \u013coti baid\u0101s, un bie\u017ei vien tr\u016bkst laika un cilv\u0113ku. Bet pirms m\u0113s p\u0101riesim pie \u0161\u012bs t\u0113mas, grib\u0113tu dzird\u0113t par Kubernetes. Es pareizi saprotu, ka produkcij\u0101 \u0161obr\u012bd nevienam nav?<\/i><\/p>\n

DS<\/b>: Mums produkcij\u0101 ir nelielas datub\u0101zes. Runa ir par desmitiem gigabaitu un nekritiskaj\u0101m pakalpojumiem, kur\u0101m nebija j\u0113gas veidot replikas (un ar\u012b nav t\u0101das vajadz\u012bbas). Un pie nosac\u012bjuma, ka Kubernetes ir norm\u0101la kr\u0101tuve. \u0160\u012b datub\u0101ze str\u0101d\u0101ja virtu\u0101laj\u0101 ma\u0161\u012bn\u0101 \u2014 nosac\u012bti VMware, virskr\u0101tuves. M\u0113s to ievietoj\u0101m PV<\/a><\/noindex> un tagad varam to p\u0101rvietot no ma\u0161\u012bnas uz ma\u0161\u012bnu.<\/p>\n

NS<\/b>: Datu b\u0101zes \u0161\u0101da izm\u0113ra, l\u012bdz 100 GB, uz labiem diskiem un lab\u0101 t\u012bkl\u0101 var izplat\u012bt da\u017eu min\u016b\u0161u laik\u0101, vai ne? \u0100trums 1 GB sekund\u0113 \u2014 tas jau nav eksotisks.<\/i><\/p>\n

DS<\/b>: J\u0101, line\u0101ra oper\u0101cija tas nav probl\u0113ma.<\/p>\n

NS<\/b>: Ok, par prod m\u0113s tikai j\u0101m\u0101ca. Bet ja apl\u016bkojam Kubernetes ne-prod vid\u0113m \u2014 k\u0101 r\u012bkoties? Es redzu, ka Zalando izstr\u0101d\u0101 operatoru<\/a><\/noindex>, Crunchy veido<\/a><\/noindex>, ir v\u0113l k\u0101di varianti. Un ir OnGres<\/a><\/noindex> \u2014 tas ir m\u016bsu labs draugs Alvaro no Sp\u0101nijas: vi\u0146i praktiski neizstr\u0101d\u0101 tikai operatoru<\/a><\/noindex>, bet visu distrib\u016bciju (StackGres<\/a><\/noindex>), kur citam Postgres v\u0113l ir paredz\u0113ts ievietot ar\u012b dubl\u0113jumus, proksi Envoy...<\/i><\/p>\n

DS<\/b>: Envoy k\u0101d\u0113\u013c? Postgres datu pl\u016bsmas sadal\u012b\u0161anai?<\/p>\n

NS<\/b>: J\u0101. T\u0101tad vi\u0146i to redz t\u0101: ja \u0146em Linux izplat\u012bjumu un kodolu, tad parasts PostgreSQL ir kodols, bet vi\u0146i v\u0113las izveidot izplat\u012bjumu, kas b\u016bs draudz\u012bgs m\u0101ko\u0146iem un darbosies Kubernetes. Vi\u0146i savieno komponentus (dubl\u0113jumus utt.) un piel\u0101go, lai tie labi darbotos.<\/i><\/p>\n

DS<\/b>: \u013boti for\u0161i! Princip\u0101 tas ir programmat\u016bra, lai izveidotu savu p\u0101rvald\u012bto Postgres.<\/p>\n

NS<\/b>: Linux izplat\u012bjumiem ir m\u016b\u017e\u012bgas probl\u0113mas: k\u0101 izstr\u0101d\u0101t draiverus, lai viss ekip\u0113jums tiktu atbalst\u012bts. Un vi\u0146iem ir ideja, ka tie darbosies Kubernetes. Es zinu, ka operator\u0101 Zalando nesen redz\u0113j\u0101m saikni ar AWS, un tas jau nav labi. Nedr\u012bkst ta\u010du b\u016bt atkar\u012bbai no konkr\u0113tas infrastrukt\u016bras \u2014 k\u0101da tad ir j\u0113ga?<\/i><\/p>\n

DS<\/b>: Nezinu, k\u0101d\u0101 situ\u0101cij\u0101 tie\u0161i Zalando saist\u012bj\u0101s, bet Kubernetes \u0161obr\u012bd kr\u0101tuve ir izstr\u0101d\u0101ta t\u0101, ka visp\u0101r\u012bgi nevar izveidot diskdubl\u0113jumu. Nesen standart\u0101 \u2014 jaun\u0101kaj\u0101 versij\u0101 specifik\u0101cij\u0101 CSI<\/a><\/noindex> \u2014 ir izveidota iesp\u0113ja veikt momentuz\u0146\u0113mumus, bet kur tas ir \u012bstenots? God\u012bgi sakot, joproj\u0101m viss ir tik nenobriedis\u2026 M\u0113s izm\u0113\u0123in\u0101m CSI virs AWS, GCE, Azure, vSphere, bet tikl\u012bdz s\u0101kat lietot, ir redzams, ka tas v\u0113l nav gatavs.<\/p>\n

NS<\/b>: T\u0101p\u0113c da\u017ereiz n\u0101kas saist\u012bties ar infrastrukt\u016bru. Dom\u0101ju, tas v\u0113l ir agr\u012bn\u0101 stadij\u0101 \u2014 izaugsmes probl\u0113mas. Jaut\u0101jums: ko tu ieteiktu ies\u0101c\u0113jiem, kuri v\u0113las izm\u0113\u0123in\u0101t PgSQL K8s? K\u0101du operatoru, varb\u016bt?<\/i><\/p>\n

DS<\/b>: Probl\u0113ma ir t\u0101da, ka Postgres mums ir tikai 3%. Mums ir v\u0113l \u013coti liels saraksts ar da\u017e\u0101du programmat\u016bru Kubernetes, nemin\u0113\u0161u visu. Piem\u0113ram, Elasticsearch. Operatoru ir daudz: da\u017ei att\u012bst\u0101s akt\u012bvi, citi - ne. M\u0113s esam izstr\u0101d\u0101ju\u0161i pras\u012bbas, k\u0101d\u0101m j\u0101b\u016bt operatoram, lai m\u0113s to uztvertu nopietni. Operatoram, kas dom\u0101ts tie\u0161i Kubernetes \u2014 ne Redis<\/a><\/noindex> (dr\u012bz public\u0113sim rakstu ar\u012b par to)<\/i>.<\/p>\n

NS<\/b>: Bet MySQL ar\u012b nav? Es zinu, ka Percona\u2026 t\u0101 k\u0101 vi\u0146i tagad nodarbojas gan ar MySQL, gan MongoDB, gan Postgres, vi\u0146iem vajadz\u0113tu izstr\u0101d\u0101t k\u0101du univers\u0101lu risin\u0101jumu: vis\u0101m datu b\u0101z\u0113m, visiem m\u0101ko\u0146u pakalpojumu sniedz\u0113jiem.<\/i><\/p>\n

DS<\/b>: M\u0113s nesagaid\u012bj\u0101m iesp\u0113ju apskat\u012bt MySQL operatorus. Tas \u0161obr\u012bd nav m\u016bsu galven\u0101 uzman\u012bba. MySQL norm\u0101li str\u0101d\u0101 patst\u0101v\u012bgi. K\u0101p\u0113c operatoram, ja var vienk\u0101r\u0161i palaist datub\u0101zi... Var palaist Docker konteineru ar Postgres, vai ar\u012b to izdar\u012bt vienk\u0101r\u0161i.<\/p>\n

NS<\/b>: Par to ar\u012b bija jaut\u0101jums. Visp\u0101r bez operatora?<\/i><\/p>\n

DS<\/b>: J\u0101, 100% gad\u012bjumu m\u016bsu PostgreSQL darbojas bez operatora. Pag \u043f\u043e\u043a\u0430 t\u0101 ir. M\u0113s akt\u012bvi izmantojam operatoru Prometheus, Redis. Mums ir pl\u0101nos atrast operatoru Elasticsearch \u2014 tas ir visvair\u0101k<\/p>\n

Datub\u0101ze test\u0113\u0161anai Kubernetes<\/h2>\n

\nNS<\/b>: P\u0101riesim pie test\u0113\u0161anas t\u0113mas. K\u0101 veikt izmai\u0146u izplat\u012b\u0161anu datub\u0101z\u0113 \u2014 no DevOps perspekt\u012bvas. Ir mikrosist\u0113mas, daudz datub\u0101zu, visu laiku kaut kas main\u0101s. K\u0101 nodro\u0161in\u0101t norm\u0101lu CI\/CD, lai datub\u0101zes puse b\u016btu k\u0101rt\u012bb\u0101? K\u0101ds ir tavs pieejas veids?<\/i><\/p>\n

DS<\/b>: Nav viena pareiz\u0101 atbildes. Ir vair\u0101ki parametri. Pirmais \u2014 tas ir datub\u0101zes apjoms, kuru m\u0113s v\u0113lamies izplat\u012bt. Tu pats piemin\u0113ji, ka uz\u0146\u0113mumos at\u0161\u0137ir\u012bgi attieksme pret to, lai prod-datub\u0101ze b\u016btu dev un stage.<\/p>\n

NS<\/b>: Bet GDPR apst\u0101k\u013cos, es dom\u0101ju, vi\u0146i attiecina aizvien liel\u0101ku uzman\u012bbu... Varu teikt, ka Eirop\u0101 jau ir s\u0101ku\u0161i piem\u0113rot sodus.<\/i><\/p>\n

DS<\/b>: Bet bie\u017ei vien var uzrakst\u012bt programmat\u016bru, kas veic datu dubl\u0113\u0161anu no ra\u017eo\u0161anas un to obfusk\u0113. Rezult\u0101t\u0101 ieg\u016bstam produkcijas datus (snap\u0161ots, dubl\u0113jums, bin\u0101r\u0101 kopija...), ta\u010du tie ir anonimiz\u0113ti. T\u0101 viet\u0101 var b\u016bt ar\u012b \u0123ener\u0113\u0161anas skripti: tie var b\u016bt fiksat\u016bras vai vienk\u0101r\u0161i skripts, kas \u0123ener\u0113 lielu datub\u0101zi. Probl\u0113ma ir t\u0101da: cik ilgs laiks nepiecie\u0161ams, lai izveidotu pamata att\u0113lu? Un cik ilgs laiks nepiecie\u0161ams, lai to izvietotu nepiecie\u0161amaj\u0101 vid\u0113?<\/p>\n

M\u0113s non\u0101c\u0101m pie sh\u0113mas: ja klientam ir fikst\u016bru datu kopums (minim\u0101l\u0101 versija datub\u0101zes), tad p\u0113c noklus\u0113juma izmantojam tos. Ja run\u0101jam par review-vid\u0113m, kad m\u0113s esam izveidoju\u0161i zaru, mums ir uzst\u0101d\u012bts lietojumprogrammas instances \u2014 m\u0113s tur izplat\u0101m nelielu datub\u0101zi. Bet viss ir izdevies labi. variantu<\/a><\/noindex>, kad no ra\u017eo\u0161anas m\u0113s reizi dien\u0101 (nakt\u012b) veicam dubl\u0113jumu un izveidojam Docker konteineru ar PostgreSQL un MySQL ar \u0161iem iel\u0101d\u0113tajiem datiem. Ja no \u0161\u012b att\u0113la nepiecie\u0161ams 50 reizes izvietot datub\u0101zi, to izdar\u012bt ir diezgan vienk\u0101r\u0161i un \u0101tri.<\/p>\n

NS<\/b>: Ar vienk\u0101r\u0161u kop\u0113\u0161anu?<\/i><\/p>\n

DS<\/b>: Dati tiek glab\u0101ti tie\u0161i Docker att\u0113l\u0101. T.i., mums ir gatavs att\u0113ls, lai ar\u012b 100 GB liels. Pateicoties Docker k\u0101rt\u0101m, m\u0113s varam \u0101tri izveidot \u0161o att\u0113lu vajadz\u012bgaj\u0101 daudzum\u0101. Metode ir primit\u012bva, bet darbojas diezgan labi.<\/p>\n

NS<\/b>: T\u0101l\u0101k, kad test\u0113jat, tas tie\u0161i iek\u0161\u0101 Docker main\u0101s, vai ne? Copy-on-write iek\u0161\u0101 Docker - izmest un s\u0101kt no jauna, viss ir k\u0101rt\u012bb\u0101. For\u0161i! Un j\u016bs to jau akt\u012bvi lietojat?<\/i><\/p>\n

DS<\/b>: J\u0101, jau k\u0101du laiku.<\/p>\n

NS<\/b>: M\u0113s nodarbojamies ar l\u012bdz\u012bg\u0101m liet\u0101m. Tikai m\u0113s neizmantojam Docker\u0101 copy-on-write, bet kaut ko citu.<\/i><\/p>\n

DS<\/b>: Tas nav visp\u0101r\u012bgs. Bet Docker\u0101 tas darbojas visur.<\/p>\n

NS<\/b>: Idejiski, j\u0101. Bet mums tur ar\u012b ir modu\u013ci, var izveidot da\u017e\u0101dus modu\u013cus un str\u0101d\u0101t ar da\u017e\u0101d\u0101m failu sist\u0113m\u0101m. \u0160eit ir b\u016btisks moments. M\u0113s no Postgres puses uz to skat\u0101mies sav\u0101d\u0101k. Tagad es paskat\u012bjos no Docker puses un redz\u0113ju, ka jums viss darbojas. Bet ja datub\u0101ze ir liela, piem\u0113ram, 1 TB, tad tas jau ir ilgs process: gan darb\u012bbas nakt\u012b, gan visu iek\u013caut Docker\u2026 Un ja 5 TB iek\u013caut Docker\u2026 Vai ar\u012b viss ir k\u0101rt\u012bb\u0101?<\/i><\/p>\n

DS<\/b>: K\u0101da starp\u012bba: ta\u010du tas ir blobi, tikai biti un baitos.<\/p>\n

NS<\/b>: Starp\u012bba ir t\u0101da: vai j\u016bs to veicat caur dubl\u0113\u0161anu un atjauno\u0161anu?<\/i><\/p>\n

DS<\/b>: Piln\u012bgi nav oblig\u0101ti. Att\u0113la \u0123ener\u0113\u0161anas veidi var b\u016bt da\u017e\u0101di.<\/p>\n

NS<\/b>: Da\u017eiem klientiem m\u0113s esam izveidoju\u0161i sist\u0113mu, kur\u0101 pamata att\u0113ls tiek nep\u0101rtraukti atjaunin\u0101ts, nevis regul\u0101ri \u0123ener\u0113ts no jauna. Tas b\u016bt\u012bb\u0101 ir kopija, bet dati tiek ieg\u016bti nevis tie\u0161i no m\u0101tes data, bet caur arh\u012bvu. Bin\u0101rais arh\u012bvs, uz kuru katru dienu tiek apstr\u0101d\u0101ti WAL dati, turpat tiek veikti ar\u012b dubl\u0113jumi\u2026 \u0160ie WAL dati p\u0113c tam nok\u013c\u016bst \u2013 ar nelielu aizkav\u0113\u0161anos (burtiski 1-2 sekundes) \u2013 pie pamata att\u0113la. No t\u0101 m\u0113s jebkur\u0101 veid\u0101 klon\u0113jam \u2013 \u0161obr\u012bd m\u016bsu noklus\u0113jums ir ZFS.<\/i><\/p>\n

DS<\/b>: Bet ar ZFS j\u016bs esat ierobe\u017eoti ar vienu mezglu.<\/p>\n

NS<\/b>: J\u0101. Bet ZFS ir v\u0113l viens burvju send<\/a><\/noindex>: ar to var nos\u016bt\u012bt snapshots un pat (es to v\u0113l neesmu \u013coti test\u0113jis, bet\u2026) var nos\u016bt\u012bt delta starp diviem PGDATA<\/code>. Paties\u012bb\u0101 mums ir v\u0113l viens r\u012bks, ko m\u0113s neesam \u012bpa\u0161i apsv\u0113ru\u0161i \u0161\u0101d\u0101m vajadz\u012bb\u0101m. PostgreSQL ir pg_rewind<\/a><\/noindex>, darbojo k\u0101 \"gudrais\" rsync, izsl\u0113dzot daudz ko, ko nevar skat\u012bties, jo tur tie\u0161\u0101m nekas nav main\u012bjies. M\u0113s varam veikt \u0101tru sinhroniz\u0101ciju starp diviem serveriem un atgriezties atpaka\u013c tie\u0161i t\u0101pat.<\/i><\/p>\n

M\u0113s cen\u0161amies \u0161aj\u0101, DBA virzien\u0101, izveidot r\u012bku, kas \u013cauj veikt to pa\u0161u, par ko tu run\u0101ji: mums ir viena datub\u0101ze, bet m\u0113s v\u0113lamies 50 reizes test\u0113t kaut ko, gandr\u012bz vienlaic\u012bgi.<\/i><\/p>\n

DS<\/b>: 50 reizes noz\u012bm\u0113, ka jums j\u0101pas\u016bta 50 Spot instan\u010du.<\/p>\n

NS<\/b>: N\u0113, visu dar\u0101m uz vienas ma\u0161\u012bnas.<\/i><\/p>\n

DS<\/b>: Bet k\u0101 j\u016bs izveidosiet 50 reizes, ja \u0161\u012b viena datub\u0101ze, teiksim, ir terabaitu? Dro\u0161i vien tai vajag, nosac\u012bti, 256 GB RAM?<\/p>\n

NS<\/b>: J\u0101, atmi\u0146as da\u017ereiz nepiecie\u0161ams daudz \u2014 tas ir norm\u0101li. Bet \u0161\u0101ds piem\u0113rs no dz\u012bves. Produkcijas ma\u0161\u012bn\u0101 ir 96 kodoli un 600 GB. Taj\u0101 pa\u0161\u0101 laik\u0101 datub\u0101z\u0113m tiek izmantoti 32 kodoli (pat 16 kodoli tagad da\u017ereiz) un atmi\u0146a 100-120 GB.<\/i><\/p>\n

DS<\/b>: Un tur ietilpst 50 kopijas?<\/p>\n

NS<\/b>: T\u0101tad, ir viena kopija, t\u0101l\u0101k darbojas copy-on-write (ZFS re\u017e\u012bm\u0101)\u2026 Past\u0101st\u012b\u0161u s\u012bk\u0101k.<\/i><\/p>\n

Mums, piem\u0113ram, datub\u0101ze uz 10 TB. Disks tam ir izveidots, ZFS v\u0113l sarukusi t\u0101s lielumu par 30-40%. T\u0101 k\u0101 m\u0113s neveicam slodzi test\u0113\u0161anu, mums prec\u012bzs atbildes laiks nav svar\u012bgs: lai b\u016btu l\u012bdz 2 reizes l\u0113n\u0101k \u2014 tas ir norm\u0101li.<\/i><\/p>\n

M\u0113s dodam iesp\u0113ju programm\u0113t\u0101jiem, QA, DBA utt. veikt test\u0113\u0161anu 1-2 pl\u016bsm\u0101s. Piem\u0113ram, vi\u0146i var palaist k\u0101du migr\u0101ciju. Tam nav nepiecie\u0161ami uzreiz 10 kodoli \u2013 tam vajag 1 Postgres backendu, 1 kodolu. Migr\u0101cija tiks uzs\u0101kta \u2013 varb\u016bt, autovacuum<\/a><\/noindex> v\u0113l k\u0101da l\u0113ks, tad otrais kodols tiks iesaist\u012bts. Mums ir atv\u0113l\u0113ti 16-32 kodoli, t\u0101p\u0113c 10 cilv\u0113ki var str\u0101d\u0101t vienlaic\u012bgi, probl\u0113mu nav.<\/i><\/p>\n

T\u0101 k\u0101 fiziski PGDATA<\/code> rezult\u0101t\u0101 m\u0113s paties\u012bb\u0101 m\u0101n\u0101m Postgres. \u012apa\u0161\u012bba ir t\u0101da: piem\u0113ram, tiek palaisti 10 Postgres vienlaic\u012bgi. Parasti probl\u0113ma ir t\u0101da, ka... shared_buffers<\/a><\/noindex>, teiksim, 25%. Attiec\u012bgi, tas ir 200 GB. Vair\u0101k par trim t\u0101diem vairs neies\u0101ks, jo atmi\u0146a beigsies.<\/i><\/p>\n

Bet k\u0101d\u0101 br\u012bd\u012b m\u0113s saprat\u0101m, ka tas nav nepiecie\u0161ams: m\u0113s iestat\u0101m shared_buffers uz 2 GB. PostgreSQL ir effective_cache_size<\/a><\/noindex>, un realit\u0101t\u0113 tikai tas ietekm\u0113 pl\u0101nus<\/a><\/noindex>. To m\u0113s iestat\u0101m uz 0,5 TB. Pat nav svar\u012bgi, ka vi\u0146i paties\u012bb\u0101 nav: vi\u0146\u0161 veido pl\u0101nus, it k\u0101 tie b\u016btu.<\/i><\/p>\n

T\u0101d\u0113j\u0101di, kad m\u0113s test\u0113jam k\u0101du migr\u0101ciju, varam apkopot visus pl\u0101nus \u2013 m\u0113s redz\u0113sim, k\u0101 tas notiks ra\u017eo\u0161an\u0101. Laiki tur b\u016bs citi (l\u0113n\u0101ki), bet dati, kurus m\u0113s paties\u012bb\u0101 las\u0101m, un pa\u0161i pl\u0101ni (k\u0101di tur JOIN ir utt.) ir tie\u0161i t\u0101di pa\u0161i k\u0101 ra\u017eo\u0161an\u0101. Un vienlaikus var palaist daudz \u0161\u0101du p\u0101rbaudes uz vienas ma\u0161\u012bnas.<\/i><\/p>\n

DS<\/b>: Vai tu neuzskati, ka \u0161eit ir da\u017eas probl\u0113mas? Pirm\u0101 \u2014 tas ir risin\u0101jums, kas darbojas tikai uz PostgreSQL. \u0160\u0101ds pieg\u0101jiens ir \u013coti specifisks, tas nav \u0123enerisks. Otr\u0101 \u2014 Kubernetes (un viss, uz ko tagad virz\u0101s m\u0101ko\u0146u tehnolo\u0123ijas) paredz daudzas mezglu sist\u0113mas, un \u0161ie mezgli ir efem\u0113ri. Bet tav\u0101 gad\u012bjum\u0101 tas ir stateful, persistejo\u0161s mezgls. \u0160\u012bs lietas man rada pretrunas.<\/p>\n

NS<\/b>: Pirmk\u0101rt \u2014 piekr\u012btu, tas ir t\u012bri Postgres st\u0101sts. Dom\u0101ju, ja mums ir k\u0101ds tie\u0161ais IO un buferis praktiski visai atmi\u0146ai, \u0161\u0101ds pieg\u0101jiens neder\u0113s \u2013 pl\u0101ni b\u016bs citi. Bet pa\u0161laik m\u0113s str\u0101d\u0101jam tikai ar Postgres, par citiem nedom\u0101jam.<\/i><\/p>\n

Par Kubernetes. Tu ta\u010du pats visur st\u0101sti, ka m\u016bsu datub\u0101ze ir persistejo\u0161a. Ja instances sabr\u016bk, svar\u012bgi ir saglab\u0101t disku. Aizpild\u0101m ar\u012b visu platformu Kubernetes, bet komponents ar Postgres ir atsevi\u0161\u0137i (lai gan reiz vi\u0146\u0161 tur b\u016bs). T\u0101p\u0113c viss ir t\u0101: instances sabr\u016bk, bet m\u0113s saglab\u0101j\u0101m vi\u0146a PV un vienk\u0101r\u0161i pievienoj\u0101m to citam (jaunam) instancei, it k\u0101 nekas neb\u016btu noticis.<\/i><\/p>\n

DS<\/b>: No manas perspekt\u012bvas, m\u0113s izveidojam podus Kubernetes. K8s \u2014 elast\u012bgs: mezgli tiek pas\u016bt\u012bti pa\u0161i p\u0113c vajadz\u012bbas. Uzdevums ir vienk\u0101r\u0161i izveidot podu un pateikt, ka tam nepiecie\u0161ami X resursi, bet t\u0101l\u0101k K8s pats tiks gal\u0101. Bet atbalsts glab\u0101tuves Kubernetes joproj\u0101m nav stabils: 1.16<\/a><\/noindex>, vien\u0101 no saviem zi\u0146ojumiem 1.17<\/a><\/noindex> (\u0161is izlaidums izn\u0101ca ned\u0113\u013cas<\/i> pirms) \u0161\u012bs \u012bpa\u0161\u012bbas k\u013c\u016bst tikai par beta versij\u0101m.<\/p>\n

Pusst pa pusgada gada \u2014 tas k\u013c\u016bs stabil\u0101ks, vai vismaz tiks deklar\u0113ts k\u0101 stabils. Tad iesp\u0113ja veikt snap\u0161otus un resize jau piln\u012bb\u0101 atrisin\u0101s j\u016bsu uzdevumu. Jo jums ir b\u0101ze. J\u0101, t\u0101 var neb\u016bt \u013coti \u0101tra, bet \u0101trums ir atkar\u012bgs no t\u0101, kas ir \u00abzem v\u0101ka\u00bb, jo da\u017eas realiz\u0101cijas sp\u0113j veikt kop\u0113\u0161anu un copy-on-write diska apak\u0161sist\u0113mas l\u012bmen\u012b.<\/p>\n

NS<\/b>: \u0160eit v\u0113l j\u0101nodro\u0161ina, lai visi dzin\u0113ji (Amazon, Google...) pasp\u0113tu uzs\u0101kt atbalst\u012bt \u0161o versiju \u2014 tas ar\u012b prasa k\u0101du laiku.<\/i><\/p>\n

DS<\/b>: Kam\u0113r m\u0113s tos neizmantojam. M\u0113s izmantojam savu.<\/p>\n

Viet\u0113j\u0101 izstr\u0101de Kubernetes<\/h2>\n

\nNS<\/b>: Vai esi sask\u0101ries ar t\u0101du v\u0113l\u0113\u0161anos, kad nepiecie\u0161ams uz viena datora palaist visus podus un veikt mazu test\u0113\u0161anu. Lai \u0101tri ieg\u016btu pier\u0101d\u012bjumu par konceptu, paskat\u012btos, vai lietotne darbojas Kubernetes, neizdalot tam veselu kaudzi datoru. Ir Minikube, vai ne?<\/i><\/p>\n

DS<\/b>: Man \u0161\u0137iet, ka \u0161is gad\u012bjums \u2014 izvietot uz viena mezgla \u2014 ir t\u012bri lok\u0101lai izstr\u0101dei. Vai ar\u012b k\u0101diem \u0161\u0101da rakstura izpausm\u0113m. Ir Minikube<\/a><\/noindex>, ir k3s<\/a><\/noindex>, KIND<\/a><\/noindex>. M\u0113s virz\u0101mies uz to, lai izmantotu Kubernetes IN Docker. Tagad s\u0101k\u0101m ar to str\u0101d\u0101t testiem.<\/p>\n

NS<\/b>: Es agr\u0101k dom\u0101ju, ka tas ir m\u0113\u0123in\u0101jums iet\u012bt visus podus vien\u0101 Docker att\u0113l\u0101. Bet izr\u0101d\u012bj\u0101s, ka tas ir pavisam cits. Tur joproj\u0101m ir atsevi\u0161\u0137i konteineri, atsevi\u0161\u0137i podi \u2014 vienk\u0101r\u0161i Docker iek\u0161ien\u0113.<\/i><\/p>\n

DS<\/b>: J\u0101. Un tur ir diezgan interesanta imit\u0101cija izveidota, bet doma ir \u0161\u0101da\u2026 Mums ir util\u012bta deploy \u2014 werf<\/a><\/noindex>. M\u0113s v\u0113lamies taj\u0101 izveidot re\u017e\u012bmu \u2013 nosac\u012bti werf up<\/code>: \u201eUzcel man viet\u0113jo Kubernetes\u201d. Un p\u0113c tam palaist tur nosac\u012btu werf follow<\/code>. Tad izstr\u0101d\u0101t\u0101js var\u0113s labot IDE, bet sist\u0113m\u0101 darbojas process, kas redz izmai\u0146as un p\u0101rb\u016bv\u0113 att\u0113lus, p\u0101rdepoy\u0113 tos lok\u0101laj\u0101 K8s. T\u0101d\u0113j\u0101di m\u0113s gribam m\u0113\u0123in\u0101t atrisin\u0101t viet\u0113j\u0101s izstr\u0101des probl\u0113mu.<\/p>\n

Snaip\u0161oti un datub\u0101zu klon\u0113\u0161ana K8s realit\u0101t\u0113s<\/h2>\n

\nNS<\/b>: Ja atgrie\u017eas pie copy-on-write. Es paman\u012bju, ka ar\u012b m\u0101ko\u0146os ir snap\u0161oti. Tie str\u0101d\u0101 at\u0161\u0137ir\u012bgi. Piem\u0113ram, GCP: tev ir milz\u012bgs instance ASV austrumu krast\u0101. Tu regul\u0101ri veic snap\u0161otus. Tu aizs\u0101c diska kopiju no snap\u0161ota uz rietumu krastu \u2014 p\u0113c da\u017e\u0101m min\u016bt\u0113m viss jau ir gatavs, darbojas \u013coti \u0101tri, tikai ke\u0161atmi\u0146ai j\u0101b\u016bt piepild\u012btai atmi\u0146\u0101. Bet \u0161ie kloni (snap\u0161oti) ir dom\u0101ti, lai \u00abprovision\u00bb jaunu apjomu. Tas ir lieliski, kad nepiecie\u0161ams izveidot daudz instan\u010du.<\/i><\/p>\n

Bet testiem, man liekas, snap\u0161oti, par kuriem tu run\u0101 Docker, vai es run\u0101ju ZFS, btrfs un pat LVM... \u2014 tie \u013cauj neizveidot faktiski jaunus datus uz viena datora. M\u0101ko\u0146os tu v\u0113l maks\u0101si par tiem katru reizi un gaid\u012bsi ne sekundes, bet min\u016btes (un gad\u012bjum\u0101 lazy load’am<\/a><\/noindex>, iesp\u0113jams, pat stundas).<\/i><\/p>\n

T\u0101 viet\u0101 tu vari ieg\u016bt \u0161os datus da\u017eu sekun\u017eu laik\u0101, veikt testu un izmest. \u0160ie snaip\u0161oti risina da\u017e\u0101das probl\u0113mas. Pirmaj\u0101 gad\u012bjum\u0101 \u2014 lai palielin\u0101tos un ieg\u016btu jaunas replikas, bet otraj\u0101 \u2014 testiem.<\/i><\/p>\n

DS<\/b>: Nesotrie\u0161u. Veikt norm\u0101lu tiltu klon\u0113\u0161anu \u2014 tas ir m\u0101ko\u0146a uzdevums. Es neesmu skat\u012bjies uz vi\u0146u \u012bstenojumu, bet zinu, k\u0101 to dar\u0101m m\u0113s uz dzel\u017eiem. Mums ir Ceph, taj\u0101 var jebkuram fiziskam tiltam (RBD<\/a><\/noindex>) teikt clone<\/i> un ieg\u016bt da\u017eu desmitu milisekun\u017eu laik\u0101 otro tiltu ar t\u0101d\u0101m pa\u0161\u0101m specifik\u0101cij\u0101m, IOPS<\/a><\/noindex>\u2018iem un taml\u012bdz\u012bgi. J\u0101izprot, ka tur iek\u0161pus\u0113 ir vilt\u012bgs copy-on-write. K\u0101p\u0113c m\u0101ko\u0146iem to nedar\u012bt t\u0101pat? Esmu p\u0101rliecin\u0101ts, ka vi\u0146i cen\u0161as to kaut k\u0101 dar\u012bt.<\/p>\n

NS<\/b>: Bet vi\u0146iem joproj\u0101m aiz\u0146ems sekundes, desmitiem sekun\u017eu, lai izgaisin\u0101tu instance, novietotu tur Docker utt.<\/i><\/p>\n

DS<\/b>: K\u0101p\u0113c oblig\u0101ti j\u0101uzce\u013c visa instance? Mums ta\u010du ir instance ar 32 kodoliem, ar 16\u2026 un taj\u0101 iek\u013caujas noteikts skaits \u2014 piem\u0113ram, \u010detri. Kad m\u0113s pas\u016bt\u0101m piekto, jau uzcelsies instance, un tad t\u0101 tiks dz\u0113sta.<\/p>\n

NS<\/b>: J\u0101, interesanti, ka Kubernetes izn\u0101k cita st\u0101sts. Mums BDs nav K8s, un viena instance. Toties daudzu terabaitu datu klon\u0113\u0161anai nepaiet vair\u0101k par div\u0101m sekund\u0113m.<\/i><\/p>\n

DS<\/b>: Tas ir lieliski. Bet mans s\u0101kotn\u0113jais uzsvars ir uz to, ka tas nav generisks risin\u0101jums. J\u0101, tas ir for\u0161s, bet der tikai Postgres un tikai uz viena mezgla.<\/p>\n

NS<\/b>: Tas der ne tikai Postgres: \u0161ie pl\u0101ni, k\u0101 es aprakst\u012bju, darbosies tikai taj\u0101. Bet ja nesatrauktu par pl\u0101niem, bet mums vienk\u0101r\u0161i ir nepiecie\u0161ami visi dati funkcion\u0101lai test\u0113\u0161anai, tad tas der\u0113s jebkurai DBMS.<\/i><\/p>\n

DS<\/b>: Pirms daudziem gadiem m\u0113s dar\u012bj\u0101m l\u012bdz\u012bgu uz LVM momentuz\u0146\u0113mumiem. Tas ir klasika. \u0160\u0101ds risin\u0101jums tika \u013coti akt\u012bvi izmantots. Vienk\u0101r\u0161i stateful mezgli \u2014 t\u0101 ir s\u0101p\u012bga vieta. Jo tos nevar laist va\u013c\u0101, vienm\u0113r par tiem j\u0101atceras...<\/p>\n

NS<\/b>: Vai tu neredzi \u0161eit k\u0101du hibr\u012bda iesp\u0113ju? Pie\u0146emsim, ka stateful \u2014 tas ir k\u0101ds pods, kas str\u0101d\u0101 uz vair\u0101kiem cilv\u0113kiem (daudziem test\u0113t\u0101jiem). Mums ir viens tilts, bet pateicoties failu sist\u0113mai kloni \u2014 lok\u0101li. Ja pods nokr\u012bt, disks paliek \u2014 pacelsies pods, inform\u0101ciju par visiem kloniem nolas\u012bs, visu atpaka\u013c pacels un teiks: \u00abL\u016bk, j\u016bsu kloni \u0161ajos portos ir uzs\u0101kti, str\u0101d\u0101jiet ar tiem t\u0101l\u0101k\u00bb.<\/i><\/p>\n

DS<\/b>: Tehniski tas noz\u012bm\u0113, ka Kubernetes ietvaros tas ir viens pods, iek\u0161 kura m\u0113s palaid\u012bsim daudz Postgresu.<\/p>\n

NS<\/b>: J\u0101. Tam ir ierobe\u017eojums: pie\u0146emsim, ka vienlaic\u012bgi ar to str\u0101d\u0101 ne vair\u0101k k\u0101 10 cilv\u0113ki. Ja nepiecie\u0161ami 20 \u2014 palaid\u012bsim otro t\u0101du pa\u0161u podu. Piln\u012bgi re\u0101li to klon\u0113t, ieg\u016bstot otro piln\u012bgu tiltu, uz kura b\u016bs t\u0101di pa\u0161i 10 \u00abpl\u0101nie\u00bb kloni. Vai tu neredzi t\u0101du iesp\u0113ju?<\/i><\/p>\n

DS<\/b>: J\u0101piecie\u0161ams pievienot \u0161eit dro\u0161\u012bbas jaut\u0101jumus. \u0160\u0101da organiz\u0113\u0161anas iesp\u0113ja noz\u012bm\u0113, ka \u0161im pod’am ir augstas privil\u0113\u0123ijas (capabilities), jo tas var veikt nestandarta oper\u0101cijas ar failu sist\u0113mu\u2026 Bet atk\u0101rtoju: es uzskatu, ka vid\u0113j\u0101 termi\u0146\u0101 Kubernetes nov\u0113rs\u012bs uzglab\u0101\u0161anas probl\u0113mas, m\u0101ko\u0146os tiks nov\u0113rstas visas probl\u0113mas ar apjomu \u2014 viss darbosies<\/p>\n

NS<\/b>: Neesmu p\u0101rliecin\u0101ts par pusotru sekundi daudziem terabaitiem. Ceph tu dari pats, bet tu run\u0101 par m\u0101ko\u0146iem. Aiziet uz m\u0101ko\u0146u, EC2 izveido klonu EBS apjoma daudzu terabaitu un paskaties, k\u0101da b\u016bs veiktsp\u0113ja. Tas neaiz\u0146ems da\u017eas sekundes. Man \u013coti interes\u0113, kad vi\u0146i sasniegs \u0161\u0101du r\u0101d\u012bt\u0101ju. Saprotu, par ko tu run\u0101, bet \u013cau\u0161os nepiekr\u012bt.<\/i><\/p>\n

DS<\/b>: Labi, bet es teicu, ka vid\u0113j\u0101 termi\u0146\u0101, nevis \u012bstermi\u0146\u0101. Da\u017eu gadu laik\u0101.<\/p>\n

Par PostgreSQL operatoru no Zalando<\/h2>\n

\n\u0160\u012bs tik\u0161an\u0101s vid\u016b pie vi\u0146as pievienoj\u0101s ar\u012b Aleksejs K\u013cukins, biju\u0161ais izstr\u0101d\u0101t\u0101js no uz\u0146\u0113muma Zalando, kur\u0161 past\u0101st\u012bja par PostgreSQL operatora v\u0113sturi:<\/p>\n

For\u0161i, ka visp\u0101r \u0161\u012b t\u0113ma ir piesk\u0101rta: gan Postgres, gan Kubernetes. Kad m\u0113s s\u0101k\u0101m to dar\u012bt Zalando 2017. gad\u0101, t\u0101 bija t\u0113ma, ar kuru visi v\u0113l\u0113j\u0101s nodarboties, bet neviens to nedar\u012bja. Visi jau ieguva Kubernetes, bet, kad jaut\u0101ja, ko dar\u012bt ar datu b\u0101z\u0113m, pat t\u0101di cilv\u0113ki k\u0101 Kelsey Hightower<\/a><\/noindex>, kas sludin\u0101ja K8s, teica apm\u0113ram sekojo\u0161o:<\/p>\n

\u00abIet uz p\u0101rvald\u012btajiem pakalpojumiem un izmantojiet tos, nepalai\u017eiet DB Kubernetes. Pret\u0113j\u0101 gad\u012bjum\u0101 j\u016bsu K8s izlemt, piem\u0113ram, veikt atjaunin\u0101jumu, izsl\u0113gs visus mezglus, un j\u016bsu dati aizlidos t\u0101lu, t\u0101lu\u00bb.<\/i><\/p>\n

M\u0113s nol\u0113m\u0101m izveidot operatoru, kur\u0161, par sp\u012bti \u0161ai padomam, palaid\u012bs Postgres DB Kubernetes. Un mums bija labs pamats \u2014 Patroni<\/a><\/noindex>. Tas ir autom\u0101tiskais failover PostgreSQL, kas izstr\u0101d\u0101ts pareizi, t.i., izmantojot etcd, consul vai ZooKeeper k\u0101 inform\u0101cijas glab\u0101tuvi par klasteri. T\u0101ds glab\u0101tuve, kas sniegs visiem, kas jaut\u0101, piem\u0113ram, k\u0101ds ir tagad l\u012bderis, to pa\u0161u inform\u0101ciju \u2014 neskatoties uz to, ka viss ir sadal\u012bts, \u2014 lai neb\u016btu split brain’a. Turkl\u0101t, mums bija Docker att\u0113lu<\/a><\/noindex> tam.<\/p>\n

Visp\u0101r, uz\u0146\u0113mumam rad\u0101s vajadz\u012bba p\u0113c auto failover p\u0113c migr\u0101cijas no iek\u0161\u0113j\u0101 dzelzs datu centra uz m\u0101ko\u0146a. M\u0101ko\u0146a risin\u0101jums balst\u012bj\u0101s uz pa\u0161a izstr\u0101d\u0101tu PaaS (Platform-as-a-Service) risin\u0101jumu. Tas ir atv\u0113rt\u0101 koda, bet, lai to uzst\u0101d\u012btu, bija j\u0101str\u0101d\u0101 smagi. To sauca STUPS<\/a><\/noindex>.<\/p>\n

S\u0101kotn\u0113ji nebija nek\u0101du Kubernetes’u. Prec\u012bz\u0101k, kad tika izv\u0113rsta pa\u0161a risin\u0101juma, K8s jau bija, bet t\u0101ds tik nenobriedis, ka ra\u017eo\u0161an\u0101 nebija der\u012bgs. Tas bija, manupr\u0101t, 2015. vai 2016. gad\u0101. L\u012bdz 2017. gadam Kubernetes k\u013cuva vair\u0101k vai maz\u0101k nobriedis \u2014 rad\u0101s nepiecie\u0161am\u012bba tur migr\u0113t.<\/p>\n

Un mums jau bija Docker konteiners. Past\u0101v\u0113ja PaaS, kas izmantoja Docker. K\u0101p\u0113c neizm\u0113\u0123in\u0101t K8s? K\u0101p\u0113c neuzrakst\u012bt savu operatoru? Murats Kabilovs, kur\u0161 pievienoj\u0101s mums no Avito, s\u0101kotn\u0113ji uzs\u0101ka \u0161o projektu p\u0113c savas iniciat\u012bvas \u2014 \"pasp\u0113l\u0113ties\", \u2014 un projekts \"uzs\u0101k\u0101s\".<\/p>\n

Bet visp\u0101r es grib\u0113ju past\u0101st\u012bt par AWS. K\u0101p\u0113c tur bija v\u0113sturiski kods, kas saist\u012bts ar AWS\u2026<\/p>\n

Kad j\u016bs uzs\u0101kat jebko Kubernetes, j\u0101atceras, ka K8s ir t\u0101ds darbs progres\u0101. Tas past\u0101v\u012bgi att\u012bst\u0101s, uzlabojas un periodiski pat sabojas. J\u0101seko vis\u0101m izmai\u0146\u0101m Kubernetes, j\u0101b\u016bt gatavam, ja kaut kas notiks, iedzi\u013cin\u0101ties taj\u0101 un uzzin\u0101t, k\u0101 tas darbojas deta\u013c\u0101s \u2014 iesp\u0113jams, pat vair\u0101k, nek\u0101 jums patiktu. Tas attiecas uz jebkuru platformu, uz kuras j\u016bs uzs\u0101kat savas DB\u2026<\/p>\n

T\u0101tad, kad m\u0113s izstr\u0101d\u0101j\u0101m operatoru, mums bija Postgres, kas str\u0101d\u0101ja ar \u0101r\u0113jo apjomu (\u0161aj\u0101 gad\u012bjum\u0101 \u2014 EBS, jo m\u0113s str\u0101d\u0101j\u0101m AWS). Datu b\u0101ze pieauga, un k\u0101d\u0101 br\u012bd\u012b n\u0101c\u0101s veikt resize: piem\u0113ram, s\u0101kotn\u0113jais EBS apjoms bija 100 TB, datu b\u0101ze pieauga l\u012bdz tam, tagad v\u0113lamies EBS 200 TB. K\u0101? Pie\u0146emsim, ka var izveidot dump\/restore uz jauna instanc\u0113m, bet tas ir ilgs un ar d\u012bkst\u0101vi.<\/p>\n

T\u0101p\u0113c m\u0113s v\u0113l\u0113j\u0101mies t\u0101du resize, kas palielin\u0101tu EBS’u part\u012bciju un p\u0113c tam teiktu failu sist\u0113mai izmantot jauno vietu. Un m\u0113s to izdar\u012bj\u0101m, bet taj\u0101 laik\u0101 Kubernetes’am nebija nek\u0101du API resize oper\u0101cijai. T\u0101 k\u0101 m\u0113s str\u0101d\u0101j\u0101m AWS, uzrakst\u012bj\u0101m kodu t\u0101 API.<\/p>\n

Neviens netrauc\u0113 izdar\u012bt to pa\u0161u cit\u0101m platform\u0101m. Operator\u0101 nav saist\u012bbas, ka to var palaist tikai AWS, un uz visu citu tas nedarbosies. Kopum\u0101 tas ir atv\u0113rta koda projekts: ja k\u0101ds v\u0113las pa\u0101trin\u0101t jaun\u0101 API izmanto\u0161anas par\u0101d\u012b\u0161anos \u2014 laipni l\u016bdzam. Ir GitHub<\/a><\/noindex>, pull piepras\u012bjumi \u2014 Zalando komanda cen\u0161as diezgan operat\u012bvi uz tiem rea\u0123\u0113t un virz\u012bt operatoru. Cik zinu, projekts piedal\u012bj\u0101s<\/a><\/noindex> Google Summer of Code un cit\u0101s l\u012bdz\u012bg\u0101s iniciat\u012bv\u0101s. Zalando \u013coti akt\u012bvi str\u0101d\u0101 pie t\u0101.\n<\/p><\/blockquote>\n

<\/p>\n

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

\nJa j\u016bs interes\u0113 t\u0113ma PostgreSQL un Kubernetes, tad j\u0101\u0146em v\u0113r\u0101, ka pag\u0101ju\u0161aj\u0101 ned\u0113\u013c\u0101 notika n\u0101kamais Postgres otrdiena, kur Nikolajs sarun\u0101j\u0101s ar Aleksandru Kuku\u0161kinu no Zalando<\/b>. Video no t\u0101 ir pieejams \u0161eit<\/a><\/noindex>.<\/p>\n

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

\nLasiet ar\u012b m\u016bsu emu\u0101ra rakstos:<\/p>\n