Buildah-ı konteynerin içərisində işə salmaq üçün təlimatlar

Konteynerin işləmə vaxtını ayrıca alət komponentlərinə ayırmağın gözəlliyi nədir? Xüsusilə, bu vasitələrin bir-birini qorumaq üçün birləşdirilməyə başlaya bilməsi.

Buildah-ı konteynerin içərisində işə salmaq üçün təlimatlar

Bir çox insan daxilində OCI konteyner şəkilləri yaratmaq ideyası ilə maraqlanır Kubernetes və ya oxşar sistem. Tutaq ki, bizdə daim şəkillər yaradan bir CI / CD var, sonra buna bənzər bir şey Red Hat OpenShift/Kubernetes tikinti yükünün balanslaşdırılması baxımından çox faydalı olardı. Bu yaxınlara qədər insanların çoxu sadəcə konteynerlərə Docker yuvasına giriş imkanı verirdi və onlara docker qurma əmrini işlətməyə icazə verirdi. Bir neçə il əvvəl göstərmişdikki, bu, çox etibarsızdır, əslində, parolsuz root və ya sudo verməkdən daha pisdir.

Beləliklə, insanlar davamlı olaraq Buildah-ı konteynerdə işlətməyə çalışırlar. Bir sözlə, biz yaratmışıq misal Fikrimizcə, Buildah-ı bir konteynerin içərisində necə işlətməyin ən yaxşısıdır və müvafiq şəkilləri üzərinə yerləşdirdi quay.io/buildah. Gəlin başlayaq...

nizamlama

Bu şəkillər qovluqdakı Buildah deposunda tapıla bilən Dockerfiles-dən hazırlanmışdır tikinti.
Burada nəzərdən keçirəcəyik Dockerfile-in stabil versiyası.

# 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

Hostun Linux nüvəsi səviyyəsində həyata keçirilən OverlayFS əvəzinə biz konteyner daxilində proqramdan istifadə edirik. qoruyucu örtüyü, çünki hazırda OverlayFS yalnız Linux imkanları vasitəsilə ona SYS_ADMIN icazələrini verdiyiniz halda quraşdırıla bilər. Və biz Buildah konteynerlərimizi heç bir kök imtiyazları olmadan idarə etmək istəyirik. Fuse-overlay olduqca sürətlidir və VFS yaddaş sürücüsündən daha yaxşı işləyir. Qeyd edək ki, Fuse istifadə edərək Buildah konteynerini işləyərkən /dev/fuse cihazı təmin edilməlidir.

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ə depolar üçün bir kataloq yaradırıq. konteyner/anbar yalnız oxumaq üçün nəzərdə tutulmuş əlavə şəkil depolarının birləşdirilməsi konsepsiyasını dəstəkləyir. Məsələn, bir maşında üst-üstə düşən yaddaş sahəsi qura və sonra bu yaddaşı başqa bir maşına quraşdırmaq üçün NFS-dən istifadə edə və çəkmə vasitəsilə yükləmədən şəkilləri istifadə edə bilərsiniz. Hostdan bəzi şəkil yaddaşını həcm kimi qoşmaq və onu konteynerin içərisində istifadə etmək üçün bizə bu yaddaş lazımdır.

# 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

Nəhayət, biz BUILDAH_ISOLATION mühit dəyişənindən istifadə edərək, Buildah konteynerinə defolt olaraq chroot izolyasiyası ilə başlasın. Burada əlavə izolyasiya tələb olunmur, çünki biz artıq bir konteynerdə işləyirik. Buildah-ın öz ad məkanı ilə ayrılmış konteynerlərini yaratması üçün SYS_ADMIN imtiyazı tələb olunur ki, bu da konteynerin SELinux və SECCOMP qaydalarının boşaldılmasını tələb edir ki, bu da təhlükəsiz konteynerdən qurmaq üçün quraşdırmamızla ziddiyyət təşkil edir.

Buildah-ı bir konteynerin içində işə salın

Yuxarıda müzakirə edilən Buildah konteyner təsviri sxemi bu cür konteynerlərin işə salınma üsulunu çevik şəkildə dəyişməyə imkan verir.

Sürətlə təhlükəsizliyə qarşı

Kompüter təhlükəsizliyi həmişə bir prosesin sürəti ilə onun ətrafına nə qədər qorunduğu arasında kompromisdir. Bu ifadə konteynerlərin yığılması zamanı da doğrudur, buna görə də aşağıda belə bir kompromis variantlarını nəzərdən keçirəcəyik.

Yuxarıda müzakirə edilən konteyner şəkli saxlanmasını /var/lib/containers-də saxlayacaq. Buna görə də, məzmunu bu qovluğa bağlamalıyıq və bunu necə edəcəyimiz konteyner şəkillərinin qurulması sürətinə çox təsir edəcəkdir.

Üç variantı nəzərdən keçirək.

