ProHoster > Blogs > Administrācija > Ieteikumi Buildah palaiŔanai konteinerā

Ieteikumi Buildah palaiŔanai konteinerā

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.

Ieteikumi Buildah palaiŔanai konteinerā

Daudzus cilvēkus piesaista ideja par konteineru OCI attēlu izveidi Kubernetes 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 Red Hat OpenShift/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. Pirms vairākiem gadiem mēs parādÄ«jāmka 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 piemērs kā, mÅ«suprāt, vislabāk ir palaist Buildah konteinerā, un ievietoja atbilstoÅ”os attēlus quay.io/buildah. Sāksim...

koriģēŔana

Å ie attēli ir veidoti no Dockerfiles, ko var atrast mapē esoÅ”ajā Buildah repozitorijā veidot attēlu.
Šeit mēs apsvērsim stabila Dockerfile versija.

# 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ā droÅ”inātājs-pārklājums, 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. Konteiners/uzglabāŔana 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

Š£ konteineri/noliktavas 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

Pievieno komentāru