Historikisht, industria IT është ndarë në dy grupe të kushteve: ata që janë "për" dhe ata që janë "kundër". Subjekti i debatit mund të jetë plotësisht arbitrar. Cila sistem operativ është më i mirë: Win apo Linux? Në smartfon, Android apo iOS? Të ruajmë gjithçka në cloud apo ta ngarkojmë në depozita RAID dhe t'i vendosim disqet në kasafortë? A kanë të drejtë PHP-istët të quhen programues? Këto debate, herë pas here, kanë një karakter eksistencial dhe nuk kanë asnjë bazë tjetër, përveç interesit sportiv.
Kështu ndodhi që me shfaqjen e kontejnerëve dhe të gjithë kësaj kuzhine që ne e duam me Docker dhe Kubernetes, filluan debatet "për" dhe "kundër" përdorimit të mundësive të reja në fusha të ndryshme të backend. (Një parantesë paraprake, zakonisht në këtë diskutim, do të përmendet Kubernetes si orkestrator, por zgjedhja e këtij instrumenti nuk ka rëndësi të veçantë. Mund të zëvendësohet me çdo mjet tjetër që ju duket më i përshtatshëm dhe i njohur.)
Dhe, duket se do të ishte një debat i thjeshtë midis dy anëve të një monedhe. Njësoj të pamenduara dhe të ashpra, si përballja e përjetshme Win vs Linux, në të cilën njerëzit e arsyeshëm ekzistojnë diku në mes. Por në rastin e kontejnerizimit, gjërat nuk janë aq të thjeshta. Zakonisht në këto debate nuk ka një anë të drejtë, por në rasti i "përdorimit" ose "mos përdorimit" të kontejnerëve për ruajtjen e DB-ve, gjithçka përmbys. Sepse në njëfarë kuptimi, të dyja palët janë të drejta, si mbështetësit ashtu edhe kundërshtarët e këtij qasje.
Anët e Mira
PĂ«r tĂ« pĂ«rmbledhur argumentimin e AnĂ«ve tĂ« Mira nĂ« njĂ« frazĂ«: âHej, 2k19 Ă«shtĂ« pĂ«rjashtuar!â TingĂ«llon si populizĂ«m, sigurisht, por nĂ«se shqyrtojmĂ« situatĂ«n nĂ« detaje, ka avantazhet e saj. Tani po i analizojmĂ« ato.
Supozoni se keni njĂ« projekt tĂ« madh nĂ« web. Ai mund tĂ« jetĂ« ndĂ«rtuar fillimisht mbi njĂ« qasje mikroshĂ«rbimi, ose nĂ« ndonjĂ« moment ka arritur aty pĂ«rmes njĂ« rrugĂ« evolucionar â kjo nuk Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme, nĂ« tĂ« vĂ«rtetĂ«. Ju keni shpĂ«rndarĂ« projektin tuaj nĂ« mikroshĂ«rbime tĂ« veçanta, keni vendosur orkestrimin, balancimin e ngarkesĂ«s, dhe shkallĂ«zimin. Dhe tani me njĂ« ndĂ«rgjegje tĂ« pastĂ«r po pini mojito nĂ« hamak gjatĂ« efekteve tĂ« Habra nĂ« vend qĂ« tĂ« ngrihni serverat qĂ« kanĂ« rĂ«nĂ«. Por nĂ« tĂ« gjitha veprimet duhet tĂ« jemi tĂ« qĂ«ndrueshĂ«m. ShumĂ« shpesh, vetĂ«m vetĂ« aplikacioni â kodi, kryhet nĂ« kontejnerĂ«. Por çfarĂ« tjetĂ«r kemi pĂ«rveç kodit?
SaktĂ«sisht, tĂ« dhĂ«nat. Zemra e çdo projekti janĂ« tĂ« dhĂ«nat e tij: kĂ«to mund tĂ« jenĂ« si njĂ« DB tipik â MySQL, Postgre, MongoDB, ashtu si edhe magazinat qĂ« pĂ«rdoren pĂ«r kĂ«rkime (ElasticSearch), magazinat e çelĂ«sit-vlerĂ« pĂ«r keqkuptime â pĂ«r shembull, redis, etj. Tani nuk do tĂ« flasim pĂ«r variantet e kĂ«qija tĂ« implementimit tĂ« backend-it, ku DB bie pĂ«r shkak tĂ« pyetjeve tĂ« shkuara keq, por pĂ«rkundrazi do tĂ« flasim pĂ«r sigurimin e qĂ«ndrueshmĂ«risĂ« sĂ« kĂ«saj DB pĂ«rballĂ« ngarkesĂ«s sĂ« klientĂ«ve. Sepse kur kontejnerizojmĂ« aplikacionin tonĂ« dhe e lejojmĂ« tĂ« shkallĂ«zohet lirshĂ«m pĂ«r tĂ« trajtuar çdo sasi tĂ« kĂ«rkesave hyrĂ«se, kjo gjithashtu rrit ngarkesĂ«n nĂ« bazĂ«n e tĂ« dhĂ«nave.
NĂ« fakt, kanali i aksesit nĂ« bazĂ«n e tĂ« dhĂ«nave dhe serveri, mbi tĂ« cilin ajo funksionon, bĂ«hen njĂ« gozhdĂ« nĂ« bukurinĂ« tonĂ« tĂ« backend-it tĂ« kontejnerizuar. NdĂ«rkohĂ« motivi kryesor i virtualizimit nĂ« kontejnerĂ« Ă«shtĂ« lĂ«vizshmĂ«ria dhe plastika e strukturĂ«s, qĂ« lejon organizimin e shpĂ«rndarjes sĂ« ngarkesĂ«s pikĂ«sore nĂ« tĂ«rĂ« infrastrukturĂ«n tonĂ« tĂ« disponueshme sa mĂ« efektivisht. KĂ«shtu, nĂ«se nuk kontejnerizojmĂ« dhe nuk shpĂ«rndajmĂ« nĂ« klaster tĂ« gjithĂ« elementĂ«t e sistemit â ne po bĂ«mĂ« njĂ« gabim shumĂ« serioz.
KaqĂ« tĂ« arsyeshme Ă«shtĂ« tĂ« klasifikosh jo vetĂ«m aplikacionin vetĂ«, por edhe shĂ«rbimet qĂ« janĂ« pĂ«rgjegjĂ«se pĂ«r ruajtjen e tĂ« dhĂ«nave. Kur klasifikojmĂ« dhe vendosim web-serverĂ« qĂ« funksionojnĂ« nĂ« mĂ«nyrĂ« tĂ« pavarur dhe shpĂ«rndajnĂ« ngarkesĂ«n ndĂ«rmjet vetes nĂ« k8s, ne tashmĂ« zgjidhim problemin e sinkronizimit tĂ« tĂ« dhĂ«nave â pĂ«r shembull, komenteve nĂ« postime, nĂ«se marrim si shembull ndonjĂ« platformĂ« mediatike ose blogu. Ne, nĂ« çdo rast, krijojmĂ« njĂ« pĂ«rfaqĂ«sim tĂ« brendshĂ«m tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave, ndonĂ«se virtual, si njĂ« ShĂ«rbim tĂ« JashtĂ«m. Problemi qĂ«ndron nĂ« faktin qĂ« vetĂ« baza e tĂ« dhĂ«nave ende nuk Ă«shtĂ« klasifikuar â web-serverat e vendosur nĂ« kub po marrin informacion nĂ« lidhje me ndryshimet nga baza jonĂ« statike tĂ« dhĂ«nash qĂ« funksionon ndaras.
A ndiheni ndonjĂ«herĂ« tĂ« dyshimtĂ«? Ne pĂ«rdorim k8s ose Swarm pĂ«r tĂ« shpĂ«rndarĂ« ngarkesĂ«n dhe pĂ«r tĂ« shmangur rĂ«nien e tĂ«rĂ«sishme serverin web, por ne nuk e bĂ«jmĂ« kĂ«tĂ« pĂ«r bazĂ«n e tĂ« dhĂ«nave. Por nĂ«se rĂ«nka baza e tĂ« dhĂ«nave, atĂ«herĂ« nĂ« tĂ« gjithĂ« infrastrukturĂ«n tonĂ« tĂ« klasifikuar nuk ka kuptim â çfarĂ« do tĂ« ishim duke bĂ«rĂ« me faqet e zbrazĂ«ta qĂ« kthejnĂ« njĂ« gabim pĂ«r qasjen nĂ« bazĂ«n e tĂ« dhĂ«nave?
PikĂ«risht pĂ«r kĂ«tĂ« arsye, duhet tĂ« klasifikojmĂ« jo vetĂ«m web-serverat, siç bĂ«het zakonisht, por edhe infrastrukturĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave. VetĂ«m nĂ« kĂ«tĂ« mĂ«nyrĂ« mund tĂ« sigurojmĂ« njĂ« strukturĂ« qĂ« punon plotĂ«sisht nĂ« njĂ« tĂ«rĂ«si, por megjithatĂ« e pavarur nga njĂ«ra-tjetra. Madje edhe nĂ«se gjysma e backend-it tonĂ« 'shembet' nĂ«n ngarkesĂ« â pjesa tjetĂ«r do tĂ« mbijetojĂ«, dhe sistemi i sinkronizimit tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave midis tyre brenda klasterit dhe mundĂ«sia e sistemit tĂ« pafund pĂ«r shkallĂ«zim dhe vendosje tĂ« klasterĂ«ve tĂ« rinj do tĂ« ndihmojĂ« pĂ«r tĂ« arritur shpejt fuqitĂ« e nevojshme â mjafton tĂ« kenĂ« raftet nĂ« qendrĂ«n e tĂ« dhĂ«nave.
Përveç kësaj, modeli i shpërndarë i bazës së të dhënave në klastera lejon që ne ta dërgojmë këtë bazë të dhënash aty ku nevojitet; nëse flasim për një shërbim global, atëherë është mjaft e pavend të synojmë një web-klaster diku në rrethin e San Franciskos dhe t'i dërgojmë paketat për qasje në bazën e të dhënave në Podmoskovje dhe mbrapsht.
Po ashtu, containerizimi i bazĂ«s sĂ« tĂ« dhĂ«nave lejon ndĂ«rtimin e tĂ« gjithĂ« elementĂ«ve tĂ« sistemit nĂ« tĂ« njĂ«jtin nivel abstraksioni. Ăka, nga ana e saj, e bĂ«n tĂ« mundur menaxhimin e kĂ«tij sistemi direkt nga kodi, nga zhvilluesit, pa tĂ«rheqjen aktive tĂ« administratorĂ«ve. Zhvilluesit menduan se ishte e nevojshme njĂ« DBMS e veçantĂ« pĂ«r njĂ« nĂ«nprojekt tĂ« ri â lehtĂ«! shkruan njĂ« skedar yaml, e ngarkon nĂ« klaster dhe Ă«shtĂ« gati.
Natyrisht, operimi i brendshĂ«m bĂ«het shumĂ« mĂ« i lehtĂ«. MĂ« tregoni, sa herĂ« keni mbyllur sytĂ« nĂ« momentet kur njĂ« anĂ«tar i ri i ekipit pĂ«rfundon nĂ« bazĂ«n e tĂ« dhĂ«nave nĂ« prodhim? E cila, nĂ« fakt, Ă«shtĂ« njĂ« dhe po funksionon pikĂ«risht tani? Sigurisht, tĂ« gjithĂ« ne jemi tĂ« rritur dhe ndoshta kemi njĂ« kopje rezervĂ« tĂ« freskĂ«t, dhe pĂ«r mĂ« tepĂ«r â pas raftit me turshitĂ« e gjyshes dhe ski tĂ« vjetra â njĂ« kopje rezervĂ« tjetĂ«r, ndoshta madje nĂ« ruajtje tĂ« ftohtĂ«, sepse njĂ« herĂ« zyrat tuaja ishin nĂ« zjarr. Por megjithatĂ«, çdo hyrje e njĂ« anĂ«tari tĂ« ri nĂ« ekip, qĂ« ka qasje nĂ« infrastrukturĂ«n nĂ« prodhim dhe, natyrisht, nĂ« bazĂ«n e tĂ« dhĂ«nave nĂ« prodhim â Ă«shtĂ« njĂ« brez validoli pĂ«r tĂ« gjithĂ« tĂ« pranishmit. Kush e di, ndoshta ai, novatori, Ă«shtĂ« i paaftĂ«? FrikĂ«sohuni, pranojeni.
Kontenerizimi dhe, nĂ« thelb, topologjia fizike e shpĂ«rndarĂ« e bazĂ«s sĂ« tĂ« dhĂ«nave tĂ« projetit tuaj ndihmon nĂ« shmangien e kĂ«tyre momenteve tĂ« stresit. Nuk i besoni novatorit? MirĂ«! Do tĂ« krijojmĂ« njĂ« klaster tĂ« tij pĂ«r punĂ« dhe do ta ndĂ«rojmĂ« nga klasterĂ«t e tjerĂ« tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave â sinhronizimi vetĂ«m pĂ«rmes njĂ« qĂ«ndrese manuale dhe kthetrave sinkron tĂ« dy çelĂ«save (njĂ« pĂ«r liderin e ekipit, e dyta pĂ«r administratorin). Dhe tĂ« gjithĂ« janĂ« tĂ« lumtur.
Tani ka ardhur koha për të kaluar në anën e kundërt të kontenerizimit të bazave të të dhënave.
Anija e Errët
Duke diskutuar se pse nuk duhet të kontenerizojmë bazën e të dhënave dhe të vazhdojmë ta mbajmë atë në një qendër të vetme server, nuk do të zbresim në retorikën e ortodoksëve dhe tehet e thënieve si "të parët e mbajti bazën në harduer, dhe ne do ta bëjmë!" Në vend të kësaj le të përpiqemi të imagjinojmë një situatë, në të cilën kontenerizimi do të sillte vërtet përfitime të dukshme.
Pranojeni, projektet qĂ« vĂ«rtet kanĂ« nevojĂ« pĂ«r njĂ« bazĂ« nĂ« kontenier mund tĂ« numĂ«rohen me gishtat e njĂ« dora tĂ« njĂ« frizuesi tĂ« jo aq tĂ« mirĂ«. NĂ« shumicĂ«n e rasteve, pĂ«rdorimi i k8s ose Docker Swarm Ă«shtĂ« tepĂ«r â shpeshherĂ« kĂ«to mjete pĂ«rdoren pĂ«r shkak se janĂ« nĂ« modĂ« dhe pĂ«r shkak tĂ« kĂ«rkesave "supreme" nga menaxherĂ«t pĂ«r ta futur gjithçka nĂ« re dhe contĂ«inierĂ«. Sepse tani Ă«shtĂ« nĂ« modĂ« dhe kĂ«shtu veprojnĂ« tĂ« gjithĂ«.
Në shumicën e rasteve, përdorimi i Kubernetes-it ose thjesht Docker-it në një projekt është tepër i tepruar. Pyetja është se jo të gjitha ekipet ose kompanitë e jashtme të angazhuara për të mbështetur infrastrukturën e klientit e kuptojnë këtë. E keqja është kur kontejnerët imponohet, për shkak se kjo ka një kosto të caktuar për klientin.
Në përgjithësi, ekziston opinioni se Docker/Kubernetes mafia thjesht po i nënshtron klientët që i japin këto çështje infrastrukturore në outoutsourcing. Sepse për të punuar me klasterët, nevojiten inxhinierë që janë të aftë dhe që kuptojnë arkitekturën e zgjidhjes së përshtatur. Ne tashmë kemi përmendur rastin tonë me revistën Republic - atje ne e mësuam ekipin e klientit të punojë në realitetet e Kubernetes-it dhe të gjithë mbetën të kënaqur. Dhe kjo ishte vërtet e drejtë. Në shumë raste,
Tani imagjinoni se kështu ne po i japim jo vetëm pjesën e serverit web në dorë të outsourcing-ut, por gjithashtu edhe mirëmbajtjen e DB-së. Kemi thënë se DB-ja është zemra, dhe humbja e zemrës është fatale për çdo organizëm të gjallë. Në thelb, perspektivat nuk janë aq të mira. Prandaj, në vend të Kubernetes-it trendi, shumë projekte do të duhet thjesht të mos kursejnë për një tarifë të arsyeshme në AWS, e cila do të zgjidhte të gjitha problemet me ngarkesën në faqen e tyre/projektin. Por AWS tani nuk është më në modë, dhe ngjyrat janë më të shtrenjta se paratë - fatkeqësisht, edhe në mjedisin IT.
Ok. Ndoshta, klasterizimi është në të vërtetë i nevojshëm për projektin, por nëse me aplikacionet stateless gjithçka është e qartë, si të organizojmë një lidhje të duhur rrjeti për bazën e të dhënave të klasterizuara?
Kur flasim për një zgjidhje inxhinierike pa probleme, e cila paraqet kalimin në k8s, shqetësimi ynë kryesor është replikimi i të dhënave në një DB të klasterizuar. Disa DB ndihmës e trajtojnë fillimisht shpërndarjen e të dhënave midis kopjeve të tyre të veçanta me një fare mirësie. Shumë të tjera nuk janë kaq mikpritëse. Dhe shpesh, argumenti kryesor për zgjedhjen e DB për projektin tonë është jo aftësia për të replikuar me minimale burime dhe kosto inxhinierike. Sidomos nëse projekti fillimisht nuk u planifikua si një mikros Servis, por thjesht evoluoi në këtë drejtim.
MendojmĂ« se nuk Ă«shtĂ« e nevojshme tĂ« flasim pĂ«r shpejtĂ«sinĂ« e disqeve rrjetĂ« â ato janĂ« tĂ« ngadalta. Pra, nuk kemi ndonjĂ« mundĂ«si reale, nĂ« rast se e nevojshme, pĂ«r tĂ« rifilluar njĂ« kopje tĂ« DB dikund ku ka mĂ« shumĂ«, pĂ«r shembull, fuqinĂ« e procesorit ose memorie tĂ« lirĂ«. Shpejt do tĂ« hasim nĂ« performancĂ«n e nĂ«n-sistemit disku tĂ« virtualizuar. Prandaj, DB duhet tĂ« jetĂ« e fiksuar nĂ« grupin e saj personal tĂ« makinave, qĂ« ndodhen nĂ« afĂ«rsi tĂ« menjĂ«hershme. Ose do tĂ« duhet ndonjĂ« mĂ«nyrĂ« pĂ«r tĂ« vendosur njĂ« sinkronizim tĂ« mjaftueshĂ«m tĂ« shpejtĂ« tĂ« tĂ« dhĂ«nave pĂ«r rezervat e parashikuara.
PĂ«r tĂ« vazhduar temĂ«n e sistemeve tĂ« architekturĂ«s virtuale: Docker Volumes, fatkeqĂ«sisht, nuk janĂ« pa probleme. NĂ« pĂ«rgjithĂ«si, nĂ« njĂ« çështje si ruajtja afatgjatĂ« e tĂ« dhĂ«nave, do tĂ« doja tĂ« pĂ«rdornim skema teknike sa mĂ« tĂ« thjeshta. Dhe shtimi i njĂ« shtrese tĂ« re abstraksioni nga sistemi i skedarĂ«ve tĂ« kontejnerit nĂ« sistemin e skedarĂ«ve tĂ« host-it prind â nĂ« vetvete Ă«shtĂ« njĂ« rrezik. Por kur ka edhe vĂ«shtirĂ«si nĂ« funksionimin e sistemit tĂ« menaxhimit tĂ« kontejnerĂ«ve pĂ«r transmetimin e tĂ« dhĂ«nave midis kĂ«tyre shtresave, atĂ«herĂ« situata bĂ«het vĂ«rtet shqetĂ«suese. Aktualisht, shumica e problemeve tĂ« njohura pĂ«r njerĂ«zimin duket se janĂ« eliminuar. Por ju e kuptoni, sa mĂ« e ndĂ«rlikuar tĂ« jetĂ« mekanizmi, aq mĂ« e thjeshtĂ« Ă«shtĂ« tĂ« prishen.
NĂ« dritĂ«n e kĂ«tyre "aventurave", Ă«shtĂ« shumĂ« mĂ« e leverdishme dhe mĂ« e thjeshtĂ« tĂ« mbani DB-nĂ« nĂ« njĂ« vend, dhe madje nĂ«se ju nevojitet kontejnerizimi i aplikacionit â le tĂ« funksionojĂ« vetĂ« dhe pĂ«rmes njĂ« gateway tĂ« shpĂ«rndarĂ« tĂ« marrĂ« lidhje tĂ« pĂ«rhershme me DB-nĂ«, e cila do tĂ« lexohet dhe shkruhet vetĂ«m njĂ« herĂ« dhe nĂ« njĂ« vend. Kjo qasje ul probabilitetin e gabimeve dhe disincronizimeve nĂ« minimum.
ĂfarĂ« po pĂ«rpiqemi tĂ« themi? Se kontejnerizimi i DB-sĂ« Ă«shtĂ« i pĂ«rshtatshĂ«m aty ku ka nevojĂ« reale pĂ«r tĂ«. Nuk mund ta shtyni njĂ« bazĂ« tĂ« aplikacionit tĂ« plotĂ« dhe ta qarkulloni ashtu siç do tĂ« keni dy dhjetĂ«ra mikrosherbime â kĂ«shtu nuk funksionon. KĂ«tĂ« duhet ta kuptoni qartĂ«.
Në vend të daljes
Nëse prisni një përfundim të qartë "të virtualizoni ose jo DB-në", do t'ju zhgënjejmë: këtu nuk do të ketë. Sepse kur krijoni çdo zgjidhje infrastrukturore, duhet të udhëhiqeni jo nga moda dhe progresi, por në radhë të parë, nga shëndeti i arsyes.
Ekzistojnë projekte për të cilat parimet dhe mjetet që vijnë me Kubernetesin, përputhen perfekt, dhe në këto projekte arrijmë paqe, të paktën në fushën e backend-it. Dhe ka projekte që kërkojnë jo kontejnerizim, por një infrastrukturë normale serveresh, sepse ato nuk mund të rimodelohen nën një model klasteri microservices, përndryshe do të bien.
Burimi: habr.com
