Mis on konteinerite täitmisruumi jagamise ilu eraldi tööriistade komponentideks? Eelkõige see, et neid tööriistu saab hakata kombineerima, et nad üksteist kaitseksid.
Paljusid köidab idee koguda konteinerite OCI-pilte raames või sarnast süsteemi. Oletame, et meil on pidev CI/CD, mis kogub pidevalt pilte, siis midagi sellist nagu /Kubernetes было бы весьма полезно с точки зрения распределения нагрузки при сборке. До недавних пор большинство людей просто давали контейнерам доступ к Docker-сокету и разрешали выполнять команду docker build. , et see on väga ebaturvaline, tegelikult on see isegi hullem kui anda paroolita root või sudo õigused.
Seetõttu püüavad inimesed pidevalt käivitada Buildah'i konteineris. Lühidalt, me lõime kuidas, meie arvates, parim viis on käivitada Buildah konteineris, ja laadisime vastavad pildid üles . Alustame…
Seadistamine
Need pildid on kogutud Dockerfile'idest, mida saab leida Buildah'i hoidlast kaustast .
Siin käsitleme .
# 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
Kuna we ei kasuta Containeris OverlayFS, mis on hosti Linuxi tuuma tasemel, kasutasime programm FUSE-overlay. 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
Seejärel loome kausta täiendavate salvestuste jaoks.
Container/storage toetab lisatud read-only piltide salvestusruumide ühendamise kontseptsiooni. Näiteks saab ühendada overlay salvestusala ühel masinal ja seejärel mountida see salvestusruum teisel masinal NFS-i kaudu ning kasutada sealt pilte ilma, et neid tuleb pullida. Me vajame seda salvestusruumi, et saaksime ühendada mõne pildi salvestusruumi hostilt 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, ütleme, et vaikimisi Buildah konteiner peaks käima chroot-isolatsiooniga. Täiendavat isolatsiooni siin ei ole vaja, kuna töötame juba konteineris. Selleks, et Buildah saaks oma konteinerid luua nimede eraldamisega, on vajalik SYS_ADMIN privileeg ning selleks tuleb konteineri jaoks leevendada SELinux ja SECCOMP reegleid, mis on vastuolus meie seadistusega, et teostada koostööd turvalisest konteinerist.
Käivitame Buildah konteineris
Eelnevalt arutatud Buildah konteineri pildiskeem võimaldab paindlikult varieerida selliste konteinerite käivitamise viise.
Kiirus vs turvalisus
Tehniline turvalisus on alati kompromiss protsessi käituskiiruse ja selle ümber kehtestatud kaitse vahel. See väide kehtib ka konteinerite koostamisel, seetõttu vaatame allpool selle kompromissi valikute üle.
Eeltoodud konteineripilt hoiab oma salvestust aadressis /var/lib/containers. Seetõttu peame sisu sellele kausta ühendama ja see, kuidas me seda teeme, mõjutab tugevalt konteineri piltide koostamise kiirus.
Vaatame kolme varianti.
Variant 1. Kui maksimaalne turvalisus on vajalik, saab iga konteineri jaoks luua oma kausta containers/image ja ühendada selle konteinerisse volume-mount kaudu. Lisaks saab konteksti katalooge ise konteineris paigutada, kataloogis /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 omab maksimaalset turvalisust: talle ei anta mingeid root-privileege capabilities'i kaudu, ning teda rakendatakse kõik SECOMP ja SELinux piirangud. Sellist konteinerit saab isegi käivitada Kasutaja Nimi ruumi isolatsiooniga, lisades valiku nagu —uidmap 0:100000:10000.
Tõhusus. Kuid siin on jõudlus minimaalne, kuna kõik pildid konteineriregioonides kopeeritakse iga kord hostile, ja vahemälu ei tööta üldse. Oma töö lõpetades peab Buildah konteiner saatma pildi registrisse ja hävitama sisu hostis. Kui konteineripilt järgmine kord koostatakse, tuleb see jälle registrist alla laadida, kuna sel hetkel ei jää hostile enam midagi.
Variant 2. Kui on vaja Docker'i tasemel jõudlust, saab hosti container/storage otse konteinerisse mountida.
# 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 viis konteinerite koostamiseks, kuna konteineril on lubatud muuta hosti salvestust, ja see võib potentsiaalselt sisestada Podmanile või CRI-O pahatahtliku kujundi. Lisaks tuleb välja lülitada SELinux'i eraldus, et Buildah konteineris olevad protsessid saaksid suhelda hosti salvestusega. Pange tähele, et see variant on siiski parem kui Docker socket, kuna konteiner on blokeeritud teiste turvafunktsioonidega ja ei saa lihtsalt võtta ja käivitada mõnda konteinerit hostis.
Tõhusus. Siin on see maksimaalne, kuna täielikult kasutatakse vahemälu. Kui Podman või CRI-O on juba vajalikku kujundit hosti alla laadinud, ei pea Buildah-protsess konteineris seda uuesti alla laadima, ja sellele tuginevad järgmised koostamised saavad samuti vajaliku vahemälust.
Variant 3. Selle meetodi olemus on ühendada mitu kujundit ühte projekti koos ühise kaustaga konteinerite kujundite jaoks.
# 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 me ei eemalda projekti kausta (/var/lib/project3) käivituste vahel, seega kasutavad kõik järgmised koostamised projekti raames vahemälu eeliseid.
Turvalisus. Midagi vahepealset variantide 1 ja 2 vahel. Ühelt poolt ei ole konteineritel juurdepääsu hosti sisule ja seega ei saa nad sisestada midagi halba Podman / CRI-O kujudesse. Teiselt poolt saab konteiner seoses oma projektiga teistes konteinerites koostamisse sekkuda.
Tõhusus. Siin on see halvem kui hosti tasemel ühise vahemälu kasutamisel, kuna ei saa kasutada juba varem Podman / CRI-O vahenditega alla laaditud kujundeid. Kuid pärast seda, kui Buildah on kujundi alla laadinud, saab seda kasutada kõigis järgnevates koostamistes projekti raames.
Lisa salvestused
Uus On olemas ülihea asi nagu täiendavad salvestused (additional stores), mille abil konteinerimootorid saavad konteinerite käivitamise ja koostamise ajal kasutada väliseid pildisalvestusi ainult lugemisrežiimis. Lisaks saab faili storage.conf lisada ühe või mitu „ainult lugemiseks“ salvestust, et konteinerimootor otsiks neid vajadusel pildist käivitamisel. Seejärel laadib ta pildi registrist ainult juhul, kui ei leia seda ühelgi nendest salvestustest. Konteinerimootor suudab kirjutada ainult kirjutamiseks saadaval olevatesse salvestustesse…
Kui kerida tagasi üles ja vaadata Dockerfile'i, mida kasutame quay.io/buildah/stable pildi koostamiseks, on seal sellised 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
Esimeses reas muudame konteineripildi /etc/containers/storage.conf, öeldes storage-draiverile, et kasutaks „additionalimagestores“ kaustas /var/lib/shared. Järgmises reas loome jagatud kausta ja lisame paar lukufaili, et välistada container/storage'ilt tulevad vead. Tegelikult loome lihtsalt tühja konteerimisruumi.
Kui mountida containers/storage selle kausta taseme võrra kõrgemal, suudab Buildah kasutada pilte.
Nüüd naaseme varem käsitletud variandi 2 juurde, kus Buildah konteiner suudab lugeda ja kirjutada containers/store'is hostidel ning seega saavutab maksimaalse jõudluse piltide vahemällu salvestamise kaudu Podman/CRI-O tasemel, kuid see annab minimaalset turvalisust, kuna võib kirjutada otse salvestustesse. Nüüd lülitame siia sisse täiendavad salvestused ja saame parima mõlema maailma.
# 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 /var/lib/containers/storage on mountitud konteineris /var/lib/shared lugemisrežiimis. Seetõttu saab Buildah töötades konteineris kasutada kõiki juba varem Podman/CRI-O vahenditega alla laaditud pilte (tere, kiirus), kuid kirjutada saab ainult oma salvestusse (tere, turvalisus). Samuti pidage meeles, et seda tehakse ilma SELinux'i eraldusjoont konteineris välja lülitamata.
Oluline nüanss
Igal juhul ei tohi kustutada ühtegi pilti madalamast salvestusest. Vastasel juhul võib Buildah konteiner crashida.
Ja see ei ole sugugi kõik eelised
Täiendavate salvestusvõimaluste potentsiaal ei piirdu ainult eespool kirjeldatud stsenaariumiga. Näiteks saab paigutada kõik konteineripildid ühisesse võrgusalvestusse ja anda sellele ligipääsu kõigile Buildah konteineritele. Oletame, et meil on sadu pilte, mida meie CI/CD süsteem regulaarselt kasutab konteineripiltide koostamiseks. Koondame kõik need pildid ühel host-salvestusse ja avame seejärel, kasutades soovitud võrgusalvestusvahendeid (NFS, Gluster, Ceph, ISCSI, S3...), ühise ligipääsu sellele salvestusele kõigile Buildah või Kubernetes sõlmedele.
Nüüd piisab, kui monteerida see võrgusalvestus Buildah konteineris aadressile /var/lib/shared ja kõik – Buildah konteinerid ei pea enam kunagi pilte läbi pull-i alla laadima. Nii et me kaotame eeltäiendamise etapi ja oleme kohe valmis konteinerite välja laskmiseks.
Ja loomulikult saab seda kasutada olemasoleva Kubernetes süsteemi või konteinerite infrastruktuuri raames, et käivitada ja töödelda konteinerite kuskil ilma igasuguste pull-piltide allalaadimist. Veelgi enam, konteineriregister, kui see saab postitamissoovi üles laadida uuendatud pilti, võib automaatselt saata selle pildi ühisesse võrgusalvestusse, kus see on koheselt kergesti kätte saada kõikidele sõlmedele.
Konteineripiltide suurused võivad mõnikord ulatuda mitme gigabaidini. Täiendavate salvestuste funktsionaalsus võimaldab vältida selliste piltide kopeerimist sõlmedesse ja muudab konteinerite käivitamise praktiliselt koheseks.
Lisaks töötame hetkel uue overlay volume mounts funktsiooni kallal, mis teeb konteinerite koostamise veelgi kiiremaks.
Kokkuvõte
Buildah'i kasutamine konteineris Kubernetes/CRI-O, Podman või isegi Docker keskkonnas on täiesti võimalik, ning see on lihtne ja palju turvalisem kui docker.socket'i kasutamine. Oleme oluliselt suurendanud paindlikkust piltidega töötamisel ning nüüd saate neid käivitada erinevatel viisidel, et saavutada optimaalne tasakaal turvalisuse ja jõudluse vahel.
Täiendavate salvestuste funktsionaalsus võimaldab kiirendada või isegi täielikult kaotada piltide allalaadimise sõlmedesse.
Allikas: habr.com
