Препораки за водење на Buildah во контејнер

Која е убавината на раздвојувањето на времето на работа на контејнерот во посебни компоненти за алати? Особено, овие алатки може да почнат да се комбинираат за да се заштитат едни со други.

Многу луѓе се привлечени од идејата за градење на контејнеризирани OCI слики внатре Кубернети или сличен систем. Да речеме дека имаме CI/CD што постојано собира слики, а потоа нешто слично Red Hat OpenShift/Kubernetes би бил доста корисен во однос на балансирање на товарот за време на градбите. До неодамна, повеќето луѓе едноставно им даваа на контејнерите пристап до приклучокот за Docker и им дозволуваа да ја извршуваат командата за изградба на docker. Пред неколку години покажавмедека ова е многу несигурно, всушност, тоа е уште полошо од давање root или sudo без лозинка.

Затоа луѓето постојано се обидуваат да ја водат Билдах во контејнер. Накратко, создадовме пример како, според наше мислење, е најдобро да се пушти Buildah во контејнер и да се објавени соодветните слики на quay.io/buildah. Ајде да почнеме...

прилагодување

Овие слики се изградени од Dockerfiles, кои може да се најдат во складиштето Buildah во папката градење.
Овде ќе разгледаме стабилна верзија на Dockerfile.

# 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, имплементиран на ниво на кернелот на домаќинот Linux, ја користиме програмата во контејнерот осигурувач-прекривка, бидејќи во моментов OverlayFS може да се монтира само ако му дадете SYS_ADMIN дозволи користејќи ги можностите на Linux. И ние сакаме да ги извршуваме нашите контејнери Buildah без никакви права за root. Преклопувањето со осигурувачи работи доста брзо и има подобри перформанси од драјверот за складирање VFS. Имајте предвид дека кога користите контејнер Buildah што користи Fuse, мора да го обезбедите уредот /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

Следно, создаваме директориум за дополнително складирање. Контејнер/складирање го поддржува концептот за поврзување дополнителни продавници за слики само за читање. На пример, можете да конфигурирате област за складирање со преклопување на една машина, а потоа да користите NFS за да ја монтирате оваа меморија на друга машина и да користите слики од неа без преземање преку повлекување. Ни треба ова складирање за да можеме да поврземе складирање на слики од домаќинот како волумен и да го користиме внатре во контејнерот.

# 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

Конечно, со користење на променливата на околината BUILDAH_ISOLATION, му кажуваме на контејнерот Buildah да работи со изолација на chroot стандардно. Овде не е потребна дополнителна изолација, бидејќи веќе работиме во контејнер. За да може Buildah да создаде свои контејнери одвоени со именски простор, потребна е привилегија SYS_ADMIN, што бара релаксирање на правилата SELinux и SECCOMP на контејнерот, што е спротивно на нашата претпочитање да се гради од безбеден контејнер.

Вклучување на Buildah во контејнер

Дијаграмот за слика на контејнерот Buildah, дискутиран погоре, ви овозможува флексибилно да ги менувате методите за лансирање на таквите контејнери.

Брзина наспроти безбедност

Компјутерската безбедност е секогаш компромис помеѓу брзината на процесот и тоа колку заштита е обвиткана околу него. Оваа изјава е вистинита и при составување контејнери, па подолу ќе ги разгледаме опциите за таков компромис.

Сликата на контејнерот дискутирана погоре ќе го задржи своето складирање во /var/lib/containers. Затоа, треба да ја монтираме содржината во оваа папка, а начинот на кој го правиме тоа многу ќе влијае на брзината на градење слики од контејнери.

Ајде да разгледаме три опции.

Опција 1. Доколку е потребна максимална безбедност, тогаш за секој контејнер можете да креирате сопствена папка за контејнери/слика и да ја поврзете со контејнерот преку монтажа за волумен. Покрај тоа, поставете го контекстуалниот директориум во самиот контејнер, во папката /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

Безбедност. Buildah што работи во таков контејнер има максимална безбедност: не му се дадени никакви привилегии за root со користење на способности и сите ограничувања на SECOMP и SELinux важат за него. Таквиот контејнер може да се работи дури и со изолација на User Namespace со додавање на опција како —uidmap 0: 100000:10000.

Изведба. Но, перформансите овде се минимални, бидејќи сите слики од регистрите на контејнери се копираат на домаќинот секој пат, а кеширањето воопшто не функционира. Кога ја завршува својата работа, контејнерот Buildah мора да ја испрати сликата во регистарот и да ја уништи содржината на домаќинот. Следниот пат кога ќе се изгради сликата на контејнерот, ќе треба повторно да се преземе од регистарот, бидејќи дотогаш нема да остане ништо на домаќинот.

Опција 2. Ако ви треба изведба на ниво на Docker, можете да го монтирате контејнерот/складирањето домаќин директно во контејнерот.

# 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

Безбедност. Ова е најмалку безбедниот начин за градење контејнери бидејќи му овозможува на контејнерот да го модифицира складиштето на домаќинот и потенцијално може да нахрани Podman или CRI-O со злонамерна слика. Дополнително, ќе треба да го оневозможите раздвојувањето на SELinux за процесите во контејнерот Buildah да можат да комуницираат со складиштето на домаќинот. Забележете дека оваа опција е сепак подобра од приклучокот Docker бидејќи контејнерот е заклучен поради преостанатите безбедносни карактеристики и не може едноставно да работи контејнер на домаќинот.

Изведба. Овде е максимум, бидејќи кеширањето е целосно искористено. Ако Podman или CRI-O веќе ја преземале потребната слика на домаќинот, тогаш процесот Buildah во контејнерот нема да мора повторно да ја презема, а следните изданија базирани на оваа слика исто така ќе можат да го земат она што им треба од кешот .

