Preporuke za pokretanje Buildaha unutar spremnika

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.

Preporuke za pokretanje Buildaha unutar spremnika

Mnoge ljude privlači ideja o izradi OCI slika u spremnicima Kubernetes ili sličan sustav. Recimo imamo CI/CD koji stalno skuplja slike, pa tako nešto Red Hat OpenShift/Kubernetes bi bio vrlo koristan u smislu balansiranja opterećenja tijekom izgradnje. Sve donedavno, većina ljudi jednostavno je kontejnerima davala pristup Docker socketu i dopuštala im pokretanje naredbe za izgradnju dockera. Prije nekoliko godina smo pokazalida je ovo vrlo nesigurno, zapravo, još je gore od davanja roota ili sudoa bez lozinke.

Zato ljudi stalno pokušavaju pokrenuti Buildah u kontejneru. Ukratko, stvorili smo primjer kako je, po našem mišljenju, najbolje pokrenuti Buildah unutar kontejnera, i objavio odgovarajuće slike kej.io/buildah. Započnimo...

podešavanje

Ove slike izrađene su iz Dockerfilesa koji se može pronaći u Buildah repozitoriju u mapi buildahimage.
Ovdje ćemo razmotriti stabilna verzija Dockerfilea.

# 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 osigurač-prekrivač, jer se trenutno OverlayFS može montirati samo ako mu date dopuštenja SYS_ADMIN koristeći mogućnosti Linuxa. I želimo pokrenuti naše Buildah kontejnere bez ikakvih root privilegija. Fuse-overlay radi prilično brzo i ima bolje performanse od VFS drivera za pohranu. Imajte na umu da kada pokrećete Buildah spremnik koji koristi Fuse, morate osigurati /dev/fuse uređaj.

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. Kontejner/skladištenje podržava koncept povezivanja dodatnih pohrana slika samo za čitanje. Na primjer, možete konfigurirati preklapajuće područje pohrane na jednom stroju, a zatim upotrijebiti NFS za montiranje ovog skladišta na drugom stroju i koristiti slike s njega bez preuzimanja putem povlačenja. Trebamo ovu pohranu kako bismo mogli povezati neku pohranu slika s hosta kao volumen i koristiti je unutar spremnika.

# 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

У spremnici/skladištenje Postoji tako cool stvar kao što su dodatne trgovine (dodatne trgovine), zahvaljujući kojima prilikom pokretanja i izgradnje spremnika, spremnici mogu koristiti vanjske pohrane slika u načinu preklapanja samo za čitanje. U suštini, možete dodati jednu ili više pohrana samo za čitanje u datoteku storage.conf tako da kada pokrenete spremnik, mehanizam spremnika traži željenu sliku u njima. Štoviše, sliku će preuzeti iz registra samo ako je ne pronađe ni u jednoj od tih pohrana. Spremnik će moći pisati samo u pohranu za pisanje...

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

Dodajte komentar