Hvad er det smukke ved at afkoble beholderens driftstid til separate værktøjskomponenter? Især disse værktøjer kan begynde at blive kombineret, så de beskytter hinanden.
Mange mennesker er tiltrukket af ideen om at bygge containeriserede OCI-billeder indeni eller lignende system. Lad os sige, at vi har en CI/CD, der konstant samler billeder, så noget som f.eks /Kubernetes ville være ret nyttig med hensyn til belastningsbalancering under builds. Indtil for nylig gav de fleste mennesker simpelthen containere adgang til en Docker-socket og tillod dem at køre docker build-kommandoen. at dette er meget usikkert, faktisk er det endnu værre end at give adgangskodefri root eller sudo.
Derfor forsøger folk konstant at køre Buildah i en container. Kort sagt, vi skabte hvordan, efter vores mening, er bedst at køre Buildah inde i en container, og postede de tilsvarende billeder på . Lad os komme igang...
justering
Disse billeder er bygget fra Dockerfiles, som kan findes i Buildah-lageret i mappen .
Her vil vi se på .
# 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
I stedet for OverlayFS, implementeret på værts Linux-kerneniveau, bruger vi programmet inde i containeren , fordi OverlayFS i øjeblikket kun kan monteres, hvis du giver den SYS_ADMIN-tilladelser ved hjælp af Linux-funktioner. Og vi ønsker at køre vores Buildah-containere uden nogen root-privilegier. Fuse-overlay virker ret hurtigt og har bedre ydeevne end VFS-lagerdriveren. Bemærk venligst, at når du kører en Buildah-container, der bruger Fuse, skal du angive /dev/fuse-enheden.
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
Dernæst opretter vi en mappe til yderligere lagerplads. understøtter konceptet med at forbinde yderligere skrivebeskyttede billedbutikker. For eksempel kan du konfigurere et overlay-lagerområde på én maskine og derefter bruge NFS til at montere dette lager på en anden maskine og bruge billeder fra det uden at downloade via pull. Vi har brug for dette lager for at kunne forbinde noget billedlager fra værten som en volumen og bruge det inde i containeren.
# 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
Endelig, ved at bruge miljøvariablen BUILDAH_ISOLATION, fortæller vi Buildah-beholderen til at køre med chroot-isolation som standard. Yderligere isolering er ikke påkrævet her, da vi allerede arbejder i en container. For at Buildah kan oprette sine egne navneområde-separerede containere, kræves SYS_ADMIN-privilegiet, hvilket ville kræve at lempe containerens SELinux- og SECCOMP-regler, hvilket er i modstrid med vores præference for at bygge fra en sikker container.
Kører Buildah inde i en container
Buildah container billeddiagrammet, der er diskuteret ovenfor, giver dig mulighed for fleksibelt at variere metoderne til at lancere sådanne containere.
Hastighed kontra sikkerhed
Computersikkerhed er altid et kompromis mellem processens hastighed og hvor meget beskyttelse der er pakket rundt om den. Dette udsagn gælder også, når man samler containere, så nedenfor vil vi overveje mulighederne for et sådant kompromis.
Beholderbilledet diskuteret ovenfor vil beholde sin lagring i /var/lib/containers. Derfor er vi nødt til at montere indholdet i denne mappe, og hvordan vi gør dette vil i høj grad påvirke hastigheden af at bygge containerbilleder.
Lad os overveje tre muligheder.
Mulighed 1. Hvis maksimal sikkerhed er påkrævet, så kan du for hver container oprette din egen mappe til containere/billede og forbinde den til containeren via volume-mount. Og desuden, placer kontekstmappen i selve containeren i /build-mappen:
# 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
Sikkerhed. Buildah, der kører i sådan en container, har maksimal sikkerhed: den får ikke nogen root-privilegier ved at bruge funktioner, og alle SECOMP- og SELinux-begrænsninger gælder for den. En sådan container kan endda køres med User Namespace-isolation ved at tilføje en mulighed som —uidmap 0: 100000:10000.
Ydeevne. Men ydeevnen her er minimal, da alle billeder fra containerregistre kopieres til værten hver gang, og caching fungerer slet ikke. Når arbejdet er færdigt, skal Buildah-containeren sende billedet til registreringsdatabasen og ødelægge indholdet på værten. Næste gang containerbilledet bygges, skal det downloades fra registreringsdatabasen igen, da der på det tidspunkt ikke vil være noget tilbage på værten.
Mulighed 2. Hvis du har brug for ydelse på Docker-niveau, kan du montere værtscontaineren/lageret direkte i containeren.
# 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
Sikkerhed. Dette er den mindst sikre måde at bygge containere på, fordi det giver containeren mulighed for at ændre lageret på værten og potentielt kan give Podman eller CRI-O et ondsindet billede. Derudover skal du deaktivere SELinux-separation, så processer i Buildah-beholderen kan interagere med lageret på værten. Bemærk, at denne mulighed stadig er bedre end en Docker-socket, fordi containeren er låst af de resterende sikkerhedsfunktioner og ikke bare kan køre en container på værten.
Ydeevne. Her er det maksimalt, da caching er fuldt brugt. Hvis Podman eller CRI-O allerede har downloadet det påkrævede billede til værten, så skal Buildah-processen inde i containeren ikke downloade det igen, og efterfølgende builds baseret på dette billede vil også kunne tage det, de har brug for fra cachen. .
Mulighed 3. Essensen af denne metode er at kombinere flere billeder i et projekt med en fælles mappe til containerbilleder.
# 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
I dette eksempel sletter vi ikke projektmappen (/var/lib/project3) mellem kørsler, så alle efterfølgende builds i projektet drager fordel af caching.
Sikkerhed. Noget i mellem mulighed 1 og 2. På den ene side har containere ikke adgang til indhold på værten og kan derfor ikke glide noget dårligt ind i Podman/CRI-O billedlageret. På den anden side kan en container som en del af dens design forstyrre samlingen af andre containere.
Ydeevne. Her er det værre end ved brug af en delt cache på værtsniveau, da man ikke kan bruge billeder, der allerede er downloadet ved hjælp af Podman/CRI-O. Men når Buildah har downloadet billedet, kan billedet bruges i alle efterfølgende builds i projektet.
Ekstra opbevaring
У Der er sådan en cool ting som yderligere butikker (yderligere butikker), takket være hvilke containermotorer, når de lancerer og bygger containere, kan bruge eksterne billedlagre i skrivebeskyttet overlejringstilstand. Grundlæggende kan du tilføje et eller flere skrivebeskyttede lager til storage.conf-filen, så når du starter containeren, leder containermotoren efter det ønskede billede i dem. Desuden vil det kun downloade billedet fra registreringsdatabasen, hvis det ikke finder det i nogen af disse lagre. Containermotoren vil kun være i stand til at skrive til skrivbart lager...
Hvis du ruller op og ser på Dockerfilen, som vi bruger til at bygge billedet quay.io/buildah/stable, er der linjer som denne:
# 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
I den første linje ændrer vi /etc/containers/storage.conf inde i containerbilledet, og fortæller lagerdriveren om at bruge "additionalimagestores" i mappen /var/lib/shared. Og i næste linje opretter vi en delt mappe og tilføjer et par låsefiler, så der ikke er misbrug fra containere/lager. I det væsentlige opretter vi blot en tom container-image-butik.
Hvis du monterer containere/lager på et niveau højere end denne mappe, vil Buildah kunne bruge billederne.
Lad os nu vende tilbage til Mulighed 2 diskuteret ovenfor, når Buildah-containeren kan læse og skrive til containere/lager på værterne og følgelig har maksimal ydeevne på grund af caching af billeder på Podman/CRI-O-niveauet, men giver et minimum af sikkerhed da den kan skrive direkte til lageret. Lad os nu tilføje yderligere lagerplads her og få det bedste fra begge verdener.
# 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
Bemærk, at værtens /var/lib/containers/storage er monteret til /var/lib/shared inde i containeren i skrivebeskyttet tilstand. Derfor kan Buildah, når de arbejder i en container, bruge alle billeder, der tidligere blev downloadet ved hjælp af Podman/CRI-O (hej, hastighed), men kan kun skrive til sit eget lager (hej, sikkerhed). Bemærk også, at dette gøres uden at deaktivere SELinux-separation for beholderen.
Vigtig nuance
Du må under ingen omstændigheder slette billeder fra det underliggende lager. Ellers kan Buildah-beholderen gå ned.
Og det er ikke alle fordelene
Mulighederne for yderligere opbevaring er ikke begrænset til ovenstående scenarie. For eksempel kan du placere alle containerbilleder på et delt netværkslager og give adgang til det til alle Buildah containere. Lad os sige, at vi har hundredvis af billeder, som vores CI/CD-system regelmæssigt bruger til at bygge containerbilleder. Vi koncentrerer alle disse billeder på én lagervært og derefter, ved hjælp af de foretrukne netværkslagringsværktøjer (NFS, Gluster, Ceph, ISCSI, S3...), åbner vi generel adgang til dette lager for alle Buildah- eller Kubernetes-noder.
Nu er det nok at montere dette netværkslager i Buildah-containeren på /var/lib/shared, og det er det - Buildah-containere behøver ikke længere at downloade billeder via pull. Således smider vi præ-befolkningsfasen ud og er straks klar til at rulle containerne ud.
Og selvfølgelig kan dette bruges i et live Kubernetes-system eller containerinfrastruktur til at starte og køre containere hvor som helst uden pull-download af billeder. Desuden kan containerregistret, der modtager en push-anmodning om at uploade et opdateret billede til det, automatisk sende dette billede til et delt netværkslager, hvor det øjeblikkeligt bliver tilgængeligt for alle noder.
Containerbilleder kan nogle gange nå mange gigabyte i størrelse. Funktionaliteten af ekstra lager giver dig mulighed for at undgå at klone sådanne billeder på tværs af noder og gør det næsten øjeblikkeligt at starte containere.
Derudover arbejder vi i øjeblikket på en ny funktion kaldet overlay volume mounts, som vil gøre det endnu hurtigere at bygge containere.
Konklusion
At køre Buildah inde i en container i Kubernetes/CRI-O, Podman eller endda Docker er gennemførligt, enkelt og meget mere sikkert end at bruge docker.socket. Vi har i høj grad øget fleksibiliteten ved at arbejde med billeder, så du kan køre dem på en række forskellige måder for at optimere balancen mellem sikkerhed og ydeevne.
Funktionaliteten af ekstra lager giver dig mulighed for at fremskynde eller endda helt eliminere download af billeder til noder.
Kilde: www.habr.com