Mis ilu on konteineri käitusaja lahtisidumisel eraldi tööriistakomponentideks? Eelkõige saab neid tööriistu hakata kombineerima, et nad üksteist kaitseksid.
Paljusid inimesi köidab idee luua konteineris OCI-pilte või sarnane süsteem. Oletame, et meil on CI/CD, mis kogub pidevalt pilte, siis midagi taolist /Kubernetes oleks ehituse ajal koormuse tasakaalustamise mõttes päris kasulik. Kuni viimase ajani andis enamik inimesi lihtsalt konteineritele juurdepääsu Dockeri pistikupesale ja lubas neil käivitada dockeri ehitamise käsku. et see on väga ebaturvaline, tegelikult on see isegi hullem kui paroolita root või sudo andmine.
Seetõttu püüavad inimesed pidevalt Buildahi konteineris käivitada. Ühesõnaga, me lõime kuidas meie arvates on Buildahi kõige parem konteineris käivitada, ja postitas vastavad pildid . Alustame...
reguleerimine
Need pildid on üles ehitatud Dockerfilesist, mille leiate kaustas Buildahi hoidlast .
Siin me kaalume .
# 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
OverlayFS-i asemel, mis on rakendatud hosti Linuxi tuuma tasemel, kasutame programmi konteineris , sest praegu saab OverlayFS-i paigaldada ainult siis, kui annate sellele Linuxi võimalusi kasutades SYS_ADMIN-i õigused. Ja me tahame oma Buildahi konteinereid käitada ilma juurõigusteta. Fuse-overlay töötab üsna kiiresti ja sellel on parem jõudlus kui VFS-mäludraiver. Pange tähele, et kui käitate Buildah'i konteinerit, mis kasutab Fuse'i, peate esitama seadme /dev/fuse.
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
Järgmisena loome täiendava salvestusruumi jaoks kataloogi. toetab täiendavate kirjutuskaitstud pildipoodide ühendamise kontseptsiooni. Näiteks saate konfigureerida ühes masinas ülekattega salvestusala ja seejärel kasutada NFS-i selle salvestusruumi ühendamiseks teise masinasse ja kasutada sellelt pilte ilma tõmbamiseta allalaadimiseta. Meil on seda salvestusruumi vaja selleks, et saaksime hostist mõne pildisalvestusruumi ühendada mahuna ja kasutada seda konteineris.
# 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
Lõpuks, kasutades keskkonnamuutujat BUILDAH_ISOLATION, käsime Buildahi konteineril vaikimisi töötada chroot-isolatsiooniga. Täiendav isolatsioon pole siin vajalik, kuna töötame juba konteineris. Selleks, et Buildah saaks luua oma nimeruumiga eraldatud konteinerid, on vaja SYS_ADMIN privileeg, mis nõuaks konteineri SELinuxi ja SECCOMP reeglite leevendamist, mis on vastuolus meie eelistusega ehitada turvalisest konteinerist.
Buildahi käivitamine konteineris
Eespool käsitletud Buildah konteineri kujutise diagramm võimaldab teil paindlikult varieerida selliste konteinerite käivitamise meetodeid.
Kiirus versus ohutus
Arvutiturve on alati kompromiss protsessi kiiruse ja selle ümber ümbritsetud kaitse vahel. See väide kehtib ka konteinerite kokkupanemisel, nii et allpool käsitleme sellise kompromissi võimalusi.
Ülalpool käsitletud konteineri kujutis säilitab oma salvestusruumi kaustas /var/lib/containers. Seetõttu peame sisu sellesse kausta ühendama ja see, kuidas me seda teeme, mõjutab oluliselt konteinerpiltide loomise kiirust.
Vaatleme kolme võimalust.
Valik 1. Kui on vaja maksimaalset turvalisust, siis saab iga konteineri jaoks luua konteinerite/pildi jaoks oma kausta ja ühendada selle konteineriga läbi volume-mount. Lisaks asetage kontekstikataloog konteinerisse endasse kausta /build:
# 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
Turvalisus. Sellises konteineris töötav Buildah on maksimaalse turvalisusega: sellele ei anta võimalusi kasutades rootõigusi ning sellele kehtivad kõik SECOMP-i ja SELinuxi piirangud. Sellist konteinerit saab käitada isegi kasutajanimeruumi eraldamisega, lisades sellise valiku nagu —uidmap 0: 100000:10000.
Etendus. Kuid jõudlus on siin minimaalne, kuna kõik konteineriregistrite pildid kopeeritakse iga kord hosti ja vahemällu salvestamine ei tööta üldse. Oma töö lõpetamisel peab Buildah konteiner pildi registrisse saatma ja hostis oleva sisu hävitama. Järgmisel konteineri kujutise loomisel tuleb see uuesti registrist alla laadida, kuna selleks ajaks pole hosti enam midagi alles.
Valik 2. Kui vajate Dockeri tasemel jõudlust, saate hosti konteineri/salvestusruumi otse konteinerisse paigaldada.
# 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
Turvalisus. See on kõige vähem turvaline konteinerite koostamise viis, kuna see võimaldab konteineril hosti salvestusruumi muuta ja võib Podmanile või CRI-O-le anda pahatahtliku pildi. Lisaks peate SELinuxi eraldamise keelama, et Buildahi konteineris olevad protsessid saaksid hosti salvestusega suhelda. Pange tähele, et see valik on siiski parem kui Dockeri pesa, kuna konteiner on ülejäänud turvafunktsioonide tõttu lukustatud ja see ei saa lihtsalt hostis konteinerit käivitada.
Etendus. Siin on see maksimum, kuna vahemälu on täielikult ära kasutatud. Kui Podman või CRI-O on vajaliku pildi juba hosti alla laadinud, siis konteineri sees olev Buildah protsess seda uuesti alla laadima ei pea ning ka järgnevad sellel pildil põhinevad buildid saavad vahemälust vajaliku võtta. .
Valik 3. Selle meetodi põhiolemus on mitme pildi ühendamine üheks projektiks konteineripiltide ühise kaustaga.
# 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
Selles näites ei kustuta me projekti kausta (/var/lib/project3) käitamiste vahel, nii et kõik järgnevad projektisisesed järgud saavad kasu vahemällu salvestamisest.
Turvalisus. Midagi valikute 1 ja 2 vahepealset. Ühest küljest pole konteineritel juurdepääsu hostis olevale sisule ja seetõttu ei saa nad midagi halba Podmani/CRI-O pildimällu libistada. Teisest küljest võib konteiner oma disaini osana segada teiste konteinerite kokkupanemist.
Etendus. Siin on see hullem kui hostitasemel jagatud vahemälu kasutamisel, kuna te ei saa kasutada pilte, mis on juba Podmani/CRI-O abil alla laaditud. Kui aga Buildah pildi alla laadib, saab pilti kasutada projekti mis tahes järgmistes ehitustes.
Täiendav salvestusruum
У On olemas selline lahe asi nagu lisapoed (lisapoed), tänu millele saavad konteinerite mootorid konteinerite käivitamisel ja ehitamisel kasutada väliseid pildipoode kirjutuskaitstud ülekatterežiimis. Põhimõtteliselt saate faili storage.conf lisada ühe või mitu kirjutuskaitstud salvestusruumi, nii et konteineri käivitamisel otsib konteineri mootor neist soovitud kujutist. Lisaks laadib see pildi registrist alla ainult siis, kui ta seda ühestki salvestusruumist ei leia. Konteinermootor saab kirjutada ainult kirjutatavale salvestusruumile...
Kui kerite üles ja vaatate Docker-faili, mida me pildi quay.io/buildah/stable koostamiseks kasutame, on seal järgmised read:
# 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
Esimesel real muudame konteineri pildi sees faili /etc/containers/storage.conf, käskides salvestusdraiveril kasutada kaustas /var/lib/shared "additionalimagestores". Ja järgmisel real loome jagatud kausta ja lisame paar lukufaili, et konteinerite / salvestusruumi kuritarvitamine ei toimuks. Sisuliselt loome lihtsalt tühja konteineri pildipoe.
Kui ühendate konteinerid/salvestusruumi sellest kaustast kõrgemale tasemele, saab Buildah pilte kasutada.
Nüüd pöördume tagasi ülalkirjeldatud variandi 2 juurde, kui Buildah' konteiner suudab lugeda ja kirjutada hostides asuvatesse konteineritesse/salvestada ning tänu Podmani/CRI-O tasemele piltide vahemällu salvestamisele on sellel maksimaalne jõudlus, kuid see tagab minimaalse turvalisuse. kuna see saab kirjutada otse salvestusruumi. Nüüd lisame siia täiendavat salvestusruumi ja kasutame mõlemast maailmast parimat.
# 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
Pange tähele, et hosti fail /var/lib/containers/storage on kirjutuskaitstud režiimis ühendatud konteineri sees kausta /var/lib/shared. Seetõttu saab Buildah konteineris töötades kasutada kõiki pilte, mis on varem Podmani/CRI-O abil alla laaditud (tere, kiirus), kuid kirjutada saab ainult enda salvestusruumi (tere, turvalisus). Pange tähele, et seda tehakse ilma konteineri SELinuxi eraldamist keelamata.
Oluline nüanss
Ärge mingil juhul kustutage aluseks olevast hoidlast pilte. Vastasel juhul võib Buildahi konteiner kokku kukkuda.
Ja need pole veel kõik eelised
Täiendava salvestusruumi võimalused ei piirdu ülaltoodud stsenaariumiga. Näiteks saate paigutada kõik konteineri pildid jagatud võrgusalvestusruumi ja anda sellele juurdepääsu kõigile Buildahi konteineritele. Oletame, et meil on sadu pilte, mida meie CI-/CD-süsteem kasutab regulaarselt konteinerkujutiste koostamiseks. Kontsentreerime kõik need pildid ühte salvestushosti ja seejärel, kasutades eelistatud võrgusalvestustööriistu (NFS, Gluster, Ceph, ISCSI, S3...), avame üldise juurdepääsu sellele salvestusruumile kõigile Buildahi või Kubernetese sõlmedele.
Nüüd piisab selle võrgumälu paigaldamisest Buildahi konteinerisse aadressil /var/lib/shared ja ongi kõik – Buildahi konteinerid ei pea enam pilte tõmbamise teel alla laadima. Seega viskame asustuseelse faasi välja ja oleme kohe valmis konteinereid välja rullima.
Ja loomulikult saab seda kasutada reaalajas Kubernetese süsteemis või konteinerite infrastruktuuris konteinerite käivitamiseks ja käitamiseks kõikjal, ilma pilte alla laadimata. Lisaks saab konteineri register, saades tõukepäringu värskendatud pildi üleslaadimiseks, selle pildi automaatselt saata jagatud võrgumällu, kus see muutub koheselt kättesaadavaks kõikidele sõlmedele.
Konteinerpildid võivad mõnikord ulatuda mitme gigabaiti suuruseni. Täiendava salvestusruumi funktsionaalsus võimaldab vältida selliste piltide kloonimist sõlmede vahel ja muudab konteinerite käivitamise peaaegu hetkeliseks.
Lisaks töötame praegu uue funktsiooni kallal nimega overlay volume mounts, mis muudab konteinerite ehitamise veelgi kiiremaks.
Järeldus
Buildahi käivitamine konteineris Kubernetes/CRI-O, Podmanis või isegi Dockeris on teostatav, lihtne ja palju turvalisem kui docker.socketi kasutamine. Oleme oluliselt suurendanud piltidega töötamise paindlikkust, nii et saate neid turvalisuse ja jõudluse vahelise tasakaalu optimeerimiseks erinevatel viisidel käitada.
Täiendava salvestusruumi funktsionaalsus võimaldab kiirendada või isegi täielikult välistada piltide sõlmedesse allalaadimise.
Allikas: www.habr.com