File lokal nalika migrasi aplikasi menyang Kubernetes
Nalika mbangun proses CI / CD nggunakake Kubernetes, kadhangkala masalah muncul saka incompatibility antarane syarat infrastruktur anyar lan aplikasi sing ditransfer menyang. Utamane, ing tataran mbangun aplikasi iku penting kanggo njaluk ΠΎΠ΄ΠΈΠ½ gambar sing bakal digunakake ing Π²ΡΠ΅Ρ lingkungan proyek lan kluster. Prinsip iki ndasari sing bener miturut Google manajemen kontainer (luwih saka sepisan babagan iki ngandika lan departemen teknis kita).
Ayo goleki solusi workaround populer kanggo nyimpen file sing bisa nyebabake akibat sing ora nyenengake nalika ngoperasikake kluster, lan uga nuduhake dalan sing luwih bener.
Panyimpenan statis
Kanggo ilustrasi, nimbang aplikasi web sing nggunakake sawetara jinis generator statis kanggo njupuk sakumpulan gambar, gaya, lan liya-liyane. Contone, framework Yii PHP nduweni manajer aset sing dibangun sing ngasilake jeneng direktori unik. Patut, output minangka sakumpulan path kanggo situs statis sing temenan ora intersect siji liyane (iki wis rampung kanggo sawetara alasan - contone, kanggo ngilangi duplikat nalika sawetara komponen nggunakake sumber padha). Dadi, metu saka kothak, pisanan sampeyan ngakses modul sumber web, file statis (nyatane, asring symlinks, nanging luwih akeh mengko) dibentuk lan ditata kanthi direktori root umum sing unik kanggo panyebaran iki:
webroot/assets/2072c2df/css/β¦
webroot/assets/2072c2df/images/β¦
webroot/assets/2072c2df/js/β¦
Apa tegese iki babagan kluster?
Conto paling prasaja
Ayo njupuk kasus sing cukup umum, nalika PHP didhisiki nginx kanggo nyebarake data statis lan ngolah panjalukan sing prasaja. Cara paling gampang - penyebaran prajurit karo rong wadah:
Saiki file statis sing digawe ing wadhah dilayani dening nginx kanthi bener. Nanging mugi kula ngelingake sampeyan yen iki minangka solusi primitif, tegese adoh saka ideal lan nduweni nuansa lan kekurangan dhewe, sing dibahas ing ngisor iki.
Panyimpenan sing luwih maju
Saiki bayangake kahanan nalika pangguna ngunjungi situs kasebut, ngemot kaca kanthi gaya sing kasedhiya ing wadhah kasebut, lan nalika dheweke maca kaca iki, kita ngirim maneh wadhah kasebut. Katalog aset wis kosong lan panjaluk PHP dibutuhake kanggo miwiti nggawe sing anyar. Nanging, sanajan sawise iki, pranala menyang statika lawas bakal ora relevan, sing bakal nyebabake kesalahan nalika nampilake statis.
Kajaba iku, kemungkinan kita duwe proyek sing luwih akeh utawa kurang, tegese siji salinan aplikasi ora bakal cukup:
Ayo dadi skala munggah penyebaran prajurit nganti rong replika.
Nalika situs pisanan diakses, aset digawe ing siji replika.
Ing sawetara titik, ingress mutusake (kanggo tujuan ngimbangi beban) ngirim panjaluk menyang replika kapindho, lan aset kasebut durung ana. Utawa Mungkin padha ora ana maneh amarga kita nggunakake RollingUpdate lan ing wayahe kita nindakake penyebaran.
Supaya ora ilang aset lawas, sampeyan bisa ngganti emptyDir ing hostPath, nambah statis fisik menyang simpul kluster. Pendekatan iki ala amarga kita kudu ikatan menyang simpul kluster tartamtu aplikasi sampeyan, amarga - yen pindhah menyang simpul liyane - direktori ora bakal ngemot file sing dibutuhake. Utawa sawetara jinis sinkronisasi direktori latar mburi antarane simpul dibutuhake.
Apa solusine?
Yen hardware lan sumber daya ngidini, sampeyan bisa nggunakake cephfs kanggo ngatur direktori sing padha bisa diakses kanggo kabutuhan statis. Dokumentasi resmi nyaranake drive SSD, paling tikel kaping telu replikasi lan sambungan "kandel" stabil antarane kelenjar kluster.
Pilihan sing kurang nuntut yaiku ngatur server NFS. Nanging, banjur sampeyan kudu njupuk menyang akun bisa nambah wektu nanggepi pangolahan panjalukan dening server web, lan toleransi fault bakal ninggalake akeh sing dikarepake. Konsekuensi saka Gagal iku catastrophic: mundhut saka gunung dooms kluster mati ing meksa beban LA cepet-cepet menyang langit.
Antarane liyane, kabeh pilihan kanggo nggawe panyimpenan sing terus-terusan bakal dibutuhake reresik latar mburi kumpulan file lawas sing diklumpukake sajrone wektu tartamtu. Ing ngarepe wadhah karo PHP sampeyan bisa sijine DaemonSet saka caching nginx, sing bakal nyimpen salinan aset kanggo wektu winates. Prilaku iki gampang dikonfigurasi nggunakake proxy_cache karo ambane panyimpenan ing dina utawa gigabyte papan disk.
Nggabungake metode iki karo sistem file sing disebarake ing ndhuwur nyedhiyakake lapangan gedhe kanggo imajinasi, mung diwatesi dening anggaran lan potensial teknis sing bakal ngetrapake lan ndhukung. Saka pengalaman, kita bisa ujar manawa sistem sing luwih gampang, luwih stabil kerjane. Nalika lapisan kasebut ditambahake, dadi luwih angel kanggo njaga infrastruktur, lan ing wektu sing padha, wektu sing digunakake kanggo diagnosa lan pulih saka kegagalan mundhak.
Rekomendasi
Yen implementasine opsi panyimpenan sing diusulake uga katon ora adil kanggo sampeyan (rumit, larang ...), mula kudu dipikirake kahanan saka sisih liyane. Yaiku, kanggo dig menyang arsitektur project lan ndandani masalah ing kode, diikat menyang sawetara struktur data statis ing gambar, definisi sing ora jelas babagan isi utawa prosedur kanggo "pemanasan" lan / utawa precompiling aset ing tahap perakitan gambar. Kanthi cara iki, kita entuk prilaku sing bisa diprediksi lan set file sing padha kanggo kabeh lingkungan lan replika aplikasi sing mlaku.
Yen kita bali menyang conto tartamtu kanthi kerangka Yii lan ora nliti strukture (sing dudu tujuan artikel kasebut), cukup kanggo nuduhake rong pendekatan populer:
Ngganti proses mbangun gambar kanggo nyelehake aset ing lokasi sing bisa ditebak. Iki disaranake / dileksanakake ing ekstensi kaya yii2-aset-statis.
Netepake hash khusus kanggo direktori aset, kaya sing dibahas ing contone. presentation iki (wiwit saka slide No. 35). Miturut cara, penulis laporan wekasanipun (lan ora tanpa alesan!) menehi saran sing sawise assembling aset ing mbangun server, upload menyang panyimpenan tengah (kaya S3), ing ngarepe sijine CDN.
Ngundhuh
Kasus liyane sing mesthi bakal ditindakake nalika migrasi aplikasi menyang kluster Kubernetes yaiku nyimpen file pangguna ing sistem file. Contone, kita maneh duwe aplikasi PHP sing nampa file liwat formulir upload, nindakake soko karo wong-wong mau sak operasi, lan dikirim maneh.
Ing Kubernetes, lokasi ing ngendi file kasebut kudu diselehake kudu umum kanggo kabeh replika aplikasi kasebut. Gumantung saka kerumitan aplikasi lan kabutuhan kanggo ngatur terus-terusan file kasebut, pilihan piranti sing dituduhake ing ndhuwur bisa uga dadi papan kasebut, nanging, kaya sing kita deleng, dheweke duwe kekurangan.
Rekomendasi
Siji solusi yaiku nggunakake panyimpenan kompatibel S3 (sanajan sawetara jinis kategori tuan rumah dhewe kaya minio). Ngalih menyang S3 mbutuhake owah-owahan ing tingkat kode, lan carane isi bakal dikirim ing mburi ngarep, kita wis wrote.
Sesi pangguna
Kapisah, perlu dicathet organisasi panyimpenan sesi pangguna. Asring iki uga file ing disk, sing ing konteks Kubernetes bakal mimpin kanggo panjalukan wewenang pancet saka pangguna yen panjalukane rampung ing wadhah liyane.
Masalah sebagian ditanggulangi kanthi nguripake stickySessions ing mlebu (fitur kasebut didhukung ing kabeh pengontrol ingress populer - kanggo rincian liyane, waca review kita)kanggo ngiket pangguna menyang pod tartamtu nganggo aplikasi:
Nanging iki ora bakal ngilangi masalah karo panyebaran bola-bali.
Rekomendasi
Cara sing luwih bener yaiku nransfer aplikasi kasebut menyang nyimpen sesi ing memcached, Redis lan solusi padha - ing umum, rampung nilar opsi file.
kesimpulan
Solusi infrastruktur sing dibahas ing teks mung layak digunakake ing format "crutches" sementara (sing muni luwih apik ing basa Inggris minangka workaround). Bisa uga relevan ing tahap pisanan migrasi aplikasi menyang Kubernetes, nanging ora kudu oyod.
Path sing disaranake umum yaiku nyingkirake wong-wong mau kanthi milih modifikasi arsitektur aplikasi sing cocog karo sing wis dingerteni akeh. 12-Faktor App. Nanging, iki - nggawa aplikasi menyang wangun stateless - mesthi tegese owah-owahan ing kode bakal dibutuhake, lan ing kene penting kanggo nemokake imbangan antarane kemampuan / syarat bisnis lan prospek kanggo ngleksanakake lan njaga dalan sing dipilih. .