Ano ang kagandahan ng pag-decoupling ng runtime ng container sa magkakahiwalay na bahagi ng tooling? Sa partikular, ang mga tool na ito ay maaaring magsimulang pagsamahin upang maprotektahan nila ang isa't isa.
Maraming mga tao ang naaakit sa ideya ng pagbuo ng mga containerized na imahe ng OCI sa loob o katulad na sistema. Sabihin nating mayroon kaming CI/CD na patuloy na nangongolekta ng mga larawan, pagkatapos ay isang katulad Ang /Kubernetes ay magiging kapaki-pakinabang sa mga tuntunin ng pagbalanse ng pag-load sa panahon ng mga build. Hanggang kamakailan lamang, karamihan sa mga tao ay nagbigay lang ng access sa mga container sa isang Docker socket at pinahintulutan silang patakbuhin ang docker build command. na ito ay napaka-insecure, sa katunayan, ito ay mas masahol pa kaysa sa pagbibigay ng walang password na ugat o sudo.
Kaya naman patuloy na sinusubukan ng mga tao na patakbuhin ang Buildah sa isang lalagyan. Sa madaling salita, lumikha kami kung paano, sa aming opinyon, ay pinakamahusay na patakbuhin ang Buildah sa loob ng isang lalagyan, at i-post ang kaukulang mga larawan sa . Magsimula na tayo...
pag-aayos
Ang mga larawang ito ay binuo mula sa Dockerfiles, na makikita sa Buildah repository sa folder .
Dito natin titingnan .
# 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
Sa halip na OverlayFS, na ipinatupad sa antas ng kernel ng host ng Linux, ginagamit namin ang programa sa loob ng lalagyan , dahil sa kasalukuyan ang OverlayFS ay maaari lamang i-mount kung bibigyan mo ito ng mga pahintulot ng SYS_ADMIN gamit ang mga kakayahan ng Linux. At gusto naming patakbuhin ang aming mga lalagyan ng Buildah nang walang anumang mga pribilehiyo sa ugat. Ang fuse-overlay ay gumagana nang mabilis at may mas mahusay na pagganap kaysa sa VFS storage driver. Pakitandaan na kapag nagpapatakbo ng container ng Buildah na gumagamit ng Fuse, dapat mong ibigay ang /dev/fuse device.
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
Susunod na lumikha kami ng isang direktoryo para sa karagdagang imbakan. sumusuporta sa konsepto ng pagkonekta ng mga karagdagang read-only na tindahan ng imahe. Halimbawa, maaari mong i-configure ang isang overlay na lugar ng imbakan sa isang makina, at pagkatapos ay gamitin ang NFS upang i-mount ang storage na ito sa isa pang makina at gumamit ng mga larawan mula rito nang hindi nagda-download sa pamamagitan ng pull. Kailangan namin ang storage na ito upang maikonekta ang ilang storage ng imahe mula sa host bilang volume at magamit ito sa loob ng container.
# 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
Panghuli, sa pamamagitan ng paggamit ng BUILDAH_ISOLATION environment variable, sinasabi namin sa Buildah container na tumakbo gamit ang chroot isolation bilang default. Hindi kinakailangan ang karagdagang pagkakabukod dito, dahil nagtatrabaho na kami sa isang lalagyan. Upang makagawa ang Buildah ng sarili nitong mga container na pinaghihiwalay ng namespace, kinakailangan ang pribilehiyo ng SYS_ADMIN, na mangangailangan ng pagrerelaks sa mga panuntunan ng SELinux at SECCOMP ng container, na salungat sa aming kagustuhan na bumuo mula sa isang secure na container.
Pagpapatakbo ng Buildah sa loob ng isang lalagyan
Ang diagram ng imahe ng lalagyan ng Buildah na tinalakay sa itaas ay nagbibigay-daan sa iyong flexible na pag-iba-iba ang mga paraan ng paglulunsad ng mga naturang container.
Bilis laban sa kaligtasan
Ang seguridad ng computer ay palaging isang kompromiso sa pagitan ng bilis ng proseso at kung gaano kalaking proteksyon ang nakabalot dito. Totoo rin ang pahayag na ito kapag nag-iipon ng mga lalagyan, kaya sa ibaba ay isasaalang-alang namin ang mga opsyon para sa naturang kompromiso.
Ang imahe ng lalagyan na tinalakay sa itaas ay pananatilihin ang imbakan nito sa /var/lib/containers. Samakatuwid, kailangan naming i-mount ang nilalaman sa folder na ito, at kung paano namin ito gagawin ay lubos na makakaapekto sa bilis ng pagbuo ng mga imahe ng lalagyan.
Isaalang-alang natin ang tatlong pagpipilian.
Pagpipilian 1. Kung kinakailangan ang pinakamataas na seguridad, pagkatapos ay para sa bawat lalagyan maaari kang lumikha ng iyong sariling folder para sa mga lalagyan/larawan at ikonekta ito sa lalagyan sa pamamagitan ng volume-mount. At bukod pa, ilagay ang direktoryo ng konteksto sa mismong lalagyan, sa folder na /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
Seguridad. Ang Buildah na tumatakbo sa naturang container ay may pinakamataas na seguridad: hindi ito binibigyan ng anumang root privilege gamit ang mga kakayahan, at lahat ng SECOMP at SELinux na mga paghihigpit ay nalalapat dito. Ang naturang container ay maaaring patakbuhin nang may User Namespace isolation sa pamamagitan ng pagdaragdag ng opsyon tulad ng βuidmap 0: 100000:10000.
Pagganap Ngunit ang pagganap dito ay minimal, dahil ang anumang mga imahe mula sa mga rehistro ng container ay kinokopya sa host sa bawat oras, at ang pag-cache ay hindi gumagana. Kapag kinukumpleto ang gawain nito, dapat ipadala ng container ng Buildah ang larawan sa registry at sirain ang nilalaman sa host. Sa susunod na pagkakataong mabuo ang imahe ng lalagyan, kakailanganin itong i-download muli mula sa pagpapatala, dahil sa oras na iyon ay wala nang matitira sa host.
Pagpipilian 2. Kung kailangan mo ng pagganap sa antas ng Docker, maaari mong i-mount ang host container/storage nang direkta sa container.
# 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
Seguridad. Ito ang hindi gaanong secure na paraan upang bumuo ng mga container dahil pinapayagan nito ang container na baguhin ang host storage at posibleng magbigay ng masasamang larawan sa Podman o CRI-O. Bilang karagdagan, kakailanganin mong i-disable ang paghihiwalay ng SELinux upang ang mga proseso sa container ng Buildah ay maaaring makipag-ugnayan sa storage sa host. Tandaan na ang opsyon na ito ay mas mahusay pa rin kaysa sa isang Docker socket dahil ang container ay naka-lock down sa pamamagitan ng natitirang mga tampok ng seguridad at hindi maaaring magpatakbo ng isang container sa host.
Pagganap Narito ito ay maximum, dahil ang pag-cache ay ganap na ginagamit. Kung na-download na ng Podman o CRI-O ang kinakailangang larawan sa host, hindi na ito kailangang i-download muli ng proseso ng Buildah sa loob ng container, at makukuha rin ng mga kasunod na build batay sa larawang ito ang kailangan nila mula sa cache .
Pagpipilian 3. Ang kakanyahan ng pamamaraang ito ay upang pagsamahin ang ilang mga imahe sa isang proyekto na may isang karaniwang folder para sa mga imahe ng lalagyan.
# 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
Sa halimbawang ito, hindi namin tinatanggal ang folder ng proyekto (/var/lib/project3) sa pagitan ng mga pagtakbo, kaya lahat ng kasunod na build sa loob ng proyekto ay nakikinabang sa pag-cache.
Seguridad. Isang bagay sa pagitan ng mga opsyon 1 at 2. Sa isang banda, ang mga container ay walang access sa nilalaman sa host at, nang naaayon, ay hindi maaaring makalusot ng isang bagay na hindi maganda sa Podman/CRI-O na imbakan ng imahe. Sa kabilang banda, bilang bahagi ng disenyo nito, ang isang lalagyan ay maaaring makagambala sa pagpupulong ng iba pang mga lalagyan.
Pagganap Narito ito ay mas masahol pa kaysa kapag gumagamit ng isang nakabahaging cache sa antas ng host, dahil hindi mo magagamit ang mga larawang na-download na gamit ang Podman/CRI-O. Gayunpaman, kapag na-download na ng Buildah ang larawan, maaaring gamitin ang larawan sa anumang kasunod na mga build sa loob ng proyekto.
Karagdagang imbakan
Π£ Mayroong isang cool na bagay tulad ng mga karagdagang tindahan (mga karagdagang tindahan), salamat sa kung saan kapag naglulunsad at nagtatayo ng mga lalagyan, ang mga makina ng lalagyan ay maaaring gumamit ng mga panlabas na tindahan ng imahe sa read-only na overlay na mode. Sa pangkalahatan, maaari kang magdagdag ng isa o higit pang mga read-only na storage sa storage.conf file upang kapag sinimulan mo ang container, hinahanap ng container engine ang gustong larawan sa mga iyon. Bukod dito, ida-download lamang nito ang imahe mula sa registry kung hindi ito mahahanap sa alinman sa mga storage na ito. Makakasulat lang ang container engine sa naisusulat na storage...
Kung mag-scroll ka pataas at titingnan ang Dockerfile na ginagamit namin upang buuin ang image quay.io/buildah/stable, may mga linyang tulad nito:
# 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
Sa unang linya, binago namin ang /etc/containers/storage.conf sa loob ng imahe ng container, na sinasabi sa driver ng storage na gumamit ng βadditionalimagestoresβ sa /var/lib/shared folder. At sa susunod na linya lumikha kami ng isang nakabahaging folder at magdagdag ng ilang mga lock file upang walang pang-aabuso mula sa mga lalagyan/imbakan. Sa totoo lang, gumagawa lang kami ng walang laman na tindahan ng larawan ng lalagyan.
Kung mag-mount ka ng mga container/storage sa mas mataas na antas kaysa sa folder na ito, magagamit ng Buildah ang mga larawan.
Ngayon, bumalik tayo sa Opsyon 2 na tinalakay sa itaas, kapag ang lalagyan ng Buildah ay maaaring magbasa at sumulat sa mga lalagyan/mag-imbak sa mga host at, nang naaayon, ay may pinakamataas na pagganap dahil sa pag-cache ng mga larawan sa antas ng Podman/CRI-O, ngunit nagbibigay ng isang minimum na seguridad mula noong maaari itong direktang sumulat sa imbakan. Ngayon, magdagdag tayo ng karagdagang storage dito at makuha ang pinakamahusay sa parehong mundo.
# 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
Tandaan na ang /var/lib/containers/storage ng host ay naka-mount sa /var/lib/shared sa loob ng container sa read-only na mode. Samakatuwid, nagtatrabaho sa isang lalagyan, maaaring gumamit ang Buildah ng anumang mga larawang na-download dati gamit ang Podman/CRI-O (hello, bilis), ngunit maaari lamang sumulat sa sarili nitong storage (hello, security). Tandaan din na ginagawa ito nang hindi pinapagana ang paghihiwalay ng SELinux para sa lalagyan.
Mahalagang pananalig
Sa anumang pagkakataon dapat mong tanggalin ang anumang mga larawan mula sa pinagbabatayan na imbakan. Kung hindi, maaaring mag-crash ang container ng Buildah.
At ito ay hindi lahat ng mga pakinabang
Ang mga posibilidad ng karagdagang storage ay hindi limitado sa senaryo sa itaas. Halimbawa, maaari mong ilagay ang lahat ng mga larawan ng lalagyan sa isang nakabahaging imbakan ng network at bigyan ito ng access sa lahat ng mga lalagyan ng Buildah. Sabihin nating mayroon kaming daan-daang larawan na regular na ginagamit ng aming CI/CD system upang bumuo ng mga larawan ng lalagyan. Itinuon namin ang lahat ng larawang ito sa isang storage host at pagkatapos, gamit ang mga gustong tool sa storage ng network (NFS, Gluster, Ceph, ISCSI, S3...), binubuksan namin ang pangkalahatang access sa storage na ito sa lahat ng Buildah o Kubernetes node.
Ngayon ay sapat na upang i-mount ang storage ng network na ito sa container ng Buildah sa /var/lib/shared at iyon na - hindi na kailangang mag-download ng mga larawan sa pamamagitan ng pull ang mga container ng Buildah. Kaya, itinatapon namin ang yugto ng pre-populasyon at agad na handa na ilunsad ang mga lalagyan.
At siyempre, magagamit ito sa loob ng isang live na Kubernetes system o imprastraktura ng container para maglunsad at magpatakbo ng mga container kahit saan nang walang anumang pull download ng mga larawan. Bukod dito, ang container registry, na tumatanggap ng push request na mag-upload ng na-update na larawan dito, ay maaaring awtomatikong ipadala ang larawang ito sa isang shared network storage, kung saan agad itong nagiging available sa lahat ng node.
Ang mga imahe ng container ay maaaring umabot minsan sa maraming gigabytes ang laki. Nagbibigay-daan sa iyo ang functionality ng karagdagang storage na maiwasan ang pag-clone ng mga naturang larawan sa mga node at ginagawang halos madalian ang paglulunsad ng mga container.
Bilang karagdagan, kasalukuyan kaming gumagawa ng bagong feature na tinatawag na overlay volume mounts, na magpapabilis ng paggawa ng mga container.
Konklusyon
Ang pagpapatakbo ng Buildah sa loob ng isang container sa Kubernetes/CRI-O, Podman, o kahit na Docker ay magagawa, simple, at mas secure kaysa sa paggamit ng docker.socket. Lubos naming pinataas ang kakayahang umangkop sa pagtatrabaho sa mga larawan, upang mapatakbo mo ang mga ito sa iba't ibang paraan upang ma-optimize ang balanse sa pagitan ng seguridad at pagganap.
Ang pag-andar ng karagdagang imbakan ay nagbibigay-daan sa iyo upang pabilisin o kahit na ganap na alisin ang pag-download ng mga imahe sa mga node.
Pinagmulan: www.habr.com