Kāds ir konteinera izpildlaika atsaistīšanas atsevišķos instrumentu komponentos skaistums? Jo īpaši šos rīkus var sākt kombinēt, lai tie aizsargātu viens otru.

Daudzus cilvēkus piesaista ideja par konteineru OCI attēlu izveidi vai līdzīga sistēma. Pieņemsim, ka mums ir CI/CD, kas pastāvīgi apkopo attēlus, pēc tam kaut ko līdzīgu /Kubernetes būtu diezgan noderīgas slodzes līdzsvarošanas ziņā būvēšanas laikā. Vēl nesen lielākā daļa cilvēku vienkārši piešķīra konteineriem piekļuvi Docker ligzdai un ļāva tiem palaist docker build komandu. ka tas ir ļoti nedroši, patiesībā tas ir vēl sliktāk nekā bezparoles root vai sudo piešķiršana.
Tāpēc cilvēki pastāvīgi cenšas palaist Buildah konteinerā. Īsāk sakot, mēs izveidojām kā, mūsuprāt, vislabāk ir palaist Buildah konteinerā, un ievietoja atbilstošos attēlus . Sāksim...
koriģēšana
Šie attēli ir veidoti no Dockerfiles, ko var atrast mapē esošajā Buildah repozitorijā .
Šeit mēs apsvērsim .
# 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 vietā, kas ieviesta resursdatora Linux kodola līmenī, mēs izmantojam programmu konteinerā , jo pašlaik OverlayFS var pievienot tikai tad, ja piešķirat tam SYS_ADMIN atļaujas, izmantojot Linux iespējas. Un mēs vēlamies palaist savus Buildah konteinerus bez root tiesībām. Drošinātāja pārklājums darbojas diezgan ātri, un tam ir labāka veiktspēja nekā VFS krātuves draiverim. Lūdzu, ņemiet vērā, ka, palaižot Buildah konteineru, kas izmanto Fuse, jums ir jānorāda /dev/fuse ierīce.
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
Tālāk mēs izveidojam direktoriju papildu glabāšanai. atbalsta papildu tikai lasāmu attēlu veikalu savienošanas koncepciju. Piemēram, varat konfigurēt pārklājuma krātuves apgabalu vienā datorā un pēc tam izmantot NFS, lai uzstādītu šo krātuvi citā datorā un izmantotu attēlus no tās, neveicot lejupielādi. Šī krātuve mums ir nepieciešama, lai varētu pievienot kādu attēlu krātuvi no resursdatora kā sējumu un izmantot to konteinerā.
# 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
Visbeidzot, izmantojot vides mainīgo BUILDAH_ISOLATION, mēs sakām, ka Buildah konteiners pēc noklusējuma darbojas ar chroot izolāciju. Šeit papildu izolācija nav nepieciešama, jo mēs jau strādājam konteinerā. Lai Buildah varētu izveidot savus ar nosaukumvietu atdalītus konteinerus, ir nepieciešama SYS_ADMIN privilēģija, kas prasītu konteinera SELinux un SECCOMP noteikumu atvieglošanu, kas ir pretrunā ar mūsu vēlmi veidot no droša konteinera.
Darbojas Buildah konteinerā
Iepriekš apspriestā Buildah konteinera attēla diagramma ļauj elastīgi mainīt šādu konteineru palaišanas metodes.
Ātrums pret drošību
Datora drošība vienmēr ir kompromiss starp procesa ātrumu un to, cik daudz aizsardzības ir ap to. Šis apgalvojums attiecas arī uz konteineru montāžu, tāpēc tālāk mēs apsvērsim šāda kompromisa iespējas.
Iepriekš apspriestais konteinera attēls saglabās savu krātuvi mapē /var/lib/containers. Tāpēc mums ir jāpievieno saturs šajā mapē, un tas, kā mēs to darīsim, lielā mērā ietekmēs konteinera attēlu veidošanas ātrumu.
Apsvērsim trīs iespējas.
Opcija 1. Ja nepieciešama maksimāla drošība, tad katram konteineram varat izveidot savu konteineru/attēla mapi un savienot to ar konteineru caur volume-mount. Turklāt ievietojiet konteksta direktoriju pašā konteinerā, mapē /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
Drošība. Buildah, kas darbojas šādā konteinerā, ir maksimāla drošība: tai netiek piešķirtas nekādas root tiesības, izmantojot iespējas, un uz to attiecas visi SECOMP un SELinux ierobežojumi. Šādu konteineru var palaist pat ar lietotāja vārdu telpas izolāciju, pievienojot tādu opciju kā —uidmap 0: 100000:10000.
Veiktspēja. Bet veiktspēja šeit ir minimāla, jo visi attēli no konteineru reģistriem katru reizi tiek kopēti uz resursdatoru, un kešatmiņa nedarbojas vispār. Pabeidzot darbu, Buildah konteineram ir jānosūta attēls uz reģistru un jāiznīcina resursdatora saturs. Nākamajā reizē, kad konteinera attēls tiks izveidots, tas būs vēlreiz jālejupielādē no reģistra, jo līdz tam laikam resursdatorā nekas nebūs palicis.
Opcija 2. Ja jums nepieciešama Docker līmeņa veiktspēja, varat uzstādīt resursdatora konteineru/krātuvi tieši konteinerā.
# 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
Drošība. Šis ir nedrošākais konteineru izveides veids, jo tas ļauj konteineram modificēt resursdatora krātuvi un potenciāli var ievadīt Podman vai CRI-O ar ļaunprātīgu attēlu. Turklāt jums būs jāatspējo SELinux atdalīšana, lai procesi Buildah konteinerā varētu mijiedarboties ar resursdatora krātuvi. Ņemiet vērā, ka šī opcija joprojām ir labāka par Docker ligzdu, jo konteineru bloķē atlikušie drošības līdzekļi, un tas nevar vienkārši palaist konteineru resursdatorā.
Veiktspēja. Šeit tas ir maksimālais, jo kešatmiņa tiek pilnībā izmantota. Ja Podman vai CRI-O jau ir lejupielādējuši nepieciešamo attēlu resursdatorā, tad Buildah procesam konteinera iekšienē tas nebūs jālejupielādē vēlreiz, un arī turpmākās uz šī attēla bāzes veidotās versijas varēs paņemt nepieciešamo no kešatmiņas. .
Opcija 3. Šīs metodes būtība ir apvienot vairākus attēlus vienā projektā ar kopēju mapi konteinera attēliem.
# 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
Šajā piemērā mēs nedzēšam projekta mapi (/var/lib/project3) starp palaišanas reizēm, tāpēc visas turpmākās projekta būves gūst labumu no kešatmiņas saglabāšanas.
Drošība. Kaut kas starp 1. un 2. opciju. No vienas puses, konteineriem nav piekļuves resursdatora saturam, un attiecīgi tie nevar ievietot kaut ko sliktu Podman/CRI-O attēlu krātuvē. No otras puses, konteiners savas konstrukcijas ietvaros var traucēt citu konteineru montāžu.
Veiktspēja. Šeit tas ir sliktāk nekā tad, ja resursdatora līmenī izmantojat koplietotu kešatmiņu, jo nevarat izmantot attēlus, kas jau ir lejupielādēti, izmantojot Podman/CRI-O. Tomēr, tiklīdz Buildah ir lejupielādējis attēlu, attēlu var izmantot jebkurā turpmākajā projekta būvniecībā.
Papildu krātuve
У Ir tāda forša lieta kā papildu veikali (papildu veikali), pateicoties kuriem, palaižot un veidojot konteinerus, konteineru dzinēji var izmantot ārējos attēlu veikalus tikai lasāmā pārklājuma režīmā. Būtībā failam storage.conf varat pievienot vienu vai vairākas tikai lasāmas krātuves, lai, palaižot konteineru, konteinera programma tajās meklētu vajadzīgo attēlu. Turklāt tas lejupielādēs attēlu no reģistra tikai tad, ja tas to neatradīs nevienā no šīm krātuvēm. Konteinera dzinējs varēs rakstīt tikai rakstāmā krātuvē...
Ja ritiniet uz augšu un skatāties uz Dockerfile, ko izmantojam, lai izveidotu attēlu quay.io/buildah/stable, ir šādas rindas:
# 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
Pirmajā rindā mēs modificējam /etc/containers/storage.conf konteinera attēlā, liekot krātuves draiverim izmantot “additionalimagestores” mapē /var/lib/shared. Un nākamajā rindā mēs izveidojam koplietotu mapi un pievienojam pāris bloķēšanas failus, lai konteineri / krātuves netiktu ļaunprātīgi izmantoti. Būtībā mēs vienkārši izveidojam tukšu konteinera attēlu veikalu.
Ja uzstādīsit konteinerus/krātuvi augstāk par šo mapi, Buildah varēs izmantot attēlus.
Tagad atgriezīsimies pie iepriekš apspriestās 2. iespējas, kad Buildah konteiners var lasīt un rakstīt konteineros/uzglabāt resursdatoros un attiecīgi tam ir maksimāla veiktspēja, pateicoties attēlu saglabāšanai kešatmiņā Podman/CRI-O līmenī, taču tas nodrošina minimālu drošību, jo tas var rakstīt tieši krātuvē. Tagad pievienosim šeit papildu krātuvi un iegūsim labāko no abām pasaulēm.
# 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
Ņemiet vērā, ka resursdatora /var/lib/containers/storage ir pievienots mapē /var/lib/shared konteinera iekšpusē tikai lasīšanas režīmā. Tāpēc, strādājot konteinerā, Buildah var izmantot visus attēlus, kas iepriekš tika lejupielādēti, izmantojot Podman/CRI-O (sveiki, ātrums), bet var rakstīt tikai savā krātuvē (sveiki, drošība). Ņemiet vērā arī to, ka tas tiek darīts, neatspējojot konteinera SELinux atdalīšanu.
Svarīgs nianses
Nekādā gadījumā nedrīkst dzēst attēlus no pamatā esošās krātuves. Pretējā gadījumā Buildah konteiners var avarēt.
Un tās nav visas priekšrocības
Papildu krātuves iespējas neaprobežojas tikai ar iepriekš minēto scenāriju. Piemēram, varat ievietot visus konteinera attēlus koplietotā tīkla krātuvē un piešķirt tai piekļuvi visiem Buildah konteineriem. Pieņemsim, ka mums ir simtiem attēlu, ko mūsu CI/CD sistēma regulāri izmanto, lai izveidotu konteinera attēlus. Mēs koncentrējam visus šos attēlus vienā krātuves resursdatorā un pēc tam, izmantojot vēlamos tīkla krātuves rīkus (NFS, Gluster, Ceph, ISCSI, S3...), mēs atveram vispārēju piekļuvi šai krātuvei visiem Buildah vai Kubernetes mezgliem.
Tagad pietiek uzstādīt šo tīkla krātuvi Buildah konteinerā vietnē /var/lib/shared, un viss — Buildah konteineriem vairs nav jālejupielādē attēli, izmantojot vilkšanu. Tādējādi mēs izmetam pirmsapdzīvotības fāzi un nekavējoties esam gatavi izritināt konteinerus.
Un, protams, to var izmantot dzīvā Kubernetes sistēmā vai konteineru infrastruktūrā, lai palaistu un palaistu konteinerus jebkur bez jebkādas attēlu lejupielādes. Turklāt konteinera reģistrs, saņemot push pieprasījumu augšupielādēt tajā atjauninātu attēlu, var automātiski nosūtīt šo attēlu uz koplietojamo tīkla krātuvi, kur tas uzreiz kļūst pieejams visiem mezgliem.
Konteinera attēlu izmērs dažkārt var sasniegt vairākus gigabaitus. Papildu krātuves funkcionalitāte ļauj izvairīties no šādu attēlu klonēšanas vairākos mezglos un padara konteineru palaišanu gandrīz acumirklī.
Turklāt mēs pašlaik strādājam pie jaunas funkcijas, ko sauc par pārklājuma tilpuma stiprinājumiem, kas padarīs konteineru būvniecību vēl ātrāku.
Secinājums
Buildah palaišana konteinerā programmā Kubernetes/CRI-O, Podman vai pat Docker ir iespējama, vienkārša un daudz drošāka nekā docker.socket izmantošana. Mēs esam ievērojami palielinājuši elastību darbā ar attēliem, lai jūs varētu tos palaist dažādos veidos, lai optimizētu līdzsvaru starp drošību un veiktspēju.
Papildu krātuves funkcionalitāte ļauj paātrināt vai pat pilnībā novērst attēlu lejupielādi mezglos.
Avots: www.habr.com
