Wat is die skoonheid daarvan om die houer se looptyd in afsonderlike gereedskapkomponente te skei? Veral die feit dat hierdie gereedskap gekombineer kan word sodat hulle mekaar beskerm.
Baie mense word aangetrek deur die idee om OCI-houerbeelde binne te bou of soortgelyke stelsel. Kom ons sê ons het 'n CI / CD wat voortdurend beelde bou, dan iets soos /Kubernetes sal baie nuttig wees in terme van bouvragbalansering. Tot onlangs het die meeste mense houers bloot toegang tot 'n Docker-sok gegee en hulle toegelaat om die docker-bou-opdrag uit te voer. dat dit baie onseker is, om die waarheid te sê, dit is selfs erger as om wagwoordlose root of sudo te gee.
Mense probeer dus voortdurend om Buildah in 'n houer te laat loop. Kortom, ons het geskep hoe, na ons mening, is dit die beste om Buildah binne 'n houer te laat loop en die ooreenstemmende beelde op te plaas . Laat ons begin...
aanpassing
Hierdie beelde is gebou uit Dockerfiles, wat in die Buildah-bewaarplek in die gids gevind kan word .
Hier sal ons oorweeg .
# 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
In plaas van OverlayFS, geïmplementeer op die vlak van die Linux-kern van die gasheer, gebruik ons die program binne die houer , want tans kan OverlayFS slegs gemonteer word as jy dit SYS_ADMIN-toestemmings deur Linux-vermoëns gee. En ons wil ons Buildah-houers bestuur sonder enige wortelvoorregte. Fuse-overlay is redelik vinnig en werk beter as die VFS-bergingbestuurder. Let daarop dat wanneer 'n Buildah-houer met Fuse gebruik word, die /dev/fuse-toestel voorsien moet word.
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
Vervolgens skep ons 'n gids vir bykomende bewaarplekke. ondersteun die konsep om addisionele leesalleen-beeldbewaarplekke te koppel. Byvoorbeeld, jy kan 'n oorlegbergingsarea op een masjien opstel, en dan NFS gebruik om hierdie berging op 'n ander masjien te monteer en beelde daarvan te gebruik sonder om via pull af te laai. Ons het hierdie berging nodig om 'n bietjie beeldberging vanaf die gasheer as 'n volume te kan koppel en dit binne die houer te gebruik.
# 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
Ten slotte gebruik ons die BUILDAH_ISOLATION omgewingsveranderlike om die Buildah-houer te vertel om by verstek met chroot-isolasie te begin. Bykomende isolasie word nie hier vereis nie, aangesien ons reeds in 'n houer werk. Om vir Buildah sy eie naamruimte-geskeide houers te skep, word die SYS_ADMIN-voorreg vereis, wat sal vereis dat die houer se SELinux- en SECCOMP-reëls losgemaak word, wat bots met ons opstelling om vanaf 'n veilige houer te bou.
Hardloop Buildah binne 'n houer
Die Buildah-houerbeeldskema wat hierbo bespreek is, laat jou toe om buigsaam te verander hoe sulke houers bekendgestel word.
Spoed versus veiligheid
Rekenaarsekuriteit is altyd 'n kompromie tussen die spoed van 'n proses en hoeveel beskerming daaromheen toegedraai is. Hierdie stelling is ook waar wanneer houers saamgestel word, so hieronder sal ons opsies vir so 'n kompromie oorweeg.
Die houerprent wat hierbo bespreek is, sal die berging daarvan in /var/lib/containers hou. Daarom moet ons inhoud op hierdie gids plaas, en hoe ons dit doen, sal die spoed van die bou van houerbeelde grootliks beïnvloed.
Kom ons kyk na drie opsies.
1 opsie. As maksimum sekuriteit vereis word, kan jy vir elke houer jou eie vouer vir houers / beeld skep en dit aan die houer koppel via volume-mount. En behalwe, plaas die konteksgids in die houer self, in die /build-lêergids:
# 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
Sekuriteit. 'n Buildah wat in so 'n houer loop, het maksimum sekuriteit: dit kry geen wortelvoorregte deur vermoëns nie, en alle SECOMP- en SELinux-beperkings is daarop van toepassing. So 'n houer kan selfs met User Namespace-isolasie uitgevoer word deur 'n opsie soos --uidmap by te voeg 0:100000:10000.
Prestasie. Maar die werkverrigting hier is minimaal, aangesien enige beelde van houerregisters elke keer na die gasheer gekopieer word, en kas werk nie vanaf die woord "geen manier nie". Wanneer dit klaar is met sy werk, moet die Buildah-houer die prent na die register stuur en die inhoud op die gasheer vernietig. Die volgende keer dat die houerbeeld gebou word, sal dit weer van die register afgelaai moet word, aangesien niks teen daardie tyd op die gasheer gelaat sal word nie.
2 opsie. As jy Docker-vlak werkverrigting benodig, kan jy die gasheer se houer/berging direk in die houer monteer.
# 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
Sekuriteit. Dit is die minste veilige manier om houers te bou, aangesien dit die houer in staat stel om die berging op die gasheer te verander en moontlik 'n kwaadwillige beeld in Podman of CRI-O kan skuif. Daarbenewens sal jy SELinux-skeiding moet deaktiveer sodat die prosesse in die Buildah-houer met die bewaarplek op die gasheer kan kommunikeer. Let daarop dat hierdie opsie steeds beter is as 'n Docker-sok, aangesien die houer deur die oorblywende sekuriteitskenmerke geblokkeer word en nie bloot enige houer op die gasheer kan optel en laat loop nie.
Prestasie. Hier is dit maksimum, aangesien caching ten volle betrokke is. As Podman of CRI-O reeds die verlangde prent na die gasheer afgelaai het, sal die Buildah-proses binne die houer dit nie weer hoef af te laai nie, en daaropvolgende bouwerk gebaseer op hierdie prent sal ook die nodige een uit die kas kan neem .
3 opsie. Die kern van hierdie metode is om verskeie beelde in een projek te kombineer met 'n gemeenskaplike gids vir houerbeelde.
# 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
In hierdie voorbeeld verwyder ons nie die projeklêer (/var/lib/project3) tussen lopies nie, so alle daaropvolgende bouwerk binne die projek trek voordeel uit kas.
Sekuriteit. Iets tussen opsies 1 en 2. Aan die een kant het houers nie toegang tot inhoud op die gasheer nie en kan gevolglik nie iets sleg in die Podman / CRI-O-beeldberging inskuif nie. Aan die ander kant, binne sy eie projek, kan 'n houer inmeng met die samestelling van ander houers.
Prestasie. Hier is dit erger as om 'n gedeelde kas op gasheervlak te gebruik, aangesien jy nie beelde kan gebruik wat reeds met Podman / CRI-O afgelaai is nie. Sodra Buildah egter die prent afgelaai het, kan daardie prent in enige daaropvolgende bouwerk binne die projek gebruik word.
Bykomende berging
У daar is so 'n gawe ding soos bykomende winkels (bykomende winkels), waardeur houerenjins, wanneer hulle begin en bou, eksterne beeldwinkels in leesalleen-oorlegmodus kan gebruik. Trouens, jy kan een of meer leesalleen-bergings by die storage.conf-lêer voeg, sodat wanneer die houer begin, die houer-enjin die verlangde beeld daarin sal soek. Boonop sal dit die prent slegs van die register aflaai as dit dit nie in enige van hierdie bergings vind nie. Die houer-enjin sal slegs na skryfbare berging kan skryf...
As ons op blaai en kyk na die Dockerfile wat ons gebruik om die quay.io/buildah/stable beeld te bou, is daar lyne soos hierdie:
# 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
Op die eerste reël wysig ons /etc/containers/storage.conf binne die houerbeeld, en vertel die stoorbestuurder om "additionalimagestores" in die /var/lib/shared folder te gebruik. En in die volgende reël skep ons 'n gedeelde vouer en voeg 'n paar slotlêers by sodat daar geen misbruik van houers/berging is nie. In wese skep ons net 'n leë houerbeeldwinkel.
As jy houers/berging 'n vlak bokant hierdie vouer berg, sal Buildah die beelde kan gebruik.
Kom ons keer nou terug na Opsie 2 wat hierbo bespreek is, wanneer die Buildah-houer na houers kan lees en skryf / op gashere kan stoor en dienooreenkomstig maksimum werkverrigting het as gevolg van beeldkas op die Podman / CRI-O-vlak, maar 'n minimum sekuriteit bied, aangesien dit direk in die stoor kan skryf. En nou sal ons bykomende berging hier inskroef en die beste van albei wêrelde kry.
# 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
Let daarop dat die gasheer se /var/lib/houers/berging gemonteer is op /var/lib/shared binne die houer in leesalleenmodus. As u dus in 'n houer werk, kan Buildah enige beelde gebruik wat reeds met Podman / CRI-O afgelaai is (hallo, spoed), maar kan slegs na sy eie berging skryf (hallo, sekuriteit). Let ook daarop dat dit gedoen word sonder om SELinux-skeiding vir die houer te deaktiveer.
Belangrike nuanse
Onder geen omstandighede moet enige beelde uit die onderliggende bewaarplek verwyder word nie. Andersins kan die Buildah-houer ineenstort.
En dit is nie al die voordele nie.
Die moontlikhede vir bykomende berging is nie beperk tot die bogenoemde scenario nie. Byvoorbeeld, jy kan alle houerbeelde in 'n gedeelde netwerkberging plaas en toegang daartoe gee aan alle Buildah-houers. Kom ons sê ons het honderde beelde wat ons CI/CD-stelsel gereeld gebruik om beelde in houers te bou. Ons konsentreer al hierdie beelde op 'n enkele stoorgasheer en deel dan, met behulp van die voorkeurnetwerkbergingsinstrumente (NFS, Gluster, Ceph, iSCSI, S3 ...), hierdie berging met alle Buildah- of Kubernetes-nodes.
Nou is dit genoeg om hierdie netwerkberging in die Buildah-houer op /var/lib/shared te monteer en dit is dit - Buildah-houers hoef glad nie meer beelde af te laai via pull nie. Ons gooi dus die voorbevolkingsfase uit en is dadelik gereed om die houers uit te rol.
En natuurlik kan dit binne 'n lewendige Kubernetes-stelsel of houerinfrastruktuur gebruik word om houers oral te begin en te laat loop sonder enige beeldtrek. Boonop, wanneer 'n houerregister 'n drukversoek ontvang om 'n bygewerkte prent daarheen op te laai, kan dit hierdie prent outomaties na 'n gedeelde netwerkberging stuur, waar dit onmiddellik vir alle nodusse beskikbaar is.
Houerbeelde kan soms baie gigagrepe groot wees. Die funksionaliteit van bykomende bergings elimineer die behoefte om sulke beelde deur nodusse te kloneer en maak die bekendstelling van houers byna onmiddellik.
Daarbenewens werk ons tans aan 'n nuwe oorlegvolume-monteringsfunksie wat die bou van houers selfs vinniger sal maak.
Gevolgtrekking
Dit is heel moontlik om Buildah binne 'n houer in 'n Kubernetes/CRI-O-omgewing, Podman of selfs Docker te laat loop, en dit is eenvoudig en baie veiliger as om docker.socket te gebruik. Ons het die buigsaamheid om met beelde te werk aansienlik verhoog, en nou kan jy dit op verskeie maniere laat loop vir die beste balans tussen sekuriteit en werkverrigting.
Die funksionaliteit van bykomende bergings laat jou toe om die aflaai van beelde na die nodusse te bespoedig of selfs heeltemal uit te skakel.
Bron: will.com