Seçim 1. Maksimum təhlükəsizlik tələb olunursa, onda hər bir konteyner üçün konteynerlər / şəkil üçün öz qovluğunu yarada və onu həcm montajı vasitəsilə konteynerə qoşa bilərsiniz. Bundan əlavə, kontekst qovluğunu konteynerin özündə, /build qovluğunda yerləşdirin:

# 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 maksimum təhlükəsizliyə malikdir: ona imkanlara görə heç bir kök imtiyazları verilmir və bütün SECOMP və SELinux məhdudiyyətləri ona tətbiq edilir.Belə konteyner hətta --uidmap kimi bir seçim əlavə etməklə İstifadəçi Adları məkanının izolyasiyası ilə işlədilə bilər. 0:100000:10000.

Performans. Ancaq burada performans minimaldır, çünki konteyner reyestrlərindən hər hansı bir şəkil hər dəfə hosta kopyalanır və keşləmə "heç bir yol yoxdur" sözündən işləmir. İşini bitirdikdə, Buildah konteyneri təsviri reyestrə göndərməli və hostdakı məzmunu məhv etməlidir. Növbəti dəfə konteyner şəkli qurulduqda, o, reyestrdən yenidən endirilməli olacaq, çünki o vaxta qədər hostda heç nə qalmayacaq.

Seçim 2. Docker səviyyəli performansa ehtiyacınız varsa, hostun konteynerini/anbarını birbaşa konteynerə quraşdıra bilərsiniz.

# 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 qurulmasının ən az təhlükəsiz yoludur, çünki o, konteynerə hostun yaddaşını dəyişməyə imkan verir və potensial olaraq Podman və ya CRI-O-ya zərərli təsviri sürüşdürə bilər. Bundan əlavə, Buildah konteynerindəki proseslərin hostdakı repozitoriya ilə qarşılıqlı əlaqədə olması üçün SELinux ayrılmasını deaktiv etməlisiniz. Nəzərə alın ki, bu seçim hələ də Docker rozetkasından daha yaxşıdır, çünki konteyner qalan təhlükəsizlik xüsusiyyətləri ilə bloklanıb və sadəcə hostda hər hansı konteyneri götürüb işlədə bilmir.

Performans. Burada maksimumdur, çünki keşləmə tamamilə iştirak edir. Əgər Podman və ya CRI-O artıq istədiyiniz şəkli hosta yükləyibsə, o zaman konteynerin daxilindəki Buildah prosesi onu yenidən yükləməli olmayacaq və bu təsvirə əsaslanan sonrakı qurmalar da lazım olanı keşdən götürə biləcək. .

Seçim 3. Bu metodun mahiyyəti konteyner şəkilləri üçün ümumi bir qovluq ilə bir neçə təsviri bir layihədə birləşdirməkdir.

# 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 misalda biz layihə qovluğunu (/var/lib/project3) icralar arasında silmirik, ona görə də layihə daxilindəki bütün sonrakı qurmalar keşləmədən faydalanır.

Təhlükəsizlik. Seçim 1 və 2 arasında bir şey. Bir tərəfdən, konteynerlərin hostdakı məzmuna çıxışı yoxdur və müvafiq olaraq Podman / CRI-O təsvir yaddaşına pis bir şey keçirə bilməz. Digər tərəfdən, öz layihəsi çərçivəsində bir konteyner digər qabların yığılmasına mane ola bilər.

Performans. Burada host səviyyəsində paylaşılan keşdən istifadə etməkdən daha pisdir, çünki Podman / CRI-O istifadə edərək artıq yüklənmiş şəkillərdən istifadə edə bilməzsiniz. Bununla belə, Buildah şəkli endirdikdən sonra həmin şəkil layihə çərçivəsində istənilən sonrakı quruluşlarda istifadə oluna bilər.

Əlavə saxlama

У konteynerlər/anbar əlavə mağazalar (əlavə mağazalar) kimi gözəl bir şey var, bunun sayəsində konteynerləri işə salarkən və qurarkən konteyner mühərrikləri yalnız oxumaq üçün üst-üstə düşmə rejimində xarici görüntü mağazalarından istifadə edə bilər. Əslində, siz storage.conf faylına bir və ya bir neçə yalnız oxumaq üçün saxlama əlavə edə bilərsiniz ki, konteyner işə salındıqda konteyner mühərriki onlarda istədiyiniz təsviri axtarsın. Üstəlik, təsviri yalnız bu anbarların heç birində tapmadıqda reyestrdən endirəcəkdir. Konteyner mühərriki yalnız yazıla bilən yaddaşa yaza biləcək...

Quay.io/buildah/stable şəklini yaratmaq üçün istifadə etdiyimiz Dockerfile-ə baxsaq, bu kimi sətirlər var:

# 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

