Kubernetes është një mjet i shkëlqyer për të nisur konteinerët Docker në një mjedis prodhimi të klasterizuar. Megjithatë, ekzistojnë detyra që Kubernetes nuk mund t'i zgjidhë. Kur bëhet fjalë për dispunimin e shpeshtë në mjedisin e punës, na nevojitet një proces i plotë i automatizuar i Blue/Green deployment për të shmangur ndalimet, i cili gjithashtu kërkon trajtimin e kërkesave HTTP nga jashtë dhe shkarkimin e SSL. Kjo kërkon integrimin me një balancues ngarkese, si ha-proxy. Një detyrë tjetër është shkallëzimi gjysmë-automatizuar i vetë klasterit Kubernetes gjatë punës në një mjedis cloud, për shembull, zvogëlimi i pjesshëm i klasterit gjatë natës.
Megjithëse Kubernetes nuk ka këto funksione menjëherë "nga kutia", ai ofron një API të cilin mund ta shfrytëzoni për të zgjidhur ngjashme detyra. Mjetet për automatizimin e Blue/Green deployment dhe shkallëzimin e klasterit Kubernetes janë zhvilluar në kuadër të projektit Cloud RTI, i cili është ndërtuar mbi open-source.
Në këtë artikull, transkriptim video, flitet për mënyrën se si të konfiguroni Kubernetes së bashku me komponentët e tjerë open-source për të krijuar një mjedis të gatshëm për prodhim, i cili pa ndalime në prodhim pranon kodin nga angazhimi git commit.
Pra, pasi keni fituar akses në aplikacionet tuaja nga bota e jashtme, mund të filloni konfigurimin e plotë të automatizimit, që do të thotë ta çoni atë në një fazë ku mund të kryeni git commit dhe të siguroheni që ky git commit përfundon në prodhim. Natyrisht, gjatë realizimit të këtyre hapave, gjatë dispunimit, nuk duam të hasim ndalime. Pra, çdo automatizim në Kubernetes fillon me API.
Kubernetes nuk është mjeti që mund të përdoret produktivisht "drejt nga kutia". Sigurisht, mund ta bëni këtë, të përdorni kubectl etj., por prapëseprapë, API është gj coisa më interesante dhe e dobishme e kësaj platforme. Duke përdorur API si një set funksionesh, mund të aksesoni praktikisht gjithçka që dëshironi të bëni në Kubernetes. Vetë kubectl gjithashtu përdor REST API.
Kjo është një API REST, prandaj mund të përdorni çdo gjuhë dhe mjet për të punuar me të, megjithatë bibliotekat e përdoruesve do ta lehtësojnë ndjeshëm jetën tuaj. Ekipi im ka shkruar 2 të tilla: një për Java / OSGi dhe një për Go. E dyta nuk përdoret shpesh, por në çdo rast keni këto gjëra të dobishme në dispozicionin tuaj. Ato përbëjnë një projekt pjesërisht me licencë open-source. Ekzistojnë shumë biblioteka të tilla për gjuhë të ndryshme, kështu që mund të zgjidhni ato më të përshtatshme.
Pra, përpara se të nisim automatizimin e përhapjes, është e nevojshme të sigurohemi se ky proces nuk do të privohet nga ndonjë pezullim. Për shembull, ekipi ynë bën shpërndarjen në prodhim në mes të ditës, kur njerëzit e përdorin aplikacionet në maksimum, prandaj është shumë e rëndësishme të shmangen vonesat në këtë proces. Për të shmangur pezullimet, përdoren 2 metoda: shpërndarja blue/green ose rifreskimi i vazhdueshëm rolling update. Në rastin e fundit, nëse keni 5 replika të aplikacionit, ato përditësohen një pas një. Ky metod është shumë efektiv, por nuk është i përshtatshëm nëse gjatë procesit të përhapjes keni versione të ndryshme të aplikacionit të ekzekutuar njëkohësisht. Në këtë rast, mund të përditësoni ndërfaqen e përdoruesit ndërsa backend po punon me versionin e vjetër, duke e ndaluar funksionimin e aplikacionit. Prandaj, nga pikëpamja e programimit, puna në kushte të tillë është mjaft sfiduese.
Kjo është një nga arsyet pse ne preferojmë të përdorim shpërndarjen blue/green për automatizimin e shpërndarjes së aplikacioneve tona. Me këtë metodë, duhet të siguroheni se në një moment të caktuar është aktive vetëm një version i aplikacionit.
Mekanizmi i shpërndarjes blue/green duket si më poshtë. Ne marrim trafik për aplikacionet tona përmes ha-proxy, i cili e drejton atë te replika që janë aktive të aplikacionit të të njëjtës version.
Kur për t'u kryer një depërtim të ri, ne përdorim Deployer, i cili merr komponentët e rinj dhe bën deploy të versionit të ri. Bërja deploy e versionit të ri të aplikacionit do të thotë se një grup i ri replikash 'ngrihet', pas së cilës këto replika të versionit të ri fillojnë në një pod të ri, të veçantë. Megjithatë, ha-proxy nuk ka informacion për to dhe për momentin nuk i drejton asnjë ngarkesë pune.
Prandaj, në radhë të parë, është e nevojshme të kryhet një kontroll funksionaliteti për versionet e reja të health checking, për të siguruar që replikat janë gati të shërbejnë ngarkesën.
Të gjitha komponentët e deploy-it duhet të mbështesin një formë të health check. Kjo mund të jetë një verifikim shumë i thjeshtë HTTP me një thirrje, kur merrni një kod me status 200, ose një kontroll më të thellë, ku kontrolloni lidhjen e replikave me bazën e të dhënave dhe shërbime të tjera, që lidhjet e mjedisit dinamik janë të qëndrueshme, dhe nëse gjithçka ngrihet dhe funksionon në mënyrë të saktë. Ky proces mund të jetë mjaft i komplikuar.
Pas konfirmimit të funksionimit nga sistemi për të gjitha replikat e përditësuara, Deployer do të azhurnojë konfigurimin dhe do t'i japë confd-in e duhur, i cili do të ri-konfigurojë ha-proxy.
Vetëm pas kësaj, trafiku do të drejtohet në pod-in me replikat e versionit të ri, dhe pod-i i vjetër do të largohet.
Ky mekanizëm nuk është një veçori e Kubernetes. Koncepti i Blue/green deployment ekziston për një kohë të gjatë dhe gjithmonë ka përdorur një balancues ngarkese. Fillimisht, ju drejtoni të gjithë trafikun në versionin e vjetër të aplikacionit, dhe pas përditësimit, plotësisht e transferoni atë në versionin e ri. Ky parim përdoret jo vetëm në Kubernetes.
Tani do t'ju prezantoj një komponent të ri të deploy-it – Deployer, i cili kryen kontrollin e funksionalitetit, ri-konfiguron proxy dhe kështu me radhë. Ky është një koncept që nuk lidhet me botën e jashtme dhe ekziston brenda Kubernetes. Do t'ju tregoj se si mund të krijoni konceptin tuaj të Deployer duke përdorur mjete open-source.
Pra, gjëja e parë që bën Deployer është të krijojë një kontrollues replikimi RC duke përdorur API-në e Kubernetes. Kjo API krijon pod-e dhe shërbime për dislokimin e mëtejshëm, pra krijon një grumbull të ri të plotë për aplikacionet tona. Sapo RC të sigurohet që replikat kanë nisur, do të kryejë kontrollin e funksionimit të tyre, Health check. Për këtë, në Deployer përdoret komanda GET /health. Ajo aktivizon komponentët përkatës të kontrollit dhe kontrollon të gjithë elementët që sigurojnë funksionimin e grumbullit.
Pasi të gjitha pod-et të raportojnë për "shëndetin" e tyre, Deployer krijon një element të ri konfigurationsh – ruajtja e shpërndarë etcd, e cila përdoret brenda Kubernetes, përfshirë për ruajtjen e konfigurimit të balancuesit të ngarkesës. Ne shkruajmë të dhëna në etcd, dhe një mjet i vogël confd ndjek etcd për shfaqjen e të dhënave të reja.
Nëse ai zbulon ndonjë ndryshim në konfigurimin fillestar, krijon një skedar të ri konfigurimi dhe ia transmeton ha-proxy. Në këtë rast, ha-proxy rindez pa humbur ndonjë lidhje dhe adreson ngarkesën në shërbimet e reja, të cilat sigurojnë funksionimin e versionit të ri të aplikacioneve tona.
Siç e shihni, pavarësisht nga numri i madh i komponentëve, këtu nuk ka asgjë të komplikueshme. Thjesht keni nevojë të kushtoni më shumë vëmendje API-së dhe etcd. Dua të ju flas për një deployer open-source që ne vetë përdorim – kjo është Amdatu Kubernetes Deployer.
Ky është një mjet për orkestrimin e dislokimeve Kubernetes, që ka këto funksione:
- dislokimi Blue/Green;
- konfigurimi i balancuesit të jashtëm të ngarkesës;
- menaxhimi i deshifruesve të dislokimeve;
- menaxhimi i dislokimeve aktuale;
- kontrolli i funksionimit të Health checks gjatë dislokimit;
- implementimi i ndryshoreve të ambientit në pod-e.
Ky Deployer është krijuar mbi API-në e Kubernetes dhe ofron një REST API për menaxhimin e deshifruesve dhe dislokimeve, si dhe një Websocket API për logjet në kohë reale gjatë procesit të dislokimit.
Ai vendos të dhënat e konfigurimit të balancuesit të ngarkesës në etcd, kështu që nuk keni pse të përdorni ha-proxy me mbështetje "të gatshme nga kutia", por mund të përdorni lehtësisht skedarin tuaj të konfigurimit të balancuesit. Amdatu Deployer është shkruar në Go, ashtu si Kubernetes vetë, dhe licencuar Apache.
Para fillimin e përdorimit të kësaj versioni të deployer-it, përdora këtë descriptor deployimi, ku janë caktuar parametrat e nevojshëm.
Një nga parametrat e rëndësishëm të këtij kodi është aktivizimi i flag-ut "useHealthCheck". Duhet të specifikojmë se gjatë procesit të vendosjes duhet të kryhet kontrolli i funksionit. Ky parametr mund të çaktivizohet kur në vendosje përdoren konteinerë të zhvilluesve të tretë që nuk kanë nevojë për verifikim. Në këtë descriptor gjithashtu përcaktohet numri i kopjeve dhe URL e frontend-it, që është e nevojshme për ha-proxy. Në fund është caktuar flag-u i specifikimit të pod-it "podspec", i cili i drejtohet Kubernetes për të marrë informacion mbi konfigurimin e porteve, imazhin etj. Ky është një descriptor relativisht i thjeshtë në formatin JSON.
Një tjetër mjet që është pjesë e projektit open-source Amdatu është Deploymentctl. Ai ka një ndërfaqe përdoruese UI për konfigurimin e vendosjes, ruan historinë e vendosjes dhe përmban webhooks për thirrje të bëra nga përdoruesit dhe zhvilluesit e tretë. Mund të mos e përdorni UI-në, pasi vetë Amdatu Deployer është një REST API, por kjo ndërfaqe mund ta lehtësojë shumë vendosjen pa pasur nevojë për ndonjë API. Deploymentctl është shkruar në OSGi/Vertx duke përdorur Angular 2.
Tani do të tregoj atë që thamë më sipër përmes ekranit, duke përdorur një regjistrim të bërë më parë, kështu që nuk do t'ju duhet të prisni. Do të vendosim një aplikacion të thjeshtë në Go. Mos u shqetësoni nëse nuk keni pasur përvojë me Go, ky është një aplikacion shumë i thjeshtë dhe gjithçka duhet t'ju jetë e qartë.
Këtu po krijojmë një server HTTP, i cili përgjigjet vetëm në /health, kështu që ky aplikacion vetëm kontrollon funksionalitetin e health check dhe asgjë më shumë. Nëse kontrolli kalon, aktivizohet struktura JSON që shihni më poshtë. Ajo përmban versionin e aplikacionit që do të vendoset nga deployer-i, mesazhin që e shihni në majë të skedarit, dhe një tip boolean — nëse aplikacioni ynë është i funksionueshëm apo jo.
Me rreshtin e fundit kam bërë pak mashtrim, sepse vendosa një vlerë të ngurtë boolean në fillim të skedarit, e cila më ndihmon të vendos edhe një aplikacion "të sëmurë". Më vonë do të merremi me këtë.
Tani, le të fillojmë. Së pari, kontrollojmë nëse ka ndonjë pod të nisur duke përdorur komandën ~ kubectl get pods dhe duke mos marrë përgjigje nga URL e front-end, sigurohemi që nuk ka ndonjë implementim në këtë moment.
Më pas, në ekran shihni ndërfaqen e Deploymentctl që e përmenda më parë, ku përcaktohen parametrat e implementimit: hapësira emri, emri i aplikacionit, versioni i implementimit, numri i kopjeve, URL e front-end, emri i kontejnerit, imazhi, kufijtë e burimeve, numri i portit për kontrollin e shëndetit, etj. Kufijtë e burimeve janë shumë të rëndësishëm, pasi lejojnë të shfrytëzohet sa më shumë “hardware” të jetë e mundur. Në këtë pikë, gjithashtu mund të shikoni logun e implementimit.
Nëse tani e përsërisim komandën ~ kubectl get pods, duket se sistemi “ngrihet” për 20 sekonda, gjatë të cilave ndodhi rekonfigurimi i ha-proxy. Pas kësaj, podi nishet dhe kopja jonë mund të shihet në logun e implementimit.
Kam prerë pritjen 20-sekondëshe nga video, dhe tani e shihni në ekran se versioni i parë i aplikacionit është implementuar. E gjithë kjo u bë vetëm përmes UI.
Tani le të provojmë versionin e dytë. Për këtë, unë ndryshoj mesazhin e aplikacionit nga “Hello, Kubernetes!” në “Hello, Deployer!”, sistemi krijon këtë imazh dhe e vendos atë në regjistrin Docker, pas së cilës thjesht e godasim përsëri butonin “Deploy” në dritaren e Deploymentctl. Në këtë rast, logu i implementimit aktivizohet automatikisht ashtu siç ndodhi gjatë implementimit të versionit të parë të aplikacionit.
Komanda ~ kubectl get pods tregon se aktualisht janë të nisura 2 versione të aplikacionit, megjithatë front-end tregon se ne ende kemi versionin 1 aktiv.
Balancuesi i ngarkesës pret derisa të kryhet kontrolli i shëndetit, pas të cilit do të drejtojë trafikun në versionin e ri. Pas 20 sekondash kalojmë në curl dhe shohim se tani kemi implementuar versionin 2 të aplikacionit, ndërsa versioni i parë është fshirë.
Ky ishte implementimi i një aplikacioni “të shëndoshë” — healthy. Le të shohim çfarë ndodh nëse për versionin e ri të aplikacionit unë ndryshoj vlerën e parametrin Healthy nga true në false, domethënë po përpiqem të implementoj një aplikacion unhealthy që nuk ka kaluar kontrollin e funksionalitetit. Kjo mund të ndodhë nëse gjatë fazës së zhvillimit në aplikacion janë bërë disa gabime konfigurimi dhe ajo u dërgua në prodhim në atë formë.
Si mund ta shihni, implementimi kalon të gjitha hapat e përmendur më sipër, dhe ~ kubectl get pods tregon se të dy pod-at janë të aktivizuar. Por ndryshe nga implementimi i mëparshëm, logu tregon një gjendje timeout. Do të thotë se për shkak të dështimit të kontrollit të shëndetit, versioni i ri i aplikacionit nuk mund të implementohet. Si rezultat, ju shihni se sistemi u kthye në përdorimin e versionit të vjetër të aplikacionit, dhe versioni i ri u fshi me thjeshtësi.
E mira në këtë është se edhe nëse keni një numër të madh kërkesash të njëkohshme që po i drejtohen aplikacionit, ata as që do ta ndjejnë ndalimin gjatë realizimit të procedurës së implementimit. Nëse e testoni këtë aplikacion me kornizën Gatling, e cila i dërgon atij sa më shumë kërkesa të jetë e mundur, asnjë nga këto kërkesa nuk do të refuzohet. Kjo do të thotë se përdoruesit tanë as që do ta ndiejnë përditësimin e versioneve në kohë reale. Nëse dështimi ndodh, puna do të vazhdojë në versionin e vjetër, nëse është e suksesshme – përdoruesit do të kalojnë në versionin e ri.
Ekziston vetëm një gjë që mund të çojë në dështim – nëse kontrolli i shëndetit kalon me sukses, por aplikacioni dështon sapo merr ngarkesën e punës, do të thotë se kolapsi do të ndodhë vetëm pas përfundimit të implementimit. Në këtë rast, do ju duhet të riktheni manualisht në versionin e vjetër. Pra, ne shqyrtuam se si të përdorim Kubernetes me mjetet open-source të destinuara për të. Procedura e implementimit do të jetë shumë më e thjeshtë nëse i integroni këto mjete në kanalet e krijimit/implementimit Build/Deploy pipelines. Në këtë drejtim, për të nisur implementimin mund të përdorni si ndërfaqen e përdoruesit ashtu edhe ta automatizoni plotësisht këtë proces, duke aplikuar, për shembull, commit to master.
Serveri ynë i ndërtimit Build Server do të krijojë një imazh Docker, do ta ngarkojë në Docker Hub ose në çdo regjistër tjetër që po përdorni. Docker Hub mbështet webhook, kështu që ne mund të nisim një implementim të largët përmes Deployer në rrugën e treguar më lart. Kështu, mund të automatizoni plotësisht implementimin e aplikacionit në një potencial produksion.
Të kalojmë në temën e radhës – shkallëzimi i klasterit Kubernetes. Dua të theksoj se komanda kubectl është komanda për shkallëzim. Me ndihmën e saj, mund të rritni lehtësisht numrin e kopjeve në klasterin tonë. Megjithatë, në praktikë, zakonisht duam të rrisim numrin e notave, jo të podëve.
Në këtë mënyrë, gjatë orëve të punës, mund t'ju nevojitet rritja, ndërsa gjatë natës, për të zvogëluar kostot e shërbimeve të Amazon – zvogëlimi i numrit të instancave të aplikacionit të drejtuara. Kjo nuk do të thotë që është e mjaftueshme të shkallëzohet vetëm numri i podëve, sepse edhe nëse një nga notat është e papërdorur, prapë do t'ju duhet të paguani për të Amazon. Kështu që përveç shkallëzimit të podëve, do t'ju nevojitet të shkallëzoni edhe numrin e makinave që përdoren.
Kjo mund të shkaktojë vështirësi, sepse pavarësisht se a përdorim Amazon ose një shërbim tjetër cloud, Kubernetes nuk di asgjë për numrin e makinave të përdorura. Mungon një mjet për të shkallëzuar sistemin në nivelin e notave.
Prandaj, na duhen të kujdesemi për notat dhe podët. Ne mund të shkallëzojmë lehtësisht lançimin e notave të reja me ndihmën e AWS API dhe grupit të makinave të shkallëzimit për të konfigurimin e numrit të nyjeve punuese në Kubernetes. Po ashtu, mund të përdorim cloud-init ose një skript të ngjashëm për regjistrimin e notave në klasterin Kubernetes.
Një makinë e re nis në grupin e Shkallëzimit, inicjon vetveten si një nyje, regjistrohet në regjistrin e masterit dhe fillon punën. Pas kësaj, mund të rritet numri i replika për t'u përdorur në nyjet e krijuara. Zvogëlimi i shkallës kërkon më shumë përpjekje, pasi është e nevojshme të sigurohemi që një hap i tillë nuk do të çojë në shkatërrimin e aplikacioneve që po funksionojnë pas çaktivizimit të makinave "të panevojshme". Për të parandaluar një skenar të tillë, duhet t'i japim nyjeve statusin "përjashtues". Kjo do të thotë se planifikuesi me default gjatë planifikimit të pods DaemonSet do të injorojë këto nyje. Planifikuesi nuk do të fshijë asgjë nga këto servera, por as do të nisë ndonjë kontejner të ri aty. Hapi tjetër është nxjerrja e nyjes drain node, dmth. transferimi i pods që po punojnë në një makinë tjetër ose në nyje të tjera që ka kapacitet të mjaftueshëm për këtë. Pasi të sigurohemi që nuk ka më kontejnerë në këto nyje, ato mund të fshihen nga Kubernetes. Pas kësaj, për Kubernetes ato thjesht do të ndalen së ekzistuari. Më pas, duhen përdorur API-të e AWS për të çaktivizuar nyjet e panevojshme, ose makinat.
Mund të përdorni Amdatu Scalerd — një tjetër mjet open-source për shkallëzim, i ngjashëm me API-të e AWS. Ai ofron një CLI për të shtuar ose hequr nyje në grup. Një karakteristikë interesante e tij është mundësia për të konfiguruar planifikuesin duke përdorur skedarin json të mëposhtëm.
Kodi i paraqitur gjysmë zvogëlon kapacitetin e grupit gjatë periudhës natën. Aty është konfiguruar si numri i replika ekzistuese, ashtu edhe kapaciteti i dëshiruar i grupit Amazon. Përdorimi i këtij planifikuesi automatikisht do të zvogëlojë numrin e nyjeve natën dhe do ta rrisë atë në mëngjes, duke lejuar kursimin e kostos së përdorimit të nyjeve të një shërbimi të tillë në re si Amazon. Kjo funksionalitet nuk është e ndërtuar brenda Kubernetes, por përdorimi i Scalerd do t'ju lejojë të shkallëzoni këtë platformë ashtu siç dëshironi.
Dua t'ju kujtoj se shumë njerëz më thonë: "Të gjitha këto janë të mira, por çfarë do të bëj me bazën time të të dhënave, e cila zakonisht ndodhet në një gjendje statike?" Si mund të nisni diçka të tillë në një mjedis dinamik si Kubernetes? Në mendimin tim, nuk duhet ta bëni këtë, nuk duhet të përpiqeni të organizoni funksionimin e një ruajtjeje të dhënash në Kubernetes. Teknikisht, është e mundur dhe në internet ka udhëzime për këtë, por do ta komplikoni seriozisht jetën tuaj.
Po, në Kubernetes ekziston koncepti i ruajtjeve të qëndrueshme, dhe mund të provoni të operoni ruajtjet e të dhënave si Mongo ose MySQL, por kjo është një detyrë mjaft e ndërlikuar. Kjo për shkak se ruajtjet e të dhënave nuk e mbështesin plotësisht bashkëveprimin me një mjedis dinamik. Shumica e bazave të të dhënave kërkojnë konfigurim të konsiderueshëm, përfshirë konfigurimin manual të klasterit, nuk i pëlqejnë automatikat dhe gjëra të ngjashme.
Prandaj, nuk ia vlen të vetëkomplikoni jetën tuaj duke përpjekur të operoni një ruajtje të dhënash në Kubernetes. Organizoni funksionimin e tyre në një mënyrë tradicionale duke përdorur shërbime të njohura dhe thjesht lejoni Kubernetes të përdorë ato.
Për të përfunduar këtë temë, dëshiroj t'ju prezantoj me platformën Cloud RTI mbi Kubernetes, me të cilën po punon ekipi im. Ajo ofron regjistrimin e centralizuar të logeve, monitorimin e aplikacioneve dhe klasterëve dhe ka shumë funksione të tjera të dobishme që do t'ju nevojiten. Ajo përdor mjete të ndryshme open-source, si Grafana për visualizimin e monitorimit.
U bë një pyetje, pse të përdorim një balancues ngarkese ha-proxy me Kubernetes. Është një pyetje e mirë, sepse aktualisht ka 2 nivele të balancimit të ngarkesës. Shërbimet Kubernetes ende ndodhen në adresa IP virtuale. Nuk mund t'i përdorni ato për portet e hosteve të jashtme, sepse nëse Amazon ngarkon hostin e tij cloud, adresa do të ndryshojë. Kjo është arsyeja pse ne vendosim ha-proxy para shërbimeve — për të krijuar një strukturë më statike për ndërveprimin e pandërprerë të trafikuit me Kubernetes.
Një tjetër pyetje e mirë – si mund të kujdeseni për ndryshimin e skemës së bazës së të dhënave gjatë implementimit të blue/green deployment? E vërteta është se, pavarësisht nëse përdorni Kubernetes, ndryshimi i skemës së bazaës së të dhënave është një detyrë komplekse. Ju duhet të siguroheni për përputhshmërinë e skemës së vjetër me atë të re, pas së cilës mund të përditësoni bazën e të dhënave dhe pastaj aplikacionet. Mund të bëni një „zëvendësim të nxehtë“ hot swapping të bazës së të dhënave dhe pastaj të përditësoni aplikacionet. Di njerëz që ngarkojnë një klaster të ri të bazës së të dhënave me një skemë të re, kjo është një opsion nëse keni një bazë të dhënash pa skemë si Mongo, por në çdo rast kjo nuk është një detyrë e lehtë. Nëse nuk ka më pyetje, faleminderit për vëmendjen!
Pak reklamë 🙂
Faleminderit që po qëndroni me ne. Ju pëlqen artikujt tanë? Doni të shihni më shumë materiale interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar tek miqtë tuaj, , një analog unik i serverëve entry-level që e kemi shpikur për Ju: (opcionet me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4 janë të disponueshme).
Dell R730xd dyfish më i lirë në qendër të të dhënave Equinix Tier IV në Amsterdam? Vetëm te ne në Holandë! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — nga $99! Lexoni rreth
Burimi: habr.com
