Konteynerlərin icra mühitini ayrı-seçkilikdə alət komponentlərinə bölmənin üstünlüyü nədir? Xüsusilə, bu alətləri bir-birləri ilə birləşdirərək bir-birini qorumaq üçün başlatmaq imkanıdır.
Çoxları konteyner OCI şəkillərini digər sistem çərçivəsində yığma fikrini cazibədar hesab edir. və ya oxşar bir sistem. Tutaq ki, davamlı olaraq şəkillər yığan bir CI/CD sistemimiz var, onda bir şey kimi /Kubernetes было бы весьма полезно с точки зрения распределения нагрузки при сборке. До недавних пор большинство людей просто давали контейнерам доступ к Docker-сокету и разрешали выполнять команду docker build. , bunun çox təhlükəsiz olmadığını, əslində, şifrə olmadan root və ya sudo verməkdən daha pis olduğunu.
Buna görə insanlar daima Buildah-ı konteynerdə başlatmağa çalışırlar. Qısa desək, biz Buildah-ı konteyner içində ən yaxşı şəkildə başlatmağın bizə görə bir misalını yaradırıq və müvafiq şəkilləri yükləmişik. Başlayaq...
Konfiqurasiya
Bu şəkillər Buildah-repozitoriyasında tapılan Dockerfiles-dan toplanmışdır. .
Burada .
# 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
öyrənəcəyik. Host Linux nüvəsi səviyyəsində həyata keçirilən OverlayFS əvəzinə, konteyner içində proqramından istifadə edirik, çünki hal-hazırda OverlayFS yalnız Linux imkanları ilə SYS_ADMIN səlahiyyətləri verildikdə montaj edə bilir. Və biz root səviyyəsində heç bir səlahiyyət olmadan Buildah konteynerlərimizi başlatmaq istəyirik. Fuse-overlay olduqca sürətli işləyir və VFS storage driver-dan daha yaxşı performansa malikdir. Buildah konteynerini çalışdırarkən Fuse istifadə edildiyində /dev/fuse cihazını təqdim etməlisiniz.
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
Sonra əlavə saxlama yerləri üçün bir kataloq yaradırıq. şəkil saxlama üçün əlavə read-only saxlama yerlərini qoşma konsepsiyasını dəstəkləyir. Məsələn, bir maşında overlay storage area qurub, sonra NFS ilə bu saxlama yerini digər bir maşında montaj edərək oradan şəkillər istifadə edə bilərsiniz, çəkmədən. Bizim bu saxlama lazım olur ki, hostdan bir şəkil saxlama yerinə bir volüme qoşulub, onu konteyner içində istifadə edə bilək.
# 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
Və nəhayət, BUILDAH_ISOLATION mühit dəyişənindən istifadə edərək, default olaraq Buildah konteynerinin chroot izolyasiyası ilə başlatılmasını bildiririk. Burada əlavə izolyasiyaya ehtiyac yoxdur, çünki biz artıq konteynerdə işləyirik. Buildah-ın öz konteynerlərini namespace ayrılması ilə yaratması üçün SYS_ADMIN səlahiyyəti tələb olunur, bu, SELinux və SECCOMP üçün konteynerin qaydalarını yumşaltmağı tələb edir ki, bu da təhlükəsiz konteynerdən yığma apara biləcəyimiz quraşdırmamıza ziddir.
Buildah-ı konteyner içində başlatırıq
Yuxarıda müzakirə olunan Buildah konteynerinin şəkil sxemi, bu cür konteynerlərin işə salınma üsullarını çevik şəkildə dəyişdirməyə imkan verir.
Sürət və Təhlükəsizlik
Kompüter təhlükəsizliyi hər zaman prosesin yerinə yetirilmə sürəti ilə onun ətrafında nə qədər müdafiə tədbirlərinin görüldüyü arasında bir kompromisdir. Bu fikir konteynerlərin qurulmasında da doğrudur, buna görə aşağıda bu cür bir kompromis variantlarını nəzərdən keçirəcəyik.
Yuxarıda müzakirə olunan konteyner imici onun depolamasını /var/lib/containers-də saxlayır. Buna görə, bu qovluğa məzmunu qeyd etməliyik, və bunu necə edəcəyimiz konteyner şəkillərinin qurulma sürətinə ciddi təsir edəcək.
Üç variantı nəzərdən keçirək.
Variant 1. Əgər maksimal təhlükəsizlik tələb olunursa, hər konteyner üçün containers/image qovluğunda öz qovluğu açıb, bunu volum-mount vasitəsilə konteynerə qoşmaq olar. Bundan əlavə, kontekstdən ibarət qovluğu konteynerin içində, /build qovluğunda yerləşdirmək mümkündür.
# 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
Təhlükəsizlik. Belə bir konteynerdə işləyən Buildah maksimal təhlükəsizlik təmin edir: ona root imtiyazları verilməmişdir, və ona bütün SECOMP və SELinux məhdudiyyətləri tətbiq edilir. Belə konteyneri User Namespace izolyasiyası ilə açmaq da mümkündür, məsələn —uidmap 0:100000:10000 seçimini əlavə etməklə.
İşin performansı. İşləmə performansı burada minimaldır, çünki konteyner reyestrindən olan bütün şəkillər hər dəfə hosta kopyalanır, və önbellekleme tamamilə işləmir. İşini başa vurduqda, Buildah konteyneri şəkli reyestrə göndərməli və hostdakı məzmunu silməlidir. Növbəti dəfə konteyner şəkli hazırlandıqda, onu yenidən reyestrdən yükləmək lazımdır, çünki hostda o vaxta qədər heç nə qalmayacaq.
Variant 2. Əgər Docker səviyyəsində performans tələb olunursa, hostun container/storage-ni birbaşa konteynerə bağlamaq mümkündür.
# 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
Təhlükəsizlik. Bu, konteynerlərin hazırlanması üçün ən az təhlükəsiz yoludur, çünki burada konteynerə hostda dəstorage-ni dəyişdirmək icazəsi verilir, və potensial olaraq o, Podman-a və ya CRI-O-ya zərərli bir imici göndərə bilər. Bundan əlavə, SELinux ayrılması deaktiv edilməlidir ki, Buildah konteynerindəki proseslər hostun depolaması ilə qarşılıqlı əlaqədə ola bilsin. Diqqət yetirin ki, bu variant hələ də Docker soketindən daha yaxşıdır, çünki konteyner qalan təhlükəsizlik funksiyaları ilə bloklanır və sadəcə olaraq hostda hansısa konteyner işə sala bilmir.
İşin performansı. Burada maksimum səviyyədə təhlükəsizdir, çünki tam önbellekleme istifadə olunur. Əgər Podman və ya CRI-O artıq lazım olan görüntünü hosta yükləmişdisə, Buildah prosesi konteynerin içində onu yenidən yükləməli olmayacaq, və bu imicə əsaslanan sonrakı yığıncaqlar da lazımı olanı önbellekdən istifadə edə biləcək.
Variant 3. Bu yöntemin özünde birkaç görüntüyü tek bir projede ortak bir klasörle birleştirmek bulunmaktadır.
# 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
Bu örnekte proje klasörünü (\/var\/lib\/project3) başlatmalar arasındaki süreçten silmiyoruz, bu nedenle projedeki sonraki tüm derlemeler önbellekleme avantajlarından yararlanır.
Təhlükəsizlik. 1 ve 2 numaralı seçeneklerin bir kombinasyonu. Diğer yandan, konteynerlerin ana makinedeki içeriğe erişimi yoktur ve dolayısıyla Podman\/CRI-O görüntü deposuna kötü içerik ekleyemez. Ancak bir proje içinde, konteyner diğer konteynerlerin derlemesine müdahale edebilir.
İşin performansı. Burada, ana makinede genel bir önbellek kullanmaya kıyasla daha kötüdür çünkü önceden Podman\/CRI-O ile indirilen görüntüler kullanılamıyor. Ancak, Buildah bir görüntüyü indirdikten sonra, bu görüntü proje dahilindeki sonraki tüm derlemelerde kullanılabilir.
Ek depolar
U Dışarıdan yalnızca okuma modunda kullanılabilen ek depolar (additional stores) gibi harika bir şey var. Bu sayede konteyner motorları, konteynerleri başlatıp derlerken dış görüntü depolarını yalnızca okuma modunda kullanabilir. Temelde, storage.conf dosyasına bir veya daha fazla "salt okunur" depo ekleyerek, konteyner başlatıldığında bu depo içinde gerekli görüntüyü arar. Konteyner motoru, bu depolar arasında gerekli görüntüyü bulamazsa, yalnızca kayıt defterinden görüntü indirecektir. Konteyner motoru yalnızca yazılabilir depolar üzerinde yazma yetkisine sahip olacaktır…
Dockerfile'ı yukarı kaydırıp quay.io\/buildah\/stable görüntüsünü inşa etmek için kullandığımızda şu satırları görebiliriz:
# 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
İlk satırda, konteyner görüntüsü içinde "/etc\/containers\/storage.conf" dosyasını değiştirerek storage sürücüsüne "/var\/lib\/shared" klasöründeki "additionalimagestores" 'u kullanmasını söylüyoruz. Bir sonraki satırda ise ortak bir klasör oluşturup birkaç kilit dosyası ekleyerek containers\/storage'den olumsuzluk yaşanmamasını sağlıyoruz. Temelde, sadece boş bir konteyner görüntü depoları oluşturuyoruz.
Eğer containers\/storage'i bu klasörün bir katman üstünde bağlarsak, Buildah görüntüleri kullanabilecektir.
Şimdi, Buildah konteynerinin ana makine üzerindeki containers\/store'da okuma ve yazma imkanı bulabildiği ve bu sayede Podman\/CRI-O seviyesinde görüntülerin önbelleklemesinden maksimum performansa sahne olduğunu ele aldığımız önceki 2 numaralı seçeneğe dönelim, fakat güvenlik en az düzeye düşüyor çünkü doğrudan depolar üzerinde yazma yetkisi bulunuyor. Şimdi buraya ek depolar ekleyip, her iki dünyanın en iyisini elde edelim.
# 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
Qeyd edək ki, /var/lib/containers/storage ev sahibi /var/lib/shared içində read-only rejimində montaj olunub. Bu səbəbdən konteynerdə işləyərkən, Buildah daha əvvəl Podman/CRI-O vasitəsilə yüklənmiş olan hər hansı bir görüntüdən istifadə edə bilər (salam, sürət), lakin yalnız öz saxlamasına yazmaq hüququna malikdir (salam, təhlükəsizlik). Ayrıca, bunun konteyner üçün SELinux ayrılması söndürülmədən edildiyini unutmayın.
Vacib incəlik
Heç bir halda alt təbəqə saxlamasından heç bir görüntünü silməmək lazımdır. Əks halda, Buildah konteyneri çökə bilər.
Və bu hələ bütün üstünlüklər deyil
Əlavə saxlamaların imkanları yalnız yuxarıda təsvir olunan ssenari ilə məhdudlaşmır. Məsələn, bütün konteyner görüntülərini birgə şəbəkə saxlamasında yerləşdirə bilər və buna bütün Buildah konteynerləri üçün giriş əldə edə bilərik. Tutaq ki, CI/CD sistemimiz müntəzəm olaraq konteyner görüntülərini yığmaq üçün yüzlərlə görüntü istifadə edir. Bütün bu görüntüləri bir ev sahibi saxlamasında cəmləşdiririk və sonra, seçdiyimiz şəbəkə saxlaması vasitələri (NFS, Gluster, Ceph, ISCSI, S3…) istifadə edərək, bu saxlamanı bütün Buildah və ya Kubernetes düyünlərinə ümumi şəkildə təqdim edirik.
İndi bu şəbəkə saxlamasını Buildah konteynerinə /var/lib/shared-də montaj etmək kifayətdir və bu qədər – Buildah konteynerlərinin görüntüləri pulla yükləməsinə ehtiyac qalmır. Beləliklə, əvvəlcədən doldurma mərhələsini (pre-population) aradan qaldırırıq və dərhal konteynerlərimizi yerləşdirməyə hazırıq.
Və əlbəttə ki, bu, işləyən Kubernetes sistemi və ya konteyner infrastrukturunun çərçivəsində istifadə edilə bilər, beləliklə konteynerləri istənilən yerdə pulla görüntü yükləmədən işə salmaq və icra etmək mümkündür. Üstəlik, konteyner registri, ona yüklənmiş görüntünün yenilənmiş versiyası üçün push sorğusu aldıqda, bu görüntünü birgə şəbəkə saxlamasına avtomatik olaraq göndərə bilər, burada o dərhal bütün düyünlərə əlçatan olur.
Konteyner görüntülərinin ölçüləri bəzən bir neçə gigabayta çata bilər. Əlavə saxlamaların funksionallığı belə görüntüləri düyünlərdə klonlamağa ehtiyac olmadan aradan qaldırır və konteynerləri işə salmağı demək olar ki, anındaca edir.
Bundan əlavə, hazırda konteynerlərin yığılmasını daha da sürətli edəcək yeni overlay volume mounts funksiyasını üzərində işləyirik.
Nəticə
Buildah-ı Kubernetes/CRI-O, Podman və ya hətta Dockerdə konteyner daxilində icra etmək tamamilə mümkündür, üstəlik bu, docker.socket istifadə etməkdən daha asan və təhlükəsizdir. Biz görüntülərlə işləmək imkanlarını əhəmiyyətli dərəcədə artırdıq və indi onların optimal təhlükəsizlik və performans arasında balanslı şəkildə işə salınma yollarını təqdim edirik.
Əlavə saxlamaların funksionallığı görüntülərin düyünlərə yüklənməsini sürətləndirmək və ya hətta tamamilə aradan qaldırmaq imkanı verir.
Mənbə: habr.com
