Wat is de skientme fan it ûntkoppelen fan de kontener-runtime yn aparte arkkomponinten? Benammen dizze ark kinne begjinne te kombinearjen sadat se beskermje elkoar.
In protte minsken wurde oanlutsen troch it idee om binnen containerisearre OCI-ôfbyldings te bouwen of ferlykber systeem. Litte we sizze dat wy in CI/CD hawwe dy't konstant bylden sammelet, dan soksawat / Kubernetes soe frij nuttich wêze yn termen fan load balancing tidens builds. Oant koartlyn joegen de measte minsken konteners gewoan tagong ta in Docker-socket en lieten se it kommando docker build útfiere. dat dit is hiel ûnfeilich, yn feite, it is noch slimmer as jaan wachtwurdleaze root of sudo.
Dêrom besykje minsken konstant Buildah yn in kontener te rinnen. Koartsein, wy makken hoe, yn ús miening, is it bêste te rinnen Buildah binnen in kontener, en pleatst de byhearrende bylden op . Litte wy begjinne...
oanpassing
Dizze ôfbyldings binne boud fan Dockerfiles, dy't te finen binne yn it Buildah-repository yn 'e map .
Hjir sille wy beskôgje .
# 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
Ynstee fan OverlayFS, ymplementearre op it host Linux-kernelnivo, brûke wy it programma yn 'e kontener , want op it stuit kin OverlayFS allinich mount wurde as jo it SYS_ADMIN-mooglikheden jouwe mei Linux-mooglikheden. En wy wolle ús Buildah-konteners útfiere sûnder root-privileges. Fuse-overlay wurket frij fluch en hat bettere prestaasjes dan de VFS-opslachbestjoerder. Tink derom dat by it útfieren fan in Buildah-kontener dy't Fuse brûkt, jo it /dev/fuse-apparaat moatte leverje.
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
Folgjende meitsje wy in map foar ekstra opslach. stipet it konsept fan it ferbinen fan ekstra read-allinnich ôfbylding winkels. Jo kinne bygelyks in overlay-opslachgebiet ynstelle op ien masine, en dan NFS brûke om dizze opslach op in oare masine te montearjen en ôfbyldings derfan te brûken sûnder te downloaden fia pull. Wy hawwe dizze opslach nedich om wat ôfbyldingsopslach fan 'e host te ferbinen as in folume en it yn' e kontener te brûken.
# 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
As lêste, troch de omjouwingsfariabele BUILDAH_ISOLATION te brûken, fertelle wy de Buildah-container om standert te rinnen mei chroot-isolaasje. Oanfoljende isolaasje is hjir net nedich, om't wy al yn in kontener wurkje. Om Buildah syn eigen nammeromte-skieden konteners te meitsjen, is it SYS_ADMIN-privilege fereaske, wat soe fereaskje it ûntspannen fan 'e SELinux- en SECCOMP-regels fan' e kontener, wat yn striid is mei ús foarkar om te bouwen fan in feilige kontener.
Running Buildah binnen in kontener
It hjirboppe besprutsen Buildah-kontenerôfbyldingsdiagram lit jo de metoaden foar it lansearjen fan sokke konteners fleksibel fariearje.
Faasje tsjin feiligens
Kompjûterfeiligens is altyd in kompromis tusken de snelheid fan it proses en hoefolle beskerming der omhinne is. Dizze útspraak is ek wier by it gearstallen fan konteners, dus hjirûnder sille wy opsjes foar sa'n kompromis beskôgje.
De hjirboppe besprutsen kontenerôfbylding sil har opslach hâlde yn /var/lib/containers. Dêrom moatte wy de ynhâld yn dizze map montearje, en hoe't wy dit dogge, sil de snelheid fan it bouwen fan kontenerôfbyldings sterk beynfloedzje.
Litte wy trije opsjes beskôgje.
Option 1. As maksimale feiligens fereaske is, dan kinne jo foar elke kontener jo eigen map meitsje foar konteners / ôfbylding en ferbine it mei de kontener fia folume-mount. En boppedat, pleatse de kontekstmap yn 'e kontener sels, yn' e / build map:
# 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
Feiligens. Buildah dy't yn sa'n kontener draait hat maksimale feiligens: it wurdt gjin root-privileezjes jûn mei help fan mooglikheden, en alle SECOMP- en SELinux-beheiningen jilde derop. Sa'n kontener kin sels útfierd wurde mei User Namespace-isolaasje troch in opsje ta te foegjen lykas —uidmap 0: 100000:10000.
Optreden. Mar de prestaasje hjir is minimaal, om't alle ôfbyldings fan kontenerregisters elke kear nei de host wurde kopieare, en caching wurket hielendal net. By it foltôgjen fan syn wurk moat de Buildah-container de ôfbylding nei it register stjoere en de ynhâld op 'e host ferneatigje. De folgjende kear dat de kontenerôfbylding wurdt boud, sil it opnij moatte wurde downloade fan 'e registraasje, om't d'r tsjin dy tiid neat mear oer is op' e host.
Option 2. As jo prestaasjes op Docker-nivo nedich binne, kinne jo de hostkontener / opslach direkt yn 'e kontener montearje.
# 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
Feiligens. Dit is de minste feilige manier om konteners te bouwen, om't it de kontener mooglik makket om host-opslach te feroarjen en Podman of CRI-O mooglik in kweade ôfbylding kin fiede. Derneist moatte jo SELinux-skieding útskeakelje, sadat prosessen yn 'e Buildah-kontener kinne ynteraksje mei de opslach op' e host. Tink derom dat dizze opsje noch altyd better is dan in Docker-socket, om't de kontener is beskoattele troch oerbleaune feiligensfunksjes en kin net gewoan in kontener op 'e host útfiere.
Optreden. Hjir is it maksimum, om't caching folslein brûkt wurdt. As Podman of CRI-O de fereaske ôfbylding al nei de host hawwe ynladen, dan hoecht it Buildah-proses yn 'e kontener it net opnij te downloaden, en folgjende builds basearre op dizze ôfbylding sille ek kinne nimme wat se nedich binne fan' e cache .
Option 3. De essinsje fan dizze metoade is om ferskate ôfbyldings te kombinearjen yn ien projekt mei in mienskiplike map foar kontenerôfbyldings.
# 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
Yn dit foarbyld wiskje wy de projektmap (/var/lib/project3) net tusken runs, sadat alle folgjende builds binnen it projekt profitearje fan caching.
Feiligens. Iets yn tusken opsjes 1 en 2. Oan 'e iene kant hawwe konteners gjin tagong ta ynhâld op' e host en kinne dus net wat min yn 'e Podman / CRI-O-ôfbylding opslach glide. Oan 'e oare kant, as ûnderdiel fan syn ûntwerp, kin in kontener ynterferearje mei de gearstalling fan oare konteners.
Optreden. Hjir is it slimmer as by it brûken fan in dielde cache op hostnivo, om't jo ôfbyldings net brûke kinne dy't al binne ynladen mei Podman/CRI-O. As Buildah lykwols de ôfbylding downloadt, kin de ôfbylding brûkt wurde yn alle folgjende builds binnen it projekt.
Ekstra opslach
У D'r is sa'n cool ding as ekstra winkels (ekstra winkels), wêrtroch't kontenermotoren by it lansearjen en bouwen fan konteners eksterne ôfbyldingswinkels kinne brûke yn allinich-lês-overlay-modus. Yn essinsje kinne jo ien of mear allinich-lêzen opslach tafoegje oan it storage.conf-bestân sadat as jo de kontener begjinne, de kontenermotor siket nei de winske ôfbylding yn har. Boppedat sil it de ôfbylding allinich downloade fan it register as it it net fynt yn ien fan dizze opslach. De kontenermotor kin allinich skriuwe nei skriuwbere opslach ...
As jo nei boppe rôlje en sjogge nei it Dockerfile dat wy brûke om de ôfbylding te bouwen quay.io/buildah/stable, binne d'r rigels lykas dit:
# 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
Yn 'e earste rigel feroarje wy /etc/containers/storage.conf yn 'e kontenerôfbylding, en fertelle de opslachbestjoerder om "additionalimagestores" te brûken yn 'e /var/lib/shared map. En yn 'e folgjende rigel meitsje wy in dielde map en foegje in pear slotbestannen ta sadat d'r gjin misbrûk is fan konteners / opslach. Yn essinsje meitsje wy gewoan in lege kontenerôfbyldingswinkel.
As jo mount containers / opslach op in nivo heger as dizze map, Buildah sil by steat wêze om te brûken de ôfbyldings.
Litte wy no weromgean nei hjirboppe besprutsen opsje 2, as de Buildah-kontener kin lêze en skriuwe nei konteners / op hosts opslaan en, sadwaande, maksimale prestaasjes hat troch caching-ôfbyldings op it Podman / CRI-O-nivo, mar in minimum fan feiligens leveret sûnt it kin direkt skriuwe nei opslach. Litte wy hjir ekstra opslach tafoegje en it bêste fan beide wrâlden krije.
# 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
Tink derom dat de /var/lib/containers/storage fan de host is monteard op /var/lib/dield yn 'e kontener yn allinich-lêsmodus. Dêrom kin Buildah wurkje yn in kontener alle ôfbyldings brûke dy't earder ynladen binne mei Podman / CRI-O (hallo, snelheid), mar kin allinich skriuwe nei har eigen opslach (hallo, feiligens). Tink derom ek dat dit wurdt dien sûnder SELinux-skieding foar de kontener út te skeakeljen.
Wichtige nuâns
Under gjin omstannichheden moatte jo ôfbyldings wiskje fan it ûnderlizzende repository. Oars kin de Buildah-kontener crashe.
En dit binne net alle foardielen
De mooglikheden fan ekstra opslach binne net beheind ta it boppesteande senario. Jo kinne bygelyks alle kontenerôfbyldings pleatse op in dielde netwurkopslach en tagong ta alle Buildah-konteners. Litte wy sizze dat wy hûnderten ôfbyldings hawwe dy't ús CI/CD-systeem regelmjittich brûkt om kontenerôfbyldings te bouwen. Wy konsintrearje al dizze ôfbyldings op ien opslachhost en dan, mei help fan de foarkommende netwurkopslachark (NFS, Gluster, Ceph, ISCSI, S3 ...), iepenje wy algemiene tagong ta dizze opslach foar alle Buildah- of Kubernetes-knooppunten.
No is it genôch om dizze netwurk opslach te montearjen yn 'e Buildah-kontener op /var/lib/shared en dat is it - Buildah-konteners hoege gjin ôfbyldings mear te downloaden fia pull. Sa smite wy de foarbefolkingsfaze út en binne wy daliks klear om de konteners út te rôljen.
En fansels kin dit brûkt wurde binnen in live Kubernetes-systeem of kontenerynfrastruktuer om konteners oeral te lansearjen en út te fieren sûnder ienige pull-download fan ôfbyldings. Boppedat kin de kontenerregistraasje, dy't in push-oanfraach ûntfangt om in bywurke ôfbylding nei it te uploaden, dizze ôfbylding automatysk stjoere nei in dielde netwurk opslach, wêr't it direkt beskikber wurdt foar alle knopen.
Containerôfbyldings kinne soms in protte gigabytes yn grutte berikke. De funksjonaliteit fan ekstra opslach lit jo it klonen fan sokke ôfbyldings oer knooppunten foarkomme en makket it lansearjen fan konteners hast direkt.
Derneist wurkje wy op it stuit oan in nije funksje neamd overlay volume mounts, dy't it bouwen fan konteners noch flugger meitsje sil.
konklúzje
It útfieren fan Buildah yn in kontener yn Kubernetes/CRI-O, Podman, of sels Docker is mooglik, ienfâldich en folle feiliger dan it brûken fan docker.socket. Wy hawwe de fleksibiliteit fan it wurkjen mei ôfbyldings sterk ferhege, sadat jo se op ferskate manieren kinne útfiere om it lykwicht tusken feiligens en prestaasjes te optimalisearjen.
De funksjonaliteit fan ekstra opslach lit jo it downloaden fan ôfbyldings nei knopen fersnelle of sels folslein eliminearje.
Boarne: www.habr.com