Konteynerning ish vaqtini alohida asbob komponentlariga ajratishning go'zalligi nimada? Xususan, bu vositalar bir-birini himoya qilish uchun birlashtirilishi mumkin.
Ko'pchilikni konteynerlangan OCI tasvirlarini yaratish g'oyasi o'ziga jalb qiladi yoki shunga o'xshash tizim. Aytaylik, bizda doimiy ravishda tasvirlarni to'playdigan CI/CD bor, keyin shunga o'xshash narsa /Kubernetes qurish paytida yukni muvozanatlash nuqtai nazaridan juda foydali bo'ladi. Yaqin vaqtgacha ko'pchilik konteynerlarga Docker soketiga kirish huquqini berishdi va ularga docker build buyrug'ini ishlatishga ruxsat berishdi. bu juda xavfsiz emas, aslida bu parolsiz root yoki sudo berishdan ham yomonroq.
Shuning uchun odamlar doimo Buildahni konteynerda ishlatishga harakat qilishadi. Qisqasi, biz yaratdik Bizning fikrimizcha, Buildah-ni konteyner ichida qanday ishlatish yaxshiroq va tegishli rasmlarni joylashtirdik . Qani boshladik...
moslashish
Ushbu tasvirlar Dockerfiles-dan yaratilgan bo'lib, ularni papkadagi Buildah omborida topish mumkin .
Bu erda biz ko'rib chiqamiz .
# stable/Dockerfile
#
# Build a Buildah container image from the latest
# stable version of Buildah on the Fedoras Updates System.
# https://bodhi.fedoraproject.org/updates/?search=buildah
# This image can be used to create a secured container
# that runs safely with privileges within the container.
#
FROM fedora:latest
# Don't include container-selinux and remove
# directories used by dnf that are just taking
# up space.
RUN yum -y install buildah fuse-overlayfs --exclude container-selinux; rm -rf /var/cache /var/log/dnf* /var/log/yum.*
# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
Xost Linux yadrosi darajasida amalga oshirilgan OverlayFS o'rniga biz konteyner ichidagi dasturdan foydalanamiz. , chunki hozirda OverlayFS faqat Linux imkoniyatlaridan foydalangan holda SYS_ADMIN ruxsatnomalarini bersangizgina o'rnatilishi mumkin. Va biz Buildah konteynerlarimizni hech qanday ildiz huquqlarisiz ishga tushirishni xohlaymiz. Fuse-overlay juda tez ishlaydi va VFS xotira drayveriga qaraganda yaxshiroq ishlashga ega. Esda tutingki, Fuse-dan foydalanadigan Buildah konteynerini ishga tushirishda siz /dev/fuse qurilmasini taqdim etishingiz kerak.
podman run --device /dev/fuse quay.io/buildahctr ...
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock
Keyin qo'shimcha saqlash uchun katalog yaratamiz. qo'shimcha faqat o'qish uchun tasvir do'konlarini ulash kontseptsiyasini qo'llab-quvvatlaydi. Misol uchun, siz bitta mashinada ustki xotira maydonini sozlashingiz va keyin NFS yordamida ushbu xotirani boshqa mashinaga o'rnatishingiz va undan rasmlarni tortib olish orqali yuklab olmasdan ishlatishingiz mumkin. Xostdan ba'zi tasvir xotirasini hajm sifatida ulash va uni konteyner ichida ishlatish uchun bizga ushbu xotira kerak.
# Set up environment variables to note that this is
# not starting with user namespace and default to
# isolate the filesystem with chroot.
ENV _BUILDAH_STARTED_IN_USERNS="" BUILDAH_ISOLATION=chroot
Nihoyat, BUILDAH_ISOLATION muhit oʻzgaruvchisidan foydalanib, biz Buildah konteyneriga sukut boʻyicha chroot izolyatsiyasi bilan ishlashini aytamiz. Bu erda qo'shimcha izolyatsiya talab qilinmaydi, chunki biz allaqachon konteynerda ishlayapmiz. Buildah o'zining nom maydoni bilan ajratilgan konteynerlarini yaratishi uchun SYS_ADMIN imtiyozi talab qilinadi, bu esa konteynerning SELinux va SECCOMP qoidalarini yumshatishni talab qiladi, bu bizning xavfsiz konteynerdan qurishni afzal ko'rishimizga ziddir.
Buildahni konteyner ichida ishga tushirish
Yuqorida muhokama qilingan Buildah konteyner tasvir diagrammasi bunday konteynerlarni ishga tushirish usullarini moslashuvchan tarzda o'zgartirishga imkon beradi.
Tezlik va xavfsizlik
Kompyuter xavfsizligi har doim jarayonning tezligi va uning atrofida qanchalik himoyalanganligi o'rtasidagi kelishuvdir. Ushbu bayonot konteynerlarni yig'ishda ham to'g'ri keladi, shuning uchun quyida biz bunday kelishuv variantlarini ko'rib chiqamiz.
Yuqorida muhokama qilingan konteyner tasviri /var/lib/containers-da saqlanadi. Shuning uchun biz ushbu jildga tarkibni o'rnatishimiz kerak va buni qanday qilishimiz konteyner tasvirlarini yaratish tezligiga katta ta'sir qiladi.
Keling, uchta variantni ko'rib chiqaylik.
1 variant. Agar maksimal xavfsizlik talab qilinsa, har bir konteyner uchun konteynerlar/tasvirlar uchun o'z papkangizni yaratishingiz va uni volume-mount orqali konteynerga ulashingiz mumkin. Bundan tashqari, kontekst katalogini konteynerning o'zida, /build papkasida joylashtiring:
# mkdir /var/lib/containers1
# podman run -v ./build:/build:z -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable
buildah -t image1 bud /build
# podman run -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable buildah push image1 registry.company.com/myuser
# rm -rf /var/lib/containers1
Xavfsizlik. Bunday konteynerda ishlaydigan Buildah maksimal xavfsizlikka ega: unga imkoniyatlardan foydalangan holda hech qanday root imtiyozlari berilmaydi va unga barcha SECOMP va SELinux cheklovlari qo'llaniladi.Bunday konteyner hatto —uidmap 0 kabi variantni qo'shish orqali User Namespace izolyatsiyasi bilan ham ishga tushirilishi mumkin: 100000:10000.
Ishlash. Ammo bu erda ishlash minimal, chunki konteyner registrlaridagi rasmlar har safar xostga ko'chiriladi va keshlash umuman ishlamaydi. Ishini tugatgandan so'ng, Buildah konteyneri tasvirni ro'yxatga olish kitobiga yuborishi va xostdagi tarkibni yo'q qilishi kerak. Keyingi safar konteyner tasviri qurilganda, uni yana registrdan yuklab olish kerak bo'ladi, chunki bu vaqtga kelib xostda hech narsa qolmaydi.
2 variant. Agar sizga Docker darajasida ishlash kerak bo'lsa, siz xost konteynerini/saqlashni to'g'ridan-to'g'ri konteynerga o'rnatishingiz mumkin.
# podman run -v ./build:/build:z -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah -t image2 bud /build
# podman run -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah push image2 registry.company.com/myuser
Xavfsizlik. Bu konteynerlarni yaratishning eng xavfsiz usuli, chunki u konteynerga xostdagi saqlashni o'zgartirish imkonini beradi va Podman yoki CRI-O ga zararli tasvirni berishi mumkin. Bundan tashqari, Buildah konteyneridagi jarayonlar xostdagi saqlash bilan o'zaro aloqada bo'lishi uchun SELinux ajratishni o'chirib qo'yishingiz kerak bo'ladi. Shuni esda tutingki, bu variant hali ham Docker rozetkasidan yaxshiroq, chunki konteyner qolgan xavfsizlik xususiyatlari tufayli bloklangan va hostda konteynerni oddiygina ishga tushira olmaydi.
Ishlash. Bu erda bu maksimal, chunki keshlash to'liq ishlatiladi. Agar Podman yoki CRI-O allaqachon xostga kerakli tasvirni yuklab olgan bo'lsa, konteyner ichidagi Buildah jarayoni uni qayta yuklab olishga majbur bo'lmaydi va ushbu rasmga asoslangan keyingi tuzilmalar ham keshdan kerakli narsani olishi mumkin. .
3 variant. Ushbu usulning mohiyati konteyner tasvirlari uchun umumiy papka bilan bir loyihaga bir nechta tasvirlarni birlashtirishdir.
# mkdir /var/lib/project3
# podman run --security-opt label_level=s0:C100, C200 -v ./build:/build:z
-v /var/lib/project3:/var/lib/containers:Z quay.io/buildah/stable buildah -t image3 bud /build
# podman run --security-opt label_level=s0:C100, C200
-v /var/lib/project3:/var/lib/containers quay.io/buildah/stable buildah push image3 registry.company.com/myuser
Ushbu misolda biz loyiha papkasini (/var/lib/project3) ishga tushirish oralig'ida o'chirmaymiz, shuning uchun loyiha ichidagi barcha keyingi tuzilmalar keshlashdan foyda ko'radi.
Xavfsizlik. 1 va 2-variantlar orasida nimadir. Bir tomondan, konteynerlar xostdagi kontentga kirish imkoniga ega emas va shunga mos ravishda Podman/CRI-O tasvir xotirasiga yomon narsalarni o'tkaza olmaydi. Boshqa tomondan, uning dizaynining bir qismi sifatida konteyner boshqa idishlarni yig'ishga xalaqit berishi mumkin.
Ishlash. Bu erda xost darajasida umumiy keshdan foydalanishdan ko'ra yomonroqdir, chunki siz Podman/CRI-O yordamida allaqachon yuklab olingan rasmlardan foydalana olmaysiz. Biroq, Buildah rasmni yuklab olgandan so'ng, tasvirni loyiha doirasidagi har qanday keyingi tuzilmalarda ishlatish mumkin.
Qo'shimcha saqlash
У Qo'shimcha do'konlar (qo'shimcha do'konlar) kabi ajoyib narsa bor, buning yordamida konteynerlarni ishga tushirish va qurishda konteyner dvigatellari tashqi tasvir do'konlaridan faqat o'qish uchun mo'ljallangan qoplama rejimida foydalanishi mumkin. Asosan, siz storage.conf fayliga bir yoki bir nechta faqat oʻqish uchun saqlash joylarini qoʻshishingiz mumkin, shunda konteynerni ishga tushirganingizda, konteyner mexanizmi ulardagi kerakli tasvirni qidiradi. Bundan tashqari, agar u ushbu xotiralarning birortasida topilmasa, rasmni ro'yxatga olish kitobidan yuklab oladi. Konteyner dvigateli faqat yoziladigan xotiraga yozishi mumkin...
Agar siz yuqoriga aylanib, quay.io/buildah/stable tasvirini yaratish uchun foydalanadigan Dockerfile-ga qarasangiz, quyidagi qatorlar mavjud:
# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock
Birinchi qatorda biz /etc/containers/storage.conf ni konteyner tasviri ichida o'zgartiramiz va saqlash drayveriga /var/lib/shared papkasida "additionalimagestores" dan foydalanishni aytamiz. Va keyingi qatorda biz umumiy papkani yaratamiz va konteynerlar/saqlashdan suiiste'mol qilinmasligi uchun bir nechta qulflangan fayllarni qo'shamiz. Aslida, biz shunchaki bo'sh konteyner tasvirlari do'konini yaratmoqdamiz.
Agar siz konteynerlarni/saqlashni ushbu jilddan yuqoriroq darajaga o'rnatsangiz, Buildah rasmlardan foydalanishi mumkin bo'ladi.
Endi yuqorida muhokama qilingan 2-variantga qaytaylik, Buildah konteyneri hostlarda konteynerlar/do'konlarni o'qishi va yozishi mumkin va shunga mos ravishda Podman/CRI-O darajasida tasvirlarni keshlash tufayli maksimal ishlashga ega, lekin minimal xavfsizlikni ta'minlaydi. chunki u to'g'ridan-to'g'ri xotiraga yozishi mumkin. Keling, bu yerga qo‘shimcha xotira joylashtiramiz va ikkala dunyoning eng yaxshisini qo‘lga kiritamiz.
# mkdir /var/lib/containers4
# podman run -v ./build:/build:z -v /var/lib/containers/storage:/var/lib/shared:ro -v /var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable
buildah -t image4 bud /build
# podman run -v /var/lib/containers/storage:/var/lib/shared:ro
-v >/var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable buildah push image4 registry.company.com/myuser
# rm -rf /var/lib/continers4
Xostning /var/lib/containers/storage faqat o'qish rejimida konteyner ichidagi /var/lib/shared-ga o'rnatilganligini unutmang. Shuning uchun, konteynerda ishlaydigan Buildah Podman/CRI-O (salom, tezlik) yordamida avval yuklab olingan har qanday tasvirlardan foydalanishi mumkin, lekin faqat o'z xotirasiga yozishi mumkin (salom, xavfsizlik). Shuni ham yodda tutingki, bu konteyner uchun SELinux ajratishni o'chirmasdan amalga oshiriladi.
Muhim nuance
Hech qanday holatda siz asosiy ombordan biron bir rasmni o'chirmasligingiz kerak. Aks holda, Buildah konteyneri qulashi mumkin.
Va bu barcha afzalliklar emas
Qo'shimcha saqlash imkoniyatlari yuqoridagi stsenariy bilan cheklanmaydi. Masalan, siz barcha konteyner tasvirlarini umumiy tarmoq xotirasiga joylashtirishingiz va unga barcha Buildah konteynerlariga kirish huquqini berishingiz mumkin. Aytaylik, bizda CI/CD tizimi muntazam ravishda konteyner tasvirlarini yaratish uchun foydalanadigan yuzlab tasvirlar mavjud. Biz ushbu tasvirlarning barchasini bitta xotira xostiga jamlaymiz va keyin afzal qilingan tarmoq saqlash vositalaridan (NFS, Gluster, Ceph, ISCSI, S3...) foydalanib, barcha Buildah yoki Kubernetes tugunlariga ushbu xotiraga umumiy kirishni ochamiz.
Endi ushbu tarmoq xotirasini /var/lib/shared-dagi Buildah konteyneriga o'rnatish kifoya va tamom - Buildah konteynerlari endi pull orqali rasmlarni yuklab olishlari shart emas. Shunday qilib, biz populyatsiyadan oldingi bosqichni tashlaymiz va darhol idishlarni siljitishga tayyormiz.
Va, albatta, bu jonli Kubernetes tizimi yoki konteyner infratuzilmasi doirasida istalgan joyda tasvirlarni tortib olmasdan konteynerlarni ishga tushirish va ishga tushirish uchun ishlatilishi mumkin. Bundan tashqari, konteyner registri, unga yangilangan rasmni yuklash uchun push so'rovini olgan holda, ushbu rasmni avtomatik ravishda umumiy tarmoq xotirasiga yuborishi mumkin, u erda u darhol barcha tugunlar uchun mavjud bo'ladi.
Konteyner tasvirlari ba'zan juda ko'p gigabaytga etishi mumkin. Qo'shimcha saqlashning funksionalligi bunday tasvirlarni tugunlar bo'ylab klonlashdan qochish imkonini beradi va konteynerlarni deyarli bir zumda ishga tushiradi.
Bundan tashqari, biz hozirda konteynerlarni qurishni yanada tezlashtiradigan “overlay volume mounts” deb nomlangan yangi xususiyat ustida ishlamoqdamiz.
xulosa
Buildah-ni Kubernetes/CRI-O, Podman yoki hatto Docker-da konteyner ichida ishlatish docker.socket-dan foydalanishdan ko'ra mumkin, sodda va xavfsizroqdir. Tasvirlar bilan ishlashning moslashuvchanligini sezilarli darajada oshirdik, shuning uchun siz ularni xavfsizlik va unumdorlik oʻrtasidagi muvozanatni optimallashtirish uchun turli usullarda ishlatishingiz mumkin.
Qo'shimcha xotiraning funksionalligi tasvirlarni tugunlarga yuklab olishni tezlashtirish yoki hatto butunlay yo'q qilish imkonini beradi.
Manba: www.habr.com