Base image — yangi machine image yoki container image qurilishi boshlanadigan tayanch tasvirdir. U keyingi qatlamlar uchun operatsion tizim fayllari, runtime, kutubxonalar yoki tashkilot tasdiqlagan sozlamalarni beradi. Tayanchni to‘g‘ri tanlash yakuniy artifact hajmi, mosligi, yangilanish jarayoni va hujum yuzasiga bevosita ta’sir qiladi.
Tarkib darajalari
Container ekotizimida base image bir necha ko‘rinishda uchraydi. To‘liq distributiv tasviri package manager, shell va odatiy diagnostika vositalarini saqlaydi. Minimal tasvir faqat zarur tizim kutubxonalarini qoldiradi. Distroless tasvir esa dasturni ishlatish uchun kerakli runtime va sertifikatlar bilan cheklanib, odatda interaktiv shell bermaydi.
FROM scratch yozuvi butunlay bo‘sh ildiz fayl tizimidan boshlashni anglatadi. Statik bog‘langan bitta binary uchun bu yetarli bo‘lishi mumkin, ammo TLS sertifikatlari, vaqt zonalari yoki foydalanuvchi ma’lumotlari alohida qo‘shilishi kerak.
Machine image uchun base odatda vendor tarqatgan operatsion tizim shabloni yoki tashkilotning golden image’i bo‘ladi. Unda bootloader, kernel, drayver va cloud agentlari ham ahamiyatli.
Tanlash mezonlari
Base image dastur arxitekturasi va runtime talablariga mos kelishi lozim. amd64 uchun qurilgan qatlam arm64 hostda emulyatsiyasiz ishlamaydi. C kutubxonasi farqi ham muhim: glibc uchun kompilyatsiya qilingan native modul musl asosidagi tasvirda qo‘shimcha moslashtirish talab qilishi mumkin.
Kichik hajmning o‘zi xavfsizlik kafolati emas. Muhim mezonlar quyidagilar:
- vendorning patch va support siyosati;
- image manbasi va raqamli imzosi;
- paketlar soni hamda ma’lum zaifliklar;
- kerakli locale, sertifikat va diagnostika imkoniyati;
- litsenziya va qayta tarqatish shartlari.
Versiyani aniqlash
runtime:latest kabi tag o‘qishga qulay, lekin vaqt o‘tishi bilan boshqa manifestga ko‘chishi mumkin. Takrorlanuvchi build uchun image digest bilan pin qilinadi:
FROM example/runtime:3.2@sha256:...
Digest aynan qaysi artifact ishlatilganini belgilaydi. Biroq pin qilingan tasvir avtomatik patch olmaydi. Dependency monitoring yangi xavfsiz digest paydo bo‘lganini aniqlab, rebuild va test jarayonini boshlashi kerak.
Qurish va yangilash
Multi-stage build kompilyator va build vositalarini birinchi bosqichda saqlab, yakuniy tasvirga faqat executable hamda runtime fayllarini ko‘chiradi. Bu build muhiti bilan production muhitini ajratadi. Paket o‘rnatilganda cache va vaqtinchalik indekslarni o‘sha qatlamning o‘zida tozalash yakuniy hajmni kamaytiradi.
Base image’da CVE tuzatilganda avlod image’lar o‘z-o‘zidan yangilanmaydi. Ularning barchasi qayta qurilib, sinovdan o‘tib, registry’ga yangi digest bilan chiqariladi. SBOM qaysi workloadlar eskirgan kutubxonani meros olganini topishga yordam beradi.
Ishlatish chegaralari
Base ichiga environment secretlari, doimiy host identifikatori yoki bitta xizmatga xos credential yozilmaydi. Container odatda root bo‘lmagan foydalanuvchi bilan ishga tushiriladi; zarur kataloglar build paytida shu foydalanuvchiga beriladi. Debug vositalari kerak bo‘lsa, ularni har bir production tasvirga qo‘shish o‘rniga alohida diagnostika image’i ishlatilishi mumkin.
Bir tashkilot bir nechta tasdiqlangan base oilasini yuritishi mumkin: masalan, Java, Python va statik binary uchun. Har birining owneri, yangilanish muddati va end-of-life sanasi bo‘lishi avlod artifactlarni boshqarishni soddalashtiradi.
Moslik testi base yangilanganda faqat dastur ishga tushishini emas, signal handling, DNS, TLS trust va vaqt zonasi kabi operatsion xatti-harakatlarni ham tekshiradi. Kichik paket yangilanishi native modul yoki sertifikat zanjiriga kutilmagan ta’sir qilishi mumkin.
Bog‘liq tushunchalar
Container image, Machine image, Golden image, Image layer, Image digest, Multi-stage build, SBOM