Bi rengekî dîrokî, pîşesaziya IT-ê ji ber her sedemekê li du kampên şertî tê dabeş kirin: yên ku "ji bo" ne û yên ku "li dijî" ne. Wekî din, mijara nakokiyan dikare bi tevahî kêfî be. Kîjan OS çêtir e: Win an Linux? Li ser smartphone Android an iOS? Ma hûn her tiştî di nav ewran de hilînin an jî wê têxin ser hilanîna RAID-a sar û pêçan têxin nav saxlemekê? Ma mafê kesên PHP heye ku jê re bernamenûs were gotin? Van nakokî, carinan, bi taybetî di xwezaya hebûnê de ne û ji bilî berjewendiya werzîşê ti bingehek wan tune.
Wusa çêbû ku bi hatina konteyneran û hemî vê pêjgeha hezkirî ya bi doker û k8-yên şertî re, nîqaşên "ji bo" û "li dijî" karanîna kapasîteyên nû di warên cihêreng ên paşerojê de dest pê kirin. (Werin em pêşî veqetandinê bikin ku her çend Kubernetes pir caran di vê nîqaşê de wekî orkestrator were destnîşan kirin, bijartina vê amûra taybetî ne girîngiyek bingehîn e. Di şûna wê de, hûn dikarin yeka din a ku ji we re herî hêsan û nasdar xuya dike biguhezînin. .)
Û, wusa dixuye, ev ê di navbera du aliyên heman pereyê de nakokiyek hêsan be. Bi qasî rûbirûbûna herheyî ya di navbera Win û Linux de, ku tê de mirovên têr li deverek navîn hene, bêaqil û bê dilovanî ye. Lê di mijara konteyneran de, her tişt ne ew çend hêsan e. Bi gelemperî di nakokiyên weha de aliyek rast tune, lê di rewşa konteynerên "bikaranîna" an "nebikaranîna" de ji bo hilanîna databasan, her tişt berovajî dibe. Ji ber ku di wateyekê de hem alîgir û hem jî dijberên vê nêzîkatiyê rast in.
Aliyê ronahî
Argumana The Light Side dikare bi yek gotinê bi kurtî were vegotin: "Silav, 2k19 li derveyî pencereyê ye!" Bê guman, ew wekî populîzmê dixuye, lê heke hûn bi hûrgulî li rewşê hûr bibin, avantajên wê hene. Werin em niha wan ji hev derxin.
Ka em bibêjin projeyek we ya mezin heye. Ew dikaribû di destpêkê de li ser bingeha nêzîkatiyek mîkro-xizmetê were çêkirin, an jî di hin xalan de ew bi rêgezek pêşveçûnê ve hatibe - ev bi rastî ne pir girîng e. We projeya me li mîkroxizmetên cihêreng belav kir, orkestrasyon, hevsengkirina barkirinê û pîvandinê saz kir. Û naha, bi wijdanek paqij, hûn li şûna ku hûn serverên ketî bilind bikin, di dema bandorên habra de mojito di hammokê de vedixwin. Lê di hemî çalakiyan de divê hûn hevgirtî bin. Pir caran, tenê serîlêdana xwe - kod - konteynirkirî ye. Ji bilî koda me çi heye?
Rast e, dane. Dilê her projeyek daneyên wê ye: ev dikare bibe DBMS-ya tîpîk - MySQL, Postgre, MongoDB, an hilanînê ku ji bo lêgerînê tê bikar anîn (ElasticSearch), hilanîna nirxa sereke ji bo cachkirinê - mînakî, redis, hwd. Niha em ne Em ê li ser vebijarkên bicîhkirina paşverû ya xelet biaxivin dema ku databas ji ber pirsên nebaş hatine nivîsandin têk diçe, û li şûna wê em ê li ser misogerkirina tolerasyona xeletiya vê databasê di bin barkirina xerîdar de biaxivin. Beriya her tiştî, gava ku em serîlêdana xwe konteynir dikin û dihêlin ku ew bi serbestî pîvandin da ku her hejmarek daxwazên hatîn pêvajoyê bike, ev bi xwezayî barkirina databasê zêde dike.
Bi rastî, kanala gihîştina databasê û servera ku ew lê dimeşe dibin çavê derziyê di pişta meya xweşik a konteynerê de. Di heman demê de, motîvasyona bingehîn a virtualbûna konteyneran tevgerîn û nermbûna strukturê ye, ku destûrê dide me ku belavkirina barkêşên lûtkeyê li seranserê binesaziya ku ji me re heye bi qasî ku gengaz organîze bike. Ango heke em hemî hêmanên heyî yên pergalê li seranserê komê konteynir nekin û nexin nav hev, em xeletiyek pir giran dikin.
Pir mentiqîtir e ku meriv ne tenê serîlêdanê bixwe, lê di heman demê de karûbarên ku ji hilanîna daneyan berpirsiyar in jî kom bikin. Bi komkirin û bicihkirina serverên malperê yên ku serbixwe dixebitin û barkirinê di nav xwe de di k8-an de belav dikin, em jixwe pirsgirêka hevdengkirina daneyan çareser dikin - heman şîroveyên li ser postan, ger em hin platformek medya an blogê wekî mînak bigirin. Di her rewşê de, me nûneriyek hundurîn, hetta virtual, ya databasê wekî Karûbarê Derve heye. Pirs ev e ku databas bixwe hîn kom nebûye - pêşkêşkerên webê yên ku di kubê de hatine bicîh kirin agahdariya li ser guheztinan ji databasa meya şerê statîk, ku ji hev vediqetîne, digirin.
Ma hûn girtina xwe hîs dikin? Em k8s an Swarm bikar tînin da ku barkirinê belav bikin û ji têkbirina servera webê ya sereke dûr bixin, lê em vê yekê ji bo databasê nakin. Lê heke databas têk bibe, wê hingê tevahiya binesaziya meya komkirî bê wate ye - rûpelên malperê yên vala ku xeletiyek gihîştina databasê vedigerînin çi feyde dikin?
Ji ber vê yekê pêdivî ye ku ne tenê serverên malperê, wekî ku bi gelemperî tê kirin, lê di heman demê de binesaziya databasê jî kom bikin. Tenê bi vî rengî em dikarin avahiyek ku bi tevahî di yek tîmekê de bixebite, lê di heman demê de ji hev serbixwe jî misoger bike. Wekî din, her çend nîvê paşiya me di bin barkirinê de "hilweşe", yên mayî dê sax bimînin, û pergala hevdengkirina databasan bi hevûdu re di hundurê komê de û şiyana ku bêdawî pîvandin û bicîhkirina komên nû dê bibe alîkar ku zû bigihîje kapasîteya pêwîst - heke tenê di navenda daneyê de rafik hebin.
Wekî din, modela databasê ya ku di koman de hatî belav kirin dihêle hûn vê databasê bigihînin cîhê ku hewce dike; Ger em li ser karûbarek gerdûnî diaxivin, wê hingê pir ne mentiqî ye ku meriv komek tevneyê li deverek devera San Francisco-yê bizivirîne û di heman demê de dema ku bigihîje databasek li herêma Moskowê û paş ve pakêtan bişîne.
Di heman demê de, konteynirkirina databasê dihêle hûn hemî hêmanên pergalê di heman astê abstraksiyonê de ava bikin. Ya ku, di encamê de, gengaz dike ku meriv vê pergalê rasterast ji kodê, ji hêla pêşdebiran ve, bêyî tevlêbûna çalak a rêvebiran ve rêve bibe. Pêşdebiran fikirîn ku ji bo bineprojeya nû DBMS-ek cihêreng hewce bû - hêsan! pelek yaml nivîsand, ew li komê barkir û hûn qediyan.
Û bê guman, operasyona navxweyî pir hêsan e. Ji min re bêje, te çend caran çavên xwe girtin dema ku endamek tîmê nû ji bo xebatê destên xwe xist nav databasa şer? Bi rastî, ya ku we tenê heye û niha dizivire kîjan e? Bê guman, em hemî li vir mezin in, û li deverek me piştgiriyek nû heye, û hîn dûrtir - li pişt refika bi xiyarên dapîrê û skirên kevn - parêzek din, belkî di depoya sar de jî, ji ber ku ofîsa we berê agir girtibû. Lê di heman demê de, her danasîna endamek tîmê nû ku gihîştina binesaziya şer û, bê guman, databasa şer heye, ji bo her kesê li derûdora xwe kelekek derbasdar e. Baş e, kî wî nas dike, nûbexş e, dibe ku ew xaçperest be? Ew tirsnak e, hûn ê bipejirînin.
Konteynerkirin û, bi rastî, topolojiya laşî ya belavkirî ya databasa projeya we ji we re dibe alîkar ku hûn ji van demên pejirandî dûr nekevin. Ma tu ji nûhekî bawer nakî? OK! Ka em komika xwe bidin wî ku pê re bixebite û databasê ji komên din veqetîne - hevdengkirin tenê bi pêlêdana destan û zivirandina hevdem a du bişkokan (yek ji bo pêşengê tîmê, ya din ji bo rêvebir). Û her kes kêfxweş e.
Û naha ew dem e ku meriv li dijberên komkirina databasê biguhezîne.
Aliyê tarî
Nîqaş kirin ku çima ne hêja ye ku databasê konteynir bikin û domkirina wê li ser yek serverek navendî bimeşînin, em ê xwe nedin ber retorîka ortodoksî û gotinên mîna "bapîran databasan li ser hardware dimeşandin, û em ê wusa jî!" Di şûna wê de, em hewl bidin ku bi rewşek ku tê de konteynirkirin dê bi rastî berdêlên berbiçav bide.
Bipejirînim, projeyên ku bi rastî hewceyê bingehek di konteynerê de ne, dikarin ji hêla ne operatorê çêtirîn makîneya şînkirinê ve li ser tiliyên yek dest werin hejmartin. Bi piranî, tewra karanîna k8s an jî Docker Swarm bixwe jî zêde ye - pir caran van amûran ji ber geşepêdana giştî ya teknolojiyê û helwestên "hêzdar" di şexsê zayendan de têne bikar anîn da ku her tiştî bixin nav ewr û konteynir. Welê, ji ber ku nuha moda ye û her kes wiya dike.
Bi kêmî ve nîvê rewşan de, karanîna Kubernetis an tenê Docker li ser projeyekê zêde ye. Pirsgirêk ev e ku hemî tîm an pargîdaniyên derveyî yên ku ji bo domandina binesaziya xerîdar hatine girtin ji vê yekê hay ne. Dema ku konteynir têne ferz kirin xirabtir e, ji ber ku ew miqdarek drav ji xerîdar re mesref dike.
Bi gelemperî, nerînek heye ku mafyaya docker/cube bi ehmeqî xerîdarên ku van pirsgirêkên binesaziyê derdixin derdixe. Beriya her tiştî, ji bo ku em bi koman re bixebitin, pêdivî ye ku em endezyarên ku jêhatî bin û bi gelemperî mîmariya çareseriya bicîhkirî fam bikin. Me berê berê doza xwe bi weşana Komarê re diyar kir - li wir me tîmê xerîdar perwerde kir ku di rastiyên Kubernetis de bixebite, û her kes razî bû. Û hêja bû. Bi gelemperî, "cîhankerên" k8s binesaziya xerîdar rehîn digirin - ji ber ku naha tenê ew fam dikin ka her tişt li wir çawa dixebite; li milê xerîdar pispor tune.
Naha bifikirin ku bi vî rengî em ne tenê beşa servera malperê, lê di heman demê de lênihêrîna databasê jî derdixin. Me got ku BD dil e û windakirina dil ji bo her organîzmayek zindî kujer e. Bi kurtasî, perspektîf ne çêtirîn in. Ji ber vê yekê, li şûna hype Kubernetis, divê gelek proje bi tenê bi tarîfa normal a AWS-ê re aciz nebin, ku dê hemî pirsgirêkên bi barkirina li ser malpera / projeya wan çareser bike. Lê AWS êdî ne moda ye, û pêşandan ji drav bêtir hêja ne - mixabin, di hawîrdora IT de jî.
OK. Dibe ku proje bi rastî hewceyê kombûnê ye, lê heke her tişt bi serîlêdanên bêdewlet re zelal be, wê hingê em çawa dikarin girêdana torê ya maqûl ji bo databasek komkirî organîze bikin?
Ger em behsa çareseriyek endezyariyê ya bêkêmasî dikin, ya ku veguheztina k8s e, wê hingê serêşiya meya sereke dubarekirina daneyan di databasek komkirî de ye. Hin DBMS di destpêkê de bi belavkirina daneyan di navbera mînakên wan ên kesane de pir dilsoz in. Gelek kesên din ew qas bixêrwazî ne. Û pir caran argumana sereke di hilbijartina DBMS-ê de ji bo projeya me ne şiyana dubarekirina bi hindik çavkanî û lêçûnên endezyariyê ye. Nemaze heke proje di destpêkê de wekî mîkroxizmetek nehatibû plansaz kirin, lê bi tenê di vî alî de pêş ket.
Em difikirin ku ne hewce ye ku meriv li ser leza ajokarên torê biaxive - ew hêdî ne. Ewan. Em hîn jî fersendek rast nînin, heke tiştek çêbibe, ku em mînakek DBMS li cîhek ku lê zêde heye ji nû ve bidin destpêkirin, mînakî, hêza pêvajoyê an RAM-a belaş. Em ê pir zû bikevin performansa binepergala dîska virtual. Li gorî vê yekê, DBMS pêdivî ye ku li ser makîneyên xwe yên kesane yên ku li nêzê wan de cih digirin, were girêdan. An jî pêdivî ye ku meriv bi rengekî veqetandî hevdemkirina daneya têra xwe bilez ji bo rezervên gumanbar sar bike.
Berdewamkirina mijara pergalên pelan ên virtual: Volumên Docker, mixabin, ne bê pirsgirêk in. Bi gelemperî, di mijarek wekî hilanîna daneya pêbawer a dirêj-dirêj de, ez dixwazim bi pileyên teknîkî yên herî hêsan re çêbikim. Û lê zêdekirina qatek abstraksiyonê ya nû ji FS-ya konteynerê li FS-ya mêvandarê dêûbav bi serê xwe xetereyek e. Lê gava ku xebata pergala piştevaniya konteyneran di veguheztina daneyan de di navbera van qatan de jî zehmetiyan tê, wê hingê ew bi rastî karesatek e. Di vê demê de, piraniya pirsgirêkên ku ji bo mirovahiya pêşverû naskirî xuya dike ku ji holê hatine rakirin. Lê hûn fam dikin, mekanîzma çiqas tevlihevtir be, ew qas hêsantir diqelişe.
Di ronahiya van hemî "serpêhatiyan" de, girtina databasê li yek cîhek pir bikêrtir û hêsantir e, û hetta ku hûn hewce ne ku serîlêdanê konteynir bikin, bihêlin ku ew bi serê xwe bixebite û di nav dergehê belavkirinê de pêwendiya hevdemî bi database, ku dê tenê carekê û li yek cîhek were xwendin û nivîsandin. Ev nêzîkatî îhtîmala xeletî û desenkronîzekirinê bi kêmanî kêm dike.
Em ber bi çi ve diçin? Digel vê yekê, konteynirkirina databasê li cîhê ku hewcedariya wê ya rastîn hebe guncan e. Hûn nekarin danegehek tev-serlêdan dakêşin û wê bizivirînin mîna ku we du dehan mîkroxizmet hene - ew bi vî rengî naxebite. Û divê ev yek bi zelalî were fêm kirin.
Li şûna hilberê
Ger hûn li benda encamek zelal in "ji bo virtualîzekirina databasê an na", wê hingê em ê we bêhêvî bikin: ew ê ne li vir be. Ji ber ku di dema afirandina çareseriyek binesaziyê de, divê mirov ne bi moda û pêşkeftinê, lê berî her tiştî bi aqilê hevbeş were rêve kirin.
Proje hene ku ji bo wan prensîb û amûrên ku bi Kubernetis re tê de bi rengek bêkêmasî li hev dikin, û di projeyên weha de bi kêmî ve li qada paşîn aştî heye. Û proje hene ku ne hewceyê konteynerkirinê, lê binesaziyek serverek normal in, ji ber ku ew di bingeh de nekarin modela koma mîkroservisê ji nû ve binirxînin, ji ber ku ew ê bikevin.
Source: www.habr.com