{"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\/hr\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres utorak br. 5: 'PostgreSQL i Kubernetes. CI\/CD. Automatizacija testiranja'","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres
\n
\nKrajem pro\u0161le godine odr\u017ean je jo\u0161 jedan livestream ruskog PostgreSQL zajedni\u0161tva #RuPostgres<\/a><\/noindex>, tijekom kojeg je njegov suosniva\u010d Nikolaj Samohvalov razgovarao s tehni\u010dkim direktorom \u00abFlanta\u00bb Dmitrijem Stolyarovim o ovoj DBMS u kontekstu Kubernetesa.<\/p>\n

Objavljujemo transkript glavnog dijela ove diskusije, a na YouTube kanalu zajednice<\/a><\/noindex> objavljena je cjelovita video snimka:<\/a><\/noindex><\/p>\n

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

Baze podataka i Kubernetes<\/h2>\n

\n\u041d\u0421<\/b>: Danas ne\u0107emo govoriti o VACUUM i CHECKPOINT-ima. \u017delimo razgovarati o Kubernetes-u. Znam da ve\u0107 ima\u0161 puno godina iskustva. Gledao sam tvoje video zapise i neke sam \u010dak ponovo pregledavao po dijelovima\u2026 Idemo odmah na stvar: za\u0161to zapravo Postgres ili MySQL u K8s?<\/i><\/p>\n

\u0414\u0421<\/b>: Na ovo pitanje ne postoji jednozna\u010dan odgovor, niti mo\u017ee postojati. Ali op\u0107enito, to je jednostavnost i prakti\u010dnost\u2026 potencijalne. Svi \u017eele managed usluge.<\/p>\n

\u041d\u0421<\/b>: Da bude kao RDS<\/a><\/noindex>, samo svoje?<\/i><\/p>\n

\u0414\u0421<\/b>: Da: kao RDS, samo gdje god \u017eeli\u0161.<\/p>\n

\u041d\u0421<\/b>: \u00abGdje god \u017eeli\u0161\u00bb \u2014 to je dobar komentar. U velikim kompanijama sve je smje\u0161teno na razli\u010ditim lokacijama. A za\u0161to onda, ako je to velika kompanija, ne uzeti gotovo rje\u0161enje? Na primjer, Nutanix ima vlastite razvojne projekte, a druge kompanije (VMware\u2026) imaju isto \u00abRDS, samo svoje\u00bb.<\/i><\/p>\n

\u0414\u0421<\/b>: Ali govorimo o posebno dizajniranom rje\u0161enju koje \u0107e raditi samo pod odre\u0111enim uvjetima. A kada je rije\u010d o Kubernetesu, ovdje je ogroman izbor infrastrukture (koja mo\u017ee biti u K8s). U su\u0161tini, to je standard za API prema oblaku\u2026<\/p>\n

\u041d\u0421<\/b>: I jo\u0161 je besplatno!<\/i><\/p>\n

\u0414\u0421<\/b>: To nije tako va\u017eno. Besplatnost je va\u017ena samo za manji segment tr\u017ei\u0161ta. Va\u017eno je ne\u0161to drugo\u2026 Sigurno se sje\u0107a\u0161 mog izlaganja \u00abBaze podataka i Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

\u041d\u0421<\/b>: Da.<\/i><\/p>\n

\u0414\u0421<\/b>: Shvatio sam da je to do\u010dekano vrlo ambivalentno. Dio ljudi je pomislio da ka\u017eem: 'Ekipa, idemo sve Baze podataka u Kubernetes!', dok su drugi mislili da su to sve stra\u0161ni bicikli. A ja sam zapravo \u017eelio govoriti o ne\u010dem drugom: 'Pogledajte \u0161to se doga\u0111a, koje probleme imamo i kako ih mo\u017eemo rije\u0161iti. Je li sada vrijeme za pokretanje baza u Kubernetes-u? U produkciji? Pa, samo ako volite\u2026 raditi odre\u0111ene stvari. Ali za dev-ove \u2014 mogu re\u0107i da preporu\u010dujem. Za dev-ove je vrlo va\u017ena dinami\u010dnost kreiranja\/brisanja okru\u017eenja.<\/p>\n

NS: Pod dev-om misli\u0161 na sva okru\u017eenja koja nisu prod? Staging, QA\u2026<\/i><\/p>\n

\u0414\u0421<\/b>: Kada govorimo o perf-stendovima, mislim da ne, jer su zahtjevi specifi\u010dni. Ako govorimo o posebnim slu\u010dajevima gdje je na stagingu potrebna jako velika baza podataka, tako\u0111er mislim da ne... Ako je to stati\u010dno okru\u017eenje, dugotrajno, koja je onda korist od toga \u0161to se baza nalazi u K8s?<\/p>\n

\u041d\u0421<\/b>: Nema nikakve. Ali gdje vidimo stati\u010dna okru\u017eenja? Stati\u010dna okru\u017eenja su ju\u010der postala zastarjela.<\/i><\/p>\n

\u0414\u0421<\/b>: Staging mo\u017ee biti stati\u010dan. Imamo klijente...<\/p>\n

\u041d\u0421<\/b>: Da, i ja imam. Veliki je problem ako imate bazu od 10 TB, a staging od 200 GB...<\/i><\/p>\n

\u0414\u0421<\/b>: Imam vrlo cool slu\u010daj! Na staging-u se nalazi produkcijska baza u koju se unose promjene. I postoji dugme: 'izvr\u0161i u produkciju'. Te promjene \u2014 delte \u2014 se dodaju (\u010dini se, jednostavno se sinkronizuju putem API-ja) u produkciju. To je vrlo egzoti\u010dna opcija.<\/p>\n

\u041d\u0421<\/b>: Vidio sam startupe u Dolini koji jo\u0161 sjede na RDS-u ili \u010dak u Heroku \u2014 to su pri\u010de od prije 2-3 godine \u2014 i preuzimaju dump sebi na laptop. Jer baza je za sada svega 80 GB, a na laptopu ima mjesta. Kasnije kupuju diskove svakome, kako bi imali po 3 baze za vo\u0111enje razli\u010ditih razvojnih projekata. Tako\u0111er sam primijetio da se ne boje kopirati prod u staging \u2014 to jako ovisi o kompaniji. Ali sam vidio i da se jako boje, i da \u010desto nedostaje vremena i resursa. No prije nego \u0161to pre\u0111emo na tu temu, \u017eelim \u010duti o Kubernetes-u. Dobro razumijem, da u produkciji to jo\u0161 nitko nema?<\/i><\/p>\n

\u0414\u0421<\/b>: Imamo male baze u produkciji. Rije\u010d je o volumenu od nekoliko desetaka gigabajta i nekriti\u010dnim servisima, za koje nam se nije dalo raditi replike (da, i nije bilo takve potrebe). I pod uvjetom da pod Kubernetes-om postoji normalno skladi\u0161te. Ova baza je radila u virtuelnoj ma\u0161ini \u2014 uvjetno u VMware-u, na vrhu SAN-a. Smjestili smo je u PV<\/a><\/noindex> i sada je mo\u017eemo prenositi s ma\u0161ine na ma\u0161inu.<\/p>\n

\u041d\u0421<\/b>: Baze takvih dimenzija, do 100 GB, na dobrim diskovima i uz dobru mre\u017eu, mogu se razdi\u0107i za nekoliko minuta, zar ne? Brzina od 1 GB u sekundi nije vi\u0161e egzoti\u010dna.<\/i><\/p>\n

\u0414\u0421<\/b>: Da, za linearnu operaciju to nije problem.<\/p>\n

\u041d\u0421<\/b>: U redu, o produkciji trebamo samo razmi\u0161ljati. A ako razmatramo Kubernetes za ne-prod okru\u017eenja \u2014 kako raditi? Vidim da u Zalandu prave operator<\/a><\/noindex>, u Crunchy imaju svoje rje\u0161enje<\/a><\/noindex>, postoje jo\u0161 neki varijante. I tu je OnGres<\/a><\/noindex> \u2014 na\u0161 dobar poznanik Alvaro iz \u0160panjolske: oni ne rade samo operator<\/a><\/noindex>, ve\u0107 \u010ditav distributiv (StackGres<\/a><\/noindex>), u koju osim samog Postgres-a planiramo staviti i backup, proxy Envoy\u2026<\/i><\/p>\n

\u0414\u0421<\/b>: Envoy za \u0161to? Za balansiranje prometom Postgres-a?<\/p>\n

\u041d\u0421<\/b>: Da. Dakle, oni to vide kao: ako uzmemo Linux distribuciju i jezgru, obi\u010dni PostgreSQL je jezgra, a oni \u017eele napraviti distribuciju koja \u0107e biti prijateljska prema obla\u010dnim uslugama i raditi unutar Kubernetes-a. Spojit \u0107e komponente (backupi itd.) i optimizirati ih kako bi dobro radili.<\/i><\/p>\n

\u0414\u0421<\/b>: Vrlo cool! U su\u0161tini, to je softver za izradu vlastitog upravljanog Postgres-a.<\/p>\n

\u041d\u0421<\/b>: Kod Linux distribucija postoje vje\u010dni problemi: kako napraviti drivere da bi se sav hardver podr\u017eao. A njihova ideja je da \u0107e raditi unutar Kubernetes-a. Znam da smo nedavno u operatoru Zalando vidjeli vezu na AWS, \u0161to ve\u0107 nije dobro. Ne bi se trebala raditi veza na specifi\u010dnu infrastrukturu \u2014 u \u010demu je onda smisao?<\/i><\/p>\n

\u0414\u0421<\/b>: Ne znam u kojoj situaciji se konkretno Zalando povezao, ali trenutno je storage u Kubernetes-u napravljen tako da se diskovni backup ne mo\u017ee uzeti na generi\u010dki na\u010din. Nedavno je u standardu \u2014 u posljednjoj verziji CSI specifikacije<\/a><\/noindex> \u2014 omogu\u0107eno snimanje snimaka, ali gdje je to implementirano? Iskreno, jo\u0161 uvijek je sve toliko sirovo... Poku\u0161avamo CSI na AWS-u, GCE-u, Azure-u, vSphere-u, ali \u010dim po\u010dne\u0161 koristiti, vidi se da to jo\u0161 nije spremno.<\/p>\n

\u041d\u0421<\/b>: Zato ponekad moramo vezati na infrastrukturu. Mislim da je to jo\u0161 uvijek rani stadij \u2014 problemi rasta. Pitanje: \u0161to bi savjetovao po\u010detnicima koji \u017eele probati PgSQL u K8s? Koji operator, mo\u017eda?<\/i><\/p>\n

\u0414\u0421<\/b>: Problem je u tome \u0161to nam je Postgres samo 3%. Imamo jo\u0161 vrlo veliki popis raznog softvera u Kubernetesu, ne\u0107u sve nabrajati. Na primjer, Elasticsearch. Ima mnogo operatera: neki se aktivno razvijaju, drugi ne. Odredili smo zahtjeve za to \u0161to bi operater trebao imati da bi ga ozbiljno shvatili. Operater upravo za Kubernetes \u2014 ne u \"operateru koji radi ne\u0161to u uvjetima Amazona\"\u2026 U praksi, prili\u010dno masovno (= gotovo svi klijenti) koristimo samo jednog operatera \u2014 za Redis<\/a><\/noindex> (uskoro \u0107emo objaviti \u010dlanak i o njemu)<\/i>.<\/p>\n

\u041d\u0421<\/b>: A za MySQL tako\u0111er nema? Znam da Percona... sada se bave i MySQL-om, i MongoDB-om, i Postgres-om, trebali bi napraviti neki univerzalni sustav: za sve baze, za sve cloud pru\u017eatelje.<\/i><\/p>\n

\u0414\u0421<\/b>: Nismo stigli da pogledamo operatore za MySQL. To nam trenutno nije glavna preokupacija. MySQL dobro radi u standalone re\u017eimu. Za\u0161to bi trebao operator, kada jednostavno mo\u017ee\u0161 pokrenuti bazu podataka\u2026 Mo\u017ee\u0161 pokrenuti Docker kontejner s Postgresom, ali mo\u017ee\u0161 ga jednostavno pokrenuti.<\/p>\n

\u041d\u0421<\/b>: O tome je tako\u0111er bilo pitanje. U potpunosti bez operatora?<\/i><\/p>\n

\u0414\u0421<\/b>: Da, 100% imamo PostgreSQL pokrenut bez operatora. Za sada tako. Aktivno koristimo operator za Prometheus, za Redis. Planiramo prona\u0107i operator za Elasticsearch \u2014 on nam je najprioritetniji, jer ga \u017eelimo implementirati 100% slu\u010dajeva u Kubernetes. Tako\u0111er, \u017eelimo da MongoDB uvijek bude u Kubernetesu. Pojavljuju se odre\u0111ene \u017eelje \u2014 imamo osje\u0107aj da mo\u017eemo ne\u0161to napraviti u tim slu\u010dajevima. O Postgresu nismo ni razmi\u0161ljali. Naravno, znamo za razli\u010dite opcije, ali u stvarnosti imamo standalone.<\/p>\n

Baza podataka za testiranje u Kubernetesu<\/h2>\n

\n\u041d\u0421<\/b>: Idemo na temu testiranja. Kako primijeniti promjene u bazi \u2014 iz perspektive DevOps-a. Ima mnogo mikroservisa, puno baza, stalno se ne\u0161to mijenja. Kako osigurati normalan CI\/CD, da s aspekta SDB-a sve bude u redu. Koji je tvoj pristup?<\/i><\/p>\n

\u0414\u0421<\/b>: Ne mo\u017ee biti jednog odgovora. Ima nekoliko parametara. Prvi je veli\u010dina baze koju \u017eelimo primijeniti. Sam si spomenuo da se razli\u010dito pristupa tome da kopija prod-baze bude na dev i stage.<\/p>\n

\u041d\u0421<\/b>: A u uvjetima GDPR-a, mislim da se pa\u017eljivije postupa\u2026 Mogu re\u0107i da su u Europi po\u010deli s ka\u017enjavanjem.<\/i><\/p>\n

\u0414\u0421<\/b>: No \u010desto se mo\u017ee napisati softver koji pravi dump s produkcije i obfuscira ga. Dobijamo produkcijske podatke (snapshot, dump, binarna kopija\u2026), ali su anonimizirani. Umjesto toga, mogu se koristiti i skripte za generaciju: to mogu biti fixtures ili jednostavno skripta koja generira veliku bazu. Problem je u tome: koliko vremena treba za stvaranje osnovnog imid\u017ea? I koliko vremena treba da se on rasporedi u potrebnom okru\u017eenju?<\/p>\n

Do\u0161li smo do sheme: ako klijent ima skup fiksnih podataka (minimalna verzija baze), onda ih po defaultu koristimo. Ako se radi o preglednim okru\u017eenjima, kada smo stvorili branch, na\u0161 instance aplikacije se pokrene \u2014 tamo primjenjujemo malu bazu. Ali dobro je i ispalo. varijantu<\/a><\/noindex>, kada s produkcije svaki dan (no\u0107u) uzimamo dump i na temelju njega sastavljamo Docker-kontejner s PostgreSQL i MySQL s tim u\u010ditanim podacima. Ako je potrebno 50 puta rasporediti bazu iz ovog imid\u017ea, to je prili\u010dno jednostavno i brzo.<\/p>\n

\u041d\u0421<\/b>: Jednostavnim kopiranjem?<\/i><\/p>\n

\u0414\u0421<\/b>: Podaci se pohranjuju direktno u Docker image-u. To jest, imamo gotov image, recimo od 100 GB. Zahvaljuju\u0107i slojevima u Docker-u, mo\u017eemo brzo pokretati ovaj image onoliko puta koliko je potrebno. Na\u010din je trivijalan, ali dobro radi.<\/p>\n

\u041d\u0421<\/b>: Dalje, kada testirate, to se unutra Docker-a mijenja, zar ne? Copy-on-write unutar Docker-a \u2014 izbacimo i krenemo iznova, sve je u redu. Super! I to ve\u0107 u potpunosti koristite?<\/i><\/p>\n

\u0414\u0421<\/b>: Ve\u0107 dugo.<\/p>\n

\u041d\u0421<\/b>: Bavimo se vrlo sli\u010dnim stvarima. Samo ne koristimo Docker-ov copy-on-write, nego ne\u0161to drugo.<\/i><\/p>\n

\u0414\u0421<\/b>: Nije generi\u010dki. A Docker-ov radi svugdje.<\/p>\n

\u041d\u0421<\/b>: Tehni\u010dki, da. No imamo i module, mo\u017eemo izraditi razli\u010dite module i raditi s razli\u010ditim datote\u010dnim sustavima. Ovdje se javlja trenutak. S aspekta Postgres-a na sve ovo gledamo druga\u010dije. Sada sam pogledao iz perspektive Docker-a i vidio da vam sve funkcionira. Ali ako je baza ogromna, na primjer, 1 TB, tada je to ve\u0107 sve sporo: i operacije no\u0107u, i stavljanje svega u Docker\u2026 A ako se 5 TB stavi u Docker\u2026 Ili je sve u redu?<\/i><\/p>\n

\u0414\u0421<\/b>: Koja je razlika: to su blob-ovi, samo bitovi i bajtovi.<\/p>\n

\u041d\u0421<\/b>: Razlika je: da li to radite preko dump i restore?<\/i><\/p>\n

\u0414\u0421<\/b>: O tome nije nu\u017eno. Postoji vi\u0161e na\u010dina generiranja ovog image-a.<\/p>\n

\u041d\u0421<\/b>: Za neke klijente postavili smo sustav koji odr\u017eava osnovnu sliku stalno a\u017euriranom, umjesto da je redovno generiramo. U su\u0161tini, to je replika koja ne prima podatke iz glavnog izvora, ve\u0107 ih dobiva putem arhive. Binarna arhiva u koju se WAL-ovi svakodnevno primjenjuju, tako\u0111er se prave sigurnosne kopije... Ovi WAL-ovi na kraju do\u0111u \u2014 s malim ka\u0161njenjem (doslovno 1-2 sekunde) \u2014 do osnovne slike. Od nje kloniramo na bilo koji na\u010din \u2014 trenutno koristimo ZFS kao zadanu opciju.<\/i><\/p>\n

\u0414\u0421<\/b>: Ali s ZFS-om ste ograni\u010deni na jedan \u010dvor.<\/p>\n

\u041d\u0421<\/b>: Da. Ali ZFS ima jo\u0161 jedan \u010darobni send<\/a><\/noindex>: s njim mo\u017eete poslati snapshot i \u010dak (ovo jo\u0161 nisam puno testirao, ali\u2026) mo\u017eete slati diferencijal izme\u0111u dvaju PGDATA<\/code>. U stvarnosti, imamo jo\u0161 jedan alat koji nismo posebno razmatrali za takve zadatke. U PostgreSQL postoji pg_rewind<\/a><\/noindex>, radi kao \"pametni\" rsync, presko\u010div\u0161i mnogo toga \u0161to se ne mora gledati, jer se tu zapravo ni\u0161ta nije promijenilo. Mo\u017eemo brzo sinkronizirati izme\u0111u dva poslu\u017eitelja i vratiti se unazad na isti na\u010din.<\/i><\/p>\n

Dakle, nastojimo s ove, DBA strane, stvoriti alat koji omogu\u0107ava ono o \u010demu si govorio: imamo jednu bazu, ali \u017eelimo 50 puta ne\u0161to testirati, gotovo istovremeno.<\/i><\/p>\n

\u0414\u0421<\/b>: 50 puta zna\u010di da trebate naru\u010diti 50 Spot instanci.<\/p>\n

\u041d\u0421<\/b>: Ne, sve radimo na jednom stroju.<\/i><\/p>\n

\u0414\u0421<\/b>: Kako \u0107ete rasporediti 50 puta, ako je ta jedna baza, recimo, terabajtna? Vjerojatno joj treba, uvjetno re\u010deno, 256 GB RAM-a?<\/p>\n

\u041d\u0421<\/b>: Da, ponekad je potrebno puno memorije \u2014 to je normalno. Ali evo primjera iz stvarnog \u017eivota. Na produkcijskom stroju imamo 96 jezgri i 600 GB. Pri tome za bazu podataka koristi 32 jezgre (\u010dak i 16 jezgra ponekad) i 100-120 GB memorije.<\/i><\/p>\n

\u0414\u0421<\/b>: I stane li 50 kopija tamo?<\/p>\n

\u041d\u0421<\/b>: Stvar je u tome da je kopija samo jedna, a dalje se koristi copy-on-write (ZFS-ov)... Opisat \u0107u detaljnije.<\/i><\/p>\n

Na\u0161a baza, primjerice, ima 10 TB. Disk za nju je napravljen, a ZFS je smanjio njezinu veli\u010dinu za 30-40%. Budu\u0107i da ne radimo optere\u0107enja testiranja, to\u010dno vrijeme odziva nam nije va\u017eno: neka bude do 2 puta sporije \u2014 to je u redu.<\/i><\/p>\n

Dajemo mogu\u0107nost programerima, QA-ovima, DBA-ima i sli\u010dno da provode testiranje u 1-2 toka. Na primjer, mogu pokrenuti neku migraciju. Ne zahtijeva odmah 10 jezgri \u2014 potrebna joj je 1 pozadinska Postgres instanca, 1 jezgra. Migracija \u0107e se pokrenuti \u2014 mo\u017eda, autovacuum<\/a><\/noindex> mo\u017eda \u0107e se jo\u0161 pokrenuti, tada \u0107e druga jezgra biti uklju\u010dena. Imamo dodijeljeno 16-32 jezgri, tako da 10 ljudi mo\u017ee raditi istovremeno, nema problema.<\/i><\/p>\n

Budu\u0107i da je fizi\u010dki PGDATA<\/code> ispadne isto, kako varamo Postgres zapravo. Fora je u tome: pokre\u0107e se, na primjer, 10 Postgres instanci istovremeno. Obi\u010dno koja je problem? Postavljaju shared_buffers<\/a><\/noindex>, recimo, na 25%. Tako da je to 200 GB. Vi\u0161e od tri takva ne mo\u017ee se pokrenuti, jer \u0107e memorija ponestati.<\/i><\/p>\n

Ali shvatili smo u nekom trenutku da to nije potrebno: postavljamo shared_buffers na 2 GB. PostgreSQL ima effective_cache_size<\/a><\/noindex>, i zapravo samo on utje\u010de na planove<\/a><\/noindex>. To postavljamo na 0,5 TB. I nije ni va\u017eno \u0161to ih zapravo nema: gradi planove kao da postoje.<\/i><\/p>\n

Prema tome, kada testiramo neku migraciju, mo\u017eemo prikupiti sve planove \u2014 vidjet \u0107emo kako \u0107e se odvijati na produkciji. Sekunde \u0107e biti druga\u010dije (sporije), ali podaci koje stvarno o\u010ditavamo i sami planovi (koji JOIN-ovi itd.) ispadaju to\u010dno isti kao na produkciji. I paralelno mo\u017eemo pokrenuti mnoge takve provjere na jednoj ma\u0161ini.<\/i><\/p>\n

\u0414\u0421<\/b>: Ne misli\u0161 li da ovdje postoji nekoliko problema? Prvi je da ovo rje\u0161enje funkcioni\u0161e samo na PostgreSQL-u. Takav pristup je veoma specifi\u010dan, nije op\u0107enit. Drugi je da Kubernetes (i sve \u0161to se sada odvija u oblaku) predvi\u0111a mno\u0161tvo \u010dvorova, a ti \u010dvorovi su efemerni. A u tvom slu\u010daju to je stateful, perzistentni \u010dvor. Ove stvari mi stvaraju nesuglasice.<\/p>\n

\u041d\u0421<\/b>: Prvo \u2014 sla\u017eem se, ovo je isklju\u010divo Postgresova pri\u010da. Mislim da ako imamo neki direct IO i memorijski bafer gotovo pod svom memorijom, takav pristup ne\u0107e odgovarati \u2014 planovi \u0107e biti druga\u010diji. Ali trenutno radimo samo s Postgresom, ne razmi\u0161ljamo o drugima.<\/i><\/p>\n

O Kubernetesu. Pa ti sam svuda govori\u0161 da imamo perzistentnu bazu. Ako instanca padne, najva\u017enije je sa\u010duvati disk. Tako je i na\u0161a cijela platforma u Kubernetesu, a komponenta s Postgresom je odvojeno (iako \u0107e i ona jednom biti tu). Zato je sve tako: instanca je pala, ali smo sa\u010duvali njen PV i jednostavno je priklju\u010dili drugoj (novoj) instanci, kao da se ni\u0161ta nije dogodilo.<\/i><\/p>\n

\u0414\u0421<\/b>: Sa svog stajali\u0161ta, stvaramo pod-ove u Kubernetesu. K8s je elasti\u010dan: \u010dvorovi se naru\u010duju sami prema potrebi. Zadatak je jednostavno stvoriti pod i re\u0107i mu da mu je potrebno X resursa, a dalje \u0107e K8s sam rije\u0161iti. No, podr\u0161ka za skladi\u0161ta u Kubernetesu jo\u0161 uvijek je nestabilna: u 1.16<\/a><\/noindex>, u 1.17<\/a><\/noindex> (ova verzija je objavljena nedjelja<\/i> natrag) ove funkcije postaju samo beta.<\/p>\n

Pro\u0107i \u0107e pola godine do godinu dana - postat \u0107e vi\u0161e-manje stabilno, ili \u0107e barem biti tako deklarirano. Tada mogu\u0107nost snimanja i promjene veli\u010dine potpuno rje\u0161ava va\u0161 problem. Zato \u0161to imate bazu. Da, mo\u017eda ne\u0107e biti jako brza, ali brzina ovisi o tome \u0161to je \"ispod haube\", jer neke implementacije znaju kopirati i koristiti copy-on-write na razini diskovnog podsustava.<\/p>\n

\u041d\u0421<\/b>: Tako\u0111e, potrebno je da svi motori (Amazon, Google\u2026) stignu po\u010deti podr\u017eavati ovu verziju \u2014 to tako\u0111e zahteva neko vreme.<\/i><\/p>\n

\u0414\u0421<\/b>: Za sada ih ne koristimo. Koristimo svoje.<\/p>\n

Lokalni razvoj pod Kubernetesom<\/h2>\n

\n\u041d\u0421<\/b>: Da li si se susreo s takvom potrebom kada treba\u0161 pokrenuti sve podove na jednom stroju i napraviti malo testiranje. Da bi brzo dobio proof of concept, pogledao da li aplikacija radi u Kubernetesu, a da ne treba\u0161 posvetiti hrpu strojeva za to. Ima Minikube, zar ne?<\/i><\/p>\n

\u0414\u0421<\/b>: \u010cini mi se da je ovaj slu\u010daj \u2014 pokrenuti na jednom \u010dvoru \u2014 isuvi\u0161e usko vezan za lokalni razvoj. Ili neka manifestacija tog obrasca. Postoji Minikube<\/a><\/noindex>, postoji k3s<\/a><\/noindex>, (Kubernetes IN Docker) i<\/a><\/noindex>. Idemo ka tome da \u0107emo koristiti Kubernetes u Dockeru. Sada smo po\u010deli raditi s njim za testove.<\/p>\n

\u041d\u0421<\/b>: Nekad sam mislio da je to poku\u0161aj omotati sve podove u jedan Docker-sliku. No, ispostavilo se da se radi o ne\u010demu sasvim drugom. I dalje su tu odvojeni kontejneri, odvojeni podovi \u2014 samo u Dockeru.<\/i><\/p>\n

\u0414\u0421<\/b>: Da. I tu je prili\u010dno zabavna imitacija napravljena, ali smisao je takav\u2026 Imamo alat za deploy \u2014 werf<\/a><\/noindex>. \u017delimo u njemu napraviti re\u017eim \u2014 uvjetno werf up<\/code>: \u00abPodigni mi lokalni Kubernetes\u00bb. A zatim pokrenuti neki werf follow<\/code>. Tada \u0107e developer mo\u0107i ure\u0111ivati u IDE-u, dok je u sustavu pokrenut proces koji prati promjene i ponovo sastavlja slike, redeploya ih u lokalni K8s. Tako \u017eelimo poku\u0161ati rije\u0161iti problem lokalnog razvoja.<\/p>\n

Snapshoti i kloniranje Baze podataka u stvarima K8s<\/h2>\n

\n\u041d\u0421<\/b>: Ako se vratimo na copy-on-write. Primijetio sam da oblak tako\u0111er ima snimke. One funkcioni\u0161u razli\u010dito. Na primjer, u GCP-u: ima\u0161 vi\u0161eterabitski instancu na isto\u010dnoj obali SAD-a. Povremeno pravi\u0161 snimke. Podigne\u0161 kopiju diska iz snimke na zapadnoj obali - za nekoliko minuta je sve spremno, radi vrlo brzo, samo treba napuniti predmemoriju u memoriji. No, ti klonovi (snimke) su tu da se \"provisiona\" novi volumen. To je super kada treba\u0161 stvoriti puno instanci.<\/i><\/p>\n

A za testove, \u010dini mi se da snimke o kojima ti pri\u010da\u0161 u Dockeru ili ja pri\u010dam u ZFS-u, btrfs-u, pa \u010dak i LVM-u... - omogu\u0107uju da na jednom stroju ne generira\u0161 stvarne nove podatke. U oblaku \u0107e\u0161 ih svaki put morati pla\u0107ati i \u010dekati ve\u0107 ne sekunde, nego minute (a u slu\u010daju lazy load-a<\/a><\/noindex>, mo\u017eda i sate).<\/i><\/p>\n

Umjesto toga, te podatke mo\u017ee\u0161 dobiti za jednu-dvije sekunde, provesti test i odbaciti. Ti snapshotovi rje\u0161avaju razli\u010dite zadatke. U prvom slu\u010daju \u2014 da se skalira\u0161 i dobije\u0161 nove replikate, a u drugom \u2014 za testove.<\/i><\/p>\n

\u0414\u0421<\/b>: Ne sla\u017eem se. Ispravno kloniranje volumena je zadatak za oblak. Nisam gledao njihovu implementaciju, ali znam kako to radimo na hardveru. Imamo Ceph, u njemu mo\u017eemo bilo kojem fizi\u010dkom volumenu (RBD<\/a><\/noindex>) re\u0107i clone<\/i> i dobiti u desetinama milisekundi drugi volumen s istim karakteristikama, IOPS<\/a><\/noindex>i sli\u010dno. Treba razumjeti da unutra postoji pametan copy-on-write. Za\u0161to oblak ne bi radio isto? Siguran sam da oni to na ovaj ili onaj na\u010din poku\u0161avaju ostvariti.<\/p>\n

\u041d\u0421<\/b>: Ali \u0107e im ipak trebati sekunde, deseci sekundi da pokrenu instancu, postave Docker itd.<\/i><\/p>\n

\u0414\u0421<\/b>: Za\u0161to bi nu\u017eno morali pokretati cijelu instancu? Imamo instancu sa 32 jezgra, na 16\u2026 i u nju stane odre\u0111eni broj \u2014 na primjer, \u010detiri. Kada naru\u010dimo petu, instanca \u0107e se ve\u0107 pokrenuti, a zatim \u0107e se obrisati.<\/p>\n

\u041d\u0421<\/b>: Da, zanimljivo, u Kubernetesu je druga\u010dija pri\u010da. Na\u0161a baza podataka nije u K8s, i imamo jednu instancu. Ipak, za kloniranje vi\u0161eterabajtne baze ne treba vi\u0161e od dvije sekunde.<\/i><\/p>\n

\u0414\u0421<\/b>: To je sjajno. Ali moja izvorna ideja je da to nije generi\u010dko rje\u0161enje. Da, super je, ali odgovara samo Postgresu i samo na jednom \u010dvoru.<\/p>\n

\u041d\u0421<\/b>: Nije samo za Postgres: to su planovi, kao \u0161to sam opisivao, radit \u0107e samo u njemu. No, ako se ne zamaram planovima, a jednostavno trebamo sve podatke za funkcionalno testiranje, tada \u0107e to odgovarati svakoj bazi podataka.<\/i><\/p>\n

\u0414\u0421<\/b>: Prije mnogo godina radili smo sli\u010dno na LVM snapshotima. To je klasika. Ovaj pristup je bio vrlo aktivno kori\u0161ten. Jednostavno, stateful \u010dvorovi su bol. Jer ih ne smije\u0161 ispustiti, uvijek ih se treba sjetiti\u2026<\/p>\n

\u041d\u0421<\/b>: Ne vidi\u0161 li ovdje neku mogu\u0107nost hibrida? Recimo, stateful \u2014 to je neki pod, radi na nekoliko ljudi (vi\u0161e testera). Imamo jedan volumen, ali zahvaljuju\u0107i datote\u010dnom sustavu klonovi su lokalni. Ako pod padne, disk ostaje \u2014 pod \u0107e se ponovo pokrenuti, zabilje\u017ei informacije o svim klonovima, sve \u0107e ponovno podi\u0107i i re\u0107i: \u201eEvo va\u0161i klonovi na ovim portovima su pokrenuti, radite s njima dalje\u201c.<\/i><\/p>\n

\u0414\u0421<\/b>: Tehni\u010dki, to zna\u010di da unutar Kubernetes-a postoji jedan pod, unutar kojeg pokre\u0107emo mnogo Postgres-a.<\/p>\n

\u041d\u0421<\/b>: Da. Ima ograni\u010denje: recimo, istovremeno s njim radi ne vi\u0161e od 10 osoba. Ako treba 20 \u2014 pokrenut \u0107emo drugi takav pod. Potpuno je realno klonirati ga, dobivaju\u0107i drugi puni volumen, na njemu \u0107e biti isti 10 \u201etankih\u201c klonova. Ne vidi\u0161 tu mogu\u0107nost?<\/i><\/p>\n

\u0414\u0421<\/b>: Treba dodati pitanja o sigurnosti ovdje. Ova organizacija podrazumijeva da ovaj pod ima visoke privilegije (capabilities), jer mo\u017ee izvoditi nestandardne operacije nad datote\u010dnim sustavom... No ponavljam: smatram da \u0107e u srednjoro\u010dnom razdoblju Kubernetes popraviti storage, u obla\u010dnim okru\u017eenjima \u0107e rije\u0161iti cijelu pri\u010du s volumenima \u2014 sve \u0107e jednostavno raditi. Bit \u0107e resize, kloniranje... Postoji volumen \u2014 ka\u017eemo: \u00abStvori novi temeljen na tome\u00bb, \u2014 i za ne\u0161to vi\u0161e od jedne sekunde dobivamo \u0161to trebamo.<\/p>\n

\u041d\u0421<\/b>: Ne vjerujem u sekundu i pol za mnogo terabajta. Na Cephu to radi\u0161 sam, a govori\u0161 o oblacima. Idi u oblak, na EC2 napravi klon volumena EBS od vi\u0161e terabajta i vidi kakva \u0107e biti izvedba. To ne\u0107e trajati nekoliko sekundi. Zanimljivo mi je kada \u0107e do\u0107i do takvog mjera. Razumijem o \u010demu govori\u0161, ali \u0107u se usuditi ne slo\u017eiti.<\/i><\/p>\n

\u0414\u0421<\/b>: U redu, ali rekao sam da u srednjoro\u010dnom razdoblju, ne kratkoro\u010dnom. Tijekom nekoliko godina.<\/p>\n

O operatoru za PostgreSQL od Zalanda<\/h2>\n

\nSredinom ovog sastanka pridru\u017eio se i Aleksej Kljukin, biv\u0161i programer iz kompanije Zalando, koji je ispri\u010dao povijest operatora PostgreSQL:<\/p>\n

Sjajno je da je ova tema uop\u0107e spomenuta: i Postgres, i Kubernetes. Kada smo po\u010deli raditi na tome u Zalandu 2017. godine, to je bila tema kojom su svi \u017eeljeli baviti, ali nitko nije radio. Svi su ve\u0107 imali Kubernetes, ali kada se pitamo kako biti s bazama podataka, \u010dak su i takvi ljudi kao Kelsey Hightower<\/a><\/noindex>, koji su propovijedali K8s, govorili otprilike sljede\u0107e:<\/p>\n

\u201eIdite na managed usluge i koristite ih, ne pokre\u0107ite BDP u Kubernetesu. Ina\u010de \u0107e va\u0161 K8s odlu\u010diti, na primjer, napraviti nadogradnju, ugasiti sve \u010dvorove i va\u0161i podaci \u0107e odletjeti daleko.\u201d<\/i><\/p>\n

Odlu\u010dili smo napraviti operator koji \u0107e, unato\u010d ovom savjetu, pokretati BDP PostgreSQL u Kubernetesu. I imali smo dobru osnovu \u2014 Patroni<\/a><\/noindex>. Ovo je automatski failover za PostgreSQL, napravljen ispravno, tj. koriste\u0107i etcd, consul ili ZooKeeper kao skladi\u0161te informacija o klasteru. Takvo skladi\u0161te koje \u0107e svakome tko pita, primjerice, tko je sada vo\u0111a, dati istu informaciju \u2014 bez obzira na to \u0161to je sve distribuirano \u2014 kako ne bi do\u0161lo do split brain-a. Osim toga, imali smo Docker-sliku<\/a><\/noindex> za njega.<\/p>\n

Ustvari, potreba za automatskim failoverom pojavila se nakon migracije iz unutarnjeg hardverskog data centra u oblak. Oblak je bio temeljen na vlastitom PaaS (Platform-as-a-Service) rje\u0161enju. Bilo je Open Source, ali da bi ga podigli, trebalo je puno truda. Zvalo se STUPS<\/a><\/noindex>.<\/p>\n

Isprva nije bilo nikakvog Kubernetes-a. Odnosno, kada se razra\u0111ivalo vlastito rje\u0161enje, K8s je ve\u0107 bio tu, ali toliko sirov da nije bio prikladan za proizvodnju. Mislim da je to bilo 2015. ili 2016. godine. Do 2017. godine Kubernetes je postao vi\u0161e-manje zreo \u2014 pojavila se potreba za migracijom tamo.<\/p>\n

Ve\u0107 smo imali Docker kontejner. Postojala je PaaS koja je koristila Docker. Za\u0161to ne probati K8s? Za\u0161to ne napisati svog operatera? Murat Kabilov, koji nam se pridru\u017eio iz Avita, zapo\u010deo je to kao projekat iz vlastite inicijative \u2014 \"da se zabavi\" \u2014 i projekat je \"poletio\".<\/p>\n

Ali generalno, \u017eeleo sam da pri\u010dam o AWS-u. Za\u0161to je istorijski imao kod povezan sa AWS-om...<\/p>\n

Kada pokre\u0107ete ne\u0161to u Kubernetes-u, morate razumeti da je K8s u stalnom razvoju. Neprestano se unapre\u0111uje, a povremeno se \u010dak i pokvari. Uvek treba pa\u017eljivo pratiti sve promene u Kubernetes-u, morate biti spremni da se u slu\u010daju potrebe upustite u njega i saznate kako sve funkcioni\u0161e u detalje \u2014 verovatno vi\u0161e nego \u0161to biste \u017eeleli. To je, zapravo, slu\u010daj sa svakom platformom na kojoj pokre\u0107ete svoje baze podataka...<\/p>\n

Dakle, kada smo pravili operatera, imali smo Postgres koji je radio sa spolja\u0161njim volumenom (u ovom slu\u010daju \u2014 EBS, jer smo radili u AWS-u). Baza podataka se \u0161irila, i u nekom trenutku se javila potreba da se izvr\u0161i resize: na primer, prvi veli\u010dina EBS-a bila je 100 TB, baza je dostigla tu veli\u010dinu, sada \u017eelimo da napravimo EBS od 200 TB. Kako? Recimo, mo\u017ee se napraviti dump\/restore na novom instance, ali to traje dugo i dolazi do zastoja.<\/p>\n

Zato smo \u017eeljeli takav resize koji \u0107e pove\u0107ati EBS particiju i potom re\u0107i datote\u010dnom sustavu da koristi novi prostor. I to smo u\u010dinili, ali to vrijeme Kubernetes nije imao nikakav API za operaciju resize-a. Budu\u0107i da smo radili na AWS-u, napisali smo kod za njegov API.<\/p>\n

Niko ne spre\u010dava da se isto uradi i za druge platforme. U operateru nema zavisnosti da se mo\u017ee pokrenuti samo na AWS-u, a na svemu ostalom ne\u0107e raditi. U su\u0161tini, ovo je Open Source projekat: ako neko \u017eeli ubrzati kori\u0161\u0107enje novog API-ja \u2014 slobodno. GitHub<\/a><\/noindex>, pull-zahtjevi \u2014 tim Zalanda se trudi da na njih brzo odgovara i unaprijedi operatera. Koliko znam, projekt je sudjelovao<\/a><\/noindex> u Google Summer of Code i nekim drugim sli\u010dnim inicijativama. Zalando aktivno radi na tome.\n<\/p><\/blockquote>\n

<\/p>\n

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

\nAko vas zanima tema PostgreSQL i Kubernetes, skre\u0107emo pa\u017enju da je pro\u0161log tjedna odr\u017ean sljede\u0107i Postgres-vtorak, gdje je s Nikolajem razgovarao Aleksandar Kuku\u0161kin iz Zalanda<\/b>. Video s doga\u0111aja je dostupan ovdje<\/a><\/noindex>.<\/p>\n

P.S.<\/h2>\n

\nPro\u010ditajte i na na\u0161em blogu:<\/p>\n