Mitä kauneutta on kontin käyttöajan erottamisessa erillisiksi työkalukomponenteiksi? Erityisesti näitä työkaluja voidaan alkaa yhdistää siten, että ne suojaavat toisiaan.
Monia ihmisiä kiinnostaa ajatus konttimuotoisten OCI-kuvien rakentamisesta tai vastaava järjestelmä. Oletetaan, että meillä on CI/CD, joka kerää jatkuvasti kuvia, sitten jotain sellaista /Kubernetes olisi varsin hyödyllinen kuormituksen tasapainottamisessa rakennusten aikana. Viime aikoihin asti useimmat ihmiset vain antoivat konteille pääsyn Docker-pistorasiaan ja antoivat heidän suorittaa Docker build -komennon. että tämä on erittäin epävarmaa, itse asiassa se on vielä pahempaa kuin salasanattoman rootin tai sudon antaminen.
Siksi ihmiset yrittävät jatkuvasti ajaa Buildahia kontissa. Lyhyesti sanottuna loimme miten mielestämme on parasta ajaa Buildah sisällä kontti, ja lähetetty vastaavat kuvat . Aloitetaan...
säätö
Nämä kuvat on rakennettu Dockerfilesista, joka löytyy kansion Buildah-arkistosta .
Tässä me katsomme .
# 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
Isäntä-Linux-ytimen tasolla toteutetun OverlayFS:n sijasta käytämme kontin sisällä olevaa ohjelmaa , koska tällä hetkellä OverlayFS voidaan asentaa vain, jos annat sille SYS_ADMIN-oikeudet käyttämällä Linuxin ominaisuuksia. Ja haluamme käyttää Buildah-säilöjämme ilman pääkäyttäjän oikeuksia. Sulakepeitto toimii melko nopeasti ja sen suorituskyky on parempi kuin VFS-tallennusohjain. Huomaa, että kun käytät Buildah-säilöä, joka käyttää Fusea, sinun on annettava /dev/fuse-laite.
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
Seuraavaksi luomme hakemiston lisätallennustilaa varten. tukee ajatusta muiden vain luku -muotoisten kuvasäilöjen yhdistämisestä. Voit esimerkiksi määrittää peittokuvan tallennusalueen yhdelle koneelle ja sitten käyttää NFS:ää tämän tallennustilan liittämiseen toiselle koneelle ja käyttää kuvia siitä lataamatta pullon kautta. Tarvitsemme tätä tallennustilaa, jotta voimme yhdistää jonkin kuvan tallennustilasta isännästä taltioona ja käyttää sitä säilön sisällä.
# 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
Lopuksi, käyttämällä BUILDAH_ISOLATION-ympäristömuuttujaa, käskemme Buildah-säilöä ajamaan oletuksena chroot-eristyksen kanssa. Tässä ei tarvita lisäeristystä, koska työskentelemme jo kontissa. Jotta Buildah voisi luoda omia nimitilalla erotettuja säilöjä, tarvitaan SYS_ADMIN-oikeus, mikä edellyttäisi säilön SELinux- ja SECCOMP-sääntöjen lieventämistä, mikä on vastoin sitä, että haluamme rakentaa suojatusta säilöstä.
Buildah käynnissä kontin sisällä
Yllä käsitellyn Buildah-konttikuvakaavion avulla voit joustavasti vaihdella tällaisten säiliöiden laukaisumenetelmiä.
Nopeus vs. turvallisuus
Tietokoneturvallisuus on aina kompromissi prosessin nopeuden ja sen ympärillä olevan suojan välillä. Tämä väite pitää paikkansa myös kontteja koottaessa, joten alla tarkastellaan vaihtoehtoja tällaiselle kompromissille.
Yllä käsitelty konttikuva säilyttää tallennustilan hakemistossa /var/lib/containers. Siksi meidän on liitettävä sisältö tähän kansioon, ja miten teemme tämän, vaikuttaa suuresti konttikuvien rakentamisen nopeuteen.
Harkitse kolmea vaihtoehtoa.
Vaihtoehto 1. Jos vaaditaan maksimaalista suojausta, voit luoda jokaiselle säiliölle oman kansion säiliöille/kuvalle ja liittää sen säiliöön volyymikiinnityksellä. Ja lisäksi aseta kontekstihakemisto itse säilöön, /build-kansioon:
# 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
Turvallisuus. Tällaisessa säilössä toimivalla Buildahilla on maksimaalinen suojaus: sille ei anneta pääkäyttäjän oikeuksia ominaisuuksien avulla, ja kaikki SECOMP- ja SELinux-rajoitukset koskevat sitä. Tällaista säilöä voidaan jopa ajaa käyttäjänimiavaruuden eristämisellä lisäämällä vaihtoehto, kuten —uidmap 0: 100000:10000.
Suorituskykyä. Mutta suorituskyky on tässä minimaalinen, koska kaikki säilörekisterien kuvat kopioidaan isäntään joka kerta, ja välimuisti ei toimi ollenkaan. Tehdessään työtään Buildah-säilön tulee lähettää kuva rekisteriin ja tuhota isäntäkoneen sisältö. Seuraavan kerran, kun säilön näköistiedosto rakennetaan, se on ladattava uudelleen rekisteristä, koska siihen mennessä isännässä ei ole enää mitään.
Vaihtoehto 2. Jos tarvitset Docker-tason suorituskykyä, voit asentaa isäntäsäiliön/tallennustilan suoraan säiliöön.
# 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
Turvallisuus. Tämä on vähiten turvallinen tapa rakentaa säilöjä, koska sen avulla säilö voi muokata isäntätallennustilaa ja saattaa mahdollisesti syöttää Podmanille tai CRI-O:lle haitallisen kuvan. Lisäksi sinun on poistettava SELinux-erottelu käytöstä, jotta Buildah-säilön prosessit voivat olla vuorovaikutuksessa isännän tallennustilan kanssa. Huomaa, että tämä vaihtoehto on silti parempi kuin Docker-kanta, koska säilytys on lukittu muiden suojausominaisuuksien vuoksi, eikä se voi yksinkertaisesti ajaa säilöä isännässä.
Suorituskykyä. Tässä se on maksimi, koska välimuisti on täysin käytetty. Jos Podman tai CRI-O on jo ladannut vaaditun kuvan isäntään, niin säilön sisällä olevan Buildah-prosessin ei tarvitse ladata sitä uudelleen, ja myöhemmät tähän kuvaan perustuvat koontiversiot voivat myös ottaa tarvitsemansa välimuistista. .
Vaihtoehto 3. Tämän menetelmän ydin on yhdistää useita kuvia yhdeksi projektiksi, jossa on yhteinen kansio konttikuville.
# 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
Tässä esimerkissä emme poista projektikansiota (/var/lib/project3) ajojen välillä, joten kaikki projektin myöhemmät koontiversiot hyötyvät välimuistista.
Turvallisuus. Jotain vaihtoehtojen 1 ja 2 väliltä. Toisaalta säilöillä ei ole pääsyä isäntäkoneen sisältöön, eivätkä ne näin ollen voi pudottaa mitään pahaa Podman/CRI-O-kuvamuistiin. Toisaalta säiliö voi osana suunnitteluaan häiritä muiden säiliöiden kokoamista.
Suorituskykyä. Tässä se on huonompi kuin käytettäessä jaettua välimuistia isäntätasolla, koska et voi käyttää kuvia, jotka on jo ladattu Podman/CRI-O:lla. Kuitenkin, kun Buildah on ladannut kuvan, kuvaa voidaan käyttää kaikissa projektin myöhemmissä koontiversioissa.
Lisäsäilytystila
У On olemassa sellainen siisti asia kuin lisämyymälät (lisämyymälät), joiden ansiosta konttimoottorit voivat käyttää ulkoisia kuvasäilöjä vain luku -peittotilassa kontteja käynnistäessään ja rakentaessaan. Pohjimmiltaan voit lisätä varasto.conf-tiedostoon yhden tai useamman vain luku -muistin, jotta säilön käynnistäessä konttikone etsii niistä haluttua kuvaa. Lisäksi se lataa kuvan rekisteristä vain, jos se ei löydä sitä mistään näistä varastoista. Konttimoottori pystyy kirjoittamaan vain kirjoitettavaan tallennustilaan...
Jos vierität ylöspäin ja katsot Docker-tiedostoa, jota käytämme kuvan quay.io/buildah/stable luomiseen, siinä on seuraavanlaisia rivejä:
# 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
Ensimmäisellä rivillä muokkaamme tiedostoa /etc/containers/storage.conf säilön kuvan sisällä ja käskemme tallennusohjainta käyttämään "additionalimagestores" -kansiota /var/lib/shared-kansiossa. Ja seuraavalla rivillä luomme jaetun kansion ja lisäämme pari lukitustiedostoa, jotta säiliöiden/tallennustilan väärinkäyttöä ei tapahdu. Pohjimmiltaan olemme yksinkertaisesti luomassa tyhjää säiliökuvakauppaa.
Jos asennat säiliöitä/tallennustilaa korkeammalle kuin tämä kansio, Buildah voi käyttää kuvia.
Palataan nyt yllä käsiteltyyn vaihtoehtoon 2, jolloin Buildah-säilö voi lukea ja kirjoittaa isäntien säilöihin/säilöihin ja sen mukaisesti sillä on maksimaalinen suorituskyky Podman/CRI-O-tason kuvien välimuistin ansiosta, mutta se tarjoaa vähimmäisturvan. koska se voi kirjoittaa suoraan tallennustilaan. Lisätään nyt tähän lisää tallennustilaa ja hyödynnetään molempien maailmojen parhaat puolet.
# 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
Huomaa, että isännän /var/lib/containers/storage on liitetty hakemistoon /var/lib/shared säilön sisällä vain luku -tilassa. Siksi säiliössä työskennellessään Buildah voi käyttää mitä tahansa kuvia, jotka on ladattu aiemmin Podman/CRI-O:lla (hei, nopeus), mutta voi kirjoittaa vain omaan tallennustilaansa (hei, turvallisuus). Huomaa myös, että tämä tehdään poistamatta SELinux-erottelua käytöstä säiliössä.
Tärkeä vivahde
Älä missään tapauksessa poista kuvia alla olevasta arkistosta. Muuten Buildah-kontti saattaa kaatua.
Ja nämä eivät ole kaikki edut
Lisätallennusmahdollisuudet eivät rajoitu yllä olevaan skenaarioon. Voit esimerkiksi sijoittaa kaikki säilökuvat jaettuun verkkotallennustilaan ja antaa pääsyn siihen kaikille Buildah-säiliöille. Oletetaan, että meillä on satoja kuvia, joita CI/CD-järjestelmämme käyttää säännöllisesti konttikuvien rakentamiseen. Keskitämme kaikki nämä kuvat yhteen tallennusisäntään ja käytämme suositeltuja verkkotallennustyökaluja (NFS, Gluster, Ceph, ISCSI, S3...) ja avaamme yleisen pääsyn tähän tallennustilaan kaikille Buildah- tai Kubernetes-solmuille.
Nyt riittää, että liität tämän verkkotallennustilan Buildah-säilöyn hakemistoon /var/lib/shared ja se on siinä - Buildah-säilöjen ei enää tarvitse ladata kuvia vedolla. Näin ollen heitämme pois esipopulaatiovaiheen ja olemme heti valmiita rullaamaan kontit ulos.
Ja tietysti tätä voidaan käyttää elävässä Kubernetes-järjestelmässä tai konttiinfrastruktuurissa konttien käynnistämiseen ja käyttämiseen missä tahansa ilman kuvien vetolatausta. Lisäksi konttirekisteri, joka vastaanottaa push-pyynnön ladata päivitetty kuva siihen, voi lähettää tämän kuvan automaattisesti jaettuun verkkotallennustilaan, jossa se tulee välittömästi kaikkien solmujen saataville.
Säilön kuvien koko voi joskus olla useita gigatavuja. Lisätallennustilan toiminnallisuuden avulla voit välttää tällaisten kuvien kloonauksen solmujen välillä ja tekee konttien käynnistämisestä lähes välitöntä.
Lisäksi kehitämme parhaillaan uutta ominaisuutta nimeltä overlay volume mounts, joka nopeuttaa konttien rakentamista entisestään.
Johtopäätös
Buildahin käyttäminen säiliön sisällä Kubernetes/CRI-O:ssa, Podmanissa tai jopa Dockerissa on mahdollista, yksinkertaista ja paljon turvallisempaa kuin docker.socketin käyttäminen. Olemme lisänneet huomattavasti kuvien työskentelyn joustavuutta, joten voit käyttää niitä useilla eri tavoilla optimoidaksesi tasapainon turvallisuuden ja suorituskyvyn välillä.
Lisätallennustilan toiminnallisuuden avulla voit nopeuttaa tai jopa poistaa kokonaan kuvien lataamisen solmuihin.
Lähde: will.com