Kakšna je lepota ločevanja izvajalnega okolja vsebnika v ločene komponente orodja? Predvsem se ta orodja lahko začnejo kombinirati tako, da se med seboj ščitijo.
Veliko ljudi privlači zamisel o izdelavi kontejnerskih slik OCI znotraj ali podoben sistem. Recimo, da imamo CI/CD, ki nenehno zbira slike, potem nekaj podobnega /Kubernetes bi bil zelo uporaben v smislu uravnoteženja obremenitve med gradnjo. Do nedavnega je večina ljudi vsebnikom preprosto omogočila dostop do vtičnice Docker in jim dovolila zagon ukaza za gradnjo dockerja. da je to zelo nevarno, v resnici je celo slabše kot dajanje root ali sudo brez gesla.
Zato ljudje nenehno poskušajo zagnati Buildah v vsebniku. Skratka, ustvarili smo kako je po našem mnenju najbolje zagnati Buildah znotraj vsebnika, in objavili ustrezne slike . Začnimo...
prilagoditev
Te slike so zgrajene iz datotek Dockerfiles, ki jih najdete v repozitoriju Buildah v mapi .
Tukaj si bomo ogledali .
# 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
Namesto OverlayFS, implementiranega na ravni gostiteljskega jedra Linuxa, uporabljamo program znotraj vsebnika , ker se trenutno OverlayFS lahko namesti le, če mu daste dovoljenja SYS_ADMIN z uporabo zmogljivosti Linuxa. In želimo zagnati vsebnike Buildah brez korenskih pravic. Fuse-overlay deluje precej hitro in ima boljše delovanje kot gonilnik za shranjevanje VFS. Upoštevajte, da morate pri izvajanju vsebnika Buildah, ki uporablja Fuse, zagotoviti napravo /dev/fuse.
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
Nato ustvarimo imenik za dodatno shranjevanje. podpira koncept povezovanja dodatnih shramb s slikami samo za branje. Na primer, lahko konfigurirate prekrivno pomnilniško območje na enem računalniku, nato pa uporabite NFS za namestitev tega pomnilnika na drug računalnik in uporabite slike iz njega brez prenosa s potegom. To shrambo potrebujemo, da lahko povežemo shrambo slik iz gostitelja kot nosilec in jo uporabimo znotraj vsebnika.
# 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
Nazadnje, z uporabo spremenljivke okolja BUILDAH_ISOLATION sporočamo vsebniku Buildah, naj privzeto deluje s chroot izolacijo. Tu dodatna izolacija ni potrebna, saj že delamo v kontejnerju. Da bi Buildah ustvaril lastne vsebnike, ločene z imenskim prostorom, je potreben privilegij SYS_ADMIN, kar bi zahtevalo sprostitev pravil SELinux in SECCOMP vsebnika, kar je v nasprotju z našo željo, da gradimo iz varnega vsebnika.
Izvajanje Buildah znotraj vsebnika
Diagram slike vsebnika Buildah, o katerem smo govorili zgoraj, vam omogoča prilagodljivo spreminjanje metod zagona takih vsebnikov.
Hitrost proti varnosti
Varnost računalnika je vedno kompromis med hitrostjo procesa in količino zaščite, ki je ovita okoli njega. Ta izjava velja tudi pri sestavljanju zabojnikov, zato bomo spodaj preučili možnosti za tak kompromis.
Zgoraj obravnavana slika vsebnika bo ohranila svojo shrambo v /var/lib/containers. Zato moramo vsebino namestiti v to mapo in kako bomo to naredili, bo močno vplivalo na hitrost gradnje slik vsebnika.
Razmislimo o treh možnostih.
Možnost 1. Če je potrebna maksimalna varnost, lahko za vsak vsebnik ustvarite lastno mapo za vsebnike/sliko in jo povežete z vsebnikom prek namestitve glasnosti. In poleg tega postavite kontekstni imenik v sam vsebnik, v mapo /build:
# 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
Varnost. Buildah, ki se izvaja v takem vsebniku, ima največjo varnost: nima nobenih korenskih pravic za uporabo zmožnosti in zanj veljajo vse omejitve SECOMP in SELinux. Tak vsebnik je mogoče celo izvajati z izolacijo uporabniškega imenskega prostora z dodajanjem možnosti, kot je —uidmap 0: 100000:10000.
Zmogljivost. Vendar je zmogljivost tukaj minimalna, saj se vse slike iz registrov vsebnikov vsakič kopirajo v gostitelja in predpomnjenje sploh ne deluje. Ko konča svoje delo, mora kontejner Buildah poslati sliko v register in uničiti vsebino na gostitelju. Ko bo slika vsebnika naslednjič zgrajena, jo bo treba znova prenesti iz registra, saj do takrat na gostitelju ne bo več ničesar.
Možnost 2. Če potrebujete zmogljivost na ravni Dockerja, lahko gostiteljski vsebnik/shrambo namestite neposredno v vsebnik.
# 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
Varnost. To je najmanj varen način za gradnjo vsebnikov, ker vsebniku omogoča spreminjanje pomnilnika gostitelja in lahko Podmanu ali CRI-O posreduje zlonamerno sliko. Poleg tega boste morali onemogočiti ločevanje SELinux, tako da lahko procesi v vsebniku Buildah komunicirajo s shrambo na gostitelju. Upoštevajte, da je ta možnost še vedno boljša od vtičnice Docker, ker je vsebnik zaklenjen s preostalimi varnostnimi funkcijami in ne more preprosto zagnati vsebnika na gostitelju.
Zmogljivost. Tukaj je največ, saj je predpomnjenje v celoti uporabljeno. Če sta Podman ali CRI-O že prenesla zahtevano sliko na gostitelja, je procesu Buildah znotraj vsebnika ne bo treba znova prenesti, naslednje gradnje, ki temeljijo na tej sliki, pa bodo prav tako lahko vzele tisto, kar potrebujejo iz predpomnilnika. .
Možnost 3. Bistvo te metode je združiti več slik v en projekt s skupno mapo za slike vsebnika.
# 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
V tem primeru ne izbrišemo projektne mape (/var/lib/project3) med zagoni, zato imajo vse naslednje gradnje znotraj projekta predpomnjenje.
Varnost. Nekaj vmes med možnostma 1 in 2. Po eni strani kontejnerji nimajo dostopa do vsebine na gostitelju in posledično ne morejo v shrambo slik Podman/CRI-O vtakniti nečesa slabega. Po drugi strani pa lahko posoda kot del svoje zasnove moti sestavljanje drugih posod.
Zmogljivost. Tukaj je slabše kot pri uporabi skupnega predpomnilnika na ravni gostitelja, saj ne morete uporabiti slik, ki so že bile prenesene s Podman/CRI-O. Ko pa Buildah prenese sliko, jo je mogoče uporabiti v kateri koli nadaljnji gradnji znotraj projekta.
Dodaten prostor za shranjevanje
У Obstaja tako kul stvar, kot so dodatne trgovine (dodatne trgovine), zahvaljujoč kateri lahko motorji vsebnikov pri zagonu in gradnji vsebnikov uporabljajo zunanje shrambe slik v načinu prekrivanja samo za branje. V bistvu lahko v datoteko storage.conf dodate eno ali več shramb samo za branje, tako da ob zagonu vsebnika mehanizem vsebnika v njih poišče želeno sliko. Poleg tega bo sliko prenesel iz registra le, če je ne najde v nobeni od teh shramb. Vsebniški motor bo lahko pisal samo v zapisljivo shrambo ...
Če se pomaknete navzgor in pogledate datoteko Dockerfile, ki jo uporabljamo za izdelavo slike quay.io/buildah/stable, so vrstice, kot je ta:
# 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
V prvi vrstici spremenimo /etc/containers/storage.conf znotraj slike vsebnika in sporočimo gonilniku za shranjevanje, naj uporabi »additionalimagestores« v mapi /var/lib/shared. In v naslednji vrstici ustvarimo mapo v skupni rabi in dodamo nekaj datotek zaklepanja, da ne pride do zlorabe iz vsebnikov/shrambe. V bistvu preprosto ustvarjamo prazno shrambo slik vsebnika.
Če vsebnike/shrambo namestite na raven, ki je višja od te mape, bo Buildah lahko uporabljal slike.
Zdaj pa se vrnimo k zgoraj obravnavani možnosti 2, ko lahko vsebnik Buildah bere in piše v vsebnike/shranjuje na gostiteljih in ima v skladu s tem največjo zmogljivost zaradi predpomnjenja slik na ravni Podman/CRI-O, vendar zagotavlja minimalno varnost saj lahko piše neposredno v shrambo. Zdaj pa tukaj dodamo dodatno shrambo in izkoristimo najboljše iz obeh svetov.
# 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
Upoštevajte, da je gostiteljev /var/lib/containers/storage nameščen v /var/lib/shared znotraj vsebnika v načinu samo za branje. Zato lahko Buildah pri delu v vsebniku uporablja vse slike, ki so bile predhodno prenesene s Podman/CRI-O (pozdravljeni, hitrost), vendar lahko piše samo v lastno shrambo (pozdravljeni, varnost). Upoštevajte tudi, da se to izvede brez onemogočanja ločevanja SELinux za vsebnik.
Pomemben odtenek
Pod nobenim pogojem ne brišite nobene slike iz osnovnega repozitorija. V nasprotnem primeru se lahko posoda Buildah zruši.
In to niso vse prednosti
Možnosti dodatnega shranjevanja niso omejene na zgornji scenarij. Na primer, vse slike vsebnikov lahko postavite v skupno omrežno shrambo in omogočite dostop do nje vsem vsebnikom Buildah. Recimo, da imamo na stotine slik, ki jih naš sistem CI/CD redno uporablja za izdelavo slik vsebnikov. Vse te slike koncentriramo na enem gostitelju za shranjevanje in nato z uporabo prednostnih orodij za omrežno shranjevanje (NFS, Gluster, Ceph, ISCSI, S3...) odpremo splošen dostop do tega pomnilnika vsem vozliščem Buildah ali Kubernetes.
Zdaj je dovolj, da to omrežno shrambo namestite v vsebnik Buildah na /var/lib/shared in to je to - vsebnikom Buildah ni več treba prenašati slik s potegom. Tako izločimo fazo pred naseljevanjem in smo takoj pripravljeni za razvaljanje posod.
In seveda, to je mogoče uporabiti znotraj živega sistema Kubernetes ali vsebniške infrastrukture za zagon in izvajanje vsebnikov kjer koli brez kakršnega koli vlečnega prenosa slik. Poleg tega lahko register vsebnikov, ki prejme potisno zahtevo za nalaganje posodobljene slike, samodejno pošlje to sliko v skupno omrežno shrambo, kjer takoj postane na voljo vsem vozliščem.
Slike vsebnika lahko včasih dosežejo veliko gigabajtov. Funkcionalnost dodatnega pomnilnika vam omogoča, da se izognete kloniranju takšnih slik v vozliščih in naredi zagon vsebnikov skoraj takojšen.
Poleg tega trenutno delamo na novi funkciji, imenovani overlay volume mounts, s katero bo gradnja kontejnerjev še hitrejša.
Zaključek
Izvajanje Buildah znotraj vsebnika v Kubernetes/CRI-O, Podman ali celo Docker je izvedljivo, preprosto in veliko bolj varno kot uporaba docker.socket. Močno smo povečali prilagodljivost dela s slikami, tako da jih lahko izvajate na različne načine, da optimizirate ravnovesje med varnostjo in zmogljivostjo.
Funkcionalnost dodatnega pomnilnika vam omogoča, da pospešite ali celo popolnoma odpravite prenos slik v vozlišča.
Vir: www.habr.com