Hva er det fine med å koble fra beholderens kjøretid til separate verktøykomponenter? Spesielt kan disse verktøyene begynne å kombineres slik at de beskytter hverandre.
Mange mennesker er tiltrukket av ideen om å bygge containeriserte OCI-bilder innenfor eller lignende system. La oss si at vi har en CI/CD som hele tiden samler bilder, så noe sånt som /Kubernetes ville være ganske nyttig når det gjelder lastbalansering under bygg. Inntil nylig ga de fleste bare containere tilgang til en Docker-socket og tillot dem å kjøre docker build-kommandoen. at dette er veldig usikkert, faktisk er det enda verre enn å gi passordløs root eller sudo.
Det er derfor folk hele tiden prøver å kjøre Buildah i en container. Kort sagt, vi skapte hvordan, etter vår mening, er best å kjøre Buildah inne i en container, og postet de tilsvarende bildene på . La oss komme i gang...
justering
Disse bildene er bygget fra Dockerfiles, som finnes i Buildah-depotet i mappen .
Her skal 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, implementert på vertens Linux-kjernenivå, bruker vi programmet inne i beholderen , fordi OverlayFS for øyeblikket bare kan monteres hvis du gir den SYS_ADMIN-tillatelser ved å bruke Linux-funksjoner. Og vi ønsker å kjøre våre Buildah-beholdere uten noen root-privilegier. Fuse-overlay fungerer ganske raskt og har bedre ytelse enn VFS-lagringsdriveren. Vær oppmerksom på at når du kjører en Buildah-beholder som bruker Fuse, må du oppgi /dev/fuse-enheten.
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
Deretter oppretter vi en katalog for ekstra lagring. støtter konseptet med å koble til flere skrivebeskyttede bildebutikker. Du kan for eksempel konfigurere et overleggslagringsområde på én maskin, og deretter bruke NFS til å montere denne lagringen på en annen maskin og bruke bilder fra den uten å laste ned via pull. Vi trenger denne lagringen for å kunne koble til noe bildelagring fra verten som et volum og bruke det inne i beholderen.
# 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
Til slutt, ved å bruke miljøvariabelen BUILDAH_ISOLATION, ber vi Buildah-beholderen kjøre med chroot-isolasjon som standard. Tilleggsisolasjon er ikke nødvendig her, siden vi allerede jobber i en container. For at Buildah skal kunne lage sine egne navneromseparerte containere, kreves SYS_ADMIN-privilegiet, noe som vil kreve å lempe containerens SELinux- og SECCOMP-regler, noe som er i strid med vår preferanse for å bygge fra en sikker container.
Kjører Buildah inne i en container
Buildah-beholderbildediagrammet diskutert ovenfor lar deg fleksibelt variere metodene for å lansere slike beholdere.
Hastighet kontra sikkerhet
Datasikkerhet er alltid et kompromiss mellom hastigheten på prosessen og hvor mye beskyttelse som er pakket rundt den. Denne uttalelsen er også sant når du monterer containere, så nedenfor vil vi vurdere alternativer for et slikt kompromiss.
Beholderbildet diskutert ovenfor vil beholde lagringen i /var/lib/containers. Derfor må vi montere innholdet i denne mappen, og hvordan vi gjør dette vil i stor grad påvirke hastigheten på å bygge containerbilder.
La oss vurdere tre alternativer.
1 alternativet. Hvis maksimal sikkerhet kreves, kan du for hver container lage din egen mappe for containere/bilde og koble den til containeren via volummontering. Og dessuten, plasser kontekstkatalogen i selve beholderen, 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
Sikkerhet. Buildah som kjører i en slik beholder har maksimal sikkerhet: den gis ingen root-privilegier ved å bruke funksjoner, og alle SECOMP- og SELinux-begrensninger gjelder for den. En slik beholder kan til og med kjøres med User Namespace-isolasjon ved å legge til et alternativ som —uidmap 0: 100000:10000.
Performance. Men ytelsen her er minimal, siden alle bilder fra containerregistre blir kopiert til verten hver gang, og caching fungerer ikke i det hele tatt. Når arbeidet er ferdig, må Buildah-beholderen sende bildet til registeret og ødelegge innholdet på verten. Neste gang containerbildet bygges, må det lastes ned fra registeret igjen, siden det ikke vil være noe igjen på verten innen den tid.
2 alternativet. Hvis du trenger ytelse på Docker-nivå, kan du montere vertsbeholderen/lagringen direkte i beholderen.
# 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
Sikkerhet. Dette er den minst sikre måten å bygge containere på fordi den lar containeren endre lagringen på verten og potensielt kan mate Podman eller CRI-O med et skadelig bilde. I tillegg må du deaktivere SELinux-separasjon slik at prosesser i Buildah-beholderen kan samhandle med lagringen på verten. Merk at dette alternativet fortsatt er bedre enn en Docker-socket fordi beholderen er låst av gjenværende sikkerhetsfunksjoner og ikke bare kan kjøre en beholder på verten.
Performance. Her er det maksimalt, siden caching er fullt brukt. Hvis Podman eller CRI-O allerede har lastet ned det nødvendige bildet til verten, trenger ikke Buildah-prosessen inne i beholderen å laste det ned igjen, og påfølgende bygg basert på dette bildet vil også kunne ta det de trenger fra cachen .
3 alternativet. Essensen av denne metoden er å kombinere flere bilder til ett prosjekt med en felles mappe for containerbilder.
# 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 eksemplet sletter vi ikke prosjektmappen (/var/lib/project3) mellom kjøringer, så alle påfølgende bygg i prosjektet drar nytte av caching.
Sikkerhet. Noe i mellom alternativ 1 og 2. På den ene siden har ikke containere tilgang til innhold på verten og kan følgelig ikke skli noe dårlig inn i Podman/CRI-O-bildelagringen. På den annen side, som en del av utformingen, kan en beholder forstyrre sammenstillingen av andre beholdere.
Performance. Her er det verre enn ved bruk av delt cache på vertsnivå, siden man ikke kan bruke bilder som allerede er lastet ned ved hjelp av Podman/CRI-O. Men når Buildah laster ned bildet, kan bildet brukes i alle påfølgende bygg i prosjektet.
Ekstra lagringsplass
У Det er en så kul ting som ekstra butikker (ekstra butikker), takket være at containermotorer kan bruke eksterne bildelagre i skrivebeskyttet overleggsmodus når de lanserer og bygger containere. I hovedsak kan du legge til en eller flere skrivebeskyttede lagringer til storage.conf-filen slik at når du starter beholderen, ser beholdermotoren etter ønsket bilde i dem. Dessuten vil den laste ned bildet fra registret bare hvis den ikke finner det i noen av disse lagringene. Beholdermotoren vil kun kunne skrive til skrivbar lagring...
Hvis du blar opp og ser på Dockerfilen som vi bruker til å bygge bildet quay.io/buildah/stable, er det linjer som dette:
# 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 linjen endrer vi /etc/containers/storage.conf inne i containerbildet, og ber lagringsdriveren bruke "additionalimagestores" i mappen /var/lib/shared. Og i neste linje lager vi en delt mappe og legger til et par låsefiler slik at det ikke blir misbruk fra containere/lagring. I hovedsak oppretter vi ganske enkelt en tom beholderbildebutikk.
Hvis du monterer containere/lager på et nivå høyere enn denne mappen, vil Buildah kunne bruke bildene.
La oss nå gå tilbake til alternativ 2 diskutert ovenfor, når Buildah-beholderen kan lese og skrive til beholdere/lager på vertene og følgelig har maksimal ytelse på grunn av caching av bilder på Podman/CRI-O-nivå, men gir et minimum av sikkerhet siden den kan skrive direkte til lagring. La oss nå legge til ekstra lagringsplass her og få det beste 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
Merk at vertens /var/lib/containers/storage er montert til /var/lib/shared inne i beholderen i skrivebeskyttet modus. Derfor, ved å jobbe i en container, kan Buildah bruke alle bilder som tidligere ble lastet ned ved hjelp av Podman/CRI-O (hei, hastighet), men kan bare skrive til sin egen lagring (hei, sikkerhet). Vær også oppmerksom på at dette gjøres uten å deaktivere SELinux-separasjon for beholderen.
Viktig nyanse
Du bør ikke under noen omstendigheter slette noen bilder fra det underliggende depotet. Ellers kan Buildah-beholderen krasje.
Og dette er ikke alle fordelene
Mulighetene for ytterligere lagring er ikke begrenset til scenariet ovenfor. Du kan for eksempel plassere alle containerbilder på en delt nettverkslagring og gi tilgang til den til alle Buildah-containere. La oss si at vi har hundrevis av bilder som CI/CD-systemet vårt regelmessig bruker for å bygge containerbilder. Vi konsentrerer alle disse bildene på én lagringsvert, og deretter, ved å bruke de foretrukne nettverkslagringsverktøyene (NFS, Gluster, Ceph, ISCSI, S3...), åpner vi generell tilgang til denne lagringen for alle Buildah- eller Kubernetes-noder.
Nå er det nok å montere denne nettverkslagringen i Buildah-beholderen på /var/lib/shared og det er det - Buildah-beholdere trenger ikke lenger å laste ned bilder via pull. Dermed kaster vi ut pre-populasjonsfasen og er umiddelbart klare til å rulle ut containerne.
Og selvfølgelig kan dette brukes innenfor et live Kubernetes-system eller containerinfrastruktur for å starte og kjøre containere hvor som helst uten pull-nedlasting av bilder. Dessuten kan containerregisteret, som mottar en push-forespørsel om å laste opp et oppdatert bilde til det, automatisk sende dette bildet til en delt nettverkslagring, hvor det umiddelbart blir tilgjengelig for alle noder.
Beholderbilder kan noen ganger nå mange gigabyte i størrelse. Funksjonaliteten til ekstra lagring lar deg unngå å klone slike bilder på tvers av noder og gjør oppstart av containere nesten øyeblikkelig.
I tillegg jobber vi for tiden med en ny funksjon kalt overleggsvolummontering, som vil gjøre det enda raskere å bygge containere.
Konklusjon
Å kjøre Buildah inne i en container i Kubernetes/CRI-O, Podman eller til og med Docker er gjennomførbart, enkelt og mye sikrere enn å bruke docker.socket. Vi har økt fleksibiliteten ved å jobbe med bilder betraktelig, slik at du kan kjøre dem på en rekke måter for å optimalisere balansen mellom sikkerhet og ytelse.
Funksjonaliteten til ekstra lagring lar deg øke hastigheten eller helt eliminere nedlastingen av bilder til noder.
Kilde: www.habr.com