Kubernetes është një mjet i shkëlqyeshëm për drejtimin e kontejnerëve Docker në një mjedis prodhimi të grumbulluar. Sidoqoftë, ka probleme që Kubernetes nuk mund t'i zgjidhë. Për vendosje të shpeshta prodhimi, ne kemi nevojë për një vendosje plotësisht të automatizuar Blu/Green për të shmangur ndërprerjen në proces, e cila gjithashtu duhet të trajtojë kërkesat e jashtme HTTP dhe të kryejë shkarkime SSL. Kjo kërkon integrim me një balancues të ngarkesës siç është ha-proxy. Një sfidë tjetër është shkallëzimi gjysmë automatik i vetë grupit Kubernetes kur funksionon në një mjedis cloud, për shembull zvogëlimi i pjesshëm i grupit gjatë natës.
Ndërsa Kubernetes nuk i ka këto veçori jashtë kutisë, ai ofron një API që mund ta përdorni për të zgjidhur probleme të ngjashme. Mjetet për vendosjen dhe shkallëzimin e automatizuar Blu/Green të një grupi Kubernetes u zhvilluan si pjesë e projektit Cloud RTI, i cili u krijua bazuar në burim të hapur.
Ky artikull, një transkriptim video, ju tregon se si të konfiguroni Kubernetes së bashku me përbërës të tjerë me burim të hapur për të krijuar një mjedis të gatshëm për prodhim që pranon kodin nga një git commit pa ndërprerje në prodhim.
Pra, pasi të keni akses në aplikacionet tuaja nga bota e jashtme, mund të filloni të konfiguroni plotësisht automatizimin, domethënë ta sillni atë në fazën ku mund të kryeni një git commit dhe të siguroheni që ky git commit të përfundojë në prodhim. Natyrisht, gjatë zbatimit të këtyre hapave, gjatë zbatimit të vendosjes, ne nuk duam të hasim kohë joproduktive. Pra, çdo automatizim në Kubernetes fillon me API.
Kubernetes nuk është një mjet që mund të përdoret në mënyrë produktive jashtë kutisë. Sigurisht, ju mund ta bëni këtë, të përdorni kubectl e kështu me radhë, por megjithatë API është gjëja më interesante dhe më e dobishme në këtë platformë. Duke përdorur API-në si një grup funksionesh, mund të përdorni pothuajse çdo gjë që dëshironi të bëni në Kubernetes. Vetë kubectl përdor gjithashtu API REST.
Kjo është REST, kështu që ju mund të përdorni çdo gjuhë ose mjet për të punuar me këtë API, por jeta juaj do të bëhet shumë më e lehtë nga bibliotekat e personalizuara. Ekipi im shkroi 2 biblioteka të tilla: një për Java/OSGi dhe një për Go. E dyta nuk përdoret shpesh, por gjithsesi këto gjëra të dobishme i keni në dispozicion. Ata janë një projekt pjesërisht i licencuar me burim të hapur. Ka shumë biblioteka të tilla për gjuhë të ndryshme, kështu që ju mund të zgjidhni ato që ju përshtaten më shumë.
Pra, përpara se të filloni të automatizoni vendosjen tuaj, duhet të siguroheni që procesi nuk do t'i nënshtrohet ndonjë ndërprerjeje. Për shembull, ekipi ynë drejton vendosjet e prodhimit gjatë mesditës kur njerëzit përdorin më së shumti aplikacionet, prandaj është e rëndësishme të shmangni vonesat në proces. Për të shmangur kohën e ndërprerjes, përdoren 2 metoda: vendosja blu/jeshile ose përditësimi i rrotullimit. Në rastin e fundit, nëse keni 5 kopje të aplikacionit që funksionojnë, ato përditësohen në mënyrë sekuenciale njëra pas tjetrës. Kjo metodë funksionon mirë, por nuk është e përshtatshme nëse keni versione të ndryshme të aplikacionit që funksionojnë njëkohësisht gjatë procesit të vendosjes. Në këtë rast, ju mund të përditësoni ndërfaqen e përdoruesit ndërsa backend po ekzekuton versionin e vjetër dhe aplikacioni do të ndalojë së punuari. Prandaj, nga pikëpamja programuese, puna në kushte të tilla është mjaft e vështirë.
Kjo është një nga arsyet pse ne preferojmë të përdorim vendosjen blu/jeshile për të automatizuar vendosjen e aplikacioneve tona. Me këtë metodë, duhet të siguroheni që vetëm një version i aplikacionit të jetë aktiv në të njëjtën kohë.
Mekanizmi i vendosjes blu/jeshile duket kështu. Ne marrim trafikun për aplikacionet tona përmes ha-proxy, i cili e përcjell atë në ekzekutimin e kopjeve të aplikacionit të të njëjtit version.
Kur bëhet një vendosje e re, ne përdorim Deployer, të cilit i jepen komponentët e rinj dhe vendos versionin e ri. Vendosja e një versioni të ri të një aplikacioni do të thotë që një grup i ri kopjesh "ngrehet", pas së cilës këto kopje të versionit të ri lëshohen në një pod të ri të veçantë. Sidoqoftë, ha-proxy nuk di asgjë rreth tyre dhe nuk dërgon ende ndonjë ngarkesë pune tek ata.
Prandaj, para së gjithash, është e nevojshme të kryhet një kontroll i performancës së versioneve të reja të kontrollit shëndetësor për të siguruar që kopjet janë gati për të servisuar ngarkesën.
Të gjithë komponentët e vendosjes duhet të mbështesin një formë kontrolli shëndetësor. Ky mund të jetë një kontroll shumë i thjeshtë i thirrjeve HTTP, kur merrni një kod me status 200, ose një kontroll më i thelluar, në të cilin kontrolloni lidhjen e kopjeve me bazën e të dhënave dhe shërbime të tjera, stabilitetin e lidhjeve të mjedisit dinamik. , dhe nëse gjithçka fillon dhe funksionon siç duhet. Ky proces mund të jetë mjaft kompleks.
Pasi sistemi të verifikojë që të gjitha kopjet e përditësuara po funksionojnë, Deployer do të përditësojë konfigurimin dhe do të kalojë konfigurimin e saktë, i cili do të rikonfigurojë ha-proxy.
Vetëm pas kësaj trafiku do të drejtohet në pod me kopje të versionit të ri dhe pod i vjetër do të zhduket.
Ky mekanizëm nuk është një tipar i Kubernetes. Koncepti i vendosjes Blu/jeshile ka ekzistuar për një kohë mjaft të gjatë dhe gjithmonë ka përdorur një balancues të ngarkesës. Së pari, ju e drejtoni të gjithë trafikun në versionin e vjetër të aplikacionit dhe pas përditësimit, e transferoni plotësisht atë në versionin e ri. Ky parim përdoret jo vetëm në Kubernetes.
Tani do t'ju prezantoj me një komponent të ri të vendosjes - Deployer, i cili kryen kontrolle shëndetësore, rikonfiguron proxies, etj. Ky është një koncept që nuk vlen për botën e jashtme dhe ekziston brenda Kubernetes. Unë do t'ju tregoj se si mund të krijoni konceptin tuaj Deployer duke përdorur mjete me burim të hapur.
Pra, gjëja e parë që bën Deployer është të krijojë një kontrollues replikimi RC duke përdorur Kubernetes API. Ky API krijon pods dhe shërbime për vendosje të mëtejshme, domethënë krijon një grup krejtësisht të ri për aplikacionet tona. Sapo RC të bindet se kopjet kanë filluar, do të kryejë një kontroll shëndetësor për funksionalitetin e tyre. Për ta bërë këtë, Deployer përdor komandën GET /health. Ai ekzekuton komponentët e duhur të skanimit dhe kontrollon të gjithë elementët që mbështesin funksionimin e grupit.
Pasi të gjitha pod-et të kenë raportuar shëndetin e tyre, Deployer krijon një element të ri konfigurimi - ruajtje të shpërndarë etcd, i cili përdoret brenda nga Kubernetes, duke përfshirë ruajtjen e konfigurimit të balancuesit të ngarkesës. Ne shkruajmë të dhëna në etcd, dhe një mjet të vogël të quajtur confd monitoron etcd për të dhëna të reja.
Nëse zbulon ndonjë ndryshim në konfigurimin fillestar, ai gjeneron një skedar të ri cilësimeve dhe e transferon atë në ha-proxy. Në këtë rast, ha-proxy riniset pa humbur asnjë lidhje dhe adreson ngarkesën në shërbime të reja që mundësojnë funksionimin e versionit të ri të aplikacioneve tona.
Siç mund ta shihni, megjithë bollëkun e komponentëve, nuk ka asgjë të komplikuar këtu. Thjesht duhet t'i kushtoni më shumë vëmendje API-së dhe etj. Unë dua t'ju tregoj për vendosësin me burim të hapur që ne vetë përdorim - Amdatu Kubernetes Deployer.
Është një mjet për orkestrimin e vendosjeve të Kubernetes dhe ka karakteristikat e mëposhtme:
- Vendosja blu/jeshile;
- vendosja e një balancuesi të jashtëm të ngarkesës;
- menaxhimi i përshkruesve të vendosjes;
- menaxhimi i vendosjes aktuale;
- kontrollimi i funksionalitetit të kontrolleve shëndetësore gjatë vendosjes;
- implementimi i variablave të mjedisit në pods.
Ky Deployer është ndërtuar në krye të Kubernetes API dhe ofron një API REST për menaxhimin e dorezave dhe vendosjeve, si dhe një API Websocket për transmetimin e regjistrave gjatë procesit të vendosjes.
Ai vendos të dhënat e konfigurimit të balancuesit të ngarkesës në etcd, kështu që nuk keni nevojë të përdorni proxy ha me mbështetje jashtë kutisë, por përdorni lehtësisht skedarin tuaj të konfigurimit të balancuesit të ngarkesës. Amdatu Deployer është shkruar në Go, si vetë Kubernetes, dhe është i licencuar nga Apache.
Përpara se të filloja të përdorja këtë version të shpërndarësit, përdora përshkruesin e mëposhtëm të vendosjes, i cili specifikon parametrat që më duhen.
Një nga parametrat e rëndësishëm të këtij kodi është aktivizimi i flamurit “useHealthCheck”. Duhet të specifikojmë se duhet të kryhet një kontroll i arsyeshëm gjatë procesit të vendosjes. Ky cilësim mund të çaktivizohet kur vendosja përdor kontejnerë të palëve të treta që nuk kanë nevojë të verifikohen. Ky përshkrues tregon gjithashtu numrin e kopjeve dhe URL-në e frontit që i nevojitet ha-proxy. Në fund është flamuri i specifikimit të pod "podspec", i cili thërret Kubernetes për informacion mbi konfigurimin e portit, imazhin, etj. Ky është një përshkrues mjaft i thjeshtë JSON.
Një mjet tjetër që është pjesë e projektit Amdatu me burim të hapur është Deploymentctl. Ai ka një ndërfaqe për konfigurimin e vendosjeve, ruan historinë e vendosjes dhe përmban grepa në internet për kthimin e thirrjeve nga përdoruesit dhe zhvilluesit e palëve të treta. Ju mund të mos përdorni ndërfaqen e përdoruesit, pasi vetë Amdatu Deployer është një API REST, por kjo ndërfaqe mund ta bëjë vendosjen shumë më të lehtë për ju pa përfshirë ndonjë API. Deploymentctl është shkruar në OSGi/Vertx duke përdorur Angular 2.
Tani do të demonstroj sa më sipër në ekran duke përdorur një regjistrim të para-regjistruar në mënyrë që të mos keni nevojë të prisni. Ne do të vendosim një aplikacion të thjeshtë Go. Mos u shqetësoni nëse nuk e keni provuar Go më parë, është një aplikacion shumë i thjeshtë kështu që duhet të jeni në gjendje ta kuptoni.
Këtu po krijojmë një server HTTP që i përgjigjet vetëm /health, kështu që ky aplikacion teston vetëm kontrollin shëndetësor dhe asgjë tjetër. Nëse kontrolli kalon, përdoret struktura JSON e treguar më poshtë. Ai përmban versionin e aplikacionit që do të vendoset nga vendosësi, mesazhin që shihni në krye të skedarit dhe llojin e të dhënave boolean - nëse aplikacioni ynë po funksionon apo jo.
Kam mashtruar pak me rreshtin e fundit, sepse kam vendosur një vlerë fikse boolean në krye të skedarit, e cila në të ardhmen do të më ndihmojë të vendos edhe një aplikacion "të pashëndetshëm". Ne do të merremi me këtë më vonë.
Pra, le të fillojmë. Së pari, ne kontrollojmë për praninë e çdo pods që funksionon duke përdorur komandën ~ kubectl get pods dhe, bazuar në mungesën e një përgjigje nga URL-ja e frontendit, sigurohemi që aktualisht nuk po bëhen vendosje.
Më pas në ekran shihni ndërfaqen Deploymentctl që përmenda, në të cilën vendosen parametrat e vendosjes: hapësira e emrave, emri i aplikacionit, versioni i vendosjes, numri i kopjeve, URL e faqes së përparme, emri i kontejnerit, imazhi, kufijtë e burimit, numri i portit për kontroll shëndetësor, etj. Kufijtë e burimeve janë shumë të rëndësishme, pasi ato ju lejojnë të përdorni sasinë maksimale të mundshme të harduerit. Këtu mund të shikoni gjithashtu regjistrin e vendosjes.
Nëse tani përsëritni komandën ~ kubectl get pods, mund të shihni që sistemi "ngrihet" për 20 sekonda, gjatë të cilit ha-proxy rikonfigurohet. Pas kësaj, pod fillon dhe kopja jonë mund të shihet në regjistrin e vendosjes.
Unë ndërpreva pritjen prej 20 sekondash nga video, dhe tani mund të shihni në ekran se versioni i parë i aplikacionit është vendosur. E gjithë kjo është bërë duke përdorur vetëm UI.
Tani le të provojmë versionin e dytë. Për ta bërë këtë, unë ndryshoj mesazhin e aplikacionit nga "Përshëndetje, Kubernetes!" në "Përshëndetje, Deployer!", sistemi krijon këtë imazh dhe e vendos atë në regjistrin Docker, pas së cilës thjesht klikojmë përsëri në butonin "Deploy" në dritaren Deploymentctl. Në këtë rast, regjistri i vendosjes hapet automatikisht në të njëjtën mënyrë siç ndodhi gjatë vendosjes së versionit të parë të aplikacionit.
Komanda ~ kubectl get pods tregon se aktualisht ekzistojnë 2 versione të aplikacionit që ekzekutohen, por pjesa e përparme tregon se ne jemi ende duke ekzekutuar versionin 1.
Balancuesi i ngarkesës pret që kontrolli shëndetësor të përfundojë përpara se të ridrejtojë trafikun në versionin e ri. Pas 20 sekondash, kalojmë në curl dhe shohim që tani kemi versionin 2 të aplikacionit të vendosur dhe i pari është fshirë.
Ky ishte vendosja e një aplikacioni "të shëndetshëm". Le të shohim se çfarë ndodh nëse për një version të ri të aplikacionit ndryshoj parametrin Healthy nga true në false, domethënë, përpiqem të vendos një aplikacion jo të shëndetshëm që ka dështuar në kontrollin shëndetësor. Kjo mund të ndodhë nëse janë bërë disa gabime konfigurimi në aplikacion në fazën e zhvillimit dhe ai është dërguar në prodhim në këtë formë.
Siç mund ta shihni, vendosja kalon nëpër të gjitha hapat e mësipërm dhe ~kubectl get pods tregon se të dy pods janë duke punuar. Por ndryshe nga vendosja e mëparshme, regjistri tregon statusin e afatit. Kjo do të thotë, për shkak të faktit se kontrolli shëndetësor dështoi, versioni i ri i aplikacionit nuk mund të vendoset. Si rezultat, shihni që sistemi është rikthyer në përdorimin e versionit të vjetër të aplikacionit dhe versioni i ri thjesht është çinstaluar.
E mira e kësaj është se edhe nëse keni një numër të madh kërkesash të njëkohshme që vijnë në aplikacion, ato as nuk do ta vërejnë kohën e ndërprerjes gjatë zbatimit të procedurës së vendosjes. Nëse e testoni këtë aplikacion duke përdorur kornizën Gatling, e cila i dërgon sa më shumë kërkesa, atëherë asnjë nga këto kërkesa nuk do të hiqet. Kjo do të thotë që përdoruesit tanë as nuk do të vërejnë përditësimet e versionit në kohë reale. Nëse dështon, puna do të vazhdojë në versionin e vjetër; nëse është i suksesshëm, përdoruesit do të kalojnë në versionin e ri.
Ekziston vetëm një gjë që mund të dështojë - nëse kontrolli shëndetësor ka sukses, por aplikacioni dështon sapo të aplikohet ngarkesa e punës, domethënë, kolapsi do të ndodhë vetëm pasi të përfundojë vendosja. Në këtë rast, do t'ju duhet të ktheheni manualisht në versionin e vjetër. Pra, ne shikuam se si të përdorim Kubernetes me mjetet me burim të hapur të krijuar për të. Procesi i vendosjes do të jetë shumë më i lehtë nëse i ndërtoni këto mjete në tubacionet tuaja Build/Deploy. Në të njëjtën kohë, për të filluar vendosjen, mund të përdorni ose ndërfaqen e përdoruesit ose ta automatizoni plotësisht këtë proces duke përdorur, për shembull, commit to master.
Serveri ynë Build do të krijojë një imazh Docker, do ta shtyjë atë në Docker Hub ose çfarëdo regjistri që përdorni. Docker Hub mbështet webhook, kështu që ne mund të aktivizojmë vendosjen në distancë nëpërmjet Deployer në mënyrën e treguar më sipër. Në këtë mënyrë ju mund të automatizoni plotësisht vendosjen e aplikacionit tuaj në prodhimin e mundshëm.
Le të kalojmë në temën tjetër - shkallëzimi i grupit Kubernetes. Vini re se komanda kubectl është një komandë shkallëzuese. Me më shumë ndihmë, ne mund të rrisim lehtësisht numrin e kopjeve në grupin tonë ekzistues. Megjithatë, në praktikë, ne zakonisht duam të rrisim numrin e nyjeve në vend të pods.
Në të njëjtën kohë, gjatë orarit të punës mund t'ju duhet të rriteni, dhe gjatë natës, për të ulur koston e shërbimeve të Amazon, mund t'ju duhet të zvogëloni numrin e instancave të aplikacioneve të ekzekutuara. Kjo nuk do të thotë se do të jetë e mjaftueshme të përshkallëzoni vetëm numrin e pods, sepse edhe nëse një nga nyjet është boshe, do t'ju duhet të paguani Amazon për të. Kjo do të thotë, së bashku me shkallëzimin e bishtajave, do t'ju duhet të shkallëzoni numrin e makinave të përdorura.
Kjo mund të jetë sfiduese sepse nëse përdorim Amazon ose një shërbim tjetër cloud, Kubernetes nuk di asgjë për numrin e makinave që përdoren. I mungon një mjet që ju lejon të shkallëzoni sistemin në nivelin e nyjeve.
Pra, ne do të duhet të kujdesemi për të dy nyjet dhe pods. Ne mund të shkallëzojmë lehtësisht nisjen e nyjeve të reja duke përdorur makinat e grupit AWS API dhe Scaling për të konfiguruar numrin e nyjeve të punëtorëve Kubernetes. Ju gjithashtu mund të përdorni cloud-init ose një skript të ngjashëm për të regjistruar nyjet në grupin Kubernetes.
Makina e re fillon në grupin Scaling, inicohet si një nyje, regjistrohet në regjistrin e masterit dhe fillon të punojë. Pas kësaj, ju mund të rrisni numrin e kopjeve për përdorim në nyjet që rezultojnë. Zvogëlimi kërkon më shumë përpjekje, pasi duhet të siguroheni që një hap i tillë të mos çojë në shkatërrimin e aplikacioneve tashmë të ekzekutuara pas fikjes së makinave "të panevojshme". Për të parandaluar një skenar të tillë, duhet të vendosni nyjet në statusin "të paplanifikuar". Kjo do të thotë që programuesi i paracaktuar do t'i injorojë këto nyje kur planifikon pods DaemonSet. Planifikuesi nuk do të fshijë asgjë nga këta serverë, por gjithashtu nuk do të nisë asnjë kontejner të ri atje. Hapi tjetër është largimi i nyjes së kullimit, domethënë transferimi i nyjeve të funksionimit prej tij në një makinë tjetër, ose nyje të tjera që kanë kapacitet të mjaftueshëm për këtë. Pasi të jeni siguruar që nuk ka më kontejnerë në këto nyje, mund t'i hiqni ato nga Kubernetes. Pas kësaj, ata thjesht do të pushojnë së ekzistuari për Kubernetes. Më pas, duhet të përdorni API-në AWS për të çaktivizuar nyjet ose makinat e panevojshme.
Ju mund të përdorni Amdatu Scalerd, një tjetër mjet shkallëzimi me burim të hapur i ngjashëm me API-në AWS. Ai siguron një CLI për të shtuar ose hequr nyjet në një grup. Karakteristika e tij interesante është aftësia për të konfiguruar planifikuesin duke përdorur skedarin e mëposhtëm json.
Kodi i treguar zvogëlon kapacitetin e grupit përgjysmë gjatë periudhës së natës. Ai konfiguron si numrin e kopjeve të disponueshme ashtu edhe kapacitetin e dëshiruar të grupit Amazon. Përdorimi i këtij programuesi do të reduktojë automatikisht numrin e nyjeve gjatë natës dhe do t'i rrisë ato në mëngjes, duke kursyer koston e përdorimit të nyjeve nga një shërbim cloud si Amazon. Ky funksion nuk është i integruar në Kubernetes, por përdorimi i Scalerd do t'ju lejojë të shkallëzoni këtë platformë si të dëshironi.
Do të doja të theksoja se shumë njerëz më thonë: "Kjo është mirë dhe mirë, por çfarë ndodh me bazën time të të dhënave, e cila zakonisht është statike?" Si mund të ekzekutoni diçka të tillë në një mjedis dinamik si Kubernetes? Sipas mendimit tim, ju nuk duhet ta bëni këtë, nuk duhet të përpiqeni të drejtoni një depo të dhënash në Kubernetes. Kjo është teknikisht e mundur, dhe në internet ka mësime për këtë temë, por kjo do t'ju komplikojë seriozisht jetën.
Po, ekziston një koncept i dyqaneve të vazhdueshme në Kubernetes dhe mund të provoni të ekzekutoni dyqane të dhënash si Mongo ose MySQL, por kjo është një detyrë mjaft e vështirë. Kjo për faktin se magazinat e të dhënave nuk mbështesin plotësisht ndërveprimin me një mjedis dinamik. Shumica e bazave të të dhënave kërkojnë konfigurim të rëndësishëm, duke përfshirë konfigurimin manual të grupit, nuk u pëlqen shkallëzimi automatik dhe gjëra të tjera të ngjashme.
Prandaj, nuk duhet ta komplikoni jetën tuaj duke u përpjekur të drejtoni një depo të dhënash në Kubernetes. Organizoni punën e tyre në mënyrën tradicionale duke përdorur shërbime të njohura dhe thjesht siguroni Kubernetes aftësinë për t'i përdorur ato.
Për të përfunduar temën, dëshiroj t'ju prezantoj me platformën Cloud RTI bazuar në Kubernetes, për të cilën ekipi im është duke punuar. Ai siguron regjistrime të centralizuara, monitorim të aplikacioneve dhe grupimeve, dhe shumë veçori të tjera të dobishme që do të jenë të dobishme. Ai përdor mjete të ndryshme me burim të hapur si Grafana për të shfaqur monitorimin.
Kishte një pyetje se pse të përdorni balancuesin e ngarkesës me proxy ha me Kubernetes. Pyetje e mirë sepse aktualisht ekzistojnë 2 nivele të balancimit të ngarkesës. Shërbimet Kubernetes ende qëndrojnë në adresat IP virtuale. Ju nuk mund t'i përdorni ato për porte në makineritë e jashtme pritëse, sepse nëse Amazon mbingarkon hostin e tij cloud, adresa do të ndryshojë. Kjo është arsyeja pse ne vendosim ha-proxy përpara shërbimeve - për të krijuar një strukturë më statike që trafiku të komunikojë pa probleme me Kubernetes.
Një pyetje tjetër e mirë është se si mund të kujdeseni për ndryshimet e skemës së bazës së të dhënave kur bëni vendosjen blu/jeshile? Fakti është se pavarësisht nga përdorimi i Kubernetes, ndryshimi i skemës së bazës së të dhënave është një detyrë e vështirë. Duhet të siguroheni që skema e vjetër dhe e re janë të pajtueshme, pas së cilës mund të përditësoni bazën e të dhënave dhe më pas të përditësoni vetë aplikacionet. Mund ta ndërroni bazën e të dhënave dhe më pas të përditësoni aplikacionet. Unë njoh njerëz që kanë nisur një grup të ri bazë të dhënash me një skemë të re, ky është një opsion nëse keni një bazë të dhënash pa skema si Mongo, por gjithsesi nuk është një detyrë e lehtë. Nëse nuk keni pyetje të tjera, faleminderit për vëmendjen tuaj!
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - nga 99 dollarë! Lexoni rreth
Burimi: www.habr.com