Disi, historikisht, industria e IT-së është e ndarë në dy kampe të kushtëzuara për çfarëdo arsye: ata që janë "për" dhe ata që janë "kundër". Për më tepër, lënda e mosmarrëveshjeve mund të jetë plotësisht arbitrare. Cili OS është më i mirë: Win apo Linux? Në një smartphone Android ose iOS? A duhet të ruani gjithçka në retë apo ta vendosni në ruajtje të ftohtë RAID dhe t'i vendosni vidhat në një kasafortë? A kanë të drejtë njerëzit e PHP të quhen programues? Këto mosmarrëveshje, nganjëherë, janë ekskluzivisht ekzistenciale në natyrë dhe nuk kanë bazë tjetër përveç interesit sportiv.
Kështu ndodhi që me ardhjen e kontejnerëve dhe gjithë kësaj kuzhine të dashur me docker dhe k8 të kushtëzuara, filluan debatet "për" dhe "kundër" përdorimit të aftësive të reja në fusha të ndryshme të backend. (Le të bëjmë një rezervë paraprakisht se megjithëse Kubernetes do të tregohet më së shpeshti si orkestrues në këtë diskutim, zgjedhja e këtij mjeti të veçantë nuk është thelbësore. Përkundrazi, ju mund të zëvendësoni ndonjë tjetër që ju duket më i përshtatshëm dhe i njohur .)
Dhe, me sa duket, kjo do të ishte një mosmarrëveshje e thjeshtë midis dy anëve të së njëjtës monedhë. Po aq e pakuptimtë dhe e pamëshirshme sa edhe përballja e përjetshme mes Win vs Linux, në të cilën njerëzit adekuat ekzistojnë diku në mes. Por në rastin e kontejnerizimit, jo gjithçka është kaq e thjeshtë. Zakonisht në mosmarrëveshje të tilla nuk ka anën e duhur, por në rastin e "përdorimit" ose "mos përdorimit" të kontejnerëve për ruajtjen e bazave të të dhënave, gjithçka kthehet përmbys. Sepse në një farë kuptimi, si mbështetësit ashtu edhe kundërshtarët e kësaj qasjeje kanë të drejtë.
Ana e ndritshme
Argumenti i Light Side mund të përshkruhet shkurtimisht me një frazë: "Përshëndetje, 2k19 është jashtë dritares!" Tingëllon si populizëm, sigurisht, por nëse thellohesh në situatën në detaje, ajo ka avantazhet e saj. Le t'i zgjidhim ato tani.
Le të themi se keni një projekt të madh në internet. Mund të ishte ndërtuar fillimisht në bazë të një qasjeje mikroshërbimi, ose në një moment ai erdhi tek ai përmes një rruge evolucionare - kjo nuk është shumë e rëndësishme, në fakt. Ju e shpërndave projektin tonë në mikroshërbime të veçanta, konfigurove orkestrimin, balancimin e ngarkesës dhe shkallëzimin. Dhe tani, me një ndërgjegje të pastër, ju pini një mojito në një shtrat i varur gjatë efekteve habra në vend që të ngrini serverë të rënë. Por në të gjitha veprimet duhet të jeni konsistent. Shumë shpesh, vetëm vetë aplikacioni - kodi - është kontejnerizuar. Çfarë kemi tjetër përveç kodit?
Kjo është e drejtë, të dhëna. Zemra e çdo projekti janë të dhënat e tij: kjo mund të jetë ose një DBMS tipike - MySQL, Postgre, MongoDB, ose hapësirë ruajtëse e përdorur për kërkim (ElasticSearch), ruajtja me vlerë kyçe për caching - për shembull, redis, etj. Aktualisht nuk jemi ne do të flasim për opsionet e shtrembëruara të zbatimit të backend-it kur baza e të dhënave prishet për shkak të pyetjeve të shkruara keq, dhe në vend të kësaj do të flasim për sigurimin e tolerancës së gabimeve të kësaj baze të dhënash nën ngarkesën e klientit. Në fund të fundit, kur e vendosim në kontejnerë aplikacionin tonë dhe e lejojmë atë të shkallëzohet lirisht për të përpunuar çdo numër kërkesash hyrëse, kjo natyrisht rrit ngarkesën në bazën e të dhënave.
Në fakt, kanali për të hyrë në bazën e të dhënave dhe serveri në të cilin funksionon bëhen syri i gjilpërës në fundin tonë të bukur me kontejnerë. Në të njëjtën kohë, motivi kryesor i virtualizimit të kontejnerëve është lëvizshmëria dhe fleksibiliteti i strukturës, gjë që na lejon të organizojmë shpërndarjen e ngarkesave të pikut në të gjithë infrastrukturën e disponueshme për ne në mënyrë sa më efikase. Kjo do të thotë, nëse nuk i vendosim kontejnerët dhe nuk i shpërndajmë të gjithë elementët ekzistues të sistemit në të gjithë grupin, ne po bëjmë një gabim shumë të rëndë.
Është shumë më logjike të grumbullosh jo vetëm vetë aplikacionin, por edhe shërbimet përgjegjëse për ruajtjen e të dhënave. Duke grumbulluar dhe vendosur serverë ueb që punojnë në mënyrë të pavarur dhe shpërndajnë ngarkesën mes tyre në k8, ne tashmë po zgjidhim problemin e sinkronizimit të të dhënave - të njëjtat komente në postime, nëse marrim si shembull disa platforma mediatike ose blogje. Në çdo rast, ne kemi një përfaqësim brenda-klaster, madje edhe virtual, të bazës së të dhënave si ExternalService. Pyetja është se vetë baza e të dhënave nuk është ende e grumbulluar - serverët e uebit të vendosur në kub marrin informacione rreth ndryshimeve nga baza e të dhënave tona të luftimeve statike, e cila rrotullohet veçmas.
A ndjen një kapje? Ne përdorim k8s ose Swarm për të shpërndarë ngarkesën dhe për të shmangur prishjen e serverit kryesor të internetit, por ne nuk e bëjmë këtë për bazën e të dhënave. Por nëse baza e të dhënave rrëzohet, atëherë e gjithë infrastruktura jonë e grumbulluar nuk ka kuptim - çfarë dobie kanë faqet boshe të internetit që kthejnë një gabim aksesi në bazën e të dhënave?
Kjo është arsyeja pse është e nevojshme të grumbullohen jo vetëm serverët në internet, siç bëhet zakonisht, por edhe infrastruktura e bazës së të dhënave. Vetëm në këtë mënyrë mund të sigurojmë një strukturë që funksionon plotësisht në një ekip, por në të njëjtën kohë të pavarur nga njëri-tjetri. Për më tepër, edhe nëse gjysma e backend-it tonë "shembet" nën ngarkesë, pjesa tjetër do të mbijetojë, dhe sistemi i sinkronizimit të bazave të të dhënave me njëri-tjetrin brenda grupit dhe aftësia për të shkallëzuar dhe vendosur pafundësisht grupime të reja do të ndihmojë në arritjen e shpejtë të kapacitetit të kërkuar - sikur të kishte rafte në qendrën e të dhënave.
Për më tepër, modeli i bazës së të dhënave të shpërndarë në grupe ju lejon të çoni pikërisht këtë bazë të dhënash atje ku është e nevojshme; Nëse po flasim për një shërbim global, atëherë është mjaft e palogjikshme të rrotullohet një grup ueb diku në zonën e San Franciskos dhe në të njëjtën kohë të dërgohen pako kur hyni në një bazë të dhënash në rajonin e Moskës dhe mbrapa.
Gjithashtu, kontejnerizimi i bazës së të dhënave ju lejon të ndërtoni të gjithë elementët e sistemit në të njëjtin nivel abstraksioni. E cila, nga ana tjetër, bën të mundur menaxhimin e këtij sistemi drejtpërdrejt nga kodi, nga zhvilluesit, pa përfshirjen aktive të administratorëve. Zhvilluesit menduan se një DBMS e veçantë ishte e nevojshme për nënprojektin e ri - e lehtë! shkroi një skedar yaml, e ngarkoi atë në grup dhe ju mbaroni.
Dhe sigurisht, funksionimi i brendshëm është thjeshtuar shumë. Më thuaj, sa herë i ke mbyllur sytë kur një anëtar i ri i ekipit fut duart në bazën e të dhënave të luftimeve për punë? Cili, në fakt, është i vetmi që keni dhe po rrotullohet tani? Sigurisht, ne jemi të gjithë të rritur këtu, dhe diku kemi një rezervë të freskët, madje edhe më larg - pas raftit me trangujve të gjyshes dhe skive të vjetra - një tjetër rezervë, ndoshta edhe në magazinë të ftohtë, sepse zyra juaj tashmë digjej dikur. Por gjithsesi, çdo prezantim i një anëtari të ri të ekipit me akses në infrastrukturën luftarake dhe, natyrisht, në bazën e të dhënave luftarake është një kovë validol për të gjithë përreth. Epo, kush e njeh atë, një i ri, ndoshta ai është me dorë të kryqëzuar? Është e frikshme, do të pajtoheni.
Kontejnerizimi dhe, në fakt, topologjia fizike e shpërndarë e bazës së të dhënave të projektit tuaj ndihmon për të shmangur momente të tilla vërtetimi. Nuk i besoni një fillestari? NE RREGULL! Le t'i japim atij grupin e tij për të punuar dhe shkëputjen e bazës së të dhënave nga grupimet e tjera - sinkronizimi vetëm me shtytje manuale dhe rrotullim sinkron të dy çelësave (njëri për drejtuesin e ekipit, tjetri për administratorin). Dhe të gjithë janë të lumtur.
Dhe tani është koha për t'u kthyer në kundërshtarë të grupimit të bazës së të dhënave.
Ana e erret
Duke argumentuar pse nuk ia vlen të kontejnerojmë bazën e të dhënave dhe të vazhdojmë ta ekzekutojmë në një server qendror, ne nuk do të përkulemi në retorikën e ortodoksive dhe deklaratave si "gjyshërit drejtonin bazat e të dhënave në harduer, dhe po kështu do të bëjmë ne!" Në vend të kësaj, le të përpiqemi të dalim me një situatë në të cilën kontejnerizimi në fakt do të paguante dividentë të prekshëm.
Pajtohem, projektet që vërtet kanë nevojë për një bazë në një enë mund të numërohen në gishtat e njërës dorë nga operatori jo më i mirë i makinës bluarëse. Në pjesën më të madhe, edhe përdorimi i k8s ose vetë Docker Swarm është i tepërt - mjaft shpesh këtyre mjeteve u drejtohen për shkak të zhurmës së përgjithshme të teknologjive dhe qëndrimeve të "të plotfuqishmit" në personin e gjinive për të shtyrë gjithçka në retë dhe kontejnerët. Epo, sepse tani është në modë dhe të gjithë e bëjnë atë.
Në të paktën gjysmën e rasteve, përdorimi i Kubernetis ose thjesht Docker në një projekt është i tepërt. Çështja është se jo të gjitha ekipet ose kompanitë e jashtme të punësuara për të mirëmbajtur infrastrukturën e klientit janë të vetëdijshëm për këtë. Është më keq kur vendosen kontejnerë, sepse klientit i kushton një sasi të caktuar monedhash.
Në përgjithësi, ekziston një mendim se mafia e dokerit/kubeve po shtyp budallallëk klientët që kontraktojnë këto çështje të infrastrukturës. Në fund të fundit, për të punuar me grupe, ne kemi nevojë për inxhinierë që janë të aftë për këtë dhe në përgjithësi të kuptojnë arkitekturën e zgjidhjes së zbatuar. Dikur e kemi përshkruar tashmë rastin tonë me botimin e Republikës - atje kemi trajnuar ekipin e klientit për të punuar në realitetet e Kubernetis dhe të gjithë ishin të kënaqur. Dhe ishte e denjë. Shpesh, "zbatuesit" e k8s marrin peng infrastrukturën e klientit - sepse tani vetëm ata e kuptojnë se si funksionon gjithçka atje; nuk ka specialistë në anën e klientit.
Tani imagjinoni që në këtë mënyrë ne kontraktojmë jo vetëm pjesën e serverit në internet, por edhe mirëmbajtjen e bazës së të dhënave. Thamë që BD është zemra dhe humbja e zemrës është fatale për çdo organizëm të gjallë. Me pak fjalë, perspektivat nuk janë më të mirat. Pra, në vend të hype Kubernetis, shumë projekte thjesht nuk duhet të shqetësohen me tarifën normale për AWS, e cila do të zgjidhë të gjitha problemet me ngarkesën në faqen/projektin e tyre. Por AWS nuk është më në modë dhe sfilatat vlejnë më shumë se paratë - për fat të keq, edhe në mjedisin e IT.
NE RREGULL. Ndoshta projekti ka vërtet nevojë për grupim, por nëse gjithçka është e qartë me aplikacionet pa shtetësi, atëherë si mund të organizojmë lidhje të mirë rrjeti për një bazë të dhënash të grumbulluar?
Nëse po flasim për një zgjidhje inxhinierike pa probleme, që është ajo që është kalimi në k8s, atëherë dhimbja jonë kryesore është riprodhimi i të dhënave në një bazë të dhënash të grumbulluar. Disa DBMS fillimisht janë mjaft besnikë ndaj shpërndarjes së të dhënave ndërmjet instancave të tyre individuale. Shumë të tjerë nuk janë aq të mirëpritur. Dhe mjaft shpesh argumenti kryesor në zgjedhjen e një DBMS për projektin tonë nuk është aftësia për t'u përsëritur me kosto minimale të burimeve dhe inxhinierisë. Sidomos nëse projekti nuk ishte planifikuar fillimisht si një mikroshërbim, por thjesht evoluoi në këtë drejtim.
Ne mendojmë se nuk ka nevojë të flasim për shpejtësinë e disqeve të rrjetit - ato janë të ngadalta. ato. Ne ende nuk kemi një mundësi reale, nëse ndodh diçka, për të rifilluar një shembull DBMS diku ku ka më shumë, për shembull, fuqi procesori ose RAM të lirë. Shumë shpejt do të hasim në performancën e nënsistemit të diskut të virtualizuar. Rrjedhimisht, DBMS duhet të lidhet me grupin e vet personal të makinave të vendosura në afërsi. Ose është e nevojshme që disi të qetësohet veçmas sinkronizimi mjaft i shpejtë i të dhënave për rezervat e supozuara.
Vazhdimi i temës së sistemeve të skedarëve virtualë: Vëllimet e Docker, për fat të keq, nuk janë pa probleme. Në përgjithësi, në një çështje të tillë si ruajtja afatgjatë e të dhënave të besueshme, do të doja të mjaftoja me skemat teknikisht më të thjeshta. Dhe shtimi i një shtrese të re abstraksioni nga FS e kontejnerit në FS të pritësit prind është një rrezik në vetvete. Por kur funksionimi i sistemit të mbështetjes së kontejnerëve ndeshet gjithashtu me vështirësi në transmetimin e të dhënave midis këtyre shtresave, atëherë është me të vërtetë një fatkeqësi. Për momentin, shumica e problemeve të njohura për njerëzimin progresiv duket se janë çrrënjosur. Por ju e kuptoni, sa më kompleks të jetë mekanizmi, aq më lehtë prishet.
Në dritën e të gjitha këtyre "aventurave", është shumë më fitimprurëse dhe më e lehtë të mbash bazën e të dhënave në një vend, dhe edhe nëse duhet ta kontejneroni aplikacionin, lëreni të funksionojë vetë dhe përmes portës së shpërndarjes të marrë komunikim të njëkohshëm me Baza e të dhënave, e cila do të lexohet dhe shkruhet vetëm një herë dhe në një vend. Kjo qasje zvogëlon mundësinë e gabimeve dhe desinkronizimit në minimum.
Në çfarë po çojmë? Për më tepër, kontejnerizimi i bazës së të dhënave është i përshtatshëm aty ku ka një nevojë reale për të. Ju nuk mund të mbushni një bazë të dhënash me aplikacione të plota dhe ta rrotulloni atë sikur të kishit dy duzina mikroshërbime - nuk funksionon në këtë mënyrë. Dhe kjo duhet kuptuar qartë.
Në vend të prodhimit
Nëse jeni duke pritur për një përfundim të qartë "për të virtualizuar bazën e të dhënave apo jo", atëherë ne do t'ju zhgënjejmë: nuk do të jetë këtu. Sepse kur krijoni ndonjë zgjidhje infrastrukturore, duhet të udhëhiqet jo nga moda dhe përparimi, por, para së gjithash, nga arsyeja e shëndoshë.
Ka projekte për të cilat parimet dhe mjetet që vijnë me Kubernetis përshtaten në mënyrë të përsosur, dhe në projekte të tilla ka paqe të paktën në zonën e pasme. Dhe ka projekte që nuk kanë nevojë për kontejnerizim, por për një infrastrukturë normale serveri, sepse në thelb nuk mund të rishkallëzohen në modelin e grupit të mikroshërbimeve, sepse do të bien.
Burimi: www.habr.com