Опција 3. Суштината на овој метод е да се комбинираат неколку слики во еден проект со заедничка папка за слики од контејнери.

# 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

Во овој пример, не ја бришеме проектната папка (/var/lib/project3) помеѓу стапките, така што сите последователни градби во рамките на проектот имаат корист од кеширањето.

Безбедност. Нешто помеѓу опциите 1 и 2. Од една страна, контејнерите немаат пристап до содржината на домаќинот и, соодветно, не можат да внесат нешто лошо во складиштето на слики Podman/CRI-O. Од друга страна, како дел од неговиот дизајн, контејнер може да се меша со склопувањето на други контејнери.

Изведба. Овде е полошо отколку кога користите споделен кеш на ниво на домаќин, бидејќи не можете да користите слики што веќе се преземени со помош на Podman/CRI-O. Меѓутоа, штом Buildah ќе ја преземе сликата, сликата може да се користи во сите наредни изданија во рамките на проектот.

Дополнително складирање

У контејнери/складирање Има толку кул работа како дополнителни продавници (дополнителни продавници), благодарение на што при лансирање и градење контејнери, моторите за контејнери можат да користат надворешни складишта за слики во режим на преклопување само за читање. Во суштина, можете да додадете еден или повеќе складишта само за читање во датотеката storage.conf, така што кога ќе го стартувате контејнерот, моторот на контејнерот ја бара саканата слика во нив. Покрај тоа, ќе ја преземе сликата од регистарот само ако не ја најде во ниту една од овие складишта. Моторот на контејнерот ќе може да пишува само во складиштето што може да се запише...

Ако дојдете нагоре и погледнете во Dockerfile што го користиме за да ја изградиме сликата quay.io/buildah/stable, има линии како ова:

# 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

Во првата линија, го менуваме /etc/containers/storage.conf внатре во сликата на контејнерот, кажувајќи му на двигателот за складирање да користи „additionalimagestores“ во /var/lib/споделената папка. И во следната линија создаваме споделена папка и додаваме неколку датотеки за заклучување за да нема злоупотреба од контејнери/складирање. Во суштина, ние едноставно создаваме празна продавница за слики од контејнер.

Ако монтирате контејнери/складирање на ниво повисоко од оваа папка, Buildah ќе може да ги користи сликите.

Сега да се вратиме на опцијата 2 што беше дискутирана погоре, кога контејнерот Buildah може да чита и пишува во контејнери/да складира на домаќините и, соодветно, има максимални перформанси поради кеширање слики на ниво Podman/CRI-O, но обезбедува минимум безбедност бидејќи може да пишува директно во складиштето. Сега да додадеме дополнителен простор овде и да го извлечеме најдоброто од двата света.

# 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

Забележете дека /var/lib/containers/storage на домаќинот е монтиран на /var/lib/shared внатре во контејнерот во режим само за читање. Затоа, работејќи во контејнер, Buildah може да ги користи сите слики што претходно биле преземени со помош на Podman/CRI-O (здраво, брзина), но може да пишува само во сопственото складирање (здраво, безбедност). Исто така, имајте предвид дека ова е направено без да се оневозможи одвојувањето на SELinux за контејнерот.

Важна нијанса

Во никој случај не треба да бришете слики од основното складиште. Во спротивно, контејнерот Buildah може да се сруши.

И ова не се сите предности

Можностите за дополнително складирање не се ограничени на горенаведеното сценарио. На пример, можете да ги поставите сите слики од контејнери на заедничко мрежно складирање и да дадете пристап до него до сите контејнери на Buildah. Да речеме дека имаме стотици слики што нашиот CI/CD систем редовно ги користи за да изгради слики од контејнери. Ги концентрираме сите овие слики на еден хост за складирање и потоа, користејќи ги претпочитаните алатки за мрежно складирање (NFS, Gluster, Ceph, ISCSI, S3...), отвораме општ пристап до ова складирање до сите јазли на Buildah или Kubernetes.

Сега е доволно да го монтирате овој мрежен склад во контејнерот Buildah на /var/lib/shared и тоа е сè - контејнерите на Buildah веќе не мора да преземаат слики преку pull. Така, ја исфрламе фазата на предпопулација и веднаш сме подготвени да ги тркаламе контејнерите.

И, се разбира, ова може да се користи во живиот систем на Kubernetes или контејнерска инфраструктура за лансирање и пуштање контејнери насекаде без никакво влечно преземање слики. Покрај тоа, регистарот на контејнери, добивајќи барање за притискање да постави ажурирана слика на него, може автоматски да ја испрати оваа слика до заедничко мрежно складирање, каде што веднаш станува достапна за сите јазли.

Сликите на контејнерите понекогаш може да достигнат многу гигабајти во големина. Функционалноста на дополнителното складирање ви овозможува да избегнете клонирање на такви слики низ јазлите и го прави лансирањето на контејнерите речиси моментално.

Дополнително, моментално работиме на нова функција наречена монтирања за јачина на преклоп, која ќе го направи изградбата на контејнери уште побрзо.

Заклучок

Работењето на Buildah во контејнер во Kubernetes/CRI-O, Podman или дури и Docker е изводливо, едноставно и многу посигурно од користењето на docker.socket. Во голема мера ја зголемивме флексибилноста за работа со слики, за да можете да ги извршувате на различни начини за да го оптимизирате балансот помеѓу безбедноста и перформансите.

Функционалноста на дополнителното складирање ви овозможува да го забрзате, па дури и целосно да го елиминирате преземањето на слики во јазли.

Извор: www.habr.com