{"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\/hu\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-kedd #5: \u201ePostgreSQL \u00e9s Kubernetes. CI\/CD. Tesztel\u00e9s automatiz\u00e1l\u00e1sa\u201d","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-kedd
\n
\nTavaly \u00e9v v\u00e9g\u00e9n \u00fajabb \u00e9l\u0151 ad\u00e1st tartottak az orosz PostgreSQL k\u00f6z\u00f6ss\u00e9g keretein bel\u00fcl #RuPostgres<\/a><\/noindex>, amelynek sor\u00e1n az alap\u00edt\u00f3, Nikolai Samokhvalov besz\u00e9lgetett a Flant m\u0171szaki igazgat\u00f3j\u00e1val, Dmitrij Sztojarlovval err\u0151l az adatb\u00e1zis-kezel\u0151r\u0151l a Kubernetes kontextus\u00e1ban.<\/p>\n

A besz\u00e9lget\u00e9s f\u0151 r\u00e9sz\u00e9nek \u00e1tirat\u00e1t tessz\u00fck k\u00f6zz\u00e9, m\u00edg a k\u00f6z\u00f6ss\u00e9g YouTube-csatorn\u00e1j\u00e1n<\/a><\/noindex> a teljes videofelv\u00e9tel tal\u00e1lhat\u00f3:<\/a><\/noindex><\/p>\n

\r\n \"Vide\u00f3\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Adatb\u00e1zisok \u00e9s Kubernetes<\/h2>\n

\nNS<\/b>: Ma nem fogunk a VACUUM-r\u00f3l \u00e9s a CHECKPOINT-okr\u00f3l besz\u00e9lni. Kubernetesr\u0151l szeretn\u00e9nk besz\u00e9lni. Tudom, hogy m\u00e1r sok \u00e9ves tapasztalatod van. N\u00e9ztem a vide\u00f3idat, \u00e9s n\u00e9h\u00e1nyat m\u00e9g darabokban is visszan\u00e9ztem\u2026 Kezdj\u00fck a l\u00e9nyeggel: mi\u00e9rt van sz\u00fcks\u00e9g egy\u00e1ltal\u00e1n a Postgresre vagy a MySQL-re a K8s-ben?<\/i><\/p>\n

DS<\/b>: Erre a k\u00e9rd\u00e9sre nincs egy\u00e9rtelm\u0171 v\u00e1lasz, \u00e9s nem is lehet. De alapvet\u0151en a potenci\u00e1lis egyszer\u0171s\u00e9gr\u0151l \u00e9s k\u00e9nyelmess\u00e9gr\u0151l van sz\u00f3... Mindenki szeretn\u00e9 a kezelt szolg\u00e1ltat\u00e1sokat.<\/p>\n

NS<\/b>: Hogy olyan legyen, mint RDS<\/a><\/noindex>, csak a saj\u00e1t rendszer\u00fcnkben?<\/i><\/p>\n

DS<\/b>: Igen, hogy olyan legyen, mint az RDS, csak b\u00e1rhol.<\/p>\n

NS<\/b>: Az, hogy \"b\u00e1rhol\" \u2014 j\u00f3 megjegyz\u00e9s. Nagy c\u00e9gekn\u00e9l mindenhol sz\u00e9tsz\u00f3rva tal\u00e1lhat\u00f3ak a dolgok. De ha ez egy nagy c\u00e9g, mi\u00e9rt ne v\u00e1lasztan\u00e1nk egy k\u00e9sz megold\u00e1st? P\u00e9ld\u00e1ul a Nutanix saj\u00e1t fejleszt\u00e9sekkel rendelkezik, m\u00e1s c\u00e9gekn\u00e9l (VMware...) is tal\u00e1lhat\u00f3 \"RDS, csak a saj\u00e1t rendszer\u00fckben\".<\/i><\/p>\n

DS<\/b>: De itt egy adott megval\u00f3s\u00edt\u00e1sr\u00f3l besz\u00e9l\u00fcnk, amely csak bizonyos felt\u00e9telek mellett fog m\u0171k\u00f6dni. Ha Kubernetesr\u0151l van sz\u00f3, itt hatalmas az infrastrukt\u00far\u00e1k sokf\u00e9les\u00e9ge (amely K8s-ben lehet). Ez val\u00f3j\u00e1ban egy API szabv\u00e1ny a felh\u0151h\u00f6z...<\/p>\n

NS<\/b>: R\u00e1ad\u00e1sul ingyenes is!<\/i><\/p>\n

DS<\/b>: Ez nem annyira fontos. Az ingyeness\u00e9g csak egy kisebb piaci szegmens sz\u00e1m\u00e1ra l\u00e9nyeges. M\u00e1s a fontos... Gondolom, eml\u00e9kszel a \"Adatb\u00e1zisok \u00e9s Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

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

DS<\/b>: \u00c9szrevettem, hogy ezt nagyon vegyesen fogadt\u00e1k. N\u00e9h\u00e1nyan azt gondolt\u00e1k, hogy azt mondom: \u201eSr\u00e1cok, ir\u00e1ny minden adatb\u00e1zis Kubernetessel!\u201d, m\u00edg m\u00e1sok azt hiszik, hogy ez mind borzalmas ker\u00e9kp\u00e1roz\u00e1s. Pedig \u00e9n val\u00f3j\u00e1ban m\u00e1st akartam mondani: \u201eN\u00e9zz\u00e9tek, mi t\u00f6rt\u00e9nik, milyen probl\u00e9m\u00e1k vannak \u00e9s hogyan lehet ezeket megoldani. Most adatb\u00e1zisokat haszn\u00e1lni Kubernetesen? Termel\u00e9sben? Csak ha szereted\u2026 v\u00e9gezni bizonyos dolgokat. De a fejleszt\u00e9shez \u2013 azt tudom mondani, hogy javaslom. A fejleszt\u00e9shez nagyon fontos a k\u00f6rnyezetek dinamikus l\u00e9trehoz\u00e1sa\/elt\u00e1vol\u00edt\u00e1sa.\u201d<\/p>\n

NS: A fejleszt\u00e9s alatt mindent \u00e9rtesz, ami nem termel\u00e9s? Staging, QA\u2026<\/i><\/p>\n

DS<\/b>: Ha a perf-standokr\u00f3l besz\u00e9l\u00fcnk, akkor val\u00f3sz\u00edn\u0171leg nem, mert ott a k\u00f6vetelm\u00e9nyek speci\u00e1lisak. Ha k\u00fcl\u00f6nleges esetekr\u0151l van sz\u00f3, ahol a staginghez nagyon nagy adatb\u00e1zis sz\u00fcks\u00e9ges, akkor sem, val\u00f3sz\u00edn\u0171leg... Ha ez egy statikus k\u00f6rnyezet, ami hossz\u00fa \u00e9let\u0171, akkor mi az el\u0151nye annak, hogy az adatb\u00e1zis K8s-ben tal\u00e1lhat\u00f3?<\/p>\n

NS<\/b>: Semmi. De hol l\u00e1tunk statikus k\u00f6rnyezeteket? A statikus k\u00f6rnyezet m\u00e1r holnap elavult.<\/i><\/p>\n

DS<\/b>: A staging lehet statikus. Vannak \u00fcgyfeleink...<\/p>\n

NS<\/b>: Igen, nekem is van. Nagy probl\u00e9ma, ha van egy 10 TB-os adatb\u00e1zisod, m\u00edg a staging csak 200 GB...<\/i><\/p>\n

DS<\/b>: Van egy nagyon men\u0151 esetem! A staging-en egy termel\u00e9si adatb\u00e1zis van, amelybe v\u00e1ltoztat\u00e1sokat vezetnek be. Van egy gomb: \u201ekivitelezni a production-ba\u201d. Ezek a m\u00f3dos\u00edt\u00e1sok \u2013 deltak\u00e9nt \u2013 be\u00e9rkeznek (\u00fagy t\u0171nik, egyszer\u0171en API-n kereszt\u00fcl szinkroniz\u00e1l\u00f3dnak) a production-ba. Ez egy nagyon egzotikus v\u00e1ltozat.<\/p>\n

NS<\/b>: L\u00e1ttam indul\u00f3 v\u00e1llalkoz\u00e1sokat a V\u00f6lgyben, amelyek m\u00e9g RDS-en vagy ak\u00e1r Herokun \u00fclnek \u2013 ez 2-3 \u00e9vvel ezel\u0151tti t\u00f6rt\u00e9netek \u2013, \u00e9s let\u00f6ltik a dumpot a laptopjukra. Mert az adatb\u00e1zis mind\u00f6ssze 80 GB, \u00e9s van hely a laptopon. Majd v\u00e1s\u00e1rolnak mindenki sz\u00e1m\u00e1ra meghajt\u00f3kat, hogy 3 adatb\u00e1zist tudjanak kezelni, k\u00fcl\u00f6nf\u00e9le fejleszt\u00e9sekhez. Ilyen is el\u0151fordul. Azt is l\u00e1ttam, hogy nem f\u00e9lnek a termel\u00e9si adatokat staging-be m\u00e1solni \u2013 ez nagyon a c\u00e9gt\u0151l f\u00fcgg. De azt is l\u00e1ttam, hogy sokan f\u00e9lnek, \u00e9s gyakran hi\u00e1nyzik az id\u0151 \u00e9s a k\u00e9z. De miel\u0151tt \u00e1tt\u00e9rn\u00e9nk erre a t\u00e9m\u00e1ra, szeretn\u00e9m hallani a Kubernetesr\u0151l. J\u00f3l \u00e9rtem, hogy a termel\u00e9sben m\u00e9g senki sincs?<\/i><\/p>\n

DS<\/b>: N\u00e1lunk kicsi adatb\u00e1zisok vannak a termel\u00e9sben. Azokr\u00f3l van sz\u00f3, amelyek n\u00e9h\u00e1ny t\u00edz gigab\u00e1jtra terjednek ki \u00e9s nem kritikus szolg\u00e1ltat\u00e1sok, amelyekn\u00e9l nem volt kedv\u00fcnk replik\u00e1kat k\u00e9sz\u00edteni (meg nem is volt ilyen ig\u00e9ny). \u00c9s csak abban az esetben, ha a Kubernetes alatt van norm\u00e1lis t\u00e1rol\u00e1s. Ez az adatb\u00e1zis egy virtu\u00e1lis g\u00e9pen m\u0171k\u00f6d\u00f6tt \u2013 mondjuk VMware-en, egy t\u00e1rol\u00f3n. Elhelyezt\u00fck benne PV<\/a><\/noindex> \u2013 \u00e9s most tudjuk vinni egyik g\u00e9pr\u0151l a m\u00e1sikra.<\/p>\n

NS<\/b>: Az ilyen m\u00e9ret\u0171 adatb\u00e1zisokat, 100 GB-ig, j\u00f3 lemezeken \u00e9s j\u00f3 h\u00e1l\u00f3zaton n\u00e9h\u00e1ny perc alatt el lehet ind\u00edtani, igaz? Az 1 GB sebess\u00e9g m\u00e1r nem egzotikus.<\/i><\/p>\n

DS<\/b>: Igen, line\u00e1ris m\u0171velet eset\u00e9n ez nem probl\u00e9ma.<\/p>\n

NS<\/b>: Rendben, a prod-r\u00f3l csak gondolkodnunk kell. De ha a Kubernetes alkalmaz\u00e1s\u00e1t nem prod k\u00f6rnyezetekhez vizsg\u00e1ljuk \u2013 hogy csin\u00e1ljuk? L\u00e1tom, hogy a Zalando oper\u00e1tort csin\u00e1l<\/a><\/noindex>, a Crunchy pedig k\u00e9sz\u00edt<\/a><\/noindex>, vannak m\u00e9g m\u00e1s lehet\u0151s\u00e9gek is. \u00c9s ott van OnGres<\/a><\/noindex> \u2013 ez a j\u00f3 ismer\u0151s\u00fcnk Alvaro Spanyolorsz\u00e1gb\u00f3l: \u0151k l\u00e9nyeg\u00e9ben nemcsak oper\u00e1tort k\u00e9sz\u00edtenek<\/a><\/noindex>, hanem egy teljes disztrib\u00faci\u00f3t (StackGres<\/a><\/noindex>), amelybe a Postgres mellett m\u00e9g a ment\u00e9st is be akartuk helyezni, proxy Envoy\u2026<\/i><\/p>\n

DS<\/b>: Mire val\u00f3 az Envoy? A Postgres forgalom kiegyens\u00falyoz\u00e1s\u00e1ra?<\/p>\n

NS<\/b>: Igen. Teh\u00e1t \u0151k \u00fagy l\u00e1tj\u00e1k, hogy ha van egy Linux disztrib\u00faci\u00f3 \u00e9s kernel, akkor a hagyom\u00e1nyos PostgreSQL a kernel, de \u0151k szeretn\u00e9nek egy disztrib\u00faci\u00f3t l\u00e9trehozni, ami felh\u0151bar\u00e1t \u00e9s Kubernetes alatt fut. \u00d6sszeillesztik a komponenseket (ment\u00e9sek stb.) \u00e9s finomhangolj\u00e1k, hogy j\u00f3l m\u0171k\u00f6djenek.<\/i><\/p>\n

DS<\/b>: Nagyon klassz! L\u00e9nyeg\u00e9ben ez egy szoftver, amely lehet\u0151v\u00e9 teszi, hogy saj\u00e1t kezelt Postgres-\u00fcnk legyen.<\/p>\n

NS<\/b>: A Linux disztrib\u00faci\u00f3knak \u00e1lland\u00f3 probl\u00e9m\u00e1i vannak: hogyan k\u00e9sz\u00edtsenek drivereket, hogy minden hardver t\u00e1mogasson. Az \u0151 elk\u00e9pzel\u00e9s\u00fck, hogy Kubernetes alatt fognak m\u0171k\u00f6dni. Tudom, hogy a Zalando oper\u00e1tor\u00e1n\u00e1l nemr\u00e9g l\u00e1ttunk egy AWS kapcsol\u00f3d\u00e1st, ami m\u00e1r nem annyira j\u00f3. Nem lenne szabad, hogy konkr\u00e9t infrastrukt\u00far\u00e1hoz k\u00f6t\u0151djenek \u2014 mi \u00e9rtelme akkor?<\/i><\/p>\n

DS<\/b>: Nem tudom, konkr\u00e9tan milyen helyzetben k\u00f6t\u0151d\u00f6tt a Zalando, de a Kubernetes jelenlegi t\u00e1rol\u00e1sa \u00fagy van kialak\u00edtva, hogy nem lehet \u00e1ltal\u00e1nos m\u00f3don lemezment\u00e9st k\u00e9sz\u00edteni. Nemr\u00e9g a legutols\u00f3 verzi\u00f3ban a CSI specifik\u00e1ci\u00f3ban a CSI specifik\u00e1ci\u00f3ban<\/a><\/noindex> \u2014 bevezett\u00e9k a pillanatk\u00e9pek lehet\u0151s\u00e9g\u00e9t, de hol van ez megval\u00f3s\u00edtva? \u0150szint\u00e9n sz\u00f3lva, m\u00e9g mindig olyan nyers, hogy\u2026 Pr\u00f3b\u00e1lkozunk a CSI-val AWS, GCE, Azure, vSphere f\u00f6l\u00f6tt, de amikor elkezded haszn\u00e1lni, l\u00e1tszik, hogy m\u00e9g nincs k\u00e9sz.<\/p>\n

NS<\/b>: Ez\u00e9rt n\u00e9ha k\u00f6t\u0151dni kell az infrastrukt\u00far\u00e1hoz. Azt hiszem, ez m\u00e9g mindig a korai szakasz \u2014 n\u00f6veked\u00e9si probl\u00e9m\u00e1k vannak. K\u00e9rd\u00e9s: mit javasoln\u00e1l a kezd\u0151knek, akik ki szeretn\u00e9k pr\u00f3b\u00e1lni a PgSQL-t K8s alatt? Milyen oper\u00e1tort aj\u00e1nlan\u00e1l?<\/i><\/p>\n

DS<\/b>: A probl\u00e9ma az, hogy a Postgres sz\u00e1munkra csak 3%. Van egy nagyon nagy list\u00e1nk egy\u00e9b szoftverekr\u0151l a Kubernetesben, nem is sorolom fel mindet. P\u00e9ld\u00e1ul Elasticsearch. Rengeteg oper\u00e1tor l\u00e9tezik: egyesek akt\u00edvan fejl\u0151dnek, m\u00e1sok nem. Mi megfogalmaztunk egy k\u00f6vetelm\u00e9nyt, hogy mi legyen az oper\u00e1torban, hogy komolyan vegy\u00fck. Az oper\u00e1tor pedig kifejezetten Kuberneteshez \u2014 nem az \u201eoper\u00e1tor, hogy valamit csin\u00e1ljunk Amazonban\u201d\u2026 Val\u00f3j\u00e1ban el\u00e9gg\u00e9 sz\u00e9les k\u00f6rben (= szinte minden \u00fcgyfel\u00fcnkn\u00e9l) egyetlen oper\u00e1tort haszn\u00e1lunk - a Redishez<\/a><\/noindex> (hamarosan megosztunk r\u00f3la egy cikket is)<\/i>.<\/p>\n

NS<\/b>: De MySQL-hez sincs? Tudom, hogy a Percona\u2026 mivel most m\u00e1r a MySQL-t, MongoDB-t \u00e9s Postgres-t is foglalkoznak, kell, hogy k\u00e9sz\u00edtsenek egy univerz\u00e1lis megold\u00e1st: minden adatb\u00e1zisra, minden felh\u0151szolg\u00e1ltat\u00f3ra.<\/i><\/p>\n

DS<\/b>: Nem n\u00e9zt\u00fck meg a MySQL oper\u00e1torokat. Jelenleg ez nem a f\u0151 f\u00f3kuszunk. A MySQL j\u00f3l m\u0171k\u00f6dik \u00f6n\u00e1ll\u00f3an. Mi\u00e9rt sz\u00fcks\u00e9ges az oper\u00e1tor, ha egyszer\u0171en elind\u00edthatod az adatb\u00e1zist\u2026 Ind\u00edthatsz egy Docker-kont\u00e9nert a Postgres-zel, vagy egyszer\u0171en elind\u00edthatod.<\/p>\n

NS<\/b>: Err\u0151l is volt k\u00e9rd\u00e9s. Teljesen oper\u00e1tor n\u00e9lk\u00fcl?<\/i><\/p>\n

DS<\/b>: Igen, 100%-ban a PostgreSQL oper\u00e1tor n\u00e9lk\u00fcl fut. Jelenleg \u00edgy van. Akt\u00edvan haszn\u00e1lunk oper\u00e1tort a Prometheus-hoz, a Redis-hez. Terveink k\u00f6z\u00f6tt szerepel, hogy tal\u00e1ljunk oper\u00e1tort az Elasticsearch-hez \u2014 ez a legfontosabb, mert 100%-ban Kubernetesen szeretn\u00e9nk telep\u00edteni. Ak\u00e1rcsak a MongoDB-t is mindig Kubernetesen szeretn\u00e9nk telep\u00edteni. Itt megjelennek bizonyos ig\u00e9nyek \u2014 van egy \u00e9rz\u00e9sem, hogy ezekben az esetekben lehetne valamit tenni. A Postgres-r\u0151l pedig m\u00e9g csak nem is n\u00e9zt\u00fcnk. Term\u00e9szetesen tudunk a k\u00fcl\u00f6nb\u00f6z\u0151 lehet\u0151s\u00e9gek l\u00e9tez\u00e9s\u00e9r\u0151l, de val\u00f3j\u00e1ban \u00f6n\u00e1ll\u00f3an fut.<\/p>\n

Adatb\u00e1zis tesztel\u00e9shez Kubernetesen<\/h2>\n

\nNS<\/b>: N\u00e9zz\u00fck meg a tesztel\u00e9s t\u00e9m\u00e1j\u00e1t. Hogyan terjesztj\u00fck ki a v\u00e1ltoz\u00e1sokat az adatb\u00e1zisban \u2014 a DevOps n\u00e9z\u0151pontj\u00e1b\u00f3l. Vannak mikroszolg\u00e1ltat\u00e1sok, sok adatb\u00e1zis, folyamatosan valahol valami v\u00e1ltozik. Hogyan biztos\u00edtjuk a norm\u00e1lis CI\/CD-t, hogy az adatb\u00e1zis szempontj\u00e1b\u00f3l minden rendben legyen. Mi a te megk\u00f6zel\u00edt\u00e9sed?<\/i><\/p>\n

DS<\/b>: Nincs egy\u00e9rtelm\u0171 v\u00e1lasz. Sz\u00e1mos t\u00e9nyez\u0151 van. Az els\u0151 a m\u00e9rete az adatb\u00e1zisnak, amelyet ki akarunk terjeszteni. Te is eml\u00edtetted, hogy a c\u00e9gekn\u00e9l k\u00fcl\u00f6nb\u00f6z\u0151en viszonyulnak ahhoz, hogy a prod adatb\u00e1zis m\u00e1solata dev \u00e9s stage k\u00f6rnyezeten legyen.<\/p>\n

NS<\/b>: GDPR keretein bel\u00fcl \u00fagy gondolom, egyre k\u00f6r\u00fcltekint\u0151bben j\u00e1rnak el\u2026 Azt tudom mondani, hogy Eur\u00f3p\u00e1ban m\u00e1r elkezdtek b\u00fcntetni.<\/i><\/p>\n

DS<\/b>: De gyakran lehet olyan szoftvert \u00edrni, ami k\u00e9sz\u00edt egy dumpot a productionb\u00f3l \u00e9s elhom\u00e1lyos\u00edtja azt. Teh\u00e1t kapunk production adatokat (snapshot, dump, bin\u00e1ris m\u00e1solat\u2026), de ezek anonim adatt\u00e1 v\u00e1lnak. Ehelyett lehetnek gener\u00e1l\u00e1si szkriptek is: ezek lehetnek fix\u00e1k, vagy egyszer\u0171en egy szkript, ami egy nagy adatb\u00e1zist gener\u00e1l. A probl\u00e9ma az, hogy mennyi id\u0151 alatt k\u00e9sz\u00fcl el az alap k\u00e9p? \u00c9s mennyi id\u0151be telik, hogy azt a megfelel\u0151 k\u00f6rnyezetben telep\u00edts\u00fck?<\/p>\n

Eljutottunk ahhoz a s\u00e9m\u00e1hoz: ha az \u00fcgyf\u00e9lnek van fixture adathalmazon (minimum verzi\u00f3 az adatb\u00e1zisb\u00f3l), akkor alap\u00e9rtelmez\u00e9s szerint haszn\u00e1ljuk \u0151ket. Ha a review-k\u00f6rnyezetekr\u0151l van sz\u00f3, amikor l\u00e9trehoztunk egy branchet, \u00e9s telep\u00edtett\u00fcnk egy p\u00e9ld\u00e1nyt az alkalmaz\u00e1sb\u00f3l \u2014 ide telep\u00edtj\u00fck a kicsi adatb\u00e1zist. De j\u00f3l megoldottuk \u00e9s a verzi\u00f3t<\/a><\/noindex>, amikor a productionb\u00f3l naponta (\u00e9jszaka) k\u00e9sz\u00edt\u00fcnk egy dumpot, \u00e9s ez alapj\u00e1n \u00f6sszerakunk egy Docker kont\u00e9nert PostgreSQL \u00e9s MySQL adatainkkal. Ha ebb\u0151l a k\u00e9pb\u0151l 50-szer kell az adatb\u00e1zist telep\u00edteni, azt el\u00e9g gyorsan \u00e9s egyszer\u0171en meg lehet csin\u00e1lni.<\/p>\n

NS<\/b>: Egyszer\u0171 m\u00e1sol\u00e1ssal?<\/i><\/p>\n

DS<\/b>: Az adatok k\u00f6zvetlen\u00fcl a Docker-k\u00e9pben t\u00e1rol\u00f3dnak. Teh\u00e1t van egy k\u00e9sz k\u00e9p\u00fcnk, mondjuk 100 GB m\u00e9retben. A Docker r\u00e9tegeinek k\u00f6sz\u00f6nhet\u0151en gyorsan telep\u00edthetj\u00fck ezt a k\u00e9pet a sz\u00fcks\u00e9ges alkalmak sz\u00e1mban. Ez egy primit\u00edv m\u00f3dszer, de j\u00f3l m\u0171k\u00f6dik.<\/p>\n

NS<\/b>: Tov\u00e1bb\u00e1, amikor tesztelsz, az k\u00f6zvetlen\u00fcl a Docker-en bel\u00fcl v\u00e1ltozik, ugye? A copy-on-write a Docker-en bel\u00fcl \u2014 kidobjuk \u00e9s \u00fajrakezdj\u00fck, minden rendben van. Klassz! Ezt m\u00e1r akt\u00edvan haszn\u00e1lj\u00e1tok?<\/i><\/p>\n

DS<\/b>: R\u00e9gen.<\/p>\n

NS<\/b>: Hasonl\u00f3 dolgokkal foglalkozunk. Csak mi nem a Docker copy-on-write-t haszn\u00e1ljuk, hanem valami m\u00e1st.<\/i><\/p>\n

DS<\/b>: Ez nem generic. A Docker-es megold\u00e1s viszont mindenhol m\u0171k\u00f6dik.<\/p>\n

NS<\/b>: Elm\u00e9letileg igen. De n\u00e1lunk is vannak modulok, amiket k\u00fcl\u00f6nb\u00f6z\u0151 f\u00e1jlrendszerekkel lehet megval\u00f3s\u00edtani. Itt egy dolog van. A Postgres szemsz\u00f6g\u00e9b\u0151l m\u00e1sk\u00e9pp tekint\u00fcnk erre az eg\u00e9szre. Most, hogy a Docker szemsz\u00f6g\u00e9b\u0151l n\u00e9ztem, l\u00e1ttam, hogy minden j\u00f3l m\u0171k\u00f6dik. De ha az adatb\u00e1zis hatalmas, p\u00e9ld\u00e1ul 1 TB, akkor m\u00e1r hosszadalmas: \u00e9jszakai m\u0171veletek, \u00e9s mindent Dockerbe betenni\u2026 De ha 5 TB-ot tesz\u00fcnk be Dockerbe\u2026 vagy minden rendben van?<\/i><\/p>\n

DS<\/b>: Mi a k\u00fcl\u00f6nbs\u00e9g: ezek blobok, csak bitek \u00e9s byte-ok.<\/p>\n

NS<\/b>: A k\u00fcl\u00f6nbs\u00e9g az, hogy ezt dump \u00e9s restore \u00fatj\u00e1n csin\u00e1lj\u00e1tok?<\/i><\/p>\n

DS<\/b>: Egy\u00e1ltal\u00e1n nem sz\u00fcks\u00e9ges. Az ennek a k\u00e9pnek a gener\u00e1l\u00e1s\u00e1ra szolg\u00e1l\u00f3 m\u00f3dszerek k\u00fcl\u00f6nb\u00f6z\u0151ek lehetnek.<\/p>\n

NS<\/b>: N\u00e9h\u00e1ny \u00fcgyfel\u00fcnk sz\u00e1m\u00e1ra bevezett\u00fck, hogy a hagyom\u00e1nyos alapk\u00e9pgener\u00e1l\u00e1s helyett folyamatosan naprak\u00e9szen tartjuk azt. L\u00e9nyeg\u00e9ben egy m\u00e1solat, de az adatok nem k\u00f6zvetlen\u00fcl a mesterb\u0151l j\u00f6nnek, hanem egy arch\u00edvumon kereszt\u00fcl. Az bin\u00e1ris arch\u00edvum, ahov\u00e1 a WAL-ok minden nap \u00e9rkeznek, ott k\u00e9sz\u00fclnek a biztons\u00e1gi m\u00e1solatok is... Ezek a WAL-ok k\u00e9s\u0151bb \u2013 egy kis k\u00e9s\u00e9ssel (mind\u00f6ssze 1-2 m\u00e1sodperc) \u2013 eljutnak az alapk\u00e9pre. Az alapk\u00e9pb\u0151l b\u00e1rmilyen m\u00f3don kl\u00f3nozunk \u2013 most alap\u00e9rtelmez\u00e9s szerint ZFS-t haszn\u00e1lunk.<\/i><\/p>\n

DS<\/b>: De a ZFS-zel egy csom\u00f3ban korl\u00e1tozott vagy.<\/p>\n

NS<\/b>: Igen. De a ZFS-nek van m\u00e9g egy var\u00e1zslatos send<\/a><\/noindex>: amivel az instant k\u00e9pet el lehet k\u00fcldeni, \u00e9s ak\u00e1r (ezt m\u00e9g nem teszteltem igaz\u00e1n, de\u2026) lehet k\u00fcldeni a delta-t a k\u00e9t k\u00f6z\u00f6tt. PGDATA<\/code>. Val\u00f3j\u00e1ban van m\u00e9g egy eszk\u00f6z\u00fcnk, amit nem igaz\u00e1n vizsg\u00e1ltunk ilyen feladatokra. A PostgreSQL-ben van pg_rewind<\/a><\/noindex>, amely mint \u201eokos\u201d rsync m\u0171k\u00f6dik, kihagyva mindent, amit nem \u00e9rdemes megn\u00e9zni, mert ott val\u00f3ban semmi sem v\u00e1ltozott. Gyors szinkroniz\u00e1l\u00e1st v\u00e9gezhet\u00fcnk k\u00e9t szerver k\u00f6z\u00f6tt, \u00e9s pontosan \u00fagy vissza tudunk csavarni.<\/i><\/p>\n

Sz\u00f3val, arra a DBA-szer\u0171 oldalra t\u00f6reksz\u00fcnk, hogy k\u00e9sz\u00edts\u00fcnk egy eszk\u00f6zt, ami lehet\u0151v\u00e9 teszi azt, amir\u0151l besz\u00e9lgett\u00e9l: van egy adatb\u00e1zisunk, de 50-szer szeretn\u00e9nk valamit egyszerre tesztelni.<\/i><\/p>\n

DS<\/b>: 50-szer azt jelenti, hogy 50 Spot p\u00e9ld\u00e1nyt kell rendelnie.<\/p>\n

NS<\/b>: Nem, mindent egy g\u00e9pen csin\u00e1lunk.<\/i><\/p>\n

DS<\/b>: De hogyan telep\u00edtesz 50 alkalommal, ha ez az egy adatb\u00e1zis mondjuk terab\u00e1jtos? Val\u00f3sz\u00edn\u0171leg sz\u00fcks\u00e9ge van felt\u00e9telezve 256 GB RAM-ra?<\/p>\n

NS<\/b>: Igen, n\u00e9ha sok mem\u00f3ri\u00e1ra van sz\u00fcks\u00e9g \u2014 ez rendben van. De egy p\u00e9lda az \u00e9letb\u0151l. A production g\u00e9pen 96 mag \u00e9s 600 GB van. Ebb\u0151l az adatb\u00e1zis sz\u00e1m\u00e1ra 32 magot haszn\u00e1lnak (most m\u00e1r 16 mag is n\u00e9ha el\u00e9g) \u00e9s 100-120 GB mem\u00f3ri\u00e1t.<\/i><\/p>\n

DS<\/b>: \u00c9s oda beles\u0171r\u00edthet\u0151 50 m\u00e1solat?<\/p>\n

NS<\/b>: Teh\u00e1t a m\u00e1solat egy, \u00e9s tov\u00e1bbra is a copy-on-write (ZFS-es)... R\u00e9szletesebben mes\u00e9lek r\u00f3la.<\/i><\/p>\n

N\u00e1lunk p\u00e9ld\u00e1ul egy 10 TB adatb\u00e1zis van. A sz\u00e1m\u00e1ra k\u00e9sz\u00edtett lemez ZFS-sel m\u00e9g 30-40%-kal \u00f6sszenyomta a m\u00e9ret\u00e9t. Mivel nem v\u00e9gz\u00fcnk terhel\u00e9ses tesztel\u00e9st, sz\u00e1munkra a pontos v\u00e1laszid\u0151 nem fontos: legyen ak\u00e1r k\u00e9tszer lassabb \u2014 az rendben van.<\/i><\/p>\n

Lehet\u0151s\u00e9get adunk a programoz\u00f3knak, QA-nak, DBA-knak stb., hogy 1-2 sz\u00e1lon v\u00e9gezzenek tesztel\u00e9st. P\u00e9ld\u00e1ul elind\u00edthatnak egy migr\u00e1ci\u00f3t. Ez nem ig\u00e9nyel azonnal 10 magot \u2013 egy Postgres h\u00e1tt\u00e9rre \u00e9s 1 magra van sz\u00fcks\u00e9ge. A migr\u00e1ci\u00f3 elindul \u2013 tal\u00e1n, autovacuum<\/a><\/noindex> m\u00e9g elindul, akkor a m\u00e1sodik mag bekapcsol\u00f3dik. 16-32 mag van elk\u00fcl\u00f6n\u00edtve, \u00edgy 10 ember egyszerre dolgozhat, nincsenek probl\u00e9m\u00e1k.<\/i><\/p>\n

Mivel fizikailag PGDATA<\/code> ugyanolyan, \u00fagy t\u0171nik, hogy val\u00f3j\u00e1ban megt\u00e9vesztj\u00fck a Postgres-t. A l\u00e9nyeg az, hogy p\u00e9ld\u00e1ul 10 Postgres-t ind\u00edtunk egyszerre. Milyen probl\u00e9ma mer\u00fcl fel \u00e1ltal\u00e1ban? Be\u00e1ll\u00edtj\u00e1k shared_buffers<\/a><\/noindex>, mondjuk, 25%-ra. Ennek megfelel\u0151en ez 200 GB. H\u00e1rom ilyen p\u00e9ld\u00e1nyt m\u00e1r nem ind\u00edthat el, mert elfogy a mem\u00f3ria.<\/i><\/p>\n

De egy pillanatban r\u00e1j\u00f6tt\u00fcnk, hogy erre nincs sz\u00fcks\u00e9g: a shared_buffers-t 2 GB-ra \u00e1ll\u00edtjuk. A PostgreSQL-nek van effective_cache_size<\/a><\/noindex>, \u00e9s val\u00f3j\u00e1ban csak ez befoly\u00e1solja a terveket<\/a><\/noindex>. Ezt 0,5 TB-ra \u00e1ll\u00edtjuk. \u00c9s m\u00e9g az sem sz\u00e1m\u00edt, hogy val\u00f3j\u00e1ban nincsenek: terveket \u00e9p\u00edt, mintha lenn\u00e9nek.<\/i><\/p>\n

Teh\u00e1t amikor tesztel\u00fcnk egy migr\u00e1ci\u00f3t, \u00f6sszegy\u0171jthetj\u00fck az \u00f6sszes tervet \u2013 l\u00e1tni fogjuk, hogyan t\u00f6rt\u00e9nik a production-en. Ott m\u00e1s m\u00e1sodpercek lesznek (lassabbak), de az adatok, amelyeket t\u00e9nylegesen olvasunk, \u00e9s maguk a tervek (milyen JOIN-ok stb.) pontosan olyanok, mint a production-en. P\u00e1rhuzamosan t\u00f6bb ilyen ellen\u0151rz\u00e9st is futtathatunk egy g\u00e9pen.<\/i><\/p>\n

DS<\/b>: Nem gondolod, hogy itt van n\u00e9h\u00e1ny probl\u00e9ma? Az els\u0151 - ez a megold\u00e1s csak PostgreSQL-en m\u0171k\u00f6dik. Ez a megk\u00f6zel\u00edt\u00e9s nagyon specifikus, nem \u00e1ltal\u00e1nos\u00edthat\u00f3. A m\u00e1sodik - a Kubernetes (\u00e9s minden, amerre a felh\u0151technol\u00f3gi\u00e1k tartanak) sz\u00e1mos csom\u00f3pontot felt\u00e9telez, \u00e9s ezek a csom\u00f3pontok efemeriek. A te esetedben viszont ez \u00e1lland\u00f3, tart\u00f3s csom\u00f3pont. Ezek a dolgok ellentmond\u00e1sokat okoznak sz\u00e1momra.<\/p>\n

NS<\/b>: El\u0151sz\u00f6r is \u2013 egyet\u00e9rtek, ez kiz\u00e1r\u00f3lag Postgres-es dolog. Azt hiszem, ha van valamilyen k\u00f6zvetlen IO-nk \u00e9s a puffert\u00e1rol\u00f3 szinte az eg\u00e9sz mem\u00f3ri\u00e1t lefedi, ez a megk\u00f6zel\u00edt\u00e9s nem fog m\u0171k\u00f6dni \u2013 a tervek m\u00e1sok lesznek. De mi eddig csak a Postgres-szel foglalkozunk, m\u00e1sr\u00f3l nem is gondolkodunk.<\/i><\/p>\n

A Kubernetesr\u0151l. Te is minden\u00fctt elmondod, hogy az adatb\u00e1zisunk tart\u00f3s. Ha az instance \u00f6sszeomlik, a legfontosabb a lemezk\u00e9p meg\u0151rz\u00e9se. N\u00e1lunk is az eg\u00e9sz platform Kubernetesben m\u0171k\u00f6dik, \u00e9s a Postgres \u00f6sszetev\u0151 k\u00fcl\u00f6n van (b\u00e1r egyszer az is ott lesz). Teh\u00e1t \u00edgy van: az instance \u00f6sszeomlott, de meg\u0151rizt\u00fck a PV-t, \u00e9s egyszer\u0171en csatlakoztattuk egy m\u00e1sik (\u00faj) instance-hez, mintha mi sem t\u00f6rt\u00e9nt volna.<\/i><\/p>\n

DS<\/b>: Az \u00e9n n\u00e9z\u0151pontomb\u00f3l n\u00e9zve pod-okat hozunk l\u00e9tre a Kubernetes-en. A K8s rugalmas: a csom\u00f3pontok automatikusan rendel\u0151dnek, amikor sz\u00fcks\u00e9ges. A feladat \u2013 egyszer\u0171en l\u00e9trehozni egy pod-ot \u00e9s megmondani, hogy X er\u0151forr\u00e1sra van sz\u00fcks\u00e9ge, a K8s pedig maga int\u00e9zkedik. De a t\u00e1rol\u00f3k t\u00e1mogat\u00e1sa a Kubernetes-en m\u00e9g mindig instabil: 1.16<\/a><\/noindex>, in 1.17<\/a><\/noindex> (ez a kiad\u00e1s megjelent hetet<\/i> ezel\u0151tt) ezek a funkci\u00f3k csak b\u00e9ta \u00e1llapot\u00faak.<\/p>\n

F\u00e9l \u00e9v vagy egy \u00e9v m\u00falva m\u00e1r viszonylag stabil lesz, vagy legal\u00e1bbis \u00edgy lesz hirdetve. Akkor a snapshotok \u00e9s a resize lehet\u0151s\u00e9ge m\u00e1r teljesen megoldja a feladatodat. Mert van egy adatb\u00e1zisod. Igen, lehet, hogy nem a leggyorsabb, de a sebess\u00e9g att\u00f3l f\u00fcgg, hogy mi van \"a motorh\u00e1ztet\u0151 alatt\", mert bizonyos megold\u00e1sok k\u00e9pesek a m\u00e1sol\u00e1sra \u00e9s a copy-on-write-ra a lemezalrendszer szintj\u00e9n.<\/p>\n

NS<\/b>: Itt m\u00e9g azt is figyelembe kell venni, hogy minden motor (Amazon, Google\u2026) elmond\u00e1sa szerint elkezdje t\u00e1mogatni ezt a verzi\u00f3t - ez is eltart egy ideig.<\/i><\/p>\n

DS<\/b>: Jelenleg nem haszn\u00e1ljuk \u0151ket. A saj\u00e1tunkat haszn\u00e1ljuk.<\/p>\n

Helyi fejleszt\u00e9s Kubernetes alatt<\/h2>\n

\nNS<\/b>: Tal\u00e1lkozt\u00e1l m\u00e1r azzal a k\u00edv\u00e1ns\u00e1ggal, amikor egy g\u00e9pen meg kell emelni az \u00f6sszes pod-ot, \u00e9s v\u00e9gezni kell egy kis tesztel\u00e9st. Hogy gyorsan bizony\u00edt\u00e9kot kapjunk arr\u00f3l, hogy az alkalmaz\u00e1s m\u0171k\u00f6dik a Kubernetes-ben, an\u00e9lk\u00fcl, hogy ehhez rengeteg g\u00e9pet rendeln\u00e9k. Van Minikube, ugye?<\/i><\/p>\n

DS<\/b>: Szerintem ez az eset \u2014 egy csom\u00f3ponton t\u00f6rt\u00e9n\u0151 \u00fczemeltet\u00e9s \u2014 kifejezetten a helyi fejleszt\u00e9sr\u0151l sz\u00f3l. Vagy valamilyen megnyilv\u00e1nul\u00e1sa ennek a mint\u00e1nak. Van Minikube<\/a><\/noindex>, van k3s<\/a><\/noindex>, (Kubernetes IN Docker) \u00e9s<\/a><\/noindex>. Arra megy\u00fcnk, hogy Kubernetes in Docker-t haszn\u00e1ljunk. Most kezdt\u00fcnk el dolgozni vele tesztekhez.<\/p>\n

NS<\/b>: R\u00e9gebben azt hittem, hogy ez az \u00f6sszes podot egy Docker-k\u00e9pbe pr\u00f3b\u00e1lja becsomagolni. De kider\u00fclt, hogy ez teljesen m\u00e1sr\u00f3l sz\u00f3l. M\u00e9g mindig k\u00fcl\u00f6n kont\u00e9nerek \u00e9s k\u00fcl\u00f6n podok vannak \u2013 egyszer\u0171en csak Docker-en bel\u00fcl.<\/i><\/p>\n

DS<\/b>: Igen. Ott el\u00e9g sz\u00f3rakoztat\u00f3 ut\u00e1nzat k\u00e9sz\u00fclt, de a l\u00e9nyeg az... Van egy eszk\u00f6z\u00fcnk a telep\u00edt\u00e9shez \u2014 werf<\/a><\/noindex>. Azt akarjuk, hogy legyen egy m\u00f3d \u2014 mondjuk, werf up<\/code>: \u201e\u00c1ll\u00edtsd fel nekem a helyi Kubernetes-t\u201d. Azt\u00e1n ind\u00edtsd el ott felt\u00e9telesen a werf follow<\/code>. Akkor a fejleszt\u0151 IDE-ben tud szerkeszteni, mik\u00f6zben a rendszerben fut egy folyamat, ami \u00e9szleli a v\u00e1ltoz\u00e1sokat \u00e9s \u00fajra\u00e9p\u00edti a k\u00e9peket, \u00fajra telep\u00edti \u0151ket a helyi K8s-be. \u00cdgy pr\u00f3b\u00e1ljuk megoldani a helyi fejleszt\u00e9s probl\u00e9m\u00e1j\u00e1t.<\/p>\n

A snapshotok \u00e9s az adatb\u00e1zis kl\u00f3noz\u00e1s a K8s val\u00f3s\u00e1g\u00e1ban<\/h2>\n

\nNS<\/b>: Ha visszat\u00e9r\u00fcnk a copy-on-write-hoz. \u00c9szrevettem, hogy a felh\u0151knek is vannak snapshotjaik. Ezek k\u00fcl\u00f6nb\u00f6z\u0151en m\u0171k\u00f6dnek. P\u00e9ld\u00e1ul a GCP-ban: van egy t\u00f6bbterabyte-os instance-od az Egyes\u00fclt \u00c1llamok keleti partj\u00e1n. Id\u0151nk\u00e9nt snapshotokat k\u00e9sz\u00edtesz. K\u00e9sz\u00edtesz egy lemezm\u00e1solatot a snapshotb\u00f3l a nyugati parton \u2013 n\u00e9h\u00e1ny percen bel\u00fcl m\u00e1r minden k\u00e9sz, nagyon gyorsan m\u0171k\u00f6dik, csak a cache-t kell felt\u00f6lteni a mem\u00f3ri\u00e1ban. De ezek a kl\u00f3nok (snapshotok) az \u00faj k\u00f6tet \"provision\u00e1l\u00e1s\u00e1hoz\" kellenek. Ez nagyszer\u0171, amikor sok instance-t kell l\u00e9trehozni.<\/i><\/p>\n

Viszont a tesztekhez \u00fagy t\u0171nik, hogy a snapshotok, amikr\u0151l besz\u00e9lsz a Docker-ben vagy amikr\u0151l \u00e9n besz\u00e9lek a ZFS-ben, btrfs-ben \u00e9s m\u00e9g LVM-ben... \u2013 lehet\u0151v\u00e9 teszik, hogy egy g\u00e9pen ne legyenek val\u00f3j\u00e1ban \u00faj adatok. A felh\u0151ben m\u00e9g minden alkalommal fizetned kell \u00e9rt\u00fck, \u00e9s m\u00e1r nem m\u00e1sodpercek, hanem percek v\u00e1rakoz\u00e1sa sz\u00fcks\u00e9ges (\u00e9s ha a lazy load-ra<\/a><\/noindex>, lehet, hogy \u00f3r\u00e1kban is).<\/i><\/p>\n

Helyette m\u00e1sodpercek alatt megkaphatod ezeket az adatokat, futhatsz egy tesztet \u00e9s eldobhatod. Ezek a snapshotok k\u00fcl\u00f6nb\u00f6z\u0151 feladatokat oldanak meg. Az els\u0151 esetben, hogy sk\u00e1l\u00e1zzunk \u00e9s \u00faj replik\u00e1kat kapjunk, m\u00edg a m\u00e1sodik esetben \u2014 tesztel\u00e9shez.<\/i><\/p>\n

DS<\/b>: Nem \u00e9rtek egyet. A megfelel\u0151 k\u00f6tetkl\u00f3noz\u00e1s feladata a felh\u0151\u00e9. Nem n\u00e9ztem meg a megval\u00f3s\u00edt\u00e1sukat, de tudom, hogy mi hogyan csin\u00e1ljuk vasalaton. Van Ceph-\u00fcnk, amiben b\u00e1rkinek meg lehet mondani egy fizikai k\u00f6tetet (RBD<\/a><\/noindex>) \u00e9s n\u00e9h\u00e1ny tizedm\u00e1sodperc alatt megkapja a m\u00e1sodik k\u00f6tetet azonos jellemz\u0151kkel, clone<\/i> IOPS stb. Meg kell \u00e9rteni, hogy bel\u00fcl \u00fcgyes copy-on-write m\u00f3dszert haszn\u00e1lnak. Mi\u00e9rt ne tudn\u00e1 a felh\u0151 is ugyanezt csin\u00e1lni? Biztos vagyok benne, hogy \u00edgy vagy \u00fagy pr\u00f3b\u00e1lkoznak ezzel.<\/a><\/noindex>\u00e9s \u00edgy tov\u00e1bb. Meg kell \u00e9rtened, hogy ott bel\u00fcl egy \u00fcgyes copy-on-write van. Mi\u00e9rt ne csin\u00e1ln\u00e1nak ugyanezt a felh\u0151ben? Biztos vagyok benne, hogy valamilyen m\u00f3don pr\u00f3b\u00e1lj\u00e1k ezt megval\u00f3s\u00edtani.<\/p>\n

NS<\/b>: Mi\u00e9rt kell felt\u00e9tlen\u00fcl egy eg\u00e9sz instansz? Van n\u00e1lunk egy 32 magos instansz, 16\u2026 \u00e9s abba belef\u00e9r n\u00e9h\u00e1ny \u2014 p\u00e9ld\u00e1ul n\u00e9gy. Amikor az \u00f6t\u00f6diket k\u00e9rj\u00fck, m\u00e1r \u00faj instansz j\u00f6n l\u00e9tre, azt\u00e1n el fog t\u0171nni.<\/i><\/p>\n

DS<\/b>: Igen, \u00e9rdekes, a Kubernetes-ben m\u00e1s a helyzet. N\u00e1lunk az adatb\u00e1zis nem fut K8s-en, \u00e9s ez egy instansz. Viszont a t\u00f6bb terab\u00e1jtos adatb\u00e1zis kl\u00f3noz\u00e1sa nem tart tov\u00e1bb k\u00e9t m\u00e1sodpercn\u00e9l.<\/p>\n

NS<\/b>: Ez men\u0151. De az alapvet\u0151 gondolatom az, hogy ez nem \u00e1ltal\u00e1nos megold\u00e1s. Igen, klassz, de csak a Postgreshez megfelel\u0151, \u00e9s csak egy node-on.<\/i><\/p>\n

DS<\/b>: Nem csak a Postgreshez j\u00f3: ezek a tervek, ahogy le\u00edrtam, csak benne fognak \u00edgy m\u0171k\u00f6dni. De ha nem foglalkozunk a tervekkel, \u00e9s csak az adatokat akarjuk a funkcion\u00e1lis tesztel\u00e9shez, akkor ez b\u00e1rmilyen DBMS-re megfelel\u0151 lesz.<\/p>\n

NS<\/b>: Sok \u00e9vvel ezel\u0151tt hasonl\u00f3t csin\u00e1ltunk LVM snapshotokkal. Ez klasszikus. Ez a megk\u00f6zel\u00edt\u00e9s nagyon akt\u00edvan alkalmazva volt. Csak a stateful node-ok \u2014 ez f\u00e1jdalom. Mert \u0151ket sosem szabad elfelejteni, mindig eml\u00e9kezni kell r\u00e1juk...<\/i><\/p>\n

DS<\/b>: Nem l\u00e1tsz itt valami hibrid lehet\u0151s\u00e9get? Tegy\u00fck fel, a stateful \u2014 ez egy pod, ami t\u00f6bb ember (sok tesztel\u0151) munk\u00e1j\u00e1t szolg\u00e1lja ki. Egy k\u00f6tet\u00fcnk van, de a f\u00e1jlrendszernek k\u00f6sz\u00f6nhet\u0151en a kl\u00f3nok \u2014 helyi. Ha a pod le\u00e1ll, a lemez megmarad \u2014 a pod \u00fajra\u00e9rkezik, az \u00f6sszes kl\u00f3nr\u00f3l inform\u00e1ci\u00f3t olvas be, mindent vissza\u00e1ll\u00edt \u00e9s azt mondja: \u201e\u00cdme, a kl\u00f3njaid ezekkel a portokkal elindultak, dolgozz vel\u00fck tov\u00e1bb\u201d.<\/p>\n

NS<\/b>: Technikai \u00e9rtelemben ez azt jelenti, hogy Kubernetes keretein bel\u00fcl ez egy pod, amely belsej\u00e9ben sok Postgres-t futtatunk.<\/i><\/p>\n

DS<\/b>: Technikai szempontb\u00f3l ez azt jelenti, hogy a Kubernetes keretein bel\u00fcl ez egy pod, amelyen bel\u00fcl sok Postgres-t ind\u00edtunk.<\/p>\n

NS<\/b>: Igen. Van egy korl\u00e1tja: p\u00e9ld\u00e1ul egyszerre nem dolgozhat vele t\u00f6bb mint 10 ember. Ha 20-ra van sz\u00fcks\u00e9g \u2014 akkor elind\u00edtunk egy m\u00e1sodik podot. Teljesen re\u00e1lis \u00fagy kl\u00f3nozni, hogy kapunk egy m\u00e1sodik teljes k\u00f6tetet, amelyen ugyanolyan 10 \u201ev\u00e9kony\u201d kl\u00f3n lesz. Nem l\u00e1tsz ilyen lehet\u0151s\u00e9get?<\/i><\/p>\n

DS<\/b>: Biztons\u00e1gi k\u00e9rd\u00e9seket kell hozz\u00e1adni ide. Ez a szervez\u00e9si lehet\u0151s\u00e9g azt jelenti, hogy ennek a pod-nak magas jogosults\u00e1gai (capabilities) vannak, mivel szok\u00e1sos m\u0171veleteket v\u00e9gezhet a f\u00e1jlrendszeren\u2026 De ism\u00e9tlem: azt gondolom, hogy k\u00f6z\u00e9pt\u00e1von a Kubernetes jav\u00edtani fogja a storage-t, a felh\u0151k megoldj\u00e1k a k\u00f6tetekkel kapcsolatos \u00f6sszes probl\u00e9m\u00e1t - minden \u201eegyszer\u0171en m\u0171k\u00f6dni fog\u201d. Lesz m\u00e9retez\u00e9s, kl\u00f3noz\u00e1s\u2026 Van egy k\u00f6tet - azt mondjuk: \u201eHozz l\u00e9tre egy \u00fajat annak alapj\u00e1n\u201d, \u00e9s m\u00e1sf\u00e9l m\u00e1sodperc m\u00falva megkapjuk, amire sz\u00fcks\u00e9g\u00fcnk van.<\/p>\n

NS<\/b>: Nem hiszek az m\u00e1sf\u00e9l m\u00e1sodpercben sok terab\u00e1jt eset\u00e9ben. A Ceph-on te csin\u00e1lod magad, de a felh\u0151r\u0151l besz\u00e9lsz. Menj a felh\u0151be, az EC2-n kl\u00f3nozz egy EBS k\u00f6tetet sok terab\u00e1jtnyi adatb\u00f3l, \u00e9s n\u00e9zd meg, milyen teljes\u00edtm\u00e9ny lesz. Ez nem fog n\u00e9h\u00e1ny m\u00e1sodpercet ig\u00e9nybe venni. Nagyon \u00e9rdekel, mikor \u00e9rik el ezt a teljes\u00edtm\u00e9nyt. \u00c9rtem, mire gondolsz, de megengedem magamnak, hogy ne \u00e9rts\u00fcnk egyet.<\/i><\/p>\n

DS<\/b>: Rendben, de azt mondtam, hogy k\u00f6z\u00e9pt\u00e1von, nem r\u00f6vidt\u00e1von. N\u00e9h\u00e1ny \u00e9ven bel\u00fcl.<\/p>\n

A Zalando PostgreSQL oper\u00e1tor\u00e1r\u00f3l<\/h2>\n

\nA tal\u00e1lkoz\u00f3 k\u00f6zep\u00e9n Alexey Klyukin, a Zalando volt fejleszt\u0151je is csatlakozott, aki elmes\u00e9lte a PostgreSQL oper\u00e1tor t\u00f6rt\u00e9net\u00e9t:<\/p>\n

Remek, hogy egy\u00e1ltal\u00e1n felvet\u0151d\u00f6tt ez a t\u00e9ma: mind a Postgres, mind a Kubernetes. Amikor 2017-ben elkezdt\u00fck csin\u00e1lni a Zalando-n\u00e1l, ez olyan t\u00e9ma volt, amely ir\u00e1nt mindenki \u00e9rdekl\u0151d\u00f6tt, de senki sem foglalkozott vele. Mindenkinek m\u00e1r volt Kubernetes-e, de amikor megk\u00e9rdezt\u00e9k, mi legyen az adatb\u00e1zisokkal, olyan emberek, mint Kelsey Hightower<\/a><\/noindex>, akik a K8s-t hirdett\u00e9k, k\u00f6r\u00fclbel\u00fcl a k\u00f6vetkez\u0151ket mondt\u00e1k:<\/p>\n

\u201eMenjetek a kezelt szolg\u00e1ltat\u00e1sokhoz \u00e9s haszn\u00e1lj\u00e1tok azokat, ne ind\u00edts\u00e1tok el az adatb\u00e1zist Kubernetes alatt. Ellenkez\u0151 esetben a K8s p\u00e9ld\u00e1ul \u00fagy d\u00f6nt, hogy friss\u00edt\u00e9st v\u00e9gez, le\u00e1ll\u00edt minden csom\u00f3pontot, \u00e9s az adatait messzire rep\u00edti.\u201d<\/i><\/p>\n

\u00dagy d\u00f6nt\u00f6tt\u00fcnk, hogy k\u00e9sz\u00edt\u00fcnk egy oper\u00e1tort, amely, ellent\u00e9tben ezzel a tan\u00e1ccsal, PostgreSQL adatb\u00e1zisokat futtat Kubernetes alatt. \u00c9s j\u00f3 alapunk volt - Patroni<\/a><\/noindex>. Ez egy automatikus failover a PostgreSQL sz\u00e1m\u00e1ra, amit helyesen k\u00e9sz\u00edtettek el, azaz az etcd, a consul vagy a ZooKeeper-t haszn\u00e1lja a klaszterinform\u00e1ci\u00f3k t\u00e1rol\u00e1s\u00e1ra. Olyan t\u00e1rol\u00f3, amely mindenkinek, aki megk\u00e9rdezi, p\u00e9ld\u00e1ul a jelenlegi vezet\u0151r\u0151l ugyanazt az inform\u00e1ci\u00f3t adja \u2013 annak ellen\u00e9re, hogy minden elosztott, \u2013 hogy elker\u00fclj\u00fck a split brain-t. Ezen k\u00edv\u00fcl volt egy Docker-k\u00e9pet<\/a><\/noindex> sz\u00e1m\u00e1ra.<\/p>\n

\u00c1ltal\u00e1ban a v\u00e1llalat aut\u00f3f\u00e1jlver\u00e9sre vonatkoz\u00f3 ig\u00e9nye a bels\u0151 vasadatk\u00f6zponton val\u00f3 migr\u00e1l\u00e1s ut\u00e1n mer\u00fclt fel a felh\u0151be. A felh\u0151 egy saj\u00e1t PaaS (Platform-as-a-Service) megold\u00e1son alapult. Ez ny\u00edlt forr\u00e1sk\u00f3d\u00fa, de ahhoz, hogy m\u0171k\u00f6d\u00e9sbe hozzuk, sokat kellett dolgozni. A neve STUPS<\/a><\/noindex>.<\/p>\n

Kezdetben nem volt Kubernetes. Pontosabban, amikor a saj\u00e1t megold\u00e1sunkat telep\u00edtett\u00fck, a K8s m\u00e1r l\u00e9tezett, de annyira nyers volt, hogy production-ra nem volt alkalmas. Ez 2015 vagy 2016 k\u00f6rny\u00e9k\u00e9n volt. 2017-re a Kubernetes m\u00e1r t\u00f6bb\u00e9-kev\u00e9sb\u00e9 \u00e9rett\u00e9 v\u00e1lt - sz\u00fcks\u00e9g lett a migr\u00e1ci\u00f3ra.<\/p>\n

M\u00e1r volt Docker-kont\u00e9ner\u00fcnk. Volt egy PaaS, ami Docker-t haszn\u00e1lt. Mi\u00e9rt ne pr\u00f3b\u00e1ln\u00e1nk ki a K8s-t? Mi\u00e9rt ne \u00edrn\u00e1nk saj\u00e1t oper\u00e1tort? Murat Kabilov, aki az Avit\u00f3t\u00f3l \u00e9rkezett hozz\u00e1nk, ezt egy saj\u00e1t kezdem\u00e9nyez\u00e9s\u0171 projektk\u00e9nt kezdte \u2014 hogy \"j\u00e1tsszon\", \u2014 \u00e9s a projekt \"megsz\u00fcletett\".<\/p>\n

De val\u00f3j\u00e1ban az AWS-r\u0151l akartam mes\u00e9lni. Mi\u00e9rt volt ott t\u00f6rt\u00e9netileg AWS-hez kapcsol\u00f3d\u00f3 k\u00f3d...<\/p>\n

Amikor valamit ind\u00edtasz a Kubernetes-ben, figyelembe kell venni, hogy a K8s egy folyamatosan fejl\u0151d\u0151 rendszer. Folyamatosan fejl\u0151dik, javul, \u00e9s id\u0151nk\u00e9nt m\u00e9g meg is hib\u00e1sodik. Gondosan figyelni kell minden v\u00e1ltoz\u00e1sra a Kubernetes-ben, k\u00e9szen kell \u00e1llni arra, hogy amennyiben sz\u00fcks\u00e9ges, m\u00e9lyebben megismerkedjen vele \u00e9s kider\u00edtse, hogyan m\u0171k\u00f6dik r\u00e9szleteiben \u2014 lehet, hogy t\u00f6bbet, mint szeretn\u00e9d. Ez \u00e1ltal\u00e1ban minden platform eset\u00e9ben \u00edgy van, amelyen az adatb\u00e1zisaidat futtatod...<\/p>\n

Teh\u00e1t, amikor oper\u00e1tort k\u00e9sz\u00edtett\u00fcnk, volt egy Postgres\u00fcnk, amely egy k\u00fcls\u0151 t\u00e1rol\u00f3val m\u0171k\u00f6d\u00f6tt (jelen esetben EBS, mivel AWS-en dolgoztunk). Az adatb\u00e1zis n\u0151tt, \u00e9s egy adott pillanatban sz\u00fcks\u00e9gess\u00e9 v\u00e1lt a m\u00e9retez\u00e9s: p\u00e9ld\u00e1ul az eredeti EBS m\u00e9ret 100 TB volt, az adatb\u00e1zis el\u00e9rte ezt a m\u00e9retet, most pedig 200 TB-os EBS-t szeretn\u00e9nk. Hogyan? Mondjuk, meg lehetne csin\u00e1lni a dump\/restore-t egy \u00faj p\u00e9ld\u00e1nyra, de ez hossz\u00fa ideig tart \u00e9s le\u00e1ll\u00e1ssal j\u00e1r.<\/p>\n

Ez\u00e9rt olyan m\u00e9retez\u00e9st szerett\u00fcnk volna, amely n\u00f6veli az EBS part\u00edci\u00f3t, majd k\u00f6zli a f\u00e1jlrendszerrel, hogy haszn\u00e1lja az \u00faj ter\u00fcletet. \u00c9s ezt v\u00e9grehajtottuk, de akkor a Kubernetes nem rendelkezett API-val a m\u00e9retez\u00e9si m\u0171velethez. Mivel az AWS-en dolgoztunk, \u00edrtunk k\u00f3dot az API-j\u00e1hoz.<\/p>\n

Senki sem akad\u00e1lyoz meg abban, hogy ugyanazt m\u00e1s platformokra is megcsin\u00e1lja. Az oper\u00e1tor nem k\u00f6t\u0151dik ahhoz, hogy csak AWS-en futtathat\u00f3, hanem m\u00e1sutt is m\u0171k\u00f6dhet. Ez egy ny\u00edlt forr\u00e1sk\u00f3d\u00fa projekt: ha valaki szeretn\u00e9 felgyors\u00edtani az \u00faj API haszn\u00e1lat\u00e1nak megjelen\u00e9s\u00e9t \u2014 sz\u00edvesen l\u00e1tjuk. GitHub<\/a><\/noindex>, a pull request \u2014 a Zalando csapata igyekszik el\u00e9g gyorsan reag\u00e1lni r\u00e1juk \u00e9s el\u0151mozd\u00edtani az oper\u00e1tort. Amennyire tudom, a projekt r\u00e9szt vett<\/a><\/noindex> a Google Summer of Code-ban \u00e9s hasonl\u00f3 kezdem\u00e9nyez\u00e9sekben. A Zalando nagyon akt\u00edvan dolgozik rajta.\n<\/p><\/blockquote>\n

<\/p>\n

P.S. B\u00f3nusz!<\/h2>\n

\nHa \u00e9rdeklik a PostgreSQL \u00e9s Kubernetes t\u00e9m\u00e1k, akkor figyeljenek, hogy m\u00falt h\u00e9ten megrendez\u00e9sre ker\u00fclt a k\u00f6vetkez\u0151 Postgres-kedd, ahol Nikolajjal besz\u00e9lgetett Alexander Kukushkin a Zalandoff\u00f3l<\/b>. A vide\u00f3 el\u00e9rhet\u0151 itt<\/a><\/noindex>.<\/p>\n

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

\nOlvasson tov\u00e1bbi inform\u00e1ci\u00f3kat a blogunkban:<\/p>\n