Zein da edukiontziaren exekuzio-denbora tresnen osagai bereizietan deskokatzearen edertasuna? Bereziki, tresna hauek konbinatzen has daitezke, elkar babesteko.
Jende asko erakartzen du barruan edukiontzidun OCI irudiak eraikitzeko ideiak edo antzeko sistema. Demagun irudiak etengabe biltzen dituen CI/CD bat dugula, gero antzeko zerbait /Kubernetes nahiko erabilgarria izango litzateke karga orekatzeari dagokionez, eraikitzeetan. Duela gutxi arte, jende gehienak edukiontziei Docker socket baterako sarbidea ematen zien eta docker eraikitzeko komandoa exekutatzeko aukera ematen zien. hori oso segurua ez dela, izan ere, pasahitz gabeko root edo sudo ematea baino are okerragoa da.
Horregatik jendea etengabe saiatzen da Buildah edukiontzi batean exekutatzen. Laburbilduz, sortu dugu nola, gure ustez, onena Buildah edukiontzi baten barruan exekutatu, eta dagozkion irudiak argitaratu . Has gaitezen...
doikuntza
Irudi hauek Dockerfiles-ekin eraiki dira, karpetako Buildah biltegian aurki daitezkeenak .
Hemen ikusiko dugu .
# 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
Ostalari Linux kernel mailan inplementatutako OverlayFS-ren ordez, programa erabiltzen dugu edukiontzi barruan , gaur egun OverlayFS Linux gaitasunak erabiliz SYS_ADMIN baimenak ematen badiozu soilik munta daitekeelako. Eta gure Buildah edukiontziak exekutatu nahi ditugu erro-pribilegiorik gabe. Fuse-overlay nahiko azkar funtzionatzen du eta VFS biltegiratze kontrolatzaileak baino errendimendu hobea du. Kontuan izan Fuse erabiltzen duen Buildah edukiontzi bat exekutatzen ari zarenean, /dev/fuse gailua eman behar duzula.
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
Ondoren, biltegiratze gehigarrirako direktorio bat sortuko dugu. Irakurtzeko soilik den irudi denda osagarriak konektatzeko kontzeptua onartzen du. Adibidez, gainjartzeko biltegiratze-eremu bat konfigura dezakezu makina batean, eta, ondoren, NFS erabil dezakezu biltegiratze hori beste makina batean muntatzeko eta bertako irudiak erabili pull bidez deskargatu gabe. Biltegiratze hau behar dugu ostalaritik irudi biltegiratze batzuk bolumen gisa konektatu eta edukiontzi barruan erabiltzeko.
# 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
Azkenik, BUILDAH_ISOLATION ingurune-aldagaia erabiliz, Buildah edukiontziari lehenespenez chroot isolamenduarekin exekutatzeko esaten ari gara. Hemen ez da isolamendu gehigarririk behar, edukiontzi batean lanean ari baikara. Buildah-ek bere izen-espazioz bereizitako edukiontziak sortzeko, SYS_ADMIN pribilegioa behar da, eta horrek edukiontziaren SELinux eta SECCOMP arauak lasaitu beharko lituzke, edukiontzi seguru batetik eraikitzea nahi dugunaren aurkakoa da.
Buildah exekutatzen edukiontzi baten barruan
Goian aztertutako Buildah edukiontziaren irudi-diagramak edukiontziak abiarazteko metodoak malgutasunez alda ditzakezu.
Abiadura versus segurtasuna
Ordenagailuaren segurtasuna prozesuaren abiaduraren eta horren inguruan dagoen babesaren arteko konpromisoa da beti. Adierazpen hau ontziak muntatzean ere egia da, beraz, jarraian konpromiso hori hartzeko aukerak aztertuko ditugu.
Goian aztertutako edukiontziaren irudiak /var/lib/containers-en gordeko du. Hori dela eta, edukia karpeta honetan muntatu behar dugu, eta nola egiten dugun edukiontzien irudiak eraikitzeko abiaduran eragin handia izango du.
Azter ditzagun hiru aukera.
Aukera 1. Segurtasun handiena behar bada, edukiontzi bakoitzeko zure karpeta sortu dezakezu edukiontzi/irudietarako eta edukiontzira konektatu bolumen-muntatu bidez. Eta gainera, jarri testuinguru-direktorioa edukiontzian bertan, /build karpetan:
# 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
Segurtasuna. Horrelako edukiontzi batean exekutatzen den Buildah-ek segurtasunik handiena du: ez zaio root pribilegiorik ematen gaitasunak erabiliz, eta SECOMP eta SELinux murrizketa guztiak aplikatzen zaizkio. Edukiontzi hori Erabiltzaile-izenen espazioa isolatuta ere exekutatu daiteke βuidmap 0 bezalako aukera bat gehituta: 100000:10000.
Emanaldia. Baina hemen errendimendua gutxienekoa da, edukiontzi-erregistroetako irudiak ostalarira kopiatzen baitira aldiro, eta cacheak ez du batere funtzionatzen. Bere lana amaitzean, Buildah edukiontziak irudia erregistrora bidali behar du eta ostalariaren edukia suntsitu. Edukiontziaren irudia eraikitzen den hurrengoan, berriro deskargatu beharko da erregistrotik, ordurako ez baita ezer geratuko ostalarian.
Aukera 2. Docker mailako errendimendua behar baduzu, ostalariaren edukiontzia/biltegiratzea zuzenean ontzian munta dezakezu.
# 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
Segurtasuna. Hau da edukiontziak eraikitzeko modurik seguruena, edukiontziari ostalari biltegiratzea aldatzeko aukera ematen diolako eta Podman edo CRI-O irudi gaizto bat eman dezakeelako. Horrez gain, SELinux-en bereizketa desgaitu beharko duzu Buildah edukiontziko prozesuek ostalariaren biltegiarekin elkarreragin dezaten. Kontuan izan aukera hau oraindik Docker-en socket bat baino hobea dela, edukiontzia gainerako segurtasun-eginbideek blokeatuta dagoelako eta ezin duelako edukiontzi bat ostalarian exekutatu.
Emanaldia. Hemen gehienezkoa da, cachea guztiz erabiltzen baita. Podman-ek edo CRI-O-k dagoeneko deskargatu badute beharrezko irudia ostalarira, orduan edukiontzi barruko Buildah prozesuak ez du berriro deskargatu beharko, eta irudi honetan oinarritutako ondorengo eraikitzeek ere behar dutena hartu ahal izango dute cachetik. .
Aukera 3. Metodo honen funtsa hainbat irudi proiektu bakarrean konbinatzea da edukiontzien irudietarako karpeta komun batekin.
# 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
Adibide honetan, ez dugu proiektuaren karpeta (/var/lib/project3) ezabatzen exekuzioen artean, beraz, proiektuaren ondorengo eraikitze guztiek cachean uzten dute.
Segurtasuna. 1. eta 2. aukeren artean dagoen zerbait. Alde batetik, edukiontziak ez daukate ostalariaren edukirako sarbiderik eta, ondorioz, ezin dute ezer txarrik sartu Podman/CRI-O irudien biltegian. Bestalde, bere diseinuaren barruan, edukiontzi batek beste edukiontzi batzuen muntaia oztopatu dezake.
Emanaldia. Hemen ostalari mailan partekatutako cache bat erabiltzean baino okerragoa da, ezin baita erabili Podman/CRI-O erabiliz dagoeneko deskargatutako irudiak. Hala ere, Buildah-ek irudia deskargatzen duenean, irudia proiektuaren ondorengo edozein eraikuntzatan erabil daiteke.
Biltegiratze gehigarria
Π£ Denda osagarriak (denda osagarriak) bezalako gauza polita dago, eta horri esker ontziak abiarazi eta eraikitzean, edukiontzi-motorrek kanpoko irudi-dendak erabil ditzakete irakurtzeko soilik gainjartzeko moduan. Funtsean, irakurtzeko soilik biltegiratze bat edo gehiago gehi ditzakezu storage.conf fitxategian, edukiontzia abiarazten duzunean, edukiontzi-motorrak haietan nahi duzun irudia bila dezan. Gainera, irudia erregistrotik deskargatuko du biltegiratze horietako batean aurkitzen ez badu soilik. Edukiontzi-motorrak idazteko moduko biltegian soilik idatzi ahal izango du...
Gora mugitzen baduzu eta quay.io/buildah/stable irudia eraikitzeko erabiltzen dugun Dockerfile-ra begiratzen baduzu, honelako lerroak daude:
# 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
Lehen lerroan, /etc/containers/storage.conf aldatzen dugu edukiontziaren irudiaren barruan, biltegiratze-gidariari /var/lib/shared karpetan "additionalimagestores" erabiltzeko esanez. Eta hurrengo lerroan karpeta partekatu bat sortzen dugu eta blokeo-fitxategi pare bat gehitzen ditugu, edukiontzietatik/biltegiratzetik gehiegikeriarik egon ez dadin. Funtsean, edukiontzi hutsaren irudi-denda bat sortzen ari gara.
Ontziak/biltegiratzea karpeta hau baino maila altuago batean muntatzen baduzu, Buildah-ek irudiak erabili ahal izango ditu.
Orain itzul gaitezen goian aztertutako 2. aukerara, Buildah edukiontziak ostalarietako edukiontzietan/biltegietan irakurtzen eta idazten duenean eta, horren arabera, errendimendu maximoa duenean Podman/CRI-O mailan irudiak gordetzeagatik, baina segurtasun minimo bat eskaintzen duenean. biltegian zuzenean idatz dezakeenez. Orain gehi ditzagun biltegiratze gehigarria hemen eta lortu bi munduetatik onena.
# 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
Kontuan izan ostalariaren /var/lib/containers/storage-n muntatuta dagoela edukiontziaren barruan /var/lib/shared irakurtzeko soilik moduan. Hori dela eta, edukiontzi batean lan eginez, Buildah-ek aldez aurretik Podman/CRI-O erabiliz deskargatutako edozein irudi erabil dezake (kaixo, abiadura), baina bere biltegian soilik idatzi dezake (kaixo, segurtasuna). Kontuan izan, gainera, hori edukiontzirako SELinux bereizketa desgaitu gabe egiten dela.
Eragina garrantzitsua
Inolaz ere ez duzu irudirik ezabatu azpiko biltegitik. Bestela, Buildah edukiontziak huts egin dezake.
Eta hauek ez dira abantaila guztiak
Biltegiratze gehigarrirako aukerak ez dira goiko eszenatokira mugatzen. Adibidez, edukiontzien irudi guztiak sareko biltegiratze partekatu batean jar ditzakezu eta horretarako sarbidea eman Buildah edukiontzi guztiei. Demagun ehunka irudi ditugula gure CI/CD sistemak edukiontzien irudiak eraikitzeko aldizka erabiltzen dituena. Irudi horiek guztiak biltegiratze-ostalari batean kontzentratzen ditugu eta, ondoren, sareko biltegiratze tresna hobetsiak erabiliz (NFS, Gluster, Ceph, ISCSI, S3...), biltegiratze honetarako sarbide orokorra irekitzen dugu Buildah edo Kubernetes nodo guztiei.
Orain nahikoa da sareko biltegiratze hau /var/lib/shared-en Buildah edukiontzian muntatzea eta kitto - Buildah edukiontziek jada ez dute irudiak deskargatu behar pull bidez. Horrela, populazio aurreko fasea bota eta berehala prest gaude edukiontziak botatzeko.
Eta, noski, Kubernetes zuzeneko sistema edo edukiontzi azpiegitura batean erabil daiteke edukiontziak edonon abiarazteko eta exekutatzeko, irudiak deskargatu gabe. Gainera, edukiontzien erregistroak, eguneratutako irudi bat igotzeko push eskaera jasota, automatikoki bidal dezake irudi hori sare partekatuko biltegiratze batera, non berehala nodo guztientzat erabilgarri egongo den.
Edukiontzien irudiak batzuetan gigabyte asko izatera irits daitezke. Biltegiratze gehigarriaren funtzionaltasunak nodoen artean horrelako irudiak klonatzea saihesteko aukera ematen du eta edukiontziak ia berehala abiarazten ditu.
Horrez gain, une honetan gainjarri bolumen-muntaiak izeneko funtzio berri bat lantzen ari gara, edukiontziak are bizkorrago eraikiko dituena.
Ondorioa
Kubernetes/CRI-O, Podman edo Docker-en Buildah edukiontzi baten barruan exekutatzen aritzea egingarria, sinplea eta askoz seguruagoa da docker.socket erabiltzea baino. Irudiekin lan egiteko malgutasuna asko handitu dugu, hainbat modutan exekutatu ahal izateko segurtasunaren eta errendimenduaren arteko oreka optimizatzeko.
Biltegiratze gehigarriaren funtzionaltasunak nodoetara irudiak deskargatzea bizkortu edo guztiz ezabatzeko aukera ematen du.
Iturria: www.habr.com