Mis on konteinerite töökeskkonna eraldamise ilu? Eelkõige see, et neid tööriistu saab alustada kombineerima, et nad üksteist kaitseksid.
Paljusid paelub idee koostada konteinerite OCI-pilte raames või sarnase süsteemi kaudu. Oletame, et meil on CI/CD, mis pidevalt genereerib pilte, siis midagi sarnast /Kubernetes было бы весьма полезно с точки зрения распределения нагрузки при сборке. До недавних пор большинство людей просто давали контейнерам доступ к Docker-сокету и разрешали выполнять команду docker build. , et see on väga ebaohutu, tegelikult on see isegi hullem kui anda paroolita root või sudo.
Seetõttu püüavad inimesed pidevalt käivitada Buildah'i konteineris. Lühidalt öeldes, oleme loonud seda, kuidas meie meelest on parim käivitada Buildah konteineris, ja oleme vastavad pildid üles laadinud . Alustame…
Seadistamine
Need pildid on loodud Dockerfile'idest, mida saab leida Buildah hoidlast kaustas .
Siin vaatame .
# 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 asemel, mis on rakendatud hosti Linuxi tuuma tasemel, kasutame konteineris programmi , kuna praegu OverlayFS suudab monteerida, kui sellele antakse SYS_ADMIN õigused Linuxi võimetega. Soovime oma Buildah konteinerid käivitada ilma root taseme õigusteta. Fuse-overlay töötab üsna kiiresti ja on jõudluse poolest parem kui VFS salvestusjuht. Pange tähele, et Buildah konteiner, mis kasutab Fuse'i, vajab seadme /dev/fuse olemasolu.
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 täiendavate salvestuskohtade katalooge. toetab täiendavate ainult lugemiseks mõeldud piltide salvestuskohtade ühendamise kontseptsiooni. Näiteks saab ühel masinal seadistada overlay salvestusala ja seejärel mountida see NFS'i abil teisele masinale ning kasutada seal olevaid pilte ilma pull'iga allalaadimata. See salvestuskoht on meil vajalik, et saaksime ühendada mõne pildi salvestuskoha 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
Ja lõpuks, kasutades keskkonnamuutujat BUILDAH_ISOLATION, ütleme, et vaikimisi Buildah konteiner peaks käivituma chroot-isolatsiooniga. Täiendav isolatsioon pole vajalik, kuna töötame juba konteineris. Et Buildah saaks luua oma konteine eraldatud nimede ruumidega, on vajalik SYS_ADMIN privileeg, mis tähendab, et tuleb nõrgendada konteineri SELinux ja SECCOMP reegleid, mis on vastuolus meie seadistusega, et teostada build'i turvalises konteineris.
Käivitame Buildah'i konteineris
Eelpool arutatud Buildah konteineri pildi skeem võimaldab paindlikult varieerida, kuidas selliseid konteinereid käivitada.
Kiirus vastu turvalisus
Arvutiturve on alati tasakaal kiirusprotsessi täitmise ja selle ümber oleva kaitse vahel. See väide kehtib ka konteinerite koostamisel, seega vaatleme allpool sellise kompromissi võimalusi.
Ülaltoodud konteineripilt hoiab oma andmeid kataloogis /var/lib/containers. Seetõttu peame sisu selle kausta monteerima, ja see, kuidas me seda teeme, mõjutab oluliselt konteineripiltide koostamise kiirus.
Vaatame kolme varianti.
Variant 1. Kui maksimaalne turvalisus on vajalik, saab iga konteineri jaoks luua oma kausta kataloogis containers/image ja ühendada selle konteineriga läbi volume-mount. Lisaks sellele saab konteksti katalooge paigutada otse konteinerisse, 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 tagab maksimaalse turvalisuse: tal ei ole root-privileege capabilities'i kaudu ning kõik SECOMP ja SELinux piirangud kehtivad. Sellist konteinerit saab isegi käivitada kasutaja nimespea isoleerimisega, lisades sellise valiku nagu —uidmap 0:100000:10000.
Töötlusvõimekus. Siin on minimaalne jõudlus, kuna kõik konteineriregistri pildid kopeeritakse iga kord hostile ja vahemälu ei toimi mitte kuidagi. Oma töö lõpetamisel peab Buildah-konteiner saatma pildi registrisse ja kustutama sisu hostist. Järgmine kord, kui konteineri pilt kokkukogutakse, tuleb see uuesti registrist alla laadida, sest hostis ei jää sel ajal enam midagi alles.
Variant 2. Kui on vajalik Docker'i tasemel jõudlus, võib 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 sel juhul on konteinerile lubatud hosti salvestust muuta ja see võib potentsiaalselt sisestada Podmanile või CRI-O-le pahatahtliku pildi. Samuti tuleb välja lülitada SELinuxi isolatsioon, et Buildah-konteineris asuvad protsessid saaksid hosti salvestusega suhelda. Pange tähele, et see variant on ikkagi parem kui Docker'i pistik, kuna konteinerit piiravad jäänud turbefunktsioonid ja see ei saa lihtsalt võtta ja käivitada mingit konteinerit hostis.
Töötlusvõimekus. Siin on see maksimaalselt, kuna vahemälu kasutatakse täielikult. Kui Podman või CRI-O on juba vajalikku imaget hostile alla laadinud, ei pea Buildah-protsess konteineri sees seda uuesti alla laadima ning sellele imagile tuginevad järgmised ehitused saavad samuti vajalikku võtta vahemälust.
Variant 3. Selle meetodi sisu on ühendada mitu imaget ühte projekti, millel on ühine kaust konteinerite imagede 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
Käesolevas näites ei eemalda me projekti kausta (/var/lib/project3) käivituste vahel, seetõttu kasutavad kõik järgmised ehitused projekti raames vahemälu eeliseid.
Turvalisus. Midagi vahepealset variantide 1 ja 2 vahel. Ühelt poolt ei pääse konteinerid hosti sisu juurde ja seega ei saa nad Podman/CRI-O imagede hoidlasse midagi halba lisada. Teiselt poolt võib konteiner oma projekti raames sekkuda teiste konteinerite ehitamisse.
Töötlusvõimekus. Siin on olukord halvem kui hosti tasemel üldise vahemälu kasutamisel, kuna ei saa kasutada juba varem Podman/CRI-O vahenditega allalaaditud pilte. Siiski, pärast Buildah'i pilti allalaadimist saab seda kasutada kõigis hilisemates projektikogumites.
Lisahoidlad
U olemas on mõningaid ägedaid asju nagu lisahoidlad (additional stores), mille abil saavad konteinerimootorid käivitus- ja kogumisprotsessi käigus kasutada väliseid pildihoidlaid read-only ülekate režiimis. Sisuliselt saab faili storage.conf lisada ühe või mitu 'ainult lugemiseks' hoidlat, et seejärel konteineri käivitamisel otsiks konteinerimootor vajalikku pilti neis. Samuti laeb see pildi registrist alla ainult siis, kui ei leia seda üheski nendest hoidlatest. Konstruktorimootor saab kirjutada ainult kirjutatavatesse hoidlatestesse...
Kui kerida üles ja vaadata Dockerfile'i, mida me kasutame quay.io/buildah/stable pildi koostamiseks, siis seal on 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 /etc/containers/storage.conf konteineri pildi sees, öeldes salvestusdriverile, et kasutada "additionalimagestores" kaustas /var/lib/shared. Järgmises reas loome ühise kausta ja lisame paar lukufaili, et vältida konflikte containers/storage poolt. Sisuliselt loome lihtsalt tühja konteineripiltide salvestuse.
Kui mountida containers/storage selle kausta kõrgemale tasemele, suudab Buildah kasutada pilte.
Nüüd naaseme eelpool käsitletud variandi 2 juurde, kus Buildah-konteiner suudab lugeda ja kirjutada containers/store hostides, omades seega maksimaalset jõudlust pilte vahemällu salvestades Podman/CRI-O tasemel, kuid pakkudes minimaalset turvalisust, kuna võib kirjutada otse salvestustesse. Nüüd lisame siia täiendavad salvestused ja saame kahest maailmast parima.
# 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
Pöörake tähelepanu, et hosti /var/lib/containers/storage on monteeritud konteineris /var/lib/shared ainult lugemisrežiimis. Seetõttu võib Buildah konteineris töötades kasutada kõiki varasemaid Podman/CRI-O vahendeid allalaaditud pilte (tervitused kiirusest), kuid kirjutada saab ainult oma salvestusse (tervitused turvalisusele). Samuti pöörake tähelepanu, et see toimub ilma SELinuxi eraldamise keelamiseta konteineri jaoks.
Oluline nüanss
Igal juhul ei ole lubatud alumisest salvestusest pilte kustutada. Vastasel korral võib Buildah konteiner kokku kukkuda.
Ja see ei ole kaugeltki kõik eelised
Lisa salvestusvõimalused ei piirdustu vaid eespool kirjeldatud stsenaariumiga. Näiteks võidakse kõik konteinerite pildid talletada ühises võrku salvestuses ja anda kõigile Buildah konteineritele sellele juurdepääs. Oletame, et meil on sadu pilte, mida meie CI/CD süsteem regulaarselt kasutab konteinerite piltide koostamisel. Koondame kõik need pildid ühele host-käivituspunktile ja seejärel, kasutades soovitud võrgu salvestusmeetodeid (NFS, Gluster, Ceph, ISCSI, S3...), avame selle salvestuse juurdepääsu kõikidele Buildah või Kubernetes sõlmedele.
Nüüd piisab, kui see võrgu salvestus mountida Buildah konteinerisse kausta /var/lib/shared ja kõik – Buildah konteeritel ei ole enam vaja pilte pullida. Nii viskame eelmise täitmisfaasi (pre-population) välja ja oleme kohe valmis konteinerite käivitamiseks.
Ja muidugi saab seda kasutada olemasolevas Kubernetes-süsteemis või konteinerite infrastruktuuris, et käivitada ja töödelda konteineriteid igal pool ilma mingite piltide allalaadimist pull-iga. Veelgi enam, konteineriregister, saades push-päringu uuendatud pildi üleslaadimiseks, saab automaatselt saata selle pildi üldisesse võrguhoidlasse, kus see muutub kõikidele sõlmedele koheselt kättesaadavaks.
Konteinerite piltide suurused võivad mõnikord ulatuda mitme gigabaidini. Täiendavate ladustamisvõimaluste funktsionaalsus võimaldab vältida selliste piltide kopeerimist sõlmedesse ning muudab konteinerite käivitamise praktiliselt hetkega.
Lisaks töötame hetkel uue overlay volume mounts funktsiooni kallal, mis teeb konteinerite koostamise veelgi kiiremaks.
Kokkuvõte
Buildah'i käitamine konteineris Kubernetes'e/CRI-O, Podmani või isegi Docker'i keskkonnas on täiesti reaalne, lisaks on see lihtsam ja oluliselt turvalisem kui docker.socket'i kasutamine. Oleme oluliselt suurendanud töötamise paindlikkust piltidega ning nüüd saate neid käivitada erinevatel viisidel, et saavutada optimaalne tasakaal turvalisuse ja jõudluse vahel.
Lisa salvestusfunktsioon kiirendab või vähendab isegi täielikult piltide allalaadimist sõlmedesse.
Allikas: habr.com
