Immutable infrastructure — ishlab turgan server yoki instance konfiguratsiyasini joyida o‘zgartirish o‘rniga, har o‘zgarishda yangi versiyali image asosida yangi resurs yaratib, eskisini almashtirish yondashuvidir. “Immutable” apparat mutlaqo o‘zgarmaydi degani emas; boshqariladigan tizim komponentlari deploymentdan keyin qo‘lda patch qilinmasligini bildiradi.
Image yaratish
Pipeline bazaviy operatsion tizim, xavfsizlik yangilanishlari, runtime va application artifactni imagega joylaydi. Image identifier yoki digest bilan o‘zgarmas versiya sifatida nashr qilinadi. Packer, container build va cloud image builderlar bu jarayonni avtomatlashtirishi mumkin.
Build bosqichi takrorlanuvchan bo‘lishi uchun dependency versiyalari va manba checksumlari qotiriladi. Image malware scan, vulnerability scan va integration testdan o‘tadi. Bir xil labelni yangi mazmun bilan ustidan yozish qaysi byte productionga chiqqanini aniqlashni qiyinlashtiradi; unique version va provenance saqlanadi.
Deployment modeli
Yangi image bilan instance guruhi yaratiladi, health checkdan o‘tadi va trafik bosqichma-bosqich unga ko‘chiriladi. Rolling deployment eski instancelarni navbat bilan, blue–green esa yangi muhitni parallel yaratib almashtiradi. Canary kichik trafik ulushida yangi versiyani kuzatadi.
Rollback eski image va konfiguratsiya versiyasiga trafikni qaytarish orqali bajariladi. Database schema yoki tashqi side effect backward-compatible bo‘lmasa, server imageini qaytarishning o‘zi yetmaydi. Migratsiya expand–contract usuli va alohida rollback rejasi bilan loyihalanadi.
Holatni ajratish
Immutable instance mahalliy diskda uzoq muddatli yagona ma’lumotni saqlamasligi kerak. Database, object storage yoki managed volume lifecyclei compute instancedan ajratiladi. Loglar markaziy tizimga yuboriladi, session state tashqi storeda saqlanadi. Shunda instance istalgan payt almashtirilishi mumkin.
Bu stateless application degani bo‘lishi mumkin, ammo butun tizim holatsiz emas. State alohida, zaxiralanadigan va migratsiya qilinadigan qatlamga ko‘chadi. Persistent volume ham immutable compute bilan birga tasodifan o‘chirilmasligi uchun ownership va retention qoidasi bilan boshqariladi.
Afzalliklari
Joyida ko‘p yillik o‘zgarishlardan keladigan configuration drift kamayadi. Testdan o‘tgan image development, staging va productionda bir xil artifact sifatida ishlaydi. Instance nosoz bo‘lsa murakkab qo‘lda ta’mirlash o‘rniga yangisi bilan almashtiriladi. Audit qaysi image qachon va qayerga joylashtirilganini ko‘rsatadi.
Isolation va tez rollback operatsion barqarorlikni oshiradi, biroq faqat pipeline ishonchli bo‘lsa. Noto‘g‘ri image avtomatik tarzda katta miqyosda tarqalishi mumkin. Staged rollout, policy gate va image signing shu xavfni boshqaradi.
Cheklovlar
Image build va instance almashtirish kichik config o‘zgarishiga ham vaqt talab qiladi. Katta VM image tarqatish tarmoq va storage xarajatini oshiradi. Emergency patch uchun ham yangi image pipeline kerak; jarayon sekin bo‘lsa operator qo‘lda o‘zgarishga qaytadi. Shu sabab build va deploy sikli yetarlicha tezlashtiriladi.
Legacy stateful tizimni birdan immutable qilish qiyin. Image ichiga machine identity, SSH host key yoki environmentga xos secret qo‘yish klonlarda takrorlanish muammosini tug‘diradi. Bunday qiymatlar instance ishga tushganda ishonchli identity orqali beriladi.
Favqulodda kirish
Production instanceda qo‘lda tuzatish zarur bo‘lsa, u vaqtinchalik incident chorasi sifatida audit qilinadi. Keyin ayni o‘zgarish image pipelinega kiritiladi va instance almashtiriladi. Aks holda qo‘lda tuzatilgan node fleetdagi yashirin istisnoga aylanadi. Break-glass ruxsati qisqa muddatli, nomlangan va markaziy jurnalga ulangan bo‘ladi.
Bog‘liq tushunchalar
Infrastructure as Code, Golden image, Provisioning, Blue–green deployment, Configuration drift, Stateless application, Image signing