Birinci sətirdə biz konteyner şəklinin daxilində /etc/containers/storage.conf faylını dəyişdirərək, yaddaş sürücüsünə /var/lib/shared qovluğunda "additionalimagestores" istifadə etməsini bildiririk. Və növbəti sətirdə biz paylaşılan qovluq yaradırıq və konteynerlərdən / anbardan sui-istifadə olmaması üçün bir neçə kilid faylı əlavə edirik. Əslində, biz sadəcə boş konteyner şəkillər mağazası yaradırıq.

Bu qovluqdan yuxarı səviyyəli konteyner/saxlama quraşdırsanız, Buildah şəkillərdən istifadə edə biləcək.

İndi yuxarıda müzakirə edilən 2-ci Seçimə qayıdaq, Buildah konteyneri konteynerlərə oxuya və yaza / hostlarda saxlaya bildikdə və müvafiq olaraq Podman / CRI-O səviyyəsində görüntü keşləməsi sayəsində maksimum performansa sahib olduqda, lakin minimum təhlükəsizlik təmin edir, bilavasitə anbarda yaza bildiyi üçün. İndi biz burada əlavə yaddaş yerləşdirəcəyik və hər iki dünyanın ən yaxşısını əldə edəcəyik.

# 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, hostun /var/lib/containers/storage yalnız oxumaq üçün rejimdə konteyner daxilində /var/lib/shared-ə quraşdırılıb. Buna görə də, konteynerdə işləyən Buildah, Podman / CRI-O (salam, sürət) istifadə edərək artıq yüklənmiş istənilən şəkillərdən istifadə edə bilər, lakin yalnız öz yaddaşına yaza bilər (salam, təhlükəsizlik). Həmçinin qeyd edin ki, bu, konteyner üçün SELinux ayrılmasını söndürmədən edilir.

Mühüm nüans

Heç bir halda heç bir şəkil əsas depodan silinməməlidir. Əks halda, Buildah konteyneri çökə bilər.

Və bu, bütün faydalar deyil.

Əlavə saxlama imkanları yuxarıdakı ssenari ilə məhdudlaşmır. Məsələn, siz bütün konteyner şəkillərini paylaşılan şəbəkə yaddaşına yerləşdirə və ona bütün Buildah konteynerlərinə giriş verə bilərsiniz. Tutaq ki, CI/CD sistemimizin konteynerləşdirilmiş şəkillər yaratmaq üçün müntəzəm olaraq istifadə etdiyi yüzlərlə təsvirimiz var. Biz bütün bu şəkilləri bir yaddaş hostunda cəmləşdiririk və sonra üstünlük verilən şəbəkə saxlama vasitələrindən (NFS, Gluster, Ceph, iSCSI, S3 ...) istifadə edərək, bu yaddaşı bütün Buildah və ya Kubernetes qovşaqları ilə paylaşırıq.

İndi bu şəbəkə yaddaşını /var/lib/shared-də Buildah konteynerinə quraşdırmaq kifayətdir və budur - Buildah konteynerləri artıq çəkmə vasitəsilə şəkilləri yükləməli deyil. Beləliklə, biz əvvəlcədən əhali mərhələsini atırıq və dərhal konteynerləri yaymağa hazırıq.

Və əlbəttə ki, bu, canlı Kubernetes sistemi və ya konteyner infrastrukturu daxilində hər hansı bir şəkil çəkmədən konteynerləri işə salmaq və işə salmaq üçün istifadə edilə bilər. Bundan əlavə, konteyner reyestri ona yenilənmiş şəkli yükləmək üçün təkan sorğusu aldıqda, o, bu şəkli avtomatik olaraq bütün qovşaqlar üçün əlçatan olan paylaşılan şəbəkə yaddaşına göndərə bilər.

Konteyner şəkillərinin ölçüsü bəzən çox gigabayt ola bilər. Əlavə anbarların funksionallığı bu cür şəkillərin qovşaqlar üzrə klonlaşdırılması ehtiyacını aradan qaldırır və konteynerlərin işə salınmasını demək olar ki, ani edir.

Bundan əlavə, biz hazırda konteynerlərin qurulmasını daha da sürətləndirəcək yeni üst-üstə düşən həcm montajı funksiyası üzərində işləyirik.

Nəticə

Buildah-ı bir konteyner daxilində Kubernetes/CRI-O mühitində, Podman və ya hətta Docker-də işə salmaq olduqca mümkündür və bu, docker.socket istifadə etməkdən daha sadə və daha təhlükəsizdir. Şəkillərlə işləmək çevikliyini xeyli artırdıq və indi təhlükəsizlik və performans arasında ən yaxşı tarazlıq üçün onları müxtəlif yollarla idarə edə bilərsiniz.

Əlavə saxlamaların funksionallığı şəkillərin qovşaqlara yüklənməsini sürətləndirməyə və ya hətta tamamilə aradan qaldırmağa imkan verir.

Mənbə: www.habr.com

Добавить комментарий