Cila është bukuria e shkëputjes së kohës së funksionimit të kontejnerit në komponentë të veçantë veglash pune? Në veçanti, këto mjete mund të fillojnë të kombinohen në mënyrë që të mbrojnë njëri-tjetrin.
Shumë njerëz tërhiqen nga ideja e ndërtimit të imazheve OCI të kontejnerizuara brenda ose sistem të ngjashëm. Le të themi se kemi një CI/CD që mbledh vazhdimisht imazhe, pastaj diçka të tillë /Kubernetes do të ishte mjaft i dobishëm për sa i përket balancimit të ngarkesës gjatë ndërtimeve. Deri kohët e fundit, shumica e njerëzve thjesht u jepnin kontejnerëve akses në një prizë Docker dhe i lejuan ata të ekzekutonin komandën e ndërtimit të docker. se kjo është shumë e pasigurt, në fakt, është edhe më keq sesa të japësh root ose sudo pa fjalëkalim.
Kjo është arsyeja pse njerëzit vazhdimisht përpiqen ta drejtojnë Buildah në një kontejner. Me pak fjalë, ne krijuam se si, sipas mendimit tonë, është më mirë të ekzekutoni Buildah brenda një kontejneri dhe të postoni imazhet përkatëse në . Le të fillojmë...
rregullim
Këto imazhe janë ndërtuar nga Dockerfiles, të cilat mund të gjenden në depon e Buildah në dosje .
Këtu do të shqyrtojmë .
# 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
Në vend të OverlayFS, të zbatuar në nivelin e kernelit të Linux-it pritës, ne përdorim programin brenda kontejnerit , sepse aktualisht OverlayFS mund të montohet vetëm nëse i jepni leje SYS_ADMIN duke përdorur aftësitë e Linux. Dhe ne duam të përdorim kontejnerët tanë Buildah pa asnjë privilegj rrënjësor. Mbivendosja e siguresave funksionon mjaft shpejt dhe ka performancë më të mirë se drejtuesi i ruajtjes VFS. Ju lutemi vini re se kur përdorni një kontejner Buildah që përdor Fuse, duhet të siguroni pajisjen /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
Më pas krijojmë një direktori për ruajtje shtesë. mbështet konceptin e lidhjes së dyqaneve shtesë të imazheve vetëm për lexim. Për shembull, mund të konfiguroni një zonë ruajtëse mbivendosjeje në një makinë dhe më pas të përdorni NFS për ta montuar këtë hapësirë ruajtëse në një pajisje tjetër dhe të përdorni imazhe prej saj pa shkarkuar me anë të tërheqjes. Ne kemi nevojë për këtë hapësirë ruajtëse në mënyrë që të mund të lidhim një pjesë të ruajtjes së imazheve nga hosti si vëllim dhe ta përdorim atë brenda kontejnerit.
# 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
Së fundi, duke përdorur variablin e mjedisit BUILDAH_ISOLATION, ne po i themi kontejnerit Buildah që të funksionojë me izolimin chroot si parazgjedhje. Këtu nuk kërkohet izolim shtesë, pasi tashmë po punojmë në një enë. Në mënyrë që Buildah të krijojë kontejnerët e vet të ndarë me hapësirën e emrave, kërkohet privilegji SYS_ADMIN, i cili do të kërkonte lehtësimin e rregullave SELinux dhe SECCOMP të kontejnerit, gjë që është në kundërshtim me preferencën tonë për të ndërtuar nga një kontejner i sigurt.
Vrapimi i Buildah brenda një kontejneri
Diagrami i imazhit të kontejnerit Buildah i diskutuar më sipër ju lejon të ndryshoni në mënyrë fleksibël metodat e hedhjes së kontejnerëve të tillë.
Shpejtësia kundrejt sigurisë
Siguria e kompjuterit është gjithmonë një kompromis midis shpejtësisë së procesit dhe sasisë së mbrojtjes së mbështjellë rreth tij. Kjo deklaratë është gjithashtu e vërtetë kur montoni kontejnerë, kështu që më poshtë do të shqyrtojmë opsionet për një kompromis të tillë.
Imazhi i kontejnerit të diskutuar më sipër do ta mbajë ruajtjen e tij në /var/lib/containers. Prandaj, ne duhet ta montojmë përmbajtjen në këtë dosje dhe mënyra se si e bëjmë këtë do të ndikojë shumë në shpejtësinë e ndërtimit të imazheve të kontejnerëve.
Le të shqyrtojmë tre opsione.
Opsioni 1. Nëse kërkohet siguri maksimale, atëherë për çdo kontejner mund të krijoni dosjen tuaj për kontejnerët/imazhin dhe ta lidhni me kontejnerin nëpërmjet montimit të volumit. Dhe përveç kësaj, vendosni direktorinë e kontekstit në vetë kontejnerin, në dosjen /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
Sigurimit. Buildah që funksionon në një kontejner të tillë ka siguri maksimale: nuk i jepet asnjë privilegj root duke përdorur aftësitë dhe të gjitha kufizimet SECOMP dhe SELinux zbatohen për të. Një kontejner i tillë mund të ekzekutohet edhe me izolimin e hapësirës së emrave të përdoruesit duke shtuar një opsion si —uidmap 0: 100000:10000.
Performanca. Por performanca këtu është minimale, pasi çdo imazh nga regjistrat e kontejnerëve kopjohet në host çdo herë, dhe cachimi nuk funksionon fare. Kur përfundon punën e tij, kontejneri Buildah duhet të dërgojë imazhin në regjistër dhe të shkatërrojë përmbajtjen në host. Herën tjetër që të ndërtohet imazhi i kontejnerit, ai do të duhet të shkarkohet përsëri nga regjistri, pasi deri në atë kohë nuk do të mbetet asgjë në host.
Opsioni 2. Nëse keni nevojë për performancë të nivelit Docker, mund ta montoni kontejnerin/magazinimin pritës direkt në kontejner.
# 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
Sigurimit. Kjo është mënyra më pak e sigurt për të ndërtuar kontejnerë, sepse lejon që kontejneri të modifikojë ruajtjen në host dhe mund të ushqejë potencialisht Podman ose CRI-O një imazh keqdashës. Përveç kësaj, do t'ju duhet të çaktivizoni ndarjen SELinux në mënyrë që proceset në kontejnerin Buildah të mund të ndërveprojnë me hapësirën ruajtëse në host. Vini re se ky opsion është akoma më i mirë se një prizë Docker sepse kontejneri është i kyçur nga veçoritë e mbetura të sigurisë dhe nuk mund të ekzekutojë thjesht një kontejner në host.
Performanca. Këtu është maksimumi, pasi memoria është përdorur plotësisht. Nëse Podman ose CRI-O e kanë shkarkuar tashmë imazhin e kërkuar në host, atëherë procesi Buildah brenda kontejnerit nuk do të duhet ta shkarkojë atë përsëri, dhe ndërtimet pasuese të bazuara në këtë imazh do të jenë gjithashtu në gjendje të marrin atë që u nevojitet nga cache .
Opsioni 3. Thelbi i kësaj metode është të kombinoni disa imazhe në një projekt me një dosje të përbashkët për imazhet e kontejnerëve.
# 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
Në këtë shembull, ne nuk e fshijmë dosjen e projektit (/var/lib/project3) ndërmjet ekzekutimeve, kështu që të gjitha ndërtimet pasuese brenda projektit përfitojnë nga ruajtja në memorie.
Sigurimit. Diçka midis opsioneve 1 dhe 2. Nga njëra anë, kontejnerët nuk kanë qasje në përmbajtjen në host dhe, në përputhje me rrethanat, nuk mund të rrëshqasin diçka të keqe në hapësirën ruajtëse të imazhit Podman/CRI-O. Nga ana tjetër, si pjesë e dizajnit të tij, një enë mund të ndërhyjë në montimin e kontejnerëve të tjerë.
Performanca. Këtu është më keq sesa kur përdorni një memorie të përbashkët në nivel pritës, pasi nuk mund të përdorni imazhe që janë shkarkuar tashmë duke përdorur Podman/CRI-O. Megjithatë, sapo Buildah të shkarkojë imazhin, imazhi mund të përdoret në çdo ndërtim të mëvonshëm brenda projektit.
Magazinim shtesë
У Ekziston një gjë kaq e lezetshme si dyqane shtesë (dyqane shtesë), falë të cilave kur lëshoni dhe ndërtoni kontejnerë, motorët e kontejnerëve mund të përdorin dyqane të jashtme imazhesh në modalitetin e mbivendosjes vetëm për lexim. Në thelb, mund të shtoni një ose më shumë memorie vetëm për lexim në skedarin storage.conf në mënyrë që kur të nisni kontejnerin, motori i kontejnerit të kërkojë imazhin e dëshiruar në to. Për më tepër, ai do të shkarkojë imazhin nga regjistri vetëm nëse nuk e gjen atë në asnjë nga këto depo. Motori i kontejnerit do të jetë në gjendje të shkruajë vetëm në ruajtje të shkrueshme...
Nëse lëvizni lart dhe shikoni Dockerfile që ne përdorim për të ndërtuar imazhin quay.io/buildah/stable, ka rreshta si kjo:
# 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
Në rreshtin e parë, ne modifikojmë /etc/containers/storage.conf brenda imazhit të kontejnerit, duke i thënë drejtuesit të ruajtjes të përdorë "additionalimagestores" në dosjen /var/lib/shared. Dhe në rreshtin tjetër ne krijojmë një dosje të përbashkët dhe shtojmë disa skedarë të kyçjes në mënyrë që të mos ketë abuzime nga kontejnerët/magazinimi. Në thelb, ne thjesht po krijojmë një dyqan bosh imazhi të kontejnerëve.
Nëse montoni kontejnerët/magazinimin në një nivel më të lartë se kjo dosje, Buildah do të jetë në gjendje të përdorë imazhet.
Tani le të kthehemi te Opsioni 2 i diskutuar më lart, kur kontejneri Buildah mund të lexojë dhe shkruajë në kontejnerë/të ruajë në hostet dhe, në përputhje me rrethanat, të ketë performancën maksimale për shkak të ruajtjes së imazheve në memorie në nivelin Podman/CRI-O, por ofron një minimum sigurie pasi mund të shkruajë drejtpërdrejt në ruajtje. Tani le të shtojmë hapësirë ruajtëse shtesë këtu dhe të përfitojmë më të mirën nga të dy botët.
# 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
Vini re se /var/lib/containers/storage e hostit është montuar në /var/lib/shared brenda kontejnerit në modalitetin vetëm për lexim. Prandaj, duke punuar në një kontejner, Buildah mund të përdorë çdo imazh që është shkarkuar më parë duke përdorur Podman/CRI-O (përshëndetje, shpejtësi), por mund të shkruajë vetëm në ruajtjen e vet (përshëndetje, siguri). Vini re gjithashtu se kjo bëhet pa çaktivizuar ndarjen SELinux për kontejnerin.
Nuancë e rëndësishme
Në asnjë rrethanë nuk duhet të fshini asnjë imazh nga depoja themelore. Përndryshe, kontejneri Buildah mund të rrëzohet.
Dhe këto nuk janë të gjitha avantazhet
Mundësitë e ruajtjes shtesë nuk janë të kufizuara në skenarin e mësipërm. Për shembull, mund të vendosni të gjitha imazhet e kontejnerëve në një hapësirë ruajtëse të përbashkët të rrjetit dhe t'u jepni akses të gjithë kontejnerëve Buildah. Le të themi se kemi qindra imazhe që sistemi ynë CI/CD përdor rregullisht për të ndërtuar imazhe të kontejnerëve. Ne i përqendrojmë të gjitha këto imazhe në një host të ruajtjes dhe më pas, duke përdorur mjetet e preferuara të ruajtjes së rrjetit (NFS, Gluster, Ceph, ISCSI, S3...), ne hapim akses të përgjithshëm në këtë hapësirë ruajtëse për të gjitha nyjet Buildah ose Kubernetes.
Tani është e mjaftueshme për të montuar këtë hapësirë ruajtëse të rrjetit në kontejnerin Buildah në /var/lib/shared dhe kaq - kontejnerët e Buildah nuk duhet të shkarkojnë më imazhe përmes tërheqjes. Kështu, ne hedhim fazën e parapopullimit dhe jemi menjëherë gati të hapim kontejnerët.
Dhe sigurisht, kjo mund të përdoret brenda një sistemi të drejtpërdrejtë Kubernetes ose infrastrukturës së kontejnerëve për të nisur dhe drejtuar kontejnerët kudo pa ndonjë shkarkim tërheqës të imazheve. Për më tepër, regjistri i kontejnerit, duke marrë një kërkesë shtytjeje për të ngarkuar një imazh të përditësuar në të, mund ta dërgojë automatikisht këtë imazh në një hapësirë ruajtëse të përbashkët të rrjetit, ku bëhet menjëherë i disponueshëm për të gjitha nyjet.
Imazhet e kontejnerëve ndonjëherë mund të arrijnë shumë gigabajt në madhësi. Funksionaliteti i ruajtjes shtesë ju lejon të shmangni klonimin e imazheve të tilla nëpër nyje dhe e bën lëshimin e kontejnerëve pothuajse të menjëhershëm.
Përveç kësaj, ne jemi duke punuar në një veçori të re të quajtur montimet e volumit të mbivendosjes, e cila do ta bëjë ndërtimin e kontejnerëve edhe më të shpejtë.
Përfundim
Përdorimi i Buildah brenda një kontejneri në Kubernetes/CRI-O, Podman apo edhe Docker është i realizueshëm, i thjeshtë dhe shumë më i sigurt se përdorimi i docker.socket. Ne kemi rritur shumë fleksibilitetin e punës me imazhet, kështu që ju mund t'i ekzekutoni ato në mënyra të ndryshme për të optimizuar ekuilibrin midis sigurisë dhe performancës.
Funksionaliteti i ruajtjes shtesë ju lejon të shpejtoni ose madje të eliminoni plotësisht shkarkimin e imazheve në nyje.
Burimi: www.habr.com