Historikisht, industria IT është ndarë në dy kampe: ata që janë "për" dhe ata që janë "kundër". Temat e debatit mund të jenë të rastësishme. Cila është sistemi operativ më i mirë: Win apo Linux? Në smartfon, Android apo iOS? Të ruash gjithçka në re apo ta ngarkosh në RAID të ftohtë dhe t'i vendosësh diskët në kasafortë? A kanë të drejtë PHP-istët të quhen programues? Këto debate, herë pas here, kanë një natyrë pur eksistenciale dhe nuk kanë ndonjë bazë tjetër përveç interesit sportiv.
Kështu ndodhi që me shfaqjen e kontejnerëve dhe të gjithë këtij të preferuari të kuzhinës me Docker dhe Kubernetes, filluan debatet "për" dhe "kundër" përdorimit të mundësive të reja në fusha të ndryshme të back-end-it. (Të bëjmë një sqarim paraprak: megjithëse shpesh në këtë diskutim do të përmendet Kubernetes si orkestrues, zgjedhja e këtij instrumenti nuk ka rëndësi thelbësore. Në vend të tij, mund të vendosni çdo tjetër që ju duket më e përshtatshme dhe e njohur.)
Dhe, dukshëm do të ishte një shpërthim i thjeshtë midis dy palëve të një medaljeje. Njësoj pa kuptim dhe pa mëshirë, si përballja e përhershme mes Win dhe Linux, në të cilën njerëzit e arsyeshëm ekzistojnë diku në mes. Por, rastin e konteinerizimit, gjërat nuk janë kaq të thjeshta. Në këto debate zakonisht nuk ka një palë të drejtë, por në rastin e "përdorimit" ose "mospërdorimit" të kontejnerëve për ruajtjen e bazave të të dhënave, çdo gjë kthehet përmbys. Sepse në njëfarë kuptimi, mbështetësit dhe kundërshtarët e një qasjeje të tillë janë të dy në të drejtë.
Anës e Bardhë
PĂ«r tĂ« pĂ«rmbledhur argumentimin e AnĂ«s sĂ« BardhĂ« mund tĂ« thuhet me njĂ« frazĂ«: âHalo, vitin 2k19 jashtĂ«!â TingĂ«llon si populizĂ«m, sigurisht, por nĂ«se e shqyrtojmĂ« situatĂ«n nĂ« detaje, ka tĂ« mirat e veta. KĂ«to do t'i shqyrtojmĂ« tani.
Supozoni se keni njĂ« projekt tĂ« madh nĂ« internet. Ai mund tĂ« jetĂ« ndĂ«rtuar fillimisht mbi njĂ« qasje mikrosherbimesh, ose ka arritur aty pĂ«rmes njĂ« rruge evolutive â nĂ« tĂ« vĂ«rtetĂ«, kjo nuk ka rĂ«ndĂ«si. Ju e keni shpĂ«rndarĂ« projektin tonĂ« nĂ« mikrosherbime tĂ« veçanta, keni konfiguruar orkestrimin, balancimin e ngarkesave dhe shkallĂ«zimin. Dhe tani me njĂ« ndĂ«rgjegje tĂ« pastĂ«r po pini njĂ« mojito nĂ« hamak, gjatĂ« efekteve tĂ« HabrĂ«s, nĂ« vend qĂ« tĂ« ngrini serverĂ«t qĂ« janĂ« rrĂ«zuar. Por nĂ« çdo veprim duhet tĂ« jeni tĂ« qĂ«ndrueshĂ«m. ShumĂ« shpesh, vetĂ«m aplikacioni vetĂ« â kodi, kontenjerizohet. ĂfarĂ« tjetĂ«r kemi pĂ«rveç kodit?
SaktĂ«, tĂ« dhĂ«nat. Zemra e çdo projekti janĂ« tĂ« dhĂ«nat e tij: mund tĂ« jetĂ« njĂ« DB tipike si MySQL, PostgreSQL, MongoDB, si dhe magazina qĂ« pĂ«rdoren pĂ«r kĂ«rkim (ElasticSearch), magazina key-value pĂ«r caching â pĂ«r shembull, redis, etj. Tani nuk do tĂ« flasim pĂ«r varianta tĂ« kĂ«qija tĂ« implementimit tĂ« backend-it, kur DB bie pĂ«r shkak tĂ« pyetjeve tĂ« shkruara keq, por do tĂ« flasim pĂ«r sigurimin e qĂ«ndrueshmĂ«risĂ« sĂ« asaj DB nĂ«n ngarkesĂ«n e klientit. Sepse kur-containerizojmĂ« aplikacionin tonĂ« dhe i lejojmĂ« atij tĂ« shkallĂ«zohet lirshĂ«m pĂ«r tĂ« pĂ«rpunuar çdo numĂ«r tĂ« thirrjeve tĂ« ardhshme, kjo natyrshĂ«m rrit edhe ngarkesĂ«n nĂ« bazĂ«n e tĂ« dhĂ«nave.
Faktikisht, kanali i aksesit nĂ« bazĂ«n e tĂ« dhĂ«nave dhe serveri ku ajo funksionon, bĂ«hen si njĂ« vrimĂ« nĂ« gjilpĂ«rĂ« nĂ« bĂ«nkĂ«ndin tonĂ« tĂ« bukur me konteinerĂ«. Motivi kryesor i virtualizimit me konteinerĂ« â Ă«shtĂ« fleksibiliteti dhe adaptueshmĂ«ria e strukturĂ«s, e cila lejon organizimin e shpĂ«rndarjes sĂ« ngarkesave maksimale pĂ«rgjatĂ« gjithĂ« infrastrukturĂ«s sonĂ« tĂ« disponueshme sa mĂ« efikasht. Pra, nĂ«se ne nuk kontejnerizojmĂ« dhe nuk shpĂ«rndajmĂ« nĂ« klasterin e tĂ« gjitha elementeve tĂ« sistemit â ne po bĂ«jmĂ« njĂ« gabim tĂ« rĂ«ndĂ«.
ĂshtĂ« shumĂ« mĂ« logjike tĂ« klasterosh jo vetĂ«m aplikacionin, por edhe shĂ«rbimet qĂ« janĂ« pĂ«rgjegjĂ«se pĂ«r ruajtjen e tĂ« dhĂ«nave. Kur klasterojmĂ« dhe vendosim serverĂ« web qĂ« punojnĂ« nĂ« mĂ«nyrĂ« tĂ« pavarur dhe ndajnĂ« ngarkesĂ«n mes tyre nĂ« k8s, ne tashmĂ« zgjidhim problemin e sinkronizimit tĂ« tĂ« dhĂ«nave â atĂ« tĂ« komenteve pĂ«r postimet, nĂ«se sjellim nĂ« shembull njĂ« media apo platformĂ« blogu. NĂ« çdo rast, krijojmĂ« njĂ« pasqyrĂ« intra-klaster tĂ« DB-sĂ« si ExternalService, edhe nĂ«se Ă«shtĂ« virtuale. ĂĂ«shtja Ă«shtĂ« qĂ« vetĂ« DB-ja ende nuk Ă«shtĂ« e klasterizuar â serverĂ«t web tĂ« instaluar nĂ« kub thithin informacion mbi ndryshimet nga baza jonĂ« statike tĂ« gjeneratĂ«s qĂ« punon veçmas.
A ndjeni ndonjĂ« grackĂ«? Ne pĂ«rdorim k8s ose Swarm pĂ«r tĂ« shpĂ«rndarĂ« ngarkesĂ«n dhe pĂ«r tĂ« shmangur rĂ«nien e serverit web, por ne nuk e bĂ«jmĂ« kĂ«tĂ« pĂ«r DB-nĂ«. Por, nĂ«se DB-ja bie, atĂ«herĂ« nĂ« tĂ«rĂ« infrastrukturĂ«n tonĂ« tĂ« klasterizuar nuk ka kuptim â çfarĂ« do na duhej nĂ« faqet e bardha web qĂ« kthejnĂ« njĂ« gabim tĂ« qasjes nĂ« bazĂ«n e tĂ« dhĂ«nave?
Prandaj, nuk Ă«shtĂ« e mjaftueshme tĂ« grumbullohen vetĂ«m serverĂ«t web, siç bĂ«het zakonisht, por gjithashtu 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, ndĂ«rsa Ă«shtĂ« nĂ« tĂ« njĂ«jtĂ«n kohĂ« e pavarur nga njĂ«ra-tjetra. MegjithatĂ«, edhe nĂ«se gjysma e prapavijĂ«s sonĂ« âshembetâ nĂ«n ngarkesĂ« â pjesa tjetĂ«r do tĂ« mbijetojĂ« dhe sistemi i sinkronizimit tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave do tĂ« sigurojĂ« njĂ« funksionim tĂ« duhur brenda grupit dhe mundĂ«sinĂ« pĂ«r zgjerim tĂ« pafund dhe vendosjen e grupeve tĂ« reja qĂ« do tĂ« na ndihmojĂ« tĂ« arrijmĂ« fuqitĂ« e nevojshme â vetĂ«m tĂ« ishin raftet 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 lejon qĂ« kjo bazĂ« tĂ« vendoset aty ku Ă«shtĂ« e nevojshme; nĂ«se flasim pĂ«r njĂ« shĂ«rbim global, atĂ«herĂ« Ă«shtĂ« mjaft irracional tĂ« menaxhohet njĂ« grup webi diku nĂ« San Francisco dhe tâi dĂ«rgohen paketat pĂ«r tâu lidhur me bazĂ«n e tĂ« dhĂ«nave nĂ« Podmoskovje dhe pĂ«r tâu kthyer.
Gjithashtu, kontenorizimi i bazave tĂ« tĂ« dhĂ«nave mundĂ«son ndĂ«rtimin e tĂ« gjitha elementeve tĂ« sistemit nĂ« tĂ« njĂ«jtin nivel abstraksioni. Ăka, nga ana tjetĂ«r, bĂ«n tĂ« mundur menaxhimin e kĂ«tij sistemi direkt nga kodi, nga zhvilluesit, pa angazhimin aktiv tĂ« administratorĂ«ve. Zhvilluesit menduan se ishte e nevojshme njĂ« DBMS e veçantĂ« pĂ«r nĂ«nprojektin e ri â lehtĂ«! shkruan njĂ« skedar yaml, ngarkohet nĂ« grup dhe Ă«shtĂ« gati.
Sigurisht, vetĂ« pĂ«rdorimi i brendshĂ«m bĂ«het shumĂ« mĂ« i lehtĂ«. MĂ« thoni, sa herĂ« keni mbyllur sytĂ« nĂ« momentet kur njĂ« anĂ«tar i ri i ekipit futi duar nĂ« bazĂ«n e tĂ« dhĂ«nave aktive? E cila, nĂ« fakt, Ă«shtĂ« njĂ« e vetme dhe po rrotullohet tani? Sigurisht, tĂ« gjithĂ« ne jemi tĂ« rritur kĂ«tu, dhe na ndodhet ndonjĂ«herĂ« njĂ« kopje rezervĂ« e freskĂ«t, dhe mĂ« tej â pas rafteve me marinat e gjyshes dhe ski tĂ« vjetra â mund tĂ« ketĂ« edhe njĂ« kopje rezervĂ« tjetĂ«r, ndoshta edhe nĂ« ruajtje tĂ« ftohtĂ«, sepse njĂ« herĂ« zjarri ndodhi nĂ« zyrĂ«n tuaj. Por megjithatĂ«, çdo hyrje e njĂ« anĂ«tari tĂ« ri tĂ« ekipit, qĂ« ka qasje nĂ« infrastruktura aktive dhe, sigurisht, nĂ« bazĂ«n e tĂ« dhĂ«nave aktive â Ă«shtĂ« njĂ« sasi e madhe tensioni pĂ«r tĂ« gjithĂ« tĂ« tjerĂ«t. Kush e di, ndoshta ai Ă«shtĂ« i papĂ«rgjegjshĂ«m? E frikshme, bien dakord.
Kontainerizimi dhe, nĂ« thelb, topologjia fizike e shpĂ«rndarĂ« e DB-sĂ« sĂ« projektit tuaj ndihmon pĂ«r tĂ« shmangur momente tĂ« tilla stresuese. Nuk i besoni njĂ« fillestar? E pa problem! Do t'i krijojmĂ« atij njĂ« klaster tĂ« vetin pĂ«r tĂ« punuar dhe do ta çaktivizojmĂ« nga klasterĂ«t e tjerĂ« tĂ« DB-sĂ« â sinkronizimi vetĂ«m pĂ«rmes njĂ« shtyse manuale dhe kthimit sinkron tĂ« dy çelĂ«save (njĂ« pĂ«r liderin e ekipit, tjetra pĂ«r administratori). Dhe tĂ« gjithĂ« do tĂ« jenĂ« tĂ« lumtur.
Tani ka ardhur koha të kalojmë në kundërshtarë të klasterizimit të DB-së.
Ankthi i Errët
Duke diskutuar se pse nuk duhet të kontenierizojmë bazën e të dhënave dhe të vazhdojmë ta kthejmë atë në një qendër të vetme serveri, nuk do të zbresim në retorikën e ortodoksëve dhe pohimeve si «gjyshërit e rrotullonin DB-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 përfitime të dukshme.
Bashkoj, projektet qĂ« realisht kanĂ« nevojĂ« pĂ«r njĂ« bazĂ« nĂ« kontejner mund tĂ« numĂ«rohen me gishta tĂ« dorĂ«s sĂ« njĂ« marangozit tĂ« zakonshĂ«m. NĂ« shumicĂ«n e rastĂ«ve, madje vetĂ« pĂ«rdorimi i k8s apo Docker Swarm Ă«shtĂ« i tepruar â shpeshherĂ« kĂ«to mjete pĂ«rdoren pĂ«r shkak tĂ« modĂ«s sĂ« teknologjive dhe udhĂ«zimeve "supreme" nga menaxherĂ«t qĂ« tĂ« gjithĂ« tĂ« kalojnĂ« nĂ« re dhe kontejnerĂ«. Sepse, tani Ă«shtĂ« e modĂ«s dhe tĂ« gjithĂ« e bĂ«jnĂ« kĂ«shtu.
TĂ« paktĂ«n nĂ« gjysmĂ«n e rasteve pĂ«rdorimi i Kubernetes apo thjesht Docker Ă«shtĂ« i tepruar nĂ« projekt. ĂĂ«shtja Ă«shtĂ« se jo tĂ« gjithĂ« ekipet apo kompanitĂ« e jashtme qĂ« janĂ« angazhuar pĂ«r tĂ« mbajtur infrastrukturĂ«n e klientit e kuptojnĂ« kĂ«tĂ«. MĂ« e keqja Ă«shtĂ« kur kontejnerĂ«t imponohen, sepse kjo ngarkohet me njĂ« sasi tĂ« caktuar monetash pĂ«r klientin.
Ka shumĂ« mendime qĂ« Docker/kubika-mafia thjesht po ia merr klientĂ«ve qĂ« i besojnĂ« kĂ«to çështje infrastrukturore outsourcing. Sepse pĂ«r tĂ« punuar me klasterĂ«t, nevojiten inxhinierĂ« qĂ« e kuptojnĂ« arkitekturĂ«n e zgjidhjes sĂ« zbatuar. Na kam pĂ«rmendur rastin tonĂ« me publikimin Republic â aty mĂ«suam ekipin e klientit tĂ« punojĂ« nĂ« realitetin e Kubernetes, dhe tĂ« gjithĂ« ishin tĂ« kĂ«naqur. Dhe kjo ishte krejt nĂ« rregull. Shpesh, megjithatĂ«, "implementuesit" e k8s i marrin infrastrukturĂ«n e klientit peng â sepse tani vetĂ«m ata e dinĂ« se si funksionon gjithçka, ndĂ«rsa nĂ« anĂ«n e klientit nuk ka specialistĂ«.
Dhe tani imagjinoni se nĂ« kĂ«tĂ« mĂ«nyrĂ« ne po e kalojmĂ« jo vetĂ«m pjesĂ«n e serverit web pĂ«r outsourcing, por edhe mirĂ«mbajtjen e DB-sĂ«. Ne kemi thĂ«nĂ« se DB-ja Ă«shtĂ« zemra, dhe humbja e zemrĂ«s Ă«shtĂ« fatale pĂ«r çdo organizĂ«m tĂ« gjallĂ«. NĂ« pĂ«rmbledhje, perspektivat nuk janĂ« ato mĂ« tĂ« mira. Prandaj, nĂ« vend tĂ« Kubernetes, shumĂ« projekte do tĂ« ishte mirĂ« tĂ« mos e kursenin pĂ«r njĂ« tarifĂ« normale nĂ« AWS, e cila do tĂ« zgjidhte tĂ« gjitha problemet me ngarkesĂ«n nĂ« faqen e tyre/projektin. Por AWS nuk Ă«shtĂ« mĂ« nĂ« modĂ«, dhe brendĂ«sia Ă«shtĂ« mĂ« e shtrenjtĂ« se paratĂ« â fatkeqĂ«sisht, edhe nĂ« mjedisin IT.
Okay. Mund të jetë se klasterizimi është vërtet i nevojshëm për projektin, por nëse për aplikacionet stateless kjo është e qartë, si mund të organizojmë një lidhje të denjë në rrjet për një bazë të dhënash të klasterizuar?
Nëse po flasim për një zgjidhje inxhinierike pa ndërprerje, siç është kalimi në k8s, atëherë shqetësimi ynë kryesor është replikimi i të dhënave në bazën e të dhënave të klasterizuar. Disa SGBD janë fillimisht mjaft të hapura ndaj ndarjes së të dhënave ndërmjet kopjeve të ndryshme. Megjithatë, shumë të tjera nuk janë aq mikpritëse. Shpesh argumentohet se aftësia për t'u replikuar me koston minimale të burimeve dhe inxhinierisë nuk është arsyeja kryesore për zgjedhjen e SGBD për projektin tonë, sidomos nëse projekti nuk ishte fillimisht planifikuar si një mikroshërbim, por thjesht evoluoi në këtë drejtim.
Nuk besojmĂ« se duhet tĂ« flasim pĂ«r shpejtĂ«sinĂ« e funksionimit tĂ« disqeve rrjetĂ« â ato janĂ« tĂ« ngadalta. Do tĂ« thotĂ«, nuk kemi mundĂ«sinĂ« reale, nĂ« rast nevoje, tĂ« rimekĂ«m njĂ« instancĂ« tĂ« DBM diku tjetĂ«r, nĂ« njĂ« vend ku ka mĂ« shumĂ«, pĂ«r shembull, burime procesorike ose memorie tĂ« lirĂ«. Shpejt do tĂ« hasim nĂ« kufizime tĂ« performancĂ«s sĂ« sistemit tĂ« disqeve tĂ« virtualizuara. Prandaj, DBM duhet tĂ« jetĂ« e lidhur me grupin e saj personal tĂ« makinave, tĂ« cilat ndodhen nĂ« afĂ«rsi. Ose ndryshe, duhet tĂ« krijojmĂ« njĂ« sinkronizim tĂ« shpejtĂ« tĂ« tĂ« dhĂ«nave pĂ«r rezervat e parashikuara.
Në vazhdim të temës së sistemeve të skedarëve virtuale: Docker Volumes, fatkeqësisht, nuk janë të paprobleme. Në përgjithësi, në një fushë si ruajtja afatgjatë dhe e besueshme e të dhënave, do të dëshironim të përdornim skema teknike sa më të thjeshta. Shtimi i një shtrese të re abstraksioni nga sistemi i skedarëve të kontejnerit në sistemin e skedarëve të hostit prind është një rrezik në vetvete. Por kur gjithashtu ndodhin probleme në punën e sistemit të sigurimit të kontejnerëve për të transmetuar të dhënat midis këtyre shtresave, atëherë situata bëhet edhe më e keqe. Aktualisht, shumica e problemeve që njohin njerëzit progresivë duket se janë eleminuar. Por e kuptoni se, sa më i ndërlikuar të jetë mekanizmi, aq më lehtë prishet ai.
NĂ« dritĂ«n e tĂ« gjitha kĂ«tyre «aventurave», Ă«shtĂ« shumĂ« mĂ« fitimprurĂ«se dhe mĂ« e thjeshtĂ« tĂ« mbani DB-nĂ« nĂ« njĂ« vend, dhe madje nĂ«se ju nevojitet kontejnerizimi i aplikacionit â le tĂ« funksionojĂ« ai vetĂ« dhe tĂ« marri lidhje tĂ« njĂ«kohshme me DB-nĂ« pĂ«rmes njĂ« gateway shpĂ«rndarĂ«s, e cila do tĂ« lexohet dhe shkruhet vetĂ«m njĂ« herĂ« dhe nĂ« njĂ« vend. Ky qasje zvogĂ«lon probabilitetin e gabimeve dhe asinkronizimeve nĂ« vlera minimale.
Ku genuine mundje? Tek qĂ« realisht ka nevojĂ« pĂ«r containerizimin e DB-sĂ«. Nuk mund tĂ« vendosni njĂ« bazĂ« tĂ« aplikacionit tĂ« plotĂ« dhe ta menaxhoni sikur tĂ« keni njĂ«zet mikros serviços â kĂ«shtu nuk funksionon. Kjo duhet tĂ« kuptohet qartĂ«.
Në vend të daljes
Nëse prisni një përgjigje të qartë "të virtualizoni ose jo DB-në", atëherë do t'u japim keqardhje: nuk do të ketë një të tillë këtu. Sepse kur krijoni ndonjë zgjidhje infrastrukturore, duhet të udhëhiqeni jo nga moda dhe përparimi, por në radhë të parë nga shëndeti i arsyes.
Ekzistojnë projekte, në të cilat parimet dhe mjetet që vijnë me Kubernetes-i janë përsosur përsëri, dhe në këto projekte arrijmë paqe të paktën në sferën e backend-it. Por ekzistojnë projekte që kërkojnë një infrastrukturë serverike normale dhe jo containerizim, sepse ato në mënyrë thelbësore nuk mund të ripërshtaten për modelin e klasterizuar mikros serviços, pasi do të bien.
Burimi: habr.com
