Kubernetes mangrupikeun alat anu saé pikeun ngajalankeun wadah Docker dina lingkungan produksi clustered. Nanging, aya masalah anu teu tiasa direngsekeun ku Kubernetes. Pikeun deployments produksi sering, urang peryogi Blue / Héjo deployment pinuh otomatis pikeun nyegah downtime dina prosés, nu ogé perlu nanganan requests HTTP éksternal sarta ngalakukeun offloads SSL. Ieu peryogi integrasi sareng pangimbang beban sapertos ha-proxy. Tangtangan anu sanésna nyaéta skala semi-otomatis tina klaster Kubernetes sorangan nalika ngajalankeun di lingkungan awan, contona sawaréh skala klaster turun peuting.
Sanaos Kubernetes henteu gaduh fitur-fitur ieu di luar kotak, éta nyayogikeun API anu anjeun tiasa dianggo pikeun ngarengsekeun masalah anu sami. Alat pikeun panyebaran Biru/Héjo otomatis sareng skala klaster Kubernetes dikembangkeun salaku bagian tina proyék Cloud RTI, anu didamel dumasar kana open-source.
Tulisan ieu, transkrip pidéo, nunjukkeun anjeun kumaha nyetél Kubernetes sareng komponén open source sanés pikeun nyiptakeun lingkungan anu siap produksi anu nampi kode tina git commit tanpa downtime dina produksi.
Janten, saatos anjeun gaduh aksés kana aplikasi anjeun ti dunya luar, anjeun tiasa mimiti nyetél otomatisasi, nyaéta, bawa ka panggung dimana anjeun tiasa ngalakukeun git commit sareng pastikeun yén git commit ieu réngsé dina produksi. Alami, nalika ngalaksanakeun léngkah-léngkah ieu, nalika ngalaksanakeun panyebaran, urang henteu hoyong ngalaman downtime. Janten, sagala otomatisasi di Kubernetes dimimitian ku API.
Kubernetes sanes alat anu tiasa dianggo sacara produktif out of the box. Tangtosna, anjeun tiasa ngalakukeun éta, nganggo kubectl sareng saterasna, tapi tetep API mangrupikeun hal anu paling pikaresepeun sareng mangpaat ngeunaan platform ieu. Ku ngagunakeun API salaku sakumpulan fungsi, anjeun tiasa ngaksés ampir naon waé anu anjeun hoyong laksanakeun di Kubernetes. kubectl sorangan ogé ngagunakeun REST API.
Ieu REST, janten anjeun tiasa nganggo basa atanapi alat naon waé pikeun damel sareng API ieu, tapi kahirupan anjeun bakal langkung gampang ku perpustakaan khusus. Tim kuring nyerat 2 perpustakaan sapertos kieu: hiji pikeun Java / OSGi sareng hiji pikeun Go. Anu kadua henteu sering dianggo, tapi dina sagala hal anjeun ngagaduhan hal-hal anu mangpaat ieu. Éta mangrupikeun proyék open source anu sawaréh dilisensikeun. Aya seueur perpustakaan pikeun basa anu béda-béda, ku kituna anjeun tiasa milih anu paling cocog sareng anjeun.
Janten, sateuacan anjeun nga-otomatiskeun panyebaran anjeun, anjeun kedah mastikeun yén prosésna moal tunduk kana downtime naon waé. Salaku conto, tim kami ngalaksanakeun panyebaran produksi nalika tengah dinten nalika jalma-jalma paling sering ngagunakeun aplikasi, janten penting pikeun ngahindarkeun telat dina prosés ieu. Pikeun ngahindarkeun downtime, 2 metode dianggo: panyebaran biru/héjo atanapi update rolling. Dina kasus anu terakhir, upami anjeun ngagaduhan 5 réplika tina aplikasi anu dijalankeun, aranjeunna diropéa sacara berturut-turut. Metoda ieu jalan hébat, tapi teu cocog mun anjeun boga versi béda tina aplikasi nu ngajalankeun sakaligus salila prosés deployment. Dina hal ieu, anjeun bisa ngamutahirkeun antarbeungeut pamaké bari backend ngajalankeun versi heubeul, sarta aplikasi bakal eureun gawé. Ku alatan éta, tina sudut pandang programming, digawé dina kaayaan kitu téh rada hese.
Ieu mangrupikeun salah sahiji alesan kunaon urang resep ngagunakeun panyebaran biru/héjo pikeun ngajadikeun otomatis panyebaran aplikasi urang. Kalayan padika ieu, anjeun kedah mastikeun yén ngan ukur hiji versi aplikasi anu aktip dina hiji waktos.
Mékanisme panyebaran biru / héjo sapertos kieu. Kami nampi lalu lintas pikeun aplikasi kami ngalangkungan ha-proxy, anu diteruskeun pikeun ngajalankeun réplika aplikasi tina versi anu sami.
Lamun deployment anyar dijieun, kami nganggo Deployer, nu dibéré komponén anyar jeung deploys versi anyar. Deploying versi anyar tina hiji aplikasi hartina susunan anyar réplika "diangkat", nu satutasna réplika tina versi anyar ieu dibuka dina misah, pod anyar. Nanging, ha-proxy henteu terang nanaon ngeunaan aranjeunna sareng henteu ngajalurkeun beban kerja ka aranjeunna.
Ku alatan éta, mimiti sagala, perlu pikeun ngalakukeun pamariksaan kinerja versi anyar tina mariksa kaséhatan pikeun mastikeun yén réplika siap ngalayanan beban.
Sadaya komponén panyebaran kedah ngadukung sababaraha bentuk pamariksaan kaséhatan. Ieu tiasa janten cek panggero HTTP anu saderhana pisan, nalika anjeun nampi kodeu kalayan status 200, atanapi cek anu langkung jero, dimana anjeun pariksa sambungan réplika sareng database sareng jasa anu sanés, stabilitas sambungan lingkungan dinamis. , sareng naha sadayana dimimitian sareng jalanna leres. Proses ieu tiasa rada rumit.
Saatos sistem verifies yén sakabéh réplika diropéa jalan, Deployer bakal ngamutahirkeun konfigurasi tur lulus confd bener, nu bakal reconfigure ha-proxy.
Ngan sanggeus ieu lalulintas bakal diarahkeun ka pod kalawan réplika tina versi anyar, sarta pod heubeul bakal ngaleungit.
Mékanisme ieu sanés fitur Kubernetes. Konsep panyebaran Biru/héjo parantos lami lami sareng sok nganggo pangimbang beban. Mimiti, anjeun langsungkeun sadaya lalu lintas kana versi aplikasi anu lami, sareng saatos pembaruan, anjeun leres-leres mindahkeun kana versi énggal. Prinsip ieu dianggo henteu ngan di Kubernetes.
Ayeuna kuring bakal ngawanohkeun anjeun komponén deployment anyar - Deployer, nu ngalakukeun cék kaséhatan, reconfigures proxy, jeung saterusna. Ieu mangrupikeun konsép anu henteu dilarapkeun ka dunya luar sareng aya di jero Kubernetes. Kuring bakal nunjukkeun anjeun kumaha anjeun tiasa nyiptakeun konsép Deployer anjeun nyalira nganggo alat open-source.
Janten, anu munggaran dilakukeun ku Deployer nyaéta nyiptakeun pengendali réplikasi RC nganggo API Kubernetes. API ieu nyiptakeun pods sarta jasa pikeun deployment salajengna, nyaeta, nyiptakeun klaster lengkep anyar pikeun aplikasi urang. Pas RC yakin yén réplika parantos ngamimitian, éta bakal ngalaksanakeun pamariksaan Kaséhatan kana fungsionalitasna. Jang ngalampahkeun ieu, Deployer nganggo paréntah GET / kaséhatan. Éta ngajalankeun komponén scan anu pas sareng mariksa sadaya elemen anu ngadukung operasi kluster.
Sanggeus kabéh pods geus dilaporkeun kaséhatan maranéhanana, Deployer nyieun unsur konfigurasi anyar - gudang disebarkeun jsb, nu dipaké internal ku Kubernetes, kaasup nyimpen konfigurasi beban balancer. Urang nulis data ka etcd, sarta alat leutik disebut confd monitor etcd pikeun data anyar.
Lamun ngadeteksi parobahan mana wae kana konfigurasi awal, eta dibangkitkeun file setelan anyar jeung mindahkeun ka ha-proxy. Dina hal ieu, ha-proxy reboots tanpa kaleungitan sambungan naon waé sareng alamat beban ka jasa énggal anu ngamungkinkeun versi anyar aplikasi urang tiasa jalan.
Sakumaha anjeun tiasa tingali, sanaos seueur komponén, teu aya anu rumit di dieu. Anjeun ngan perlu nengetan leuwih kana API jeung jsb. Abdi hoyong nyarioskeun ka anjeun ngeunaan panyebaran open-source anu kami anggo - Amdatu Kubernetes Deployer.
Ieu mangrupikeun alat pikeun ngatur panyebaran Kubernetes sareng gaduh fitur-fitur ieu:
- deployment Bulao / Héjo;
- nyetel hiji balancer beban éksternal;
- manajemén descriptor deployment;
- ngatur deployment sabenerna;
- mariksa pungsionalitas cék Kaséhatan salila deployment;
- palaksanaan variabel lingkungan kana pods.
Deployer ieu diwangun dina luhureun API Kubernetes jeung nyadiakeun API REST pikeun ngatur handles na deployments, kitu ogé Websocket API pikeun ngalirkeun data log salila prosés deployment.
Éta nempatkeun data konfigurasi load balancer kana etcd, ku kituna anjeun teu kedah nganggo ha-proxy kalayan dukungan anu luar biasa, tapi gampang ngagunakeun file konfigurasi load balancer anjeun nyalira. Amdatu Deployer ditulis dina Go, sapertos Kubernetes sorangan, sareng dilisensikeun ku Apache.
Sateuacan kuring ngamimitian nganggo versi panyebaran ieu, kuring nganggo deskriptor penyebaran di handap ieu, anu netepkeun parameter anu kuring peryogikeun.
Salah sahiji parameter penting tina kode ieu nyaéta ngaktipkeun bendera "useHealthCheck". Urang kedah netepkeun yén pamariksaan sanity kedah dilakukeun nalika prosés panyebaran. Setelan ieu tiasa ditumpurkeun nalika panyebaran nganggo wadah pihak katilu anu henteu kedah diverifikasi. Deskriptor ieu ogé nunjukkeun jumlah réplika sareng URL frontend anu diperyogikeun ha-proxy. Dina tungtungna aya pod spésifikasi bandéra "podspec", nu nelepon Kubernetes pikeun émbaran ngeunaan konfigurasi port, gambar, jsb. Ieu mangrupikeun deskriptor JSON anu cukup saderhana.
Alat anu sanésna mangrupikeun bagian tina proyék Amdatu open-source nyaéta Deploymentctl. Mibanda UI pikeun ngonpigurasikeun panyebaran, nyimpen sajarah panyebaran, sareng ngandung webhooks pikeun nelepon balik ti pangguna sareng pamekar pihak katilu. Anjeun teu tiasa nganggo UI saprak Amdatu Deployer sorangan mangrupikeun API REST, tapi antarbeungeut ieu tiasa ngajantenkeun panyebaran langkung gampang pikeun anjeun tanpa ngalibetkeun API. Deploymentctl ditulis dina OSGi/Vertx nganggo Angular 2.
Kuring ayeuna bakal nunjukkeun di luhur dina layar nganggo rékaman anu tos dirékam supados anjeun henteu kedah ngantosan. Kami bakal nyebarkeun aplikasi Go anu sederhana. Tong hariwang upami anjeun henteu acan nyobian Go sateuacanna, éta mangrupikeun aplikasi anu saderhana pisan janten anjeun kedah tiasa terang.
Di dieu urang nyieun hiji server HTTP nu ukur ngabales / kaséhatan, jadi aplikasi ieu ukur nguji cek kaséhatan jeung sia sejenna. Upami cek pas, struktur JSON anu dipidangkeun di handap ieu dianggo. Ieu ngandung versi aplikasi anu bakal disebarkeun ku panyebaran, pesen anu anjeun tingali di luhur file, sareng jinis data boolean - naha aplikasi urang jalan atanapi henteu.
Kuring curang saeutik jeung garis panungtungan, sabab kuring nempatkeun hiji nilai boolean tetep dina luhureun file, nu di mangsa nu bakal datang bakal nulungan kuring nyebarkeun malah hiji "damang" aplikasi. Urang bakal nungkulan ieu engké.
Ku kituna hayu urang ngamimitian. Kahiji, urang pariksa ayana sagala pods ngajalankeun maké paréntah ~ kubectl get pods na, dumasar kana henteuna respon ti URL frontend, urang pastikeun yén euweuh deployments ayeuna keur dijieun.
Teras dina layar anjeun ningali antarmuka Deploymentctl anu ku kuring disebatkeun, dimana parameter panyebaran diatur: ruang ngaran, nami aplikasi, versi penyebaran, jumlah réplika, URL hareup-tungtung, nami wadahna, gambar, wates sumberdaya, nomer port pikeun pariksa kaséhatan, jsb. wates sumberdaya pohara penting, sabab ngidinan Anjeun pikeun ngagunakeun jumlah maksimum mungkin hardware. Di dieu anjeun ogé tiasa ningali log Deployment.
Upami anjeun ayeuna ngulang paréntah ~ kubectl get pods, anjeun tiasa ningali yén sistem "freezes" salami 20 detik, nalika ha-proxy dikonfigurasi deui. Saatos ieu, pod dimimitian, sareng réplika kami tiasa ditingali dina log penyebaran.
Kuring motong kaluar 20 detik antosan ti video, tur ayeuna anjeun tiasa ningali dina layar nu versi mimiti aplikasi nu geus deployed. Sadaya ieu dilakukeun ngan ukur nganggo UI.
Ayeuna hayu urang coba versi kadua. Jang ngalampahkeun ieu, kuring ngarobah pesen aplikasi tina "Halo, Kubernetes!" dina "Halo, Deployer!", Sistem nyiptakeun gambar ieu sareng nempatkeun éta dina pendaptaran Docker, saatos éta urang ngan saukur klik tombol "Deploy" deui dina jandela Deploymentctl. Dina hal ieu, log panyebaran sacara otomatis diluncurkeun dina cara anu sami sareng anu kajantenan nalika nyebarkeun versi mimiti aplikasi.
Paréntah ~ kubectl get pods nunjukkeun yén ayeuna aya 2 versi aplikasi anu dijalankeun, tapi frontend nunjukkeun yén urang masih ngajalankeun versi 1.
Pengimbang beban ngantosan pamariksaan kaséhatan réngsé sateuacan alihan lalu lintas ka versi énggal. Saatos 20 detik, urang ngalih ka curl sareng ningali yén urang ayeuna gaduh versi 2 tina aplikasi anu disebarkeun, sareng anu munggaran parantos dihapus.
Ieu mangrupikeun panyebaran aplikasi "séhat". Hayu urang tingali naon anu lumangsung lamun versi anyar tina aplikasi kuring ngarobah parameter Sehat tina leres mun palsu, nyaeta, abdi nyobian nyebarkeun hiji aplikasi damang nu geus gagal dina dipariksa kaséhatan. Ieu tiasa kajantenan upami sababaraha kasalahan konfigurasi dilakukeun dina aplikasi dina tahap pamekaran, sareng dikirim kana produksi dina bentuk ieu.
Sakumaha anjeun tiasa tingali, panyebaran ngalangkungan sadaya léngkah di luhur sareng ~kubectl get pods nunjukkeun yén duanana pods jalan. Tapi teu kawas deployment saméméhna, log nembongkeun status timeout. Nyaéta, kusabab kanyataan yén pamariksaan kaséhatan gagal, versi anyar aplikasina henteu tiasa disebarkeun. Hasilna, anjeun tiasa ningali yén sistem parantos dibalikkeun deui nganggo vérsi aplikasi anu lami, sareng vérsi énggal parantos dihapus.
Hal anu saé ngeunaan ieu nyaéta sanaos anjeun gaduh sajumlah ageung panyuwunan sakaligus anu asup kana aplikasi, aranjeunna moal bakal aya perhatikeun downtime nalika ngalaksanakeun prosedur panyebaran. Upami anjeun nguji aplikasi ieu nganggo kerangka Gatling, anu ngirimkeun saloba pamundut anu mungkin, teras teu aya pamundut ieu anu bakal dileungitkeun. Ieu ngandung harti yén pamaké urang malah moal perhatikeun apdet versi sacara real waktos. Upami gagal, padamelan bakal diteruskeun dina versi anu lami; upami éta suksés, pangguna bakal ngalih ka versi énggal.
Aya ngan ukur hiji hal anu tiasa gagal - upami pamariksaan kaséhatan suksés, tapi aplikasina gagal pas beban kerja diterapkeun, nyaéta, runtuhna bakal lumangsung ngan saatos panyebaran réngsé. Dina hal ieu, anjeun bakal kudu sacara manual gulung deui ka versi heubeul. Janten, urang ningali kumaha ngagunakeun Kubernetes sareng alat open-source anu dirancang pikeun éta. Prosés panyebaran bakal langkung gampang upami anjeun ngawangun alat-alat ieu kana saluran pipa Build / Deploy anjeun. Dina waktos anu sami, pikeun ngamimitian panyebaran, anjeun tiasa nganggo antarbeungeut pangguna atanapi ngajadikeun otomatis prosés ieu ku ngagunakeun, contona, komitmen pikeun ngawasaan.
Server Build kami bakal nyiptakeun gambar Docker, nyorong kana Docker Hub atanapi pendaptaran naon waé anu anjeun anggo. Docker Hub ngadukung webhook, ku kituna urang tiasa memicu panyebaran jauh via Deployer ku cara anu dipidangkeun di luhur. Ku cara ieu anjeun tiasa ngajadikeun otomatis panyebaran aplikasi anjeun ka produksi poténsial.
Hayu urang ngaléngkah ka topik salajengna - skala klaster Kubernetes. Catet yén paréntah kubectl nyaéta paréntah skala. Kalayan pitulung langkung, urang tiasa sacara gampil ningkatkeun jumlah réplika dina kluster anu tos aya. Nanging, dina prakna, urang biasana hoyong ningkatkeun jumlah node tinimbang pods.
Dina waktos anu sami, salami jam damel anjeun kedah ningkat, sareng wengi, pikeun ngirangan biaya jasa Amazon, anjeun panginten kedah ngirangan jumlah instansi aplikasi anu ngajalankeun. Ieu henteu hartosna yén skala ngan ukur jumlah pod bakal cekap, sabab sanaos salah sahiji titik teu dianggurkeun, anjeun tetep kedah mayar Amazon pikeun éta. Hartina, babarengan jeung skala nu pods, anjeun bakal kudu skala jumlah mesin dipaké.
Ieu tiasa janten tantangan sabab naha urang nganggo Amazon atanapi jasa awan anu sanés, Kubernetes henteu terang nanaon ngeunaan jumlah mesin anu dianggo. Ieu lacks alat nu ngidinan Anjeun pikeun skala sistem dina tingkat titik.
Janten urang kedah ngurus boh node sareng pods. Urang bisa kalayan gampang skala peluncuran titik anyar ngagunakeun API AWS jeung mesin grup Scaling pikeun ngonpigurasikeun jumlah titik worker Kubernetes. Anjeun ogé tiasa nganggo awan-init atanapi skrip anu sami pikeun ngadaptar titik dina klaster Kubernetes.
Mesin anyar dimimitian dina grup Scaling, initiates sorangan salaku titik, ngadaptar dina pendaptaran master tur mimitian digawé. Saatos ieu, anjeun tiasa ningkatkeun jumlah réplika pikeun dianggo dina titik anu dihasilkeun. Skala handap merlukeun leuwih usaha, anjeun kudu mastikeun yén hambalan saperti teu ngakibatkeun karuksakan geus ngajalankeun aplikasi sanggeus mareuman "teu perlu" mesin. Pikeun nyegah skenario sapertos kitu, anjeun kedah nyetél titik kana status "unschedulable". Ieu ngandung harti yén penjadwal standar bakal malire titik ieu nalika ngajadwalkeun pod DaemonSet. Penjadwal moal mupus nanaon tina server ieu, tapi ogé bakal ngajalankeun euweuh wadah anyar dinya. Lengkah saterusna nyaéta pikeun ngaleungitkeun titik solokan, nyaéta, mindahkeun pods anu ngajalankeun ti dinya ka mesin anu sanés, atanapi titik sanés anu ngagaduhan kapasitas anu cekap pikeun ieu. Sakali anjeun mastikeun yén teu aya deui wadah dina titik ieu, anjeun tiasa ngahapus aranjeunna tina Kubernetes. Saatos ieu, aranjeunna ngan saukur bakal lirén pikeun Kubernetes. Salajengna, anjeun kedah nganggo API AWS pikeun nganonaktipkeun titik atanapi mesin anu teu perlu.
Anjeun tiasa nganggo Amdatu Scalerd, alat skala sumber terbuka sanés anu sami sareng API AWS. Éta nyayogikeun CLI pikeun nambihan atanapi ngahapus titik dina klaster. Fitur anu pikaresepeun nyaéta kamampuan pikeun ngonpigurasikeun jadwal nganggo file json di handap ieu.
Kodeu ditémbongkeun ngurangan kapasitas klaster ku satengah salila periode peuting. Éta ngonpigurasikeun jumlah réplika anu sayogi sareng kapasitas anu dipikahoyong tina kluster Amazon. Ngagunakeun scheduler ieu otomatis bakal ngurangan jumlah titik peuting jeung nambahanana isuk-isuk, nyimpen biaya pamakéan titik tina layanan awan kawas Amazon. Fitur ieu teu diwangun kana Kubernetes, tapi ngagunakeun Scalerd bakal ngidinan Anjeun pikeun skala platform ieu kumaha ogé rék.
Abdi hoyong nunjukkeun yén seueur jalma anu nyarios ka kuring, "Éta saé sareng saé, tapi kumaha upami database kuring, anu biasana statik?" Kumaha anjeun tiasa ngajalankeun sapertos kieu dina lingkungan dinamis sapertos Kubernetes? Dina pamanggih kuring, anjeun teu kudu ngalakukeun ieu, anjeun teu kudu nyoba ngajalankeun gudang data di Kubernetes. Ieu téhnisna mungkin, tur aya tutorials on Internet dina subjék ieu, tapi serius bakal ngahesekeun hirup anjeun.
Leres, aya konsép toko pengkuh di Kubernetes, sareng anjeun tiasa nyobian ngajalankeun toko data sapertos Mongo atanapi MySQL, tapi ieu mangrupikeun tugas anu padat karya. Ieu alatan kanyataan yén gudang data teu pinuh ngarojong interaksi jeung lingkungan dinamis. Paling basis data merlukeun konfigurasi signifikan, kaasup konfigurasi manual tina klaster, teu resep autoscaling jeung hal séjén nu sarupa.
Janten, anjeun henteu kedah ngahesekeun kahirupan anjeun ku nyobian ngajalankeun gudang data di Kubernetes. Atur karyana ku cara tradisional nganggo ladenan anu biasa sareng cukup masihan Kubernetes kamampuan pikeun ngagunakeunana.
Pikeun nyimpulkeun topik, kuring hoyong ngenalkeun anjeun kana platform Cloud RTI dumasar kana Kubernetes, anu tim kuring damel. Éta nyayogikeun logging terpusat, aplikasi sareng ngawaskeun klaster, sareng seueur fitur anu kapaké sanés anu tiasa dianggo. Éta ngagunakeun sababaraha alat open-source sapertos Grafana pikeun nampilkeun monitoring.
Aya patarosan ngeunaan naha ngagunakeun ha-proxy load balancer sareng Kubernetes. Patarosan anu saé sabab ayeuna aya 2 tingkat kasaimbangan beban. Ladenan Kubernetes masih aya dina alamat IP virtual. Anjeun teu tiasa nganggo aranjeunna pikeun palabuhan dina mesin host éksternal sabab upami Amazon overloads host awan na, alamatna bakal robih. Ieu sababna kami nempatkeun ha-proxy di payuneun jasa - pikeun nyiptakeun struktur anu langkung statik pikeun lalu lintas komunikasi lancar sareng Kubernetes.
Patarosan anu sanés nyaéta kumaha anjeun tiasa ngurus parobahan skéma database nalika ngalaksanakeun panyebaran biru / héjo? Kanyataan yén henteu paduli panggunaan Kubernetes, ngarobih skéma database mangrupikeun tugas anu sesah. Anjeun kedah mastikeun yén skéma anu lami sareng énggal cocog, saatos anjeun tiasa ngapdet pangkalan data teras ngapdet aplikasi nyalira. Anjeun tiasa hot swap database lajeng ngapdet aplikasi. Kuring nyaho jalma anu geus booted up klaster database lengkep anyar kalawan schema anyar, ieu mangrupa pilihan lamun boga database schemeless kawas Mongo, tapi teu hiji tugas gampang atoh. Upami anjeun teu gaduh patarosan salajengna, hatur nuhun kana perhatian anjeun!
Sababaraha iklan 🙂
Hatur nuhun pikeun tetep sareng kami. Naha anjeun resep artikel kami? Hoyong ningali eusi anu langkung narik? Dukung kami ku cara nempatkeun pesenan atanapi nyarankeun ka babaturan, , analog unik tina server tingkat éntri, anu diciptakeun ku kami pikeun anjeun: (sadia kalawan RAID1 na RAID10, nepi ka 24 cores sarta nepi ka 40GB DDR4).
Dell R730xd 2 kali langkung mirah dina puseur data Equinix nagara golongan IV di Amsterdam? Ngan di dieu di Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ti $99! Baca ngeunaan
sumber: www.habr.com