{"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\/sq\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-e mart\u00eb Nr. 5: \"PostgreSQL dhe Kubernetes. CI\/CD. Automatizimi i testimit\"","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-e
\n
\nN\u00eb fund t\u00eb vitit t\u00eb kaluar u mbajt nj\u00eb tjet\u00ebr transmetim t\u00eb drejtp\u00ebrdrejt\u00eb t\u00eb komunitetit rus t\u00eb PostgreSQL, #RuPostgres<\/a><\/noindex>, n\u00eb kuad\u00ebr t\u00eb t\u00eb cilit bashk\u00ebthemeluesi i tij Nikolai Samokhvalov fliste me drejtorin teknik t\u00eb \u00abFlanta\u00bb, Dmitry Stolyarov, p\u00ebr k\u00ebt\u00eb SGBD n\u00eb kontekstin e Kubernetes.<\/p>\n

Ne publikojm\u00eb transkriptin e pjes\u00ebs kryesore t\u00eb k\u00ebsaj diskusione, dhe n\u00eb kanalin YouTube t\u00eb komunitetit<\/a><\/noindex> \u00ebsht\u00eb publikuar regjistrimi i plot\u00eb video:<\/a><\/noindex><\/p>\n

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

Baza t\u00eb dh\u00ebnash dhe Kubernetes<\/h2>\n

\nNS<\/b>: Nuk do flasim sot p\u00ebr VACUUM dhe CHECKPOINT\u00ebt. Duam t\u00eb flasim p\u00ebr Kubernetes. E di q\u00eb ke shum\u00eb vite p\u00ebrvoj\u00eb. I kam par\u00eb videot e tua dhe disa madje i kam p\u00ebrs\u00ebritur... Le t\u00eb kalojm\u00eb direkt n\u00eb thelbin: p\u00ebrse Postgres ose MySQL n\u00eb K8s?<\/i><\/p>\n

DS<\/b>: Nuk ka nj\u00eb p\u00ebrgjigje t\u00eb qart\u00eb p\u00ebr k\u00ebt\u00eb pyetje dhe nuk mund t\u00eb ket\u00eb. Por n\u00eb p\u00ebrgjith\u00ebsi, \u00ebsht\u00eb thjesht\u00ebsi dhe komoditet\u2026 potenciale. T\u00eb gjith\u00eb duan sh\u00ebrbime t\u00eb menaxhuara.<\/p>\n

NS<\/b>: Q\u00eb si RDS<\/a><\/noindex>, vet\u00ebm n\u00eb sht\u00ebpi?<\/i><\/p>\n

DS<\/b>: Po: q\u00eb si RDS, vet\u00ebm kudo.<\/p>\n

NS<\/b>: \u00abKudo\u00bb \u2014 kjo \u00ebsht\u00eb nj\u00eb v\u00ebrejtje e mir\u00eb. N\u00eb kompanit\u00eb e m\u00ebdha, gjith\u00e7ka \u00ebsht\u00eb e shp\u00ebrndar\u00eb n\u00eb vende t\u00eb ndryshme. Pse at\u00ebher\u00eb, n\u00ebse \u00ebsht\u00eb nj\u00eb kompani e madhe, t\u00eb mos marr\u00ebsh nj\u00eb zgjidhje t\u00eb gatshme? P\u00ebr shembull, Nutanix ka zhvillimet e veta, kompanit\u00eb e tjera (VMware\u2026) kan\u00eb gjithashtu \u00abRDS, vet\u00ebm n\u00eb sht\u00ebpi\u00bb.<\/i><\/p>\n

DS<\/b>: Por po flasim p\u00ebr nj\u00eb implementim t\u00eb ve\u00e7ant\u00eb, i cili do t\u00eb funksionoj\u00eb vet\u00ebm n\u00eb kushte t\u00eb caktuara. Kur flasim p\u00ebr Kubernetes, ka nj\u00eb shum\u00ebllojshm\u00ebri t\u00eb madhe infrastrukture (e cila mund t\u00eb jet\u00eb n\u00eb K8s). N\u00eb thelb, kjo \u00ebsht\u00eb nj\u00eb standard p\u00ebr API p\u00ebr cloud\u2026<\/p>\n

NS<\/b>: Dhe gjithashtu falas!<\/i><\/p>\n

DS<\/b>: Kjo nuk \u00ebsht\u00eb aq e r\u00ebnd\u00ebsishme. Falas p\u00ebrb\u00ebn nj\u00eb segment t\u00eb vog\u00ebl t\u00eb tregut. E r\u00ebnd\u00ebsishme \u00ebsht\u00eb di\u00e7ka tjet\u00ebr\u2026 Ti, ndoshta, e mban mend prezantiminBaza t\u00eb dh\u00ebnash dhe Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

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

DS<\/b>: E kuptova q\u00eb u perceptua shum\u00eb n\u00eb m\u00ebnyra t\u00eb ndryshme. Disa njer\u00ebz menduan se po thosha: \u201cDjem, shkojm\u00eb me t\u00eb gjitha DB n\u00eb Kubernetes!\u201d, - kurse t\u00eb tjer\u00ebt menduan se ishin vet\u00ebm bi\u00e7ikleta t\u00eb tmerrshme. Por un\u00eb doja t\u00eb flisja p\u00ebr nj\u00eb gj\u00eb tjet\u00ebr: \u201cShikoni, \u00e7far\u00eb po ndodh, cilat jan\u00eb problemet dhe si mund t'i zgjidhim. A \u00ebsht\u00eb koha p\u00ebr t\u00eb shkuar me databaza n\u00eb Kubernetes? N\u00eb prodhim? Vet\u00ebm n\u00ebse d\u00ebshironi\u2026 t\u00eb merret me gj\u00ebra t\u00eb caktuara. Por p\u00ebr dev-in, mund t\u00eb them q\u00eb e rekomandoj. P\u00ebr dev-in, dinamizmi n\u00eb krijimin\/fshirjen e mjediseve \u00ebsht\u00eb shum\u00eb i r\u00ebnd\u00ebsish\u00ebm.\u201d<\/p>\n

\u041d\u0421: Po me dev-in ke parasysh t\u00eb gjitha mjediset q\u00eb nuk jan\u00eb prodhim? Staging, QA\u2026<\/i><\/p>\n

DS<\/b>: N\u00ebse flasim p\u00ebr performanc\u00ebn, ndoshta jo, sepse aty k\u00ebrkesat jan\u00eb specifike. N\u00ebse flasim p\u00ebr raste t\u00eb ve\u00e7anta, ku n\u00eb staging duhet nj\u00eb DB shum\u00eb e madhe, at\u00ebher\u00eb ndoshta ashtu\u2026 N\u00ebse \u00ebsht\u00eb nj\u00eb ambient statik, afatgjat\u00eb, cila \u00ebsht\u00eb p\u00ebrfitimi q\u00eb DB \u00ebsht\u00eb n\u00eb K8s?<\/p>\n

NS<\/b>: Asnj\u00eb. Por ku i shohim ambientet statike? Ambientet statike kan\u00eb skaduar tashm\u00eb nes\u00ebr.<\/i><\/p>\n

DS<\/b>: Staging mund t\u00eb jet\u00eb statik. Ne kemi klient\u00eb\u2026<\/p>\n

NS<\/b>: Po, kam edhe un\u00eb. \u00cbsht\u00eb nj\u00eb problem i madh, n\u00ebse ke nj\u00eb DB me 10 Tb, nd\u00ebrsa staging \u2014 200 Gb\u2026<\/i><\/p>\n

DS<\/b>: Kam nj\u00eb rast shum\u00eb t\u00eb mrekulluesh\u00ebm! N\u00eb staging ndodhet baza e prodhimit, n\u00eb t\u00eb cil\u00ebn b\u00ebhen ndryshime. Dhe \u00ebsht\u00eb parashikuar nj\u00eb buton: \u201cdergo n\u00eb prodhim\u201d. K\u00ebto ndryshime \u2014 delta \u2014 shkarkohen (mendoi, thjesht sinkronizohen p\u00ebrmes API-t) n\u00eb prodhim. Ky \u00ebsht\u00eb nj\u00eb variant shum\u00eb eksotik.<\/p>\n

NS<\/b>: Kam par\u00eb startup-e n\u00eb Lugin\u00ebn q\u00eb jan\u00eb ende n\u00eb RDS ose madje n\u00eb Heroku \u2014 jan\u00eb histori 2-3-vje\u00e7are \u2014 dhe ata shkarkojn\u00eb dump n\u00eb laptop. Sepse baza \u00ebsht\u00eb vet\u00ebm 80 GB, dhe n\u00eb laptop ka hap\u00ebsir\u00eb. Pastaj ata blejn\u00eb disqe p\u00ebr secilin, q\u00eb t\u00eb ken\u00eb 3 baza p\u00ebr t\u00eb b\u00ebr\u00eb zhvillime t\u00eb ndryshme. K\u00ebshtu ndodhin edhe k\u00ebto gj\u00ebra. Kam par\u00eb gjithashtu q\u00eb nuk kan\u00eb frik\u00eb t\u00eb kopjojn\u00eb prodhimin n\u00eb staging \u2014 shum\u00eb varion nga kompania. Por kam par\u00eb q\u00eb shum\u00eb frik\u00ebsohen, dhe shpesh her\u00eb u mungon koha e duhur. Por para se t\u00eb kalojm\u00eb n\u00eb k\u00ebt\u00eb tem\u00eb, jam kurioz p\u00ebr Kubernetes. E kuptoj sakt\u00eb q\u00eb n\u00eb prodhim nuk ka askush?<\/i><\/p>\n

DS<\/b>: Ne kemi disa baza t\u00eb vogla n\u00eb prodhim. B\u00ebhet fjal\u00eb p\u00ebr volume n\u00eb dhjet\u00ebra gigabajt dhe sh\u00ebrbime q\u00eb nuk jan\u00eb kritike, p\u00ebr t\u00eb cilat ishte len\u00eb t\u00eb b\u00ebhet kopje (as nuk ka nj\u00eb nevoj\u00eb t\u00eb till\u00eb). Dhe me kushtin q\u00eb n\u00ebn Kubernetes ka nj\u00eb ruajtje t\u00eb mir\u00eb. Kjo baz\u00eb ka punuar n\u00eb nj\u00eb makin\u00eb virtuale \u2014 n\u00eb m\u00ebnyr\u00eb hipotetike n\u00eb VMware, mbi nj\u00eb sistem ruajtjeje. Ne e vendos\u00ebm n\u00eb PV<\/a><\/noindex> dhe tani mund ta transferojm\u00eb nga makina n\u00eb makin\u00eb.<\/p>\n

NS<\/b>: Baza t\u00eb k\u00ebtij madh\u00ebsie, deri n\u00eb 100 Gb, n\u00eb disqe t\u00eb mira dhe me nj\u00eb rrjet t\u00eb mir\u00eb mund t\u00eb shp\u00ebrndahet brenda disa minutash, e drejt\u00eb? Shpejt\u00ebsia prej 1 Gb n\u00eb sekond\u00eb \u2014 kjo nuk \u00ebsht\u00eb m\u00eb ekzotike.<\/i><\/p>\n

DS<\/b>: Po, p\u00ebr nj\u00eb operacion linear, kjo nuk \u00ebsht\u00eb problem.<\/p>\n

NS<\/b>: Okej, p\u00ebr prodhim duhet vet\u00ebm t\u00eb mendojm\u00eb. Por n\u00ebse e shqyrtojm\u00eb Kubernetes p\u00ebr ambientet jo-prodhuese \u2014 si ta b\u00ebjm\u00eb? Shikoj q\u00eb n\u00eb Zalando po b\u00ebjn\u00eb operator<\/a><\/noindex>, n\u00eb Crunchy po punojn\u00eb<\/a><\/noindex>, ka edhe disa mund\u00ebsi t\u00eb tjera. Dhe ka OnGres<\/a><\/noindex> \u2014 ky \u00ebsht\u00eb nj\u00eb mik yn\u00eb i mir\u00eb Alvaro nga Spanja: ata b\u00ebjn\u00eb p\u00ebrfundimisht jo vet\u00ebm operatori<\/a><\/noindex>, por nj\u00eb distribucion t\u00eb t\u00ebr\u00eb (StackGres<\/a><\/noindex>), n\u00eb t\u00eb cilin p\u00ebrve\u00e7 Postgres-it kemi vendosur edhe nj\u00eb backup, proxy Envoy...<\/i><\/p>\n

DS<\/b>: Envoy p\u00ebr \u00e7far\u00eb? P\u00ebr balancimin e trafikut pik\u00ebrisht Postgres?<\/p>\n

NS<\/b>: Po, ato ata e shohin si: n\u00ebse marrim nj\u00eb distribuim t\u00eb Linux-it dhe kernelin, at\u00ebher\u00eb PostgreSQL-i i zakonsh\u00ebm \u00ebsht\u00eb kernel, dhe ata duan t\u00eb krijojn\u00eb nj\u00eb distribucion q\u00eb do t\u00eb jet\u00eb miq\u00ebsor me cloud-in dhe do t\u00eb funksionoj\u00eb n\u00eb Kubernetes. Ata lidhen me komponent\u00ebt (backup-et etj.) dhe i testojn\u00eb q\u00eb t\u00eb funksionojn\u00eb mir\u00eb.<\/i><\/p>\n

DS<\/b>: Shum\u00eb super! N\u00eb thelb, kjo \u00ebsht\u00eb nj\u00eb soft q\u00eb krijon PostgreSQL t\u00eb menaxhuar.<\/p>\n

NS<\/b>: Distribuimet e Linux-it kan\u00eb probleme t\u00eb vazhdueshme: si t\u00eb b\u00ebjn\u00eb drejtuese q\u00eb t\u00eb mb\u00ebshtetet \u00e7do hardware. Dhe ata kan\u00eb iden\u00eb q\u00eb do t\u00eb punojn\u00eb n\u00eb Kubernetes. E di q\u00eb n\u00eb operatorin Zalando, s\u00eb fundmi, kemi par\u00eb lidhje me AWS dhe kjo nuk \u00ebsht\u00eb shum\u00eb mir\u00eb. Nuk duhet t\u00eb ket\u00eb lidhje me nj\u00eb infrastruktur\u00eb t\u00eb ve\u00e7ant\u00eb \u2014 \u00e7far\u00eb ka kuptim at\u00ebher\u00eb?<\/i><\/p>\n

DS<\/b>: Nuk e di, n\u00eb cil\u00ebn situat\u00eb konkretisht Zalando u lidh, por n\u00eb Kubernetes tani storage \u00ebsht\u00eb b\u00ebr\u00eb k\u00ebshtu q\u00eb nuk mund t\u00eb merret nj\u00eb backup diskesh n\u00eb m\u00ebnyr\u00eb generike. S\u00eb fundmi, n\u00eb standard, n\u00eb versionin m\u00eb t\u00eb fundit specifikacioni CSI<\/a><\/noindex> \u2014 krijoi mund\u00ebsin\u00eb e snapshot-eve, por ku \u00ebsht\u00eb realizuar? Sinqerisht, ende \u00ebsht\u00eb kaq n\u00eb fillim\u2026 Ne po provojm\u00eb CSI mbi AWS, GCE, Azure, vSphere, por sapo fillon ta p\u00ebrdor\u00ebsh, shihet se nuk \u00ebsht\u00eb ende gati.<\/p>\n

NS<\/b>: Prandaj, ndonj\u00ebher\u00eb duhet t\u00eb lidhemi me infrastruktur\u00ebn. Mendoj se kjo \u00ebsht\u00eb ende nj\u00eb faz\u00eb e hershme \u2014 problemet e rritjes. Pyetje: \u00e7far\u00eb do t\u00eb sugjeroje p\u00ebr fillestar\u00ebt q\u00eb duan t\u00eb provojn\u00eb PgSQL n\u00eb K8s? Cili operator, ndoshta?<\/i><\/p>\n

DS<\/b>: Problemi \u00ebsht\u00eb se Postgres p\u00ebr ne \u00ebsht\u00eb 3%. Ne kemi nj\u00eb list\u00eb shum\u00eb t\u00eb madhe t\u00eb softuerit t\u00eb ndrysh\u00ebm n\u00eb Kubernetes, nuk do ta p\u00ebrmend t\u00eb gjith\u00eb. P\u00ebr shembull, Elasticsearch. Ka shum\u00eb operator\u00eb: disa po zhvillohen aktivisht, t\u00eb tjer\u00eb - jo. Ne kemi p\u00ebrgatitur k\u00ebrkesat tona p\u00ebr at\u00eb q\u00eb duhet t\u00eb ket\u00eb nj\u00eb operator q\u00eb ta shohim seriozisht. N\u00eb operatorin p\u00ebr Kubernetes - jo n\u00eb \"operatorin, p\u00ebr t\u00eb b\u00ebr\u00eb di\u00e7ka n\u00eb kushtet e Amazon-it\"... N\u00eb fakt, ne p\u00ebrdorim n\u00eb m\u00ebnyr\u00eb mjaft masive (= pothuajse te t\u00eb gjith\u00eb klient\u00ebt) nj\u00eb operator t\u00eb vet\u00ebm - p\u00ebr Redis<\/a><\/noindex> (shpejt do t\u00eb publikojm\u00eb nj\u00eb artikull edhe p\u00ebr t\u00eb)<\/i>.<\/p>\n

NS<\/b>: Dhe p\u00ebr MySQL nuk ka? E di q\u00eb Percona\u2026 pasi ata tani merren me MySQL, MongoDB dhe PostgreSQL, ata duhet t\u00eb krijojn\u00eb nj\u00eb zgjidhje universale: p\u00ebr t\u00eb gjitha databazat, p\u00ebr t\u00eb gjitha ofruesit e cloud.<\/i><\/p>\n

DS<\/b>: Nuk kemi pasur koh\u00eb t\u00eb shohim operator\u00ebt p\u00ebr MySQL. P\u00ebr ne tani nuk \u00ebsht\u00eb fokusi kryesor. MySQL funksionon mir\u00eb n\u00eb standalone. Pse nj\u00eb operator, n\u00ebse mund t\u00eb thjesht nis\u00ebsh DBA\u2026 Mund t\u00eb startosh nj\u00eb kontejner Docker me Postgres, apo mund ta nis\u00ebsh thjesht.<\/p>\n

NS<\/b>: Edhe p\u00ebr k\u00ebt\u00eb ishte nj\u00eb pyetje. N\u00eb fakt pa operator?<\/i><\/p>\n

DS<\/b>: Po, n\u00eb 100% t\u00eb rasteve PostgreSQL yn\u00eb \u00ebsht\u00eb nisur pa operator. Deri tani k\u00ebshtu. Ne aktivisht p\u00ebrdorim operator p\u00ebr Prometheus, p\u00ebr Redis. Kemi n\u00eb planet t\u00eb gjejm\u00eb nj\u00eb operator p\u00ebr Elasticsearch \u2014 ai \u00ebsht\u00eb m\u00eb i r\u00ebnd\u00ebsish\u00ebm, sepse duam ta vendosim n\u00eb 100% t\u00eb rasteve n\u00eb Kubernetes. Po ashtu, si\u00e7 duam t\u00eb arrijm\u00eb t\u00eb vendosim gjithashtu MongoDB gjithmon\u00eb n\u00eb Kubernetes. K\u00ebtu dalin disa d\u00ebshira \u2014 ka nj\u00eb ndjesi se n\u00eb k\u00ebto raste mund t\u00eb b\u00ebhet di\u00e7ka. Dhe p\u00ebr Postgres, ne as nuk kemi par\u00eb. Sigurisht, e dim\u00eb p\u00ebr ekzistenc\u00ebn e variant\u00ebve t\u00eb ndrysh\u00ebm, por n\u00eb fakt ne kemi standalone.<\/p>\n

DB p\u00ebr testim n\u00eb Kubernetes<\/h2>\n

\nNS<\/b>: Le t\u00eb kalojm\u00eb te tema e testimit. Si t\u00eb implementosh ndryshimet n\u00eb baz\u00eb \u2014 nga perspektiva e DevOps. Ka mikrosh\u00ebrbime, shum\u00eb baza, gjithmon\u00eb di\u00e7ka po ndryshon diku. Si t\u00eb sigurosh nj\u00eb CI\/CD normal, p\u00ebr t\u00eb qen\u00eb gjith\u00e7ka n\u00eb rregull nga perspektiva e DB-s\u00eb. Cili \u00ebsht\u00eb qasja jote?<\/i><\/p>\n

DS<\/b>: Nuk mund t\u00eb ket\u00eb nj\u00eb p\u00ebrgjigje t\u00eb vetme. Ka disa parametra. E para \u2014 \u00ebsht\u00eb madh\u00ebsia e baz\u00ebs, q\u00eb ne duam t\u00eb implementojm\u00eb. Ti vet\u00eb e theke se n\u00eb kompanit\u00eb lidhen ndryshe me at\u00eb q\u00eb nj\u00eb kopje e baz\u00ebs prodhuese t\u00eb jet\u00eb n\u00eb dev dhe stage.<\/p>\n

NS<\/b>: Dhe n\u00eb kushte GDPR, mendoj se ata jan\u00eb gjithnj\u00eb e m\u00eb t\u00eb kujdessh\u00ebm\u2026 Mund t\u00eb them se n\u00eb Evrop\u00eb filluan t\u00eb gjobisin.<\/i><\/p>\n

DS<\/b>: Por shpeshher\u00eb mund t\u00eb shkruhet nj\u00eb soft q\u00eb b\u00ebn dump nga production dhe e obfuskon at\u00eb. K\u00ebshtu kemi t\u00eb dh\u00ebna prodhimi (snapshot, dump, kopjebinare\u2026), por ato jan\u00eb t\u00eb anonimizuara. N\u00eb vend t\u00eb k\u00ebsaj, mund t\u00eb jen\u00eb dhe skriptet e gjenerimit: k\u00ebto mund t\u00eb jen\u00eb fikstura ose thjesht nj\u00eb skript q\u00eb gjeneron nj\u00eb baz\u00eb t\u00eb madhe. Problemi \u00ebsht\u00eb: sa koh\u00eb duke krijuar imazhin baz\u00eb? Dhe sa koh\u00eb duhet p\u00ebr ta p\u00ebrdorur at\u00eb n\u00eb ambientin e nevojsh\u00ebm?<\/p>\n

Ne arrit\u00ebm n\u00eb nj\u00eb skem\u00eb: n\u00ebse klienti ka nj\u00eb grup t\u00eb dh\u00ebnash fikstura (versioni minimal i baz\u00ebs), at\u00ebher\u00eb si rregull p\u00ebrdorim ato. N\u00ebse flasim p\u00ebr ambientet review, kur ne krijuam branch-in, na u krijua nj\u00eb instanc\u00eb e aplikacionit \u2014 ne atje implementojm\u00eb nj\u00eb baz\u00eb t\u00eb vog\u00ebl. Por u arrit gjithashtu t\u00eb opsion<\/a><\/noindex>, kur nga production nj\u00eb her\u00eb n\u00eb dit\u00eb (nat\u00ebn) e b\u00ebjm\u00eb dump-in dhe e mbledhim mbi baz\u00ebn e tij Docker-kontainer me PostgreSQL dhe MySQL me k\u00ebto t\u00eb dh\u00ebna t\u00eb ngarkuara. N\u00ebse nga ky imazh duhen 50 her\u00eb t\u00eb b\u00ebhet baza, kjo b\u00ebhet mjaft thjesht dhe shpejt.<\/p>\n

NS<\/b>: Me kopjim t\u00eb thjesht\u00eb?<\/i><\/p>\n

DS<\/b>: T\u00eb dh\u00ebnat ruhen direkt n\u00eb imazhin Docker. Dometh\u00ebn\u00eb, ne kemi nj\u00eb imazh t\u00eb gatsh\u00ebm, le t\u00eb themi, 100 GB. Fal\u00eb shtresave n\u00eb Docker, ne mund t\u00eb sh\u00ebrbim shpejt k\u00ebt\u00eb imazh aq her\u00eb sa na nevojitet. Metoda \u00ebsht\u00eb e thjesht\u00eb, por funksionon mir\u00eb.<\/p>\n

NS<\/b>: M\u00eb pas, kur testoni, ndodhet brenda Docker-it, apo jo? Copy-on-write brenda Docker-it - heqim dhe fillojm\u00eb nga e para, gjith\u00e7ka \u00ebsht\u00eb mir\u00eb. Super! Dhe ju tashm\u00eb e p\u00ebrdorni k\u00ebt\u00eb?<\/i><\/p>\n

DS<\/b>: Prej nj\u00eb kohe.<\/p>\n

NS<\/b>: Ne po merremi me gj\u00ebra shum\u00eb t\u00eb ngjashme. Vet\u00ebm se ne nuk p\u00ebrdorim copy-on-write t\u00eb Docker-it, por ndonj\u00eb gj\u00eb tjet\u00ebr.<\/i><\/p>\n

DS<\/b>: Nuk \u00ebsht\u00eb generic. Por ai i Docker-it punon kudo.<\/p>\n

NS<\/b>: N\u00eb parim, po. Por ne gjithashtu kemi module, mund t\u00eb b\u00ebjm\u00eb modula t\u00eb ndryshme dhe t\u00eb punojm\u00eb me sisteme t\u00eb ndryshme skedar\u00ebsh. K\u00ebtu \u00ebsht\u00eb nj\u00eb moment. Ne nga ana e Postgres e shohim k\u00ebt\u00eb ndryshe. Tani e kam par\u00eb nga ana e Docker-it dhe pash\u00eb q\u00eb gjith\u00e7ka funksionon. Por n\u00ebse baza \u00ebsht\u00eb e madhe, p\u00ebr shembull, 1 TB, at\u00ebher\u00eb kjo tashm\u00eb \u00ebsht\u00eb e gjat\u00eb: dhe operacionet nat\u00ebn, dhe t\u00eb ngjesh gjith\u00e7ka n\u00eb Docker\u2026 Dhe n\u00ebse duhen 5 TB t\u00eb ngjeshen n\u00eb Docker\u2026 Apo gjith\u00e7ka \u00ebsht\u00eb n\u00eb rregull?<\/i><\/p>\n

DS<\/b>: \u00c7far\u00eb r\u00ebnd\u00ebsi ka: ato jan\u00eb bloba, thjesht biti dhe byte.<\/p>\n

NS<\/b>: R\u00ebnd\u00ebsia \u00ebsht\u00eb: e b\u00ebni k\u00ebt\u00eb p\u00ebrmes dump dhe restore?<\/i><\/p>\n

DS<\/b>: Absolutisht jo, m\u00ebnyrat e krijimit t\u00eb k\u00ebtij imazhi mund t\u00eb jen\u00eb t\u00eb ndryshme.<\/p>\n

NS<\/b>: P\u00ebr disa klient\u00eb, ne kemi b\u00ebr\u00eb q\u00eb n\u00eb vend t\u00eb gjenerimit t\u00eb rregullt t\u00eb imazhit t\u00eb baz\u00ebs, ne e mbajm\u00eb at\u00eb gjithmon\u00eb n\u00eb gjendje t\u00eb azhurnuar. Ai n\u00eb thelb \u00ebsht\u00eb nj\u00eb replik\u00eb, por t\u00eb dh\u00ebnat nuk i merr nga masteri drejtp\u00ebrdrejt, por p\u00ebrmes arkivit. Nj\u00eb arkiv binar, ku WAL-t\u00eb ngarkohen \u00e7do dit\u00eb, gjithashtu b\u00ebhen kopje rezerv\u00eb... K\u00ebto WAL-t\u00eb m\u00eb pas mb\u00ebrrijn\u00eb \u2014 me nj\u00eb vones\u00eb t\u00eb vog\u00ebl (n\u00eb t\u00eb v\u00ebrtet\u00eb 1-2 sekonda) \u2014 n\u00eb imazhin baz\u00eb. Nga aty ne klonojm\u00eb me \u00e7do m\u00ebnyr\u00eb \u2014 tani p\u00ebr tani si rregull p\u00ebrdorim ZFS.<\/i><\/p>\n

DS<\/b>: Por me ZFS jeni t\u00eb kufizuar n\u00eb nj\u00eb nyje.<\/p>\n

NS<\/b>: Po. Por ZFS ka gjithashtu nj\u00eb magji d\u00ebrgo<\/a><\/noindex>: me t\u00eb mund t\u00eb d\u00ebrgoni nj\u00eb snapshot dhe madje (k\u00ebt\u00eb nuk e kam testuar shum\u00eb p\u00ebrpara, por\u2026) mund t\u00eb d\u00ebrgoni dyt\u00eb mes dy PGDATA<\/code>. N\u00eb t\u00eb v\u00ebrtet\u00eb, ne kemi nj\u00eb mjet tjet\u00ebr, t\u00eb cilin nuk e kemi shqyrtuar shum\u00eb p\u00ebr k\u00ebto detyra. N\u00eb PostgreSQL ka pg_rewind<\/a><\/noindex>, i cili funksionon si nj\u00eb rsync \u201cinteligjent\u201d, q\u00eb shmang shum\u00eb nga ajo q\u00eb nuk \u00ebsht\u00eb e nevojshme t\u00eb shikohet, sepse atje nuk ka ndryshuar asgj\u00eb. Ne mund t\u00eb b\u00ebjm\u00eb nj\u00eb sinkronizim t\u00eb shpejt\u00eb mes dy server\u00ebve dhe t\u00eb kthehemi pas nj\u00eblloj.<\/i><\/p>\n

Pra, ne p\u00ebrpiqemi nga kjo an\u00eb m\u00eb DBA-t\u00eb, t\u00eb krijojm\u00eb nj\u00eb mjet q\u00eb lejon t\u00eb b\u00ebjm\u00eb t\u00eb nj\u00ebjt\u00ebn gj\u00eb p\u00ebr t\u00eb cil\u00ebn the more: ne kemi nj\u00eb baz\u00eb, por duam t\u00eb testojm\u00eb di\u00e7ka 50 her\u00eb, pothuajse nj\u00ebkoh\u00ebsisht.<\/i><\/p>\n

DS<\/b>: 50 her\u00eb do t\u00eb thot\u00eb se ju duhet t\u00eb porositni 50 instanca Spot.<\/p>\n

NS<\/b>: Jo, e b\u00ebjm\u00eb n\u00eb nj\u00eb makin\u00eb.<\/i><\/p>\n

DS<\/b>: Por si do ta zhvilloni 50 her\u00eb, n\u00ebse kjo nj\u00eb baz\u00eb, le t\u00eb themi, \u00ebsht\u00eb nj\u00eb terabajt? M\u00eb shum\u00eb se t\u00eb pakt\u00ebn 256 GB RAM?<\/p>\n

NS<\/b>: Po, ndonj\u00ebher\u00eb nevojitet shum\u00eb memorie \u2014 kjo \u00ebsht\u00eb normale. Por nj\u00eb shembull nga jeta. N\u00eb makinat e production jan\u00eb 96 b\u00ebrtham\u00eb dhe 600 GB. N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb p\u00ebr DB p\u00ebrdoren 32 b\u00ebrthama (n\u00eb disa raste edhe 16 b\u00ebrthama tani) dhe memorja 100-120 GB.<\/i><\/p>\n

DS<\/b>: Dhe atje futen 50 copia?<\/p>\n

NS<\/b>: Pra, kopja \u00ebsht\u00eb nj\u00eb, pastaj punon copy-on-write (ZFS)... Do t\u00eb tregoj m\u00eb shum\u00eb.<\/i><\/p>\n

P\u00ebr shembull, baza jon\u00eb \u00ebsht\u00eb 10 TB. Disku p\u00ebr t\u00eb \u00ebsht\u00eb b\u00ebr\u00eb, ZFS akoma e ka kompresuar madh\u00ebsin\u00eb e saj me rreth 30-40%. Pasi ne nuk b\u00ebjm\u00eb testim ngarkese, koha e sakt\u00eb e reagimit nuk ka r\u00ebnd\u00ebsi: le t\u00eb jet\u00eb deri n\u00eb 2 her\u00eb m\u00eb e ngadalt\u00eb \u2014 kjo \u00ebsht\u00eb n\u00eb rregull.<\/i><\/p>\n

Ne u japim mund\u00ebsin\u00eb programmer\u00ebve, QA, DBA etj. t\u00eb kryejn\u00eb testime n\u00eb 1-2 procese. P\u00ebr shembull, ata mund t\u00eb fillojn\u00eb nj\u00eb migrim. Ai nuk k\u00ebrkon menj\u00ebher\u00eb 10 b\u00ebrthama \u2014 i nevojitet 1 backend i Postgres-it, 1 b\u00ebrtham\u00eb. Migrimi do t\u00eb filloj\u00eb \u2014 ndoshta, autovacuum<\/a><\/noindex> do t\u00eb filloj\u00eb p\u00ebrs\u00ebri, at\u00ebher\u00eb do t\u00eb angazhohet b\u00ebrthama e dyt\u00eb. Ne kemi rezervuar 16-32 b\u00ebrthama, k\u00ebshtu q\u00eb 10 njer\u00ebz mund t\u00eb punojn\u00eb nj\u00ebkoh\u00ebsisht, nuk ka probleme.<\/i><\/p>\n

Pasi fizikisht PGDATA<\/code> po ashtu, rezulton q\u00eb ne e mashtrojm\u00eb n\u00eb t\u00eb v\u00ebrtet\u00eb Postgres-in. K\u00ebtu \u00ebsht\u00eb triku: p\u00ebr shembull, aktivizohen 10 Postgres n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb. Problemi zakonisht \u00ebsht\u00eb? Vendosin shared_buffers<\/a><\/noindex>, le t\u00eb themi, n\u00eb 25%. P\u00ebr rrjedhoj\u00eb, kjo \u00ebsht\u00eb 200 GB. Nuk mund t\u00eb aktivizoni m\u00eb shum\u00eb se tre t\u00eb till\u00eb, sepse memoria do t\u00eb mbaroj\u00eb.<\/i><\/p>\n

Por n\u00eb nj\u00eb moment kupton se kjo nuk \u00ebsht\u00eb e nevojshme: ne e vendosim shared_buffers n\u00eb 2 GB. N\u00eb PostgreSQL ka effective_cache_size<\/a><\/noindex>, dhe n\u00eb realitet ai ndikon vet\u00ebm n\u00eb planet<\/a><\/noindex>. Ne e vendosim at\u00eb n\u00eb 0,5 TB. Dhe madje nuk ka r\u00ebnd\u00ebsi se ata n\u00eb t\u00eb v\u00ebrtet\u00eb nuk ekzistojn\u00eb: ai nd\u00ebrtan planet sikur ata jan\u00eb.<\/i><\/p>\n

Pra, kur testojm\u00eb ndonj\u00eb migrim, mund t\u00eb mbledhim t\u00eb gjitha planet \u2014 do t\u00eb shohim se si do t\u00eb ndodh\u00eb n\u00eb prodhim. Sekundat aty do t\u00eb jen\u00eb t\u00eb tjera (m\u00eb t\u00eb ngadalta), por t\u00eb dh\u00ebnat q\u00eb ne n\u00eb t\u00eb v\u00ebrtet\u00eb lexojm\u00eb dhe vet\u00eb planet (\u00e7far\u00eb join-e dhe etj.) jan\u00eb sakt\u00ebsisht t\u00eb nj\u00ebjtat si n\u00eb prodhim. Dhe mund t\u00eb aktivizojm\u00eb shum\u00eb verifikime t\u00eb tilla n\u00eb nj\u00eb makin\u00eb.<\/i><\/p>\n

DS<\/b>: A nuk mendon se k\u00ebtu ka disa probleme? E para \u2014 \u00ebsht\u00eb nj\u00eb zgjidhje q\u00eb punon vet\u00ebm n\u00eb PostgreSQL. Ky qasje \u2014 \u00ebsht\u00eb shum\u00eb specifike, nuk \u00ebsht\u00eb generic. E dyta \u2014 Kubernetes (dhe gjith\u00e7ka, ku tani po shkojn\u00eb teknologjit\u00eb cloud) supozon shum\u00eb nyje, dhe k\u00ebto nyje \u2014 jan\u00eb efemerale. Dhe n\u00eb rastin t\u00ebnd, ky \u00ebsht\u00eb nj\u00eb nyje stateful, me p\u00ebrhershm\u00ebri. K\u00ebto gj\u00ebra m\u00eb krijojn\u00eb kontradita.<\/p>\n

NS<\/b>: E para \u2014 pajtohem, kjo \u00ebsht\u00eb nj\u00eb histori krejt\u00ebsisht Postgres. Mendoj se n\u00ebse kemi ndonj\u00eb IO t\u00eb drejt\u00eb dhe nj\u00eb bufer t\u00eb plot\u00eb n\u00ebn gjith\u00eb memorien, ky qasje nuk do t\u00eb funksionoj\u00eb \u2014 planet do t\u00eb jen\u00eb t\u00eb tjera. Por p\u00ebr momentin punojm\u00eb vet\u00ebm me Postgres, p\u00ebr t\u00eb tjer\u00ebt nuk po mendojm\u00eb.<\/i><\/p>\n

Rreth Kubernetes. Ti vet\u00eb e ndan gjithandej se ne kemi nj\u00eb baz\u00eb persistente. N\u00ebse instanca bie, e r\u00ebnd\u00ebsishme \u00ebsht\u00eb t\u00eb ruash diskun. Pra, e gjith\u00eb platforma jon\u00eb \u00ebsht\u00eb gjithashtu n\u00eb Kubernetes, nd\u00ebrsa komponenti me Postgres \u2014 ndaras (edhe pse nj\u00eb dit\u00eb do t\u00eb jet\u00eb atje). Pra, gjith\u00e7ka \u00ebsht\u00eb k\u00ebshtu: instanca ra, por ne e ruajm\u00eb PV-n\u00eb e saj dhe thjesht e lidhim me nj\u00eb instanc\u00eb tjet\u00ebr (t\u00eb re), si\u00e7 nuk ndodhi asgj\u00eb.<\/i><\/p>\n

DS<\/b>: Nga k\u00ebndv\u00ebshtrimi im, ne krijojm\u00eb pod\u2019\u00eb n\u00eb Kubernetes. K8s \u00ebsht\u00eb elastik: nyjat porositen vet\u00eb sipas nevoj\u00ebs. Detyra \u00ebsht\u00eb thjesht t\u00eb krijosh nj\u00eb pod dhe t\u00eb thuash se i duhen X burime, dhe m\u00eb pas K8s do ta menaxhoj\u00eb vet\u00eb. Por mb\u00ebshtetja p\u00ebr ruajtjet n\u00eb Kubernetes ende \u00ebsht\u00eb e paq\u00ebndrueshme: n\u00eb 1.16<\/a><\/noindex>, n\u00eb 1.17<\/a><\/noindex> (kjo l\u00ebshim doli jav\u00eb<\/i> m\u00eb par\u00eb) k\u00ebto karakteristika b\u00ebhen vet\u00ebm beta.<\/p>\n

Pas gjasht\u00eb muajsh deri n\u00eb nj\u00eb vit \u2014 do t\u00eb b\u00ebhet m\u00eb se pak stabil, ose t\u00eb pakt\u00ebn do t\u00eb shpallet si i till\u00eb. Pastaj mund\u00ebsia e snapshoteve dhe resize do t\u00eb zgjidh\u00eb plot\u00ebsisht problemin tuaj. Sepse ju keni baz\u00ebn. Po, ajo mund t\u00eb mos jet\u00eb shum\u00eb e shpejt\u00eb, por shpejt\u00ebsia varet nga ajo q\u00eb \u00ebsht\u00eb 'n\u00ebn kapak', sepse disa zbatime mund t\u00eb b\u00ebjn\u00eb kopjimin dhe copy-on-write n\u00eb nivelin e n\u00ebnstruktures s\u00eb disqeve.<\/p>\n

NS<\/b>: K\u00ebtu duhet gjithashtu q\u00eb t\u00eb gjitha motor\u00ebt (Amazon, Google\u2026) t\u00eb fillojn\u00eb t\u00eb mb\u00ebshtesin k\u00ebt\u00eb version \u2014 kjo gjithashtu merr pak koh\u00eb.<\/i><\/p>\n

DS<\/b>: Deri tani ne nuk i p\u00ebrdorim. Ne p\u00ebrdorim tonat.<\/p>\n

Zhvillimi lokal n\u00ebn Kubernetes<\/h2>\n

\nNS<\/b>: A ke hasur ndonj\u00ebher\u00eb n\u00eb nj\u00eb k\u00ebrkes\u00eb t\u00eb till\u00eb, kur duhet t\u00eb ngresh t\u00eb gjith\u00eb pod\u2019\u00eb n\u00eb nj\u00eb makin\u00eb dhe t\u00eb b\u00ebsh nj\u00eb testim t\u00eb till\u00eb t\u00eb vog\u00ebl. Q\u00eb t\u00eb b\u00ebsh shpejt nj\u00eb prov\u00eb koncepti, t\u00eb shoh\u00ebsh se si funksionon aplikacioni n\u00eb Kubernetes, pa dedikuar shum\u00eb makina p\u00ebr k\u00ebt\u00eb. Ka Minikube, apo jo?<\/i><\/p>\n

DS<\/b>: M\u00eb duket se ky rast \u2014 t\u00eb vendos\u00ebsh n\u00eb nj\u00eb nyje \u2014 \u00ebsht\u00eb p\u00ebr zhvillimin lokal ekskluzivisht. Ose ndonj\u00eb shfaqje e k\u00ebtij modeli. Ka Minikube<\/a><\/noindex>, ka k3s<\/a><\/noindex>, testet e rifreskuara t\u00eb e2e.<\/a><\/noindex>. Ne po shkojm\u00eb drejt p\u00ebrdorimit t\u00eb Kubernetes IN Docker. Tani kemi filluar t\u00eb punojm\u00eb me t\u00eb p\u00ebr teste.<\/p>\n

NS<\/b>: M\u00eb par\u00eb mendova se ishte p\u00ebrpjekje p\u00ebr t\u00eb mb\u00ebshtjell\u00eb t\u00eb gjith\u00eb pod\u2019\u00eb n\u00eb nj\u00eb imazh Docker. Por doli se \u00ebsht\u00eb di\u00e7ka krejt tjet\u00ebr. Prap\u00eb ka konteiner\u00eb t\u00eb ve\u00e7ant\u00eb, pod\u2019\u00eb t\u00eb ve\u00e7ant\u00eb \u2014 thjesht n\u00eb Docker.<\/i><\/p>\n

DS<\/b>: Po. Dhe aty \u00ebsht\u00eb b\u00ebr\u00eb nj\u00eb imitim mjaft arg\u00ebtues, por kuptimi \u00ebsht\u00eb se... Kemi nj\u00eb utilitar p\u00ebr deploy \u2014 werf<\/a><\/noindex>. Duam ta b\u00ebjm\u00eb nj\u00eb modalitet \u2014 ndryshe werf up<\/code>: 'Ngri mu Kubernetes lokal'. Dhe m\u00eb pas t\u00eb nis\u00eb atje nj\u00eb werf follow<\/code>. At\u00ebher\u00eb zhvilluesi mund t\u00eb redaktoj\u00eb n\u00eb IDE, nd\u00ebrsa n\u00eb sistem \u00ebsht\u00eb n\u00eb funksion nj\u00eb proces q\u00eb sheh ndryshimet dhe rind\u00ebrton imazhet, duke i ri-diplouar ato n\u00eb K8s lokale. K\u00ebshtu duam t\u00eb p\u00ebrpiqemi t\u00eb zgjidhim problemin e zhvillimit lokal.<\/p>\n

Snapshot-et dhe klonimi i DB n\u00eb realitetin e K8s<\/h2>\n

\nNS<\/b>: N\u00ebse kthehemi te copy-on-write. Kam v\u00ebn\u00eb re se edhe n\u00eb cloud ka snapshot-e. Ato funksionojn\u00eb ndryshe. P\u00ebr shembull, n\u00eb GCP: ke nj\u00eb instanc\u00eb shum\u00eb terabajt\u00ebsh n\u00eb bregun lindor t\u00eb ShBA-s\u00eb. B\u00ebn snapshot-e periodicisht. Ngre nj\u00eb kopje disku nga snapshot n\u00eb bregun per\u00ebndimor \u2014 pas disa minutash, gjith\u00e7ka \u00ebsht\u00eb gati, punon shum\u00eb shpejt, vet\u00ebm cache-in duhet ta mbush\u00ebsh n\u00eb memorie. Por k\u00ebto klone (snapshot-e) jan\u00eb p\u00ebr t\u00eb 'provision' nj\u00eb volum t\u00eb ri. Kjo \u00ebsht\u00eb e shk\u00eblqyer kur duhet t\u00eb krijosh shum\u00eb instanca.<\/i><\/p>\n

Por p\u00ebr testet, m\u00eb duket se snapshot-et, p\u00ebr t\u00eb cilat ti flet n\u00eb Docker ose un\u00eb flas n\u00eb ZFS, btrfs dhe madje LVM\u2026 \u2014 ato lejojn\u00eb q\u00eb n\u00eb nj\u00eb makin\u00eb t\u00eb vetme t\u00eb mos krijosh realisht t\u00eb dh\u00ebna t\u00eb reja. N\u00eb cloud ti do t\u00eb paguash p\u00ebr to \u00e7do her\u00eb dhe do t\u00eb pres\u00ebsh tashm\u00eb jo sekonda, por minuta (dhe n\u00eb rastin e load-it t\u00eb len\u00eb<\/a><\/noindex>, ndoshta, edhe or\u00eb).<\/i><\/p>\n

N\u00eb vend t\u00eb k\u00ebsaj, mund t\u00eb marr\u00ebsh k\u00ebto t\u00eb dh\u00ebna p\u00ebr nj\u00eb deri n\u00eb dy sekonda, t\u00eb realizosh testin dhe ta heq\u00ebsh. K\u00ebto snapshot-e zgjidhin detyra t\u00eb ndryshme. N\u00eb rastin e par\u00eb \u2014 p\u00ebr t\u00eb shkall\u00ebzuar dhe p\u00ebr t\u00eb marr\u00eb replika t\u00eb reja, nd\u00ebrsa n\u00eb t\u00eb dytin \u2014 p\u00ebr teste.<\/i><\/p>\n

DS<\/b>: Nuk do t\u00eb pajtohem. T\u00eb b\u00ebsh nj\u00eb klonim normal t\u00eb volumeve \u2014 kjo \u00ebsht\u00eb nj\u00eb detyr\u00eb e cloud. Nuk e kam par\u00eb implementimin e tyre, por e di si e b\u00ebjm\u00eb ne n\u00eb harduer. Ne kemi Ceph, n\u00eb t\u00eb cilin mund t\u2019i themi \u00e7do volumi fizik (RBD<\/a><\/noindex>) dhe t\u00eb marrim n\u00eb disa milisekonda nj\u00eb volum t\u00eb dyt\u00eb me karakteristika t\u00eb nj\u00ebjta, clone<\/i> IOPS etj. Duhet t\u00eb kuptohet se brenda saj ka nj\u00eb copy-on-write t\u00eb nd\u00ebrlikuar. Pse cloud-i nuk e b\u00ebn k\u00ebshtu? Jam i sigurt q\u00eb ata p\u00ebrpiqen ta b\u00ebjn\u00eb k\u00ebt\u00eb n\u00eb nj\u00eb form\u00eb ose tjet\u00ebr.<\/a><\/noindex>: Teknikisht, kjo do t\u00eb thot\u00eb se brenda Kubernetes \u00ebsht\u00eb nj\u00eb pod, brenda t\u00eb cilit ne startojm\u00eb shum\u00eb Postgres.<\/p>\n

NS<\/b>: Por shum\u00eb koh\u00eb, minuta dhe nj\u00eb pjes\u00eb tjet\u00ebr do t\u00eb merren p\u00ebr t\u00eb ngritur instanc\u00ebn, p\u00ebr t\u00eb futur Docker, etj.<\/i><\/p>\n

DS<\/b>: Pse \u00ebsht\u00eb e nevojshme t\u00eb ngritni nj\u00eb instanc\u00eb t\u00eb plot\u00eb? Ne kemi nj\u00eb instanc\u00eb me 32 b\u00ebrthama, nj\u00eb me 16\u2026 dhe n\u00eb t\u00eb futet nj\u00eb num\u00ebr i caktuar \u2014 p\u00ebr shembull, kat\u00ebr. Kur t\u00eb porositim t\u00eb pestin, do t\u00eb ngrihet nj\u00eb instanc\u00eb, dhe m\u00eb pas do t\u00eb fshihet.<\/p>\n

NS<\/b>: Po, \u00ebsht\u00eb interesante. N\u00eb Kubernetes ndodh nj\u00eb histori tjet\u00ebr. Ne nuk e kemi DB-n\u00eb n\u00eb K8s, dhe kemi nj\u00eb instanc\u00eb. Por, p\u00ebr sa i p\u00ebrket klonimit t\u00eb nj\u00eb baze t\u00eb dh\u00ebnash me shum\u00eb terabajt, nuk merr m\u00eb shum\u00eb se dy sekonda.<\/i><\/p>\n

DS<\/b>: Kjo \u00ebsht\u00eb fantastike. Por q\u00ebllimi im fillestar \u00ebsht\u00eb se kjo nuk \u00ebsht\u00eb nj\u00eb zgjidhje generike. Po, \u00ebsht\u00eb e shk\u00eblqyer, por funksionon vet\u00ebm p\u00ebr Postgres dhe vet\u00ebm n\u00eb nj\u00eb nyj\u00eb.<\/p>\n

NS<\/b>: Nuk \u00ebsht\u00eb vet\u00ebm p\u00ebr Postgres: k\u00ebto plane, si\u00e7 e p\u00ebrshkrova, do t\u00eb funksionojn\u00eb vet\u00ebm n\u00eb t\u00eb. Por n\u00ebse nuk merremi me planet, dhe na duhen thjesht t\u00eb dh\u00ebnat p\u00ebr testim funksional, at\u00ebher\u00eb kjo do t\u00eb funksionoj\u00eb p\u00ebr \u00e7do DB.<\/i><\/p>\n

DS<\/b>: Para shum\u00eb vitesh, ne b\u00ebm\u00eb di\u00e7ka t\u00eb ngjashme me snapshotet LVM. Kjo \u00ebsht\u00eb klasike. Ky qasje \u00ebsht\u00eb p\u00ebrdorur shum\u00eb. Vet\u00ebm node-t me shtet jan\u00eb t\u00eb dhimbshme. Sepse nuk duhet t'i l\u00ebsh, duhet gjithmon\u00eb t\u00eb kujdesesh p\u00ebr to...<\/p>\n

NS<\/b>: A nuk sheh ndonj\u00eb mund\u00ebsi hibridi k\u00ebtu? Supozoni, shtetful \u2014 \u00ebsht\u00eb nj\u00eb pod, funksionon p\u00ebr disa njer\u00ebz (shum\u00eb testues). T\u00eb dh\u00ebnat tona jan\u00eb nj\u00eb, por fal\u00eb sistemit t\u00eb skedave klon\u00ebt jan\u00eb lokal\u00eb. N\u00ebse pod bie, disku mbetet \u2014 podi do t\u00eb ngrihet, do t\u00eb lexoj\u00eb informacionin p\u00ebr t\u00eb gjith\u00eb klon\u00ebt, gjith\u00e7ka do t\u00eb ngjitet p\u00ebrs\u00ebri dhe do t\u00eb thot\u00eb: 'K\u00ebtu jan\u00eb klon\u00ebt tuaj n\u00eb k\u00ebto porte, vazhdoni t\u00eb punoni me ta'.<\/i><\/p>\n

DS<\/b>: \u0422\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438 \u044d\u0442\u043e \u043e\u0437\u043d\u0430\u0447\u0430\u0435\u0442, \u0447\u0442\u043e \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 Kubernetes \u044d\u0442\u043e \u043e\u0434\u0438\u043d pod, \u0432\u043d\u0443\u0442\u0440\u0438 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0435\u043c \u043c\u043d\u043e\u0433\u043e Postgres’\u043e\u0432.<\/p>\n

NS<\/b>: Po. Ai ka nj\u00eb kufi: p\u00ebr shembull, nuk punojn\u00eb m\u00eb shum\u00eb se 10 persona me t\u00eb. N\u00ebse duhen 20 \u2014 do t\u00eb aktivizojm\u00eb nj\u00eb pod t\u00eb dyt\u00eb t\u00eb till\u00eb. \u00cbsht\u00eb krejt\u00ebsisht e mundur ta klonosh, duke marr\u00eb nj\u00eb v\u00ebllim t\u00eb dyt\u00eb, ku do t\u00eb ket\u00eb 10 'klon\u00eb t\u00eb holl\u00eb' t\u00eb till\u00eb. A nuk e sheh at\u00eb mund\u00ebsi?<\/i><\/p>\n

DS<\/b>: Duhet t\u00eb shtohet k\u00ebtu pyetje mbi sigurin\u00eb. Ky variant organizimi n\u00ebnkupton q\u00eb ky pod ka privilegje t\u00eb larta (capabilities), sepse ai mund t\u00eb kryej\u00eb operacione t\u00eb pazakonta mbi sistemin e skedar\u00ebve\u2026 Por po e p\u00ebrs\u00ebris: mendoj se n\u00eb nj\u00eb perspektiv\u00eb afatmesme Kubernetes do t\u00eb rregulloj\u00eb ruajtjen, n\u00eb cloud do t\u00eb rregullohet e gjith\u00eb historia me volumin - gjith\u00e7ka do t\u00eb funksionoj\u00eb 'thjesht'. Do t\u00eb ket\u00eb resize, klonim\u2026 Ka nj\u00eb volum - ne themi: 'Krijo nj\u00eb t\u00eb ri mbi at\u00eb', dhe brenda nj\u00eb sekonde e gjysm\u00eb e marrim at\u00eb q\u00eb na nevojitet.<\/p>\n

NS<\/b>: Nuk besoj n\u00eb nj\u00eb sekond\u00eb e gjysm\u00eb p\u00ebr shum\u00eb terabajt. N\u00eb Ceph e b\u00ebn vet\u00eb, dhe po flet p\u00ebr re. Shko n\u00eb re, b\u00ebj nj\u00eb klon t\u00eb volumit EBS t\u00eb shum\u00eb terabajt dhe shiko se \u00e7far\u00eb performance do t\u00eb ket\u00eb. Kjo nuk do t\u00eb marr\u00eb disa sekonda. M\u00eb intereson shum\u00eb t\u00eb di se kur do t\u00eb arrijn\u00eb nj\u00eb tregues t\u00eb till\u00eb. E kuptoj \u00e7far\u00eb thua, por do ta lejoj veten t\u00eb mos pajtohem.<\/i><\/p>\n

DS<\/b>: Ok, por thash\u00eb se n\u00eb nj\u00eb afat mesatar, jo afatshkurt\u00ebr. Brenda disa viteve.<\/p>\n

P\u00ebr operatorin p\u00ebr PostgreSQL nga Zalando<\/h2>\n

\nN\u00eb mes t\u00eb k\u00ebsaj takimi, u bashkua gjithashtu Alexey Klyukin, nj\u00eb ish-zhvillues nga kompania Zalando, i cili tregoi historin\u00eb e operatorit PostgreSQL:<\/p>\n

\u00cbsht\u00eb shum\u00eb mir\u00eb q\u00eb kjo tem\u00eb \u00ebsht\u00eb p\u00ebrmendur: si Postgres, ashtu edhe Kubernetes. Kur ne filluam ta b\u00ebjm\u00eb at\u00eb n\u00eb Zalando n\u00eb vitin 2017, kjo ishte nj\u00eb tem\u00eb q\u00eb t\u00eb gjith\u00eb donin t\u00eb merreshin me t\u00eb, por askush nuk e b\u00ebnte. T\u00eb gjith\u00eb kishin filluar t\u00eb merrnin Kubernetes, por kur pyeteshin se si duhej p\u00ebrballemi me bazat e t\u00eb dh\u00ebnave, madje edhe njer\u00ebz si Kelsey Hightower<\/a><\/noindex>, predikuan K8s, thoshin di\u00e7ka t\u00eb till\u00eb:<\/p>\n

\u2018Shkoni n\u00eb sh\u00ebrbime t\u00eb menaxhuara dhe p\u00ebrdorni ato, mos zhvilloni DB n\u00eb Kubernetes. Ndryshe, K8s juaj do t\u00eb vendos\u00eb, p\u00ebr shembull, t\u00eb b\u00ebj\u00eb nj\u00eb p\u00ebrmir\u00ebsim, do t'i fik\u00eb t\u00eb gjitha nyjat dhe t\u00eb dh\u00ebnat tuaja do t\u00eb fluturojn\u00eb shum\u00eb larg.\u2019<\/i><\/p>\n

Ne vendos\u00ebm t\u00eb b\u00ebjm\u00eb nj\u00eb operator q\u00eb, p\u00ebrkund\u00ebr k\u00ebtij k\u00ebshilli, do t\u00eb aktivizonte DB Postgres n\u00eb Kubernetes. Dhe ne kishim nj\u00eb baz\u00eb t\u00eb fort\u00eb \u2014 Patroni<\/a><\/noindex>. Ky \u00ebsht\u00eb nj\u00eb automatik failover p\u00ebr PostgreSQL, i b\u00ebr\u00eb si\u00e7 duhet, dmth. duke p\u00ebrdorur etcd, consul ose ZooKeeper si depo t\u00eb informacionit p\u00ebr klasterin. Nj\u00eb depo e till\u00eb, q\u00eb do t'i jepte t\u00eb gjith\u00ebve q\u00eb pyesin, p\u00ebr shembull, cili \u00ebsht\u00eb lider aktual, t\u00eb nj\u00ebjtin informacion - pavar\u00ebsisht se kemi gjith\u00e7ka t\u00eb shp\u00ebrndar\u00eb - p\u00ebr t\u00eb shmangur split brain. Plus, ne kishim Docker-image<\/a><\/noindex> p\u00ebr t\u00eb.<\/p>\n

N\u00eb t\u00eb v\u00ebrtet\u00eb, nevoja p\u00ebr auto failover n\u00eb kompani u shfaq pas migrimit nga qendra e t\u00eb dh\u00ebnave n\u00eb hardware n\u00eb cloud. Cloud ishte i bazuar n\u00eb nj\u00eb zgjidhje t\u00eb brendshme PaaS (Platform-as-a-Service). Ishte Open Source, por p\u00ebr ta ngritur at\u00eb, duhej shum\u00eb pun\u00eb. E quajt\u00ebn STUPS<\/a><\/noindex>.<\/p>\n

Fillimisht nuk kishte asnj\u00eb Kubernetes. M\u00eb sakt\u00eb, kur u zhvillua zgjidhja e brendshme, K8s ishte tashm\u00eb, por aq i papjekur sa nuk p\u00ebrshtatej p\u00ebr prodhim. Ishte, sipas mendjes time, vitit 2015 ose 2016. Deri n\u00eb vitin 2017, Kubernetes kishte arritur nj\u00eb nivel m\u00eb t\u00eb pjekur - u b\u00eb e nevojshme migrimi atje.<\/p>\n

Kemi pat\u00eb nj\u00eb kontenier Docker. Kishim nj\u00eb PaaS q\u00eb p\u00ebrdorte Docker. Pse t\u00eb mos provojm\u00eb K8s? Pse t\u00eb mos shkruajm\u00eb operatorin ton\u00eb? Murat Kabilov, q\u00eb erdhi te ne nga Avito, e nisi k\u00ebt\u00eb si nj\u00eb projekt me iniciativ\u00eb t\u00eb tij\u00ebn \u2014 \"t\u00eb loj\u00eb\", \u2014 dhe projekti \"tradhtoi\".<\/p>\n

Por n\u00eb t\u00eb v\u00ebrtet\u00eb doja t\u00eb flisja p\u00ebr AWS. Pse kishte historikisht kod q\u00eb lidhej me AWS\u2026<\/p>\n

Kur filloni ndonj\u00eb gj\u00eb n\u00eb Kubernetes, duhet t\u00eb kuptoni se K8s \u00ebsht\u00eb nj\u00eb pun\u00eb n\u00eb vazhdim. Ai zhvillohet vazhdimisht, p\u00ebrmir\u00ebsohet dhe her\u00eb pas here madje d\u00ebshtojn\u00eb. Duhet t\u00eb jeni t\u00eb v\u00ebmendsh\u00ebm ndaj t\u00eb gjitha ndryshimeve n\u00eb Kubernetes, duhet t\u00eb jeni t\u00eb gatsh\u00ebm q\u00eb n\u00eb rast nevoje t\u00eb zhyteni brenda tij dhe t\u00eb m\u00ebsoni si funksionon n\u00eb detaje \u2014 ndoshta m\u00eb shum\u00eb se sa d\u00ebshironit. Kjo ndodh, n\u00eb thelb, me \u00e7do platform\u00eb mbi t\u00eb cil\u00ebn zhvilloni bazat e t\u00eb dh\u00ebnave tuaj\u2026<\/p>\n

Pra, kur po b\u00ebnim operatorin, kishim Postgres q\u00eb punonte me nj\u00eb v\u00ebllim t\u00eb jasht\u00ebm (n\u00eb k\u00ebt\u00eb rast \u2014 EBS, duke pasur parasysh se ishim n\u00eb AWS). Baza e t\u00eb dh\u00ebnave u rrit, dhe n\u00eb nj\u00eb moment na duhej t\u00eb b\u00ebjm\u00eb resizing: p\u00ebr shembull, madh\u00ebsia fillestare e EBS ishte 100 Tb, baza e t\u00eb dh\u00ebnave e arriti at\u00eb madh\u00ebsi, tani duam t\u00eb b\u00ebjm\u00eb EBS 200 Tb. Si? Supozoni se mund t\u00eb b\u00ebni dump\/restore n\u00eb nj\u00eb instanc\u00eb t\u00eb re, por kjo merr shum\u00eb koh\u00eb dhe shkakton ndalesa.<\/p>\n

Prandaj, d\u00ebshironim nj\u00eb resize, i cili do t\u00eb rritej ndarjen EBS dhe pastaj do t\u00eb thoshte sistemit t\u00eb skedar\u00ebve t\u00eb p\u00ebrdorte hap\u00ebsir\u00ebn e re. Dhe ne e b\u00ebm\u00eb k\u00ebt\u00eb, por n\u00eb at\u00eb koh\u00eb Kubernetes nuk kishte asnj\u00eb API p\u00ebr operacionin e resize. Duke qen\u00eb se punonim n\u00eb AWS, shkruam kod p\u00ebr API-n\u00eb e saj.<\/p>\n

Askush nuk e ndalon t\u00eb b\u00ebj\u00eb t\u00eb nj\u00ebjt\u00ebn gj\u00eb p\u00ebr platformat e tjera. N\u00eb operator nuk ka nj\u00eb var\u00ebsi q\u00eb mund t\u00eb niset vet\u00ebm n\u00eb AWS, dhe n\u00eb \u00e7do platform\u00eb tjet\u00ebr nuk do t\u00eb funksionoj\u00eb. N\u00eb p\u00ebrgjith\u00ebsi, ky \u00ebsht\u00eb nj\u00eb projekt Open Source: n\u00ebse dikush d\u00ebshiron t\u00eb nxitoj\u00eb shfaqjen e nj\u00eb API t\u00eb ri \u2014 \u00ebsht\u00eb i mir\u00ebpritur. Ka GitHub<\/a><\/noindex>, k\u00ebrkesa pull \u2014 ekipi i Zalando mundohet t\u00eb reagoj\u00eb mjaft shpejt ndaj tyre dhe t\u00eb promovoj\u00eb operatorin. Sipas asaj q\u00eb di, projekti ka marr\u00eb pjes\u00eb<\/a><\/noindex> n\u00eb Google Summer of Code dhe n\u00eb disa iniciativa t\u00eb tjera t\u00eb ngjashme. Zalando \u00ebsht\u00eb shum\u00eb aktiv n\u00eb k\u00ebt\u00eb.\n<\/p><\/blockquote>\n

<\/p>\n

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

\nN\u00ebse jeni t\u00eb interesuar p\u00ebr tem\u00ebn e PostgreSQL dhe Kubernetes, at\u00ebher\u00eb gjithashtu vini re se jav\u00ebn e kaluar u mbajt Postgres-i i radh\u00ebs, ku Nikolai u komunikua me Aleksand\u00ebr Kukushkin nga Zalando<\/b>. Video nga ai \u00ebsht\u00eb e disponueshme k\u00ebtu<\/a><\/noindex>.<\/p>\n

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

\nLexoni gjithashtu n\u00eb blogun ton\u00eb:<\/p>\n