Piye wae, historis, industri IT dipérang dadi rong kamp kondisional kanggo alesan apa wae: sing "kanggo" lan sing "nglawan". Menapa malih, subyek regejegan bisa rampung sembarang. OS endi sing luwih apik: Win utawa Linux? Ing smartphone Android utawa iOS? Apa sampeyan kudu nyimpen kabeh ing mega utawa sijine ing panyimpenan RAID kadhemen lan sijine ngawut-awut ing aman? Apa wong PHP duwe hak diarani programer? Sengketa iki, kadhangkala, sacara eksklusif eksistensial lan ora ana dhasar liyane saka kapentingan olahraga.
Iku mung kedaden sing karo tekane saka kontaner lan kabeh iki masakan sing ditresnani karo docker lan k8s kondisional, debat "kanggo" lan "nglawan" nggunakake kapabilitas anyar ing macem-macem wilayah backend wiwit. (Ayo nggawe reservasi luwih dhisik yen sanajan Kubernetes asring dituduhake minangka orkestra ing diskusi iki, pilihan alat tartamtu iki ora penting banget. Nanging, sampeyan bisa ngganti alat liyane sing katon paling trep lan akrab karo sampeyan. .)
Lan, misale jek, iki bakal dadi regejegan prasaja antarane loro-lorone saka duwit receh padha. Ora ana gunane lan tanpa welas asih minangka konfrontasi langgeng antarane Win vs Linux, ing ngendi ana wong sing cukup ana ing tengah-tengah. Nanging ing kasus containerization, ora kabeh gampang banget. Biasane ing perselisihan kasebut ora ana sisih tengen, nanging ing kasus "nggunakake" utawa "ora nggunakake" wadhah kanggo nyimpen database, kabeh dadi terbalik. Amarga ing pangertèn tartamtu, loro panyengkuyung lan mungsuh pendekatan iki bener.
Sisih padhang
Argumentasi The Light Side bisa diterangake kanthi ringkes ing salah sawijining frasa: "Halo, 2k19 ana ing njaba jendela!" Iku muni kaya populisme, mesthi, nanging yen sampeyan delve menyang kahanan ing rinci, iku duwe kaluwihan. Ayo diurutake saiki.
Contone, sampeyan duwe proyek web gedhe. Bisa uga dibangun kanthi basis pendekatan microservice, utawa ing sawetara titik kasebut liwat jalur evolusi - iki ora penting banget, nyatane. Sampeyan nyebarake proyek kita dadi layanan mikro sing kapisah, nyiyapake orkestrasi, imbangan beban, lan skala. Lan saiki, kanthi ati nurani sing resik, sampeyan ngombe mojito ing hammock sajrone efek habra tinimbang ngunggahake server sing tiba. Nanging ing kabeh tumindak sampeyan kudu konsisten. Asring banget, mung aplikasi kasebut dhewe-kode-konten. Apa liyane sing kita duwe kajaba kode?
Bener, data. Inti saka proyek apa wae yaiku data: iki bisa dadi DBMS khas - MySQL, Postgre, MongoDB, utawa panyimpenan sing digunakake kanggo nggoleki (ElasticSearch), panyimpenan nilai kunci kanggo caching - contone, redis, lan liya-liyane. kita bakal pirembagan bab opsi implementasine backend bengkong nalika database tubrukan amarga pitakonan ditulis kurang, lan tinimbang kita bakal pirembagan bab mesthekake toleransi fault database iki banget ing mbukak klien. Sawise kabeh, nalika kita ngemot aplikasi kita lan ngidini ukuran bebas kanggo ngolah sawetara panjaluk sing mlebu, iki kanthi alami nambah beban ing database.
Nyatane, saluran kanggo ngakses database lan server sing mbukak dadi mripat jarum ing backend kontaner sing apik. Ing wektu sing padha, motif utama virtualisasi wadah yaiku mobilitas lan keluwesan struktur, sing ngidini kita ngatur distribusi beban puncak ing kabeh infrastruktur sing kasedhiya kanggo kita kanthi efisien. Sing, yen kita ora containerize lan muter metu kabeh ana unsur sistem tengen kluster, kita nggawe kesalahan serius banget.
Iku luwih logis kanggo cluster ora mung aplikasi dhewe, nanging uga layanan tanggung jawab kanggo nyimpen data. Kanthi nglumpukake lan nyebarake server web sing makarya kanthi mandiri lan nyebarake beban ing k8s, kita wis ngrampungake masalah sinkronisasi data - komentar sing padha ing kiriman, yen kita njupuk sawetara media utawa platform blog minangka conto. Ing kasus apa wae, kita duwe perwakilan intra-cluster, malah virtual, saka database minangka ExternalService. Pitakonan iku database dhewe durung clustered - server web disebarake ing kubus njupuk informasi bab owah-owahan saka database pertempuran statis kita, kang muter dhewe.
Apa sampeyan rumangsa nyekel? Kita nggunakake k8s utawa Swarm kanggo disebaraké mbukak lan supaya nabrak server web utama, nanging kita ora nindakake iki kanggo database. Nanging yen database crash, kabeh infrastruktur clustered kita ora ana gunane - apa gunane kaca web kosong sing ngasilake kesalahan akses database?
Mulane perlu kanggo cluster ora mung server web, kaya biasane rampung, nanging uga infrastruktur database. Mung kanthi cara iki kita bisa njamin struktur sing bisa digunakake kanthi lengkap ing siji tim, nanging ing wektu sing padha bebas saka saben liyane. Menapa malih, sanajan setengah saka backend kita "ambruk" ing beban, liyane bakal urip, lan sistem nyinkronake database karo saben liyane ing kluster lan kemampuan kanggo endlessly ukuran lan masang kluster anyar bakal bantuan cepet tekan kapasitas sing dibutuhake - yen mung ana rak ing pusat data.
Kajaba iku, model basis data sing disebarake ing kluster ngidini sampeyan njupuk basis data iki menyang papan sing dibutuhake; Yen kita ngomong babagan layanan global, mula ora logis kanggo muter kluster web ing endi wae ing wilayah San Francisco lan ing wektu sing padha ngirim paket nalika ngakses database ing wilayah Moskow lan bali.
Uga, containerization database ngidini sampeyan mbangun kabeh unsur sistem ing tingkat abstraksi sing padha. Kang, ing siji, ndadekake iku bisa kanggo ngatur sistem iki langsung saka kode, dening pangembang, tanpa keterlibatan aktif administrator. Pangembang mikir yen DBMS sing kapisah dibutuhake kanggo subproyek anyar - gampang! nulis file yaml, diunggah menyang kluster lan sampeyan wis rampung.
Lan mesthi, operasi internal banget simplified. Marang kula, carane kakehan sampeyan nutup mata nalika anggota tim anyar sijine tangan menyang database pertempuran kanggo karya? Sing, nyatane, mung siji sing sampeyan duwe lan muter saiki? Mesthine, kita kabeh wong diwasa ing kene, lan ing endi wae kita duwe cadangan sing seger, lan malah luwih adoh - ing mburi rak karo timun nenek lan ski lawas - cadangan liyane, bisa uga ana ing panyimpenan sing adhem, amarga kantor sampeyan wis tau kobong. Nanging kabeh padha, saben introduksi saka anggota tim anyar karo akses menyang prasarana pertempuran lan, mesthi, kanggo database pertempuran iku ember saka validol kanggo kabeh wong watara. Nah, sapa sing kenal karo dheweke, wong anyar, mungkin dheweke tangan salib? Iku medeni, sampeyan bakal setuju.
Kontainerisasi lan, nyatane, topologi fisik sing disebarake ing basis data proyek sampeyan mbantu ngindhari wektu validasi kasebut. Ora percaya karo wong anyar? OK! Ayo menehi kluster dhewe kanggo nggarap lan medhot database saka klompok liyane - sinkronisasi mung kanthi manual push lan rotasi sinkron saka rong tombol (siji kanggo pimpinan tim, liyane kanggo admin). Lan kabeh wong seneng.
Lan saiki wektune ganti dadi mungsuh clustering database.
Sisih peteng
Argumentasi kenapa ora worth containerizing database lan terus kanggo mbukak ing siji server pusat, kita ora bakal stoop menyang retorika orthodoxies lan statements kaya "simbah mlayu database ing hardware, lan kita bakal!" Nanging, ayo nyoba nggawe kahanan sing kontainerisasi bakal menehi dividen sing nyata.
Setuju, proyek sing pancene mbutuhake basis ing wadhah bisa diitung nganggo driji siji kanthi ora operator mesin panggilingan sing paling apik. Umume, malah nggunakake k8s utawa Docker Swarm dhewe keluwih - asring alat iki digunakake amarga hype umum teknologi lan sikap "kuwoso" ing wong saka jender kanggo push kabeh menyang awan lan wadhah. Ya, amarga saiki wis modis lan kabeh wong nindakake.
Ing paling setengah saka kasus, nggunakake Kubernetis utawa mung Docker ing project keluwih. Masalahe yaiku ora kabeh tim utawa perusahaan outsourcing sing disewakake kanggo njaga infrastruktur klien ngerti babagan iki. Iku Samsaya Awon nalika kontaner dileksanakake, amarga biaya jumlah tartamtu saka dhuwit recehan kanggo klien.
Umumé, ana pendapat sing docker / mafia kubus bodho crushing klien sing outsource masalah infrastruktur iki. Sawise kabeh, kanggo nggarap kluster, kita butuh insinyur sing bisa nindakake iki lan umume ngerti arsitektur solusi sing ditindakake. Kita wis nate nerangake kasus kita karo publikasi Republik - ing kana kita nglatih tim klien supaya bisa kerja ing kasunyatan Kubernetis, lan kabeh wong marem. Lan iku prayoga. Asring, "implementers" k8s njupuk hostage infrastruktur klien - amarga saiki mung ngerti carane kabeh bisa digunakake ing kono; ora ana spesialis ing sisih klien.
Saiki bayangake yen kanthi cara iki kita ora mung outsource bagean server web, nanging uga pangopènan database. Kita ngomong yen BD iku jantung, lan mundhut jantung iku fatal kanggo organisme urip. Ing cendhak, prospek ora sing paling apik. Dadi, tinimbang hype Kubernetis, akeh proyek kudu ora ngganggu tarif normal kanggo AWS, sing bakal ngrampungake kabeh masalah babagan beban ing situs / proyek kasebut. Nanging AWS ora modis maneh, lan pamer regane luwih akeh tinimbang dhuwit - sayange, ing lingkungan IT uga.
OK. Mbok menawa proyek kasebut mbutuhake clustering, nanging yen kabeh wis jelas karo aplikasi stateless, kepiye carane bisa ngatur konektivitas jaringan sing apik kanggo database clustered?
Yen kita ngomong babagan solusi teknik sing mulus, yaiku transisi menyang k8s, mula sirah utama kita yaiku replikasi data ing database clustered. Sawetara DBMS wiwitane cukup setya karo distribusi data ing antarane kedadeyan individu. Akeh liyane sing ora dadi sambutan. Lan cukup asring argumen utama kanggo milih DBMS kanggo proyek kita ora kemampuan kanggo niru kanthi biaya sumber daya lan teknik sing minimal. Utamane yen proyek kasebut ora direncanakake minangka layanan mikro, nanging mung berkembang ing arah kasebut.
Kita mikir ora perlu ngomong babagan kacepetan drive jaringan - padha alon. Sing. Kita isih ora duwe kesempatan nyata, yen soko mengkono, kanggo miwiti maneh Kayata DBMS nang endi wae ngendi ana liyane, Contone, daya prosesor utawa RAM free. Kita bakal cepet banget mbukak kinerja subsistem disk virtual. Mulane, DBMS kudu dipaku menyang pesawat pribadine dhewe saka mesin dumunung ing jarak cedhak. Utawa perlu piye wae kapisah kelangan mudhun sinkronisasi data cekap cepet kanggo cadangan mestine.
Nerusake topik sistem file virtual: Volume Docker, sayangé, ora bebas masalah. Umumé, ing babagan panyimpenan data sing bisa dipercaya kanggo jangka panjang, aku pengin nggawe rencana sing paling gampang kanthi teknis. Lan nambah lapisan abstraksi anyar saka FS wadhah menyang FS saka inang induk minangka resiko dhewe. Nanging nalika operasi saka sistem support containerization uga nemokke kangelan karo ngirim data antarane lapisan iki, iku pancene bilai. Ing wayahe, akeh masalah sing dikenal kanggo manungsa progresif katon wis diilangi. Nanging sampeyan ngerti, mekanisme sing luwih rumit, luwih gampang rusak.
Ing cahya saka kabeh iki "petualangan," iku luwih duwe bathi lan luwih gampang kanggo nyimpen database ing sak panggonan, lan malah yen sampeyan perlu kanggo containerize aplikasi, supaya iku mbukak dhewe lan liwat gateway distribusi nampa komunikasi simultaneous karo database, sing bakal diwaca lan ditulis mung sapisan lan Ing sak panggonan. Pendekatan iki nyuda kemungkinan kesalahan lan desynchronization minimal.
Apa sing kita tuju? Menapa malih, containerization database cocok ing ngendi ana kabutuhan nyata. Sampeyan ora bisa ngisi database aplikasi lengkap lan muter kaya-kaya sampeyan duwe rong rolas layanan mikro - ora bisa kaya ngono. Lan iki kudu dingerteni kanthi jelas.
Tinimbang output
Yen sampeyan ngenteni kesimpulan sing jelas "kanggo virtualisasi database utawa ora," mula kita bakal nguciwani sampeyan: ora bakal ana ing kene. Amarga nalika nggawe solusi infrastruktur, siji kudu dipandu ora dening fashion lan kemajuan, nanging, pisanan kabeh, dening akal sehat.
Ana proyek sing prinsip lan alat sing kasedhiya karo Kubernetis pas, lan ing proyek kasebut ana tentrem paling ora ing wilayah mburi. Lan ana proyèk sing ora perlu containerization, nanging infrastruktur server normal, amarga padha dhasar ora bisa rescale kanggo model kluster microservice, amarga padha bakal tiba.
Source: www.habr.com