Kio estas la beleco de apartigi la ujan rultempon en apartajn ilajn komponantojn? Precipe, la fakto, ke ĉi tiuj iloj povas komenci esti kombinitaj, por ke ili protektas unu la alian.
Multaj homoj estas altiritaj de la ideo konstrui OCI-ujojn ene aŭ simila sistemo. Ni diru, ke ni havas CI/KD kiu konstante konstruas bildojn, tiam ion similan /Kubernetes estus tre utila rilate al konstrua ŝarĝoekvilibro. Ĝis antaŭ nelonge, plej multaj homoj simple donis al ujoj aliron al Docker-ingo kaj permesis al ili ruli la docker-konstruan komandon. ke ĉi tio estas tre nesekura, fakte, ĝi estas eĉ pli malbona ol doni senpasvorton radikon aŭ sudo.
Do homoj konstante provas kuri Buildah en ujo. Resume, ni kreis kiel, laŭ nia opinio, estas plej bone ruli Buildah ene de ujo, kaj afiŝi la respondajn bildojn . Ni komencu...
alĝustigo
Ĉi tiuj bildoj estas konstruitaj el Dockerfiles, kiuj troviĝas en la Buildah-deponejo en la dosierujo .
Ĉi tie ni konsideros .
# 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
Anstataŭ OverlayFS, efektivigita ĉe la nivelo de la Linukso-kerno de la gastiganto, ni uzas la programon ene de la ujo. , ĉar nuntempe OverlayFS povas munti nur se vi donas al ĝi SYS_ADMIN-permesojn per Linukso-kapabloj. Kaj ni volas ruli niajn Buildah-ujojn sen iuj ajn radikaj privilegioj. Fuze-overlay estas sufiĉe rapida kaj funkcias pli bone ol la VFS-stoka ŝoforo. Notu, ke kiam oni rulas Buildah-ujon per Fuse, la /dev/fuse-aparato devas esti provizita.
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
Poste ni kreas dosierujon por pliaj deponejoj. subtenas la koncepton konekti pliajn nurlegeblajn bilddeponejojn. Ekzemple, vi povas agordi superkovritan stokejon sur unu maŝino, kaj tiam uzi NFS por munti ĉi tiun stokadon sur alia maŝino kaj uzi bildojn de ĝi sen elŝuti per tirado. Ni bezonas ĉi tiun stokadon por povi konekti iom da bildstokado de la gastiganto kiel volumo kaj uzi ĝin ene de la ujo.
# 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
Fine, ni uzas la mediovariablon BUILDAH_ISOLATION por diri al la Buildah-ujo komenci kun chroot-izolado defaŭlte. Plia izolado ne estas bezonata ĉi tie, ĉar ni jam laboras en ujo. Por ke Buildah kreu siajn proprajn nomspac-separitajn ujojn, la SYS_ADMIN-privilegio estas postulata, kio postulus malstreĉigi la SELinux kaj SECCOMP-regulojn de la ujo, kiuj konfliktus kun nia aranĝo por konstrui el sekura ujo.
Rulu Buildah en ujo
La Buildah-ujo bildskemo diskutita supre permesas vin flekseble varii kiel tiaj ujoj estas lanĉitaj.
Rapido kontraŭ sekureco
Komputila sekureco ĉiam estas kompromiso inter la rapideco de procezo kaj kiom da protekto estas ĉirkaŭ ĝi. Ĉi tiu deklaro ankaŭ validas dum kunvenado de ujoj, do ĉi-sube ni konsideros eblojn por tia kompromiso.
La ujo-bildo diskutita supre konservos sian stokadon en /var/lib/containers. Tial ni devas munti enhavon al ĉi tiu dosierujo, kaj kiel ni faras tion multe influos la rapidecon konstrui ujajn bildojn.
Ni konsideru tri eblojn.
1-opcio. Se necesas maksimuma sekureco, tiam por ĉiu ujo vi povas krei vian propran dosierujon por ujoj / bildo kaj konekti ĝin al la ujo per volumo-munto. Kaj krome, metu la kuntekstan dosierujon en la ujo mem, en la dosierujon /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
Sekureco. Buildah funkcianta en tia ujo havas maksimuman sekurecon: ĝi ne ricevas iujn ajn radikajn privilegiojn laŭ kapabloj, kaj ĉiuj limigoj de SECOMP kaj SELinux validas por ĝi.Tia ujo eĉ povas esti rulita kun izolado de Uzantnomspaco aldonante opcion kiel --uidmap 0:100000:10000.
Rendimento. Sed la agado ĉi tie estas minimuma, ĉar ajnaj bildoj de kontenaj registroj estas kopiitaj al la gastiganto ĉiufoje, kaj kaŝmemoro ne funkcias de la vorto "neniel". Kiam ĝi finas sian laboron, la Buildah-ujo devas sendi la bildon al la registro kaj detrui la enhavon sur la gastiganto. La venontan fojon kiam la ujo-bildo estos konstruita, ĝi devos esti elŝutita denove el la registro, ĉar nenio restos sur la gastiganto ĝis tiu tempo.
2-opcio. Se vi bezonas Docker-nivelan agadon, vi povas munti la ujon/stokadon de la gastiganto rekte en la ujon.
# 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
Sekureco. Ĉi tiu estas la malplej sekura maniero konstrui ujojn, ĉar ĝi permesas al la ujo modifi la stokadon sur la gastiganto kaj eble povus gliti malican bildon en Podman aŭ CRI-O. Krome, vi devos malŝalti SELinux-disigon por ke la procezoj en la Buildah-ujo povu interagi kun la deponejo sur la gastiganto. Notu, ke ĉi tiu opcio ankoraŭ estas pli bona ol Docker-ingo, ĉar la ujo estas blokita de la ceteraj sekurecaj funkcioj kaj ne povas simple preni kaj ruli ajnan ujon sur la gastiganto.
Rendimento. Ĉi tie ĝi estas maksimuma, ĉar kaŝmemoro estas plene implikita. Se Podman aŭ CRI-O jam elŝutis la deziratan bildon al la gastiganto, tiam la Buildah-procezo ene de la ujo ne devos elŝuti ĝin denove, kaj postaj konstruoj bazitaj sur ĉi tiu bildo ankaŭ povos preni la necesan el la kaŝmemoro. .
3-opcio. La esenco de ĉi tiu metodo estas kombini plurajn bildojn en unu projekton kun komuna dosierujo por ujbildoj.
# 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
En ĉi tiu ekzemplo, ni ne forigas la projektan dosierujon (/var/lib/project3) inter kuroj, do ĉiuj postaj konstruoj ene de la projekto utiligas kaŝmemoron.
Sekureco. Io inter ebloj 1 kaj 2. Unuflanke, ujoj ne havas aliron al enhavo sur la gastiganto kaj, sekve, ne povas gliti ion malbonan en la bildstokadon Podman / CRI-O. Aliflanke, ene de sia propra projekto, ujo povas malhelpi la muntadon de aliaj ujoj.
Rendimento. Ĉi tie ĝi estas pli malbona ol uzi komunan kaŝmemoron ĉe la gastiga nivelo, ĉar vi ne povas uzi bildojn, kiuj jam estis elŝutitaj per Podman / CRI-O. Tamen, post kiam Buildah elŝutis la bildon, tiu bildo povas esti uzata en iuj postaj konstruoj ene de la projekto.
Plia stokado
У ekzistas tiel bonega afero kiel pliaj vendejoj (pliaj vendejoj), dank'al kiu, kiam oni ekfunkciigas kaj konstruas ujojn, ujmotoroj povas uzi eksterajn bildbutikojn en nurlegebla reĝimo. Fakte, vi povas aldoni unu aŭ plurajn nurlegeblajn stokaĵojn al la storage.conf dosiero, tiel ke kiam la ujo komenciĝas, la ujo-motoro serĉos la deziratan bildon en ili. Krome, ĝi elŝutos la bildon el la registro nur se ĝi ne trovas ĝin en iu el ĉi tiuj stokejoj. La ujo-motoro nur povos skribi al skribebla stokado...
Se ni rulumu supren kaj rigardas la Dockerfile, kiun ni uzas por konstrui la bildon quay.io/buildah/stable, estas linioj kiel ĉi tio:
# 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
Sur la unua linio, ni modifas /etc/containers/storage.conf ene de la ujo-bildo, dirante al la stokada pelilo uzi "additionalimagestores" en la /var/lib/shared dosierujo. Kaj en la sekva linio, ni kreas komunan dosierujon kaj aldonas kelkajn ŝlosildosierojn por ke ne estu misuzo de ujoj / stokado. Esence, ni nur kreas malplenan ujan bildvendejon.
Se vi muntas ujojn/stoki nivelon super ĉi tiu dosierujo, Buildah povos uzi la bildojn.
Nun ni revenu al Opcio 2 diskutita supre, kiam la Buildah-ujo povas legi kaj skribi al ujoj / vendejo en gastigantoj kaj, sekve, havas maksimuman rendimenton pro bilda kaŝmemoro ĉe la Podman / CRI-O-nivelo, sed donas minimumon de sekureco, ĉar ĝi povas skribi rekte en stokado. Kaj nun ni ŝraŭbos plian stokadon ĉi tie kaj ricevos la plej bonan el ambaŭ mondoj.
# 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
Notu ke la gastiganto /var/lib/containers/storage estas muntita al /var/lib/shared ene de la ujo en nurlegebla reĝimo. Tial, laborante en ujo, Buildah povas uzi iujn ajn bildojn, kiuj jam estis elŝutitaj per Podman / CRI-O (saluton, rapideco), sed povas nur skribi al sia propra stokado (saluton, sekureco). Rimarku ankaŭ, ke tio estas farita sen malŝalti SELinux-disigon por la ujo.
Grava nuance
Sub neniuj cirkonstancoj iuj bildoj estu forigitaj el la subesta deponejo. Alie, la Buildah-ujo povas kraŝi.
Kaj tio ne estas ĉiuj avantaĝoj.
La eblecoj por plia stokado ne estas limigitaj al la supra scenaro. Ekzemple, vi povas meti ĉiujn ujajn bildojn en komuna retstokado kaj doni aliron al ĝi al ĉiuj Buildah ujoj. Ni diru, ke ni havas centojn da bildoj, kiujn nia CI/CD-sistemo regule uzas por konstrui enhavigitajn bildojn. Ni koncentras ĉiujn ĉi tiujn bildojn sur ununura stokado-gastiganto kaj tiam, uzante la preferatajn retajn stokad ilojn (NFS, Gluster, Ceph, iSCSI, S3 ...), dividas ĉi tiun stokadon kun ĉiuj Buildah aŭ Kubernetes nodoj.
Nun sufiĉas munti ĉi tiun retan stokadon en la Buildah-ujon sur /var/lib/shared kaj jen - Buildah-ujo tute ne devas elŝuti bildojn per pull. Tiel, ni forĵetas la antaŭloĝantan fazon kaj tuj pretas elruli la ujojn.
Kaj kompreneble, ĉi tio povas esti uzata ene de viva Kubernetes-sistemo aŭ kontenera infrastrukturo por lanĉi kaj funkciigi ujojn ie ajn sen ia bildo-tiro. Plie, kiam ujo-registro ricevas puŝpeton por alŝuti ĝisdatigitan bildon al ĝi, ĝi povas aŭtomate sendi ĉi tiun bildon al komuna retstokado, kie ĝi estas tuj disponebla por ĉiuj nodoj.
Ujbildoj foje povas esti multaj gigabajtoj en grandeco. La funkcieco de pliaj stokaĵoj forigas la bezonon kloni tiajn bildojn per nodoj kaj faras la lanĉon de ujoj preskaŭ tuja.
Krome, ni nuntempe laboras pri nova tegaĵo de volumo muntadoj, kiu faros konstrui ujojn eĉ pli rapide.
konkludo
Ruli Buildah en ujo en medio Kubernetes/CRI-O, Podman, aŭ eĉ Docker estas sufiĉe ebla, kaj ĝi estas simpla kaj multe pli sekura ol uzi docker.socket. Ni multe pliigis la flekseblecon labori kun bildoj, kaj nun vi povas ruli ilin diversmaniere por la plej bona ekvilibro inter sekureco kaj rendimento.
La funkcieco de pliaj stokoj permesas vin akceli aŭ eĉ tute forigi la elŝuton de bildoj al la nodoj.
fonto: www.habr.com