U čemu je ljepota odvajanja vremena izvođenja spremnika u zasebne komponente alata? Posebno se ti alati mogu početi kombinirati tako da štite jedni druge.
Mnoge ljude privlači ideja o izradi OCI slika u spremnicima
Zato ljudi stalno pokušavaju pokrenuti Buildah u kontejneru. Ukratko, stvorili smo
podešavanje
Ove slike izrađene su iz Dockerfilesa koji se može pronaći u Buildah repozitoriju u mapi
Ovdje ćemo razmotriti
# 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
Umjesto OverlayFS-a, implementiranog na razini kernela glavnog Linuxa, koristimo program unutar spremnika
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
Zatim stvaramo direktorij za dodatnu pohranu.
# 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
Konačno, upotrebom varijable okruženja BUILDAH_ISOLATION, kažemo Buildah spremniku da radi s chroot izolacijom prema zadanim postavkama. Ovdje nije potrebna dodatna izolacija, jer već radimo u kontejneru. Kako bi Buildah stvorio vlastite spremnike odvojene prostorom imena, potrebna je povlastica SYS_ADMIN, što bi zahtijevalo ublažavanje SELinux i SECCOMP pravila spremnika, što je u suprotnosti s našim preferencijama da gradimo iz sigurnog spremnika.
Pokretanje Buildaha unutar spremnika
Dijagram slike spremnika Buildah o kojem je gore bilo riječi omogućuje vam da fleksibilno mijenjate metode pokretanja takvih spremnika.
Brzina protiv sigurnosti
Računalna sigurnost uvijek je kompromis između brzine procesa i količine zaštite koja je omotana oko njega. Ova izjava vrijedi i za sastavljanje spremnika, pa ćemo u nastavku razmotriti mogućnosti za takav kompromis.
Gore razmotrena slika spremnika zadržat će svoju pohranu u /var/lib/containers. Stoga moramo montirati sadržaj u ovu mapu, a način na koji ćemo to učiniti uvelike će utjecati na brzinu izgradnje slika spremnika.
Razmotrimo tri opcije.
Opcija 1. Ako je potrebna maksimalna sigurnost, tada za svaki spremnik možete stvoriti vlastitu mapu za spremnike/sliku i povezati je sa spremnikom preko volume-mount-a. I osim toga, smjestite kontekstni direktorij u sam spremnik, u mapu /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
Sigurnost. Buildah koji radi u takvom spremniku ima maksimalnu sigurnost: ne dobiva nikakve root privilegije za korištenje mogućnosti i na njega se primjenjuju sva SECOMP i SELinux ograničenja. Takav se spremnik čak može pokrenuti s izolacijom prostora korisničkog imena dodavanjem opcije poput —uidmap 0: 100000:10000.
Izvođenje. Ali izvedba je ovdje minimalna, jer se sve slike iz registara spremnika svaki put kopiraju na host, a predmemorija uopće ne radi. Po završetku svog rada, Buildah spremnik mora poslati sliku u registar i uništiti sadržaj na hostu. Sljedeći put kad se slika spremnika izgradi, morat će se ponovo preuzeti iz registra, jer do tog vremena na glavnom računalu neće ostati ništa.
Opcija 2. Ako trebate izvedbu na razini Dockera, možete montirati host spremnik/skladište izravno u spremnik.
# 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
Sigurnost. Ovo je najmanje siguran način za izradu spremnika jer dopušta spremniku da modificira pohranu na glavnom računalu i potencijalno može dati Podmanu ili CRI-O zlonamjernu sliku. Osim toga, morat ćete onemogućiti SELinux odvajanje kako bi procesi u Buildah spremniku mogli komunicirati s pohranom na glavnom računalu. Imajte na umu da je ova opcija još uvijek bolja od Docker utičnice jer je spremnik zaključan preostalim sigurnosnim značajkama i ne može jednostavno pokrenuti spremnik na glavnom računalu.
Izvođenje. Ovdje je maksimum, jer se predmemoriranje u potpunosti koristi. Ako su Podman ili CRI-O već preuzeli potrebnu sliku na glavno računalo, tada je Buildah proces unutar spremnika neće morati ponovno preuzeti, a naknadne nadogradnje temeljene na ovoj slici također će moći uzeti ono što trebaju iz predmemorije .
Opcija 3. Bit ove metode je kombiniranje nekoliko slika u jedan projekt sa zajedničkom mapom za slike spremnika.
# 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
U ovom primjeru ne brišemo projektnu mapu (/var/lib/project3) između pokretanja, tako da sve naredne nadogradnje unutar projekta imaju koristi od predmemoriranja.
Sigurnost. Nešto između opcija 1 i 2. S jedne strane, spremnici nemaju pristup sadržaju na hostu i, sukladno tome, ne mogu ubaciti nešto loše u Podman/CRI-O pohranu slika. S druge strane, kao dio svog dizajna, spremnik može ometati sklapanje drugih spremnika.
Izvođenje. Ovdje je gore nego kada koristite dijeljenu predmemoriju na razini hosta, jer ne možete koristiti slike koje su već preuzete pomoću Podman/CRI-O. Međutim, nakon što Buildah preuzme sliku, slika se može koristiti u svim sljedećim izgradnjama unutar projekta.
Dodatna pohrana
У
Ako se pomaknete prema gore i pogledate Dockerfile koji koristimo za izradu slike quay.io/buildah/stable, postoje linije poput ovih:
# 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
U prvom redu mijenjamo /etc/containers/storage.conf unutar slike spremnika, govoreći upravljačkom programu za pohranu da koristi “additionalimagestores” u /var/lib/shared mapi. A u sljedećem retku kreiramo dijeljenu mapu i dodamo nekoliko zaključanih datoteka tako da nema zlouporabe iz spremnika/skladišta. U biti, jednostavno stvaramo praznu pohranu slika spremnika.
Ako montirate spremnike/skladište na razini višoj od ove mape, Buildah će moći koristiti slike.
Sada se vratimo na Opciju 2 o kojoj smo govorili gore, kada Buildah spremnik može čitati i pisati u spremnike/pohranjivati na hostovima i, sukladno tome, ima maksimalnu izvedbu zbog predmemoriranja slika na Podman/CRI-O razini, ali pruža minimalnu sigurnost budući da može pisati izravno u pohranu. Dodajmo sada dodatnu pohranu i iskoristimo najbolje od oba svijeta.
# 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
Imajte na umu da je /var/lib/containers/storage glavnog računala montiran na /var/lib/shared unutar spremnika u načinu rada samo za čitanje. Stoga, radeći u spremniku, Buildah može koristiti bilo koje slike koje su prethodno preuzete pomoću Podman/CRI-O (bok, brzina), ali može pisati samo u vlastitu pohranu (bok, sigurnost). Također imajte na umu da se to radi bez onemogućavanja SELinux odvajanja za spremnik.
Važna nijansa
Ni pod kojim okolnostima ne biste trebali brisati slike iz temeljnog repozitorija. Inače bi se Buildah kontejner mogao srušiti.
A to nisu sve prednosti
Mogućnosti dodatne pohrane nisu ograničene na gornji scenarij. Na primjer, možete smjestiti sve slike spremnika na dijeljenu mrežnu pohranu i dati joj pristup svim Buildah spremnicima. Recimo da imamo stotine slika koje naš CI/CD sustav redovito koristi za izradu slika spremnika. Koncentriramo sve te slike na jednom hostu za pohranu, a zatim, koristeći preferirane mrežne alate za pohranu (NFS, Gluster, Ceph, ISCSI, S3...), otvaramo opći pristup ovoj pohrani svim Buildah ili Kubernetes čvorovima.
Sada je dovoljno ovu mrežnu pohranu montirati u Buildah spremnik na /var/lib/shared i to je to - Buildah spremnici više ne moraju preuzimati slike putem povlačenja. Tako izbacujemo fazu prije naseljavanja i odmah smo spremni za izbacivanje spremnika.
I naravno, ovo se može koristiti unutar živog Kubernetes sustava ili infrastrukture kontejnera za pokretanje i pokretanje kontejnera bilo gdje bez ikakvog preuzimanja slika. Štoviše, registar spremnika, koji prima push zahtjev za učitavanje ažurirane slike u njega, može automatski poslati tu sliku u dijeljenu mrežnu pohranu, gdje odmah postaje dostupna svim čvorovima.
Slike spremnika ponekad mogu doseći veličinu od mnogo gigabajta. Funkcionalnost dodatne pohrane omogućuje vam da izbjegnete kloniranje takvih slika preko čvorova i čini pokretanje spremnika gotovo trenutnim.
Osim toga, trenutačno radimo na novoj značajci pod nazivom overlay volume mounts, koja će izgradnju kontejnera učiniti još bržom.
Zaključak
Pokretanje Buildaha unutar spremnika u Kubernetes/CRI-O, Podmanu ili čak Dockeru izvedivo je, jednostavno i puno sigurnije od korištenja docker.socket. Znatno smo povećali fleksibilnost rada sa slikama, tako da ih možete pokretati na različite načine kako biste optimizirali ravnotežu između sigurnosti i performansi.
Funkcionalnost dodatne pohrane omogućuje vam ubrzanje ili čak potpuno uklanjanje preuzimanja slika na čvorove.
Izvor: www.habr.com