Препоръки за стартиране на Buildah в контейнер

Каква е привлекателността на разделението на средите за изпълнение на контейнерите на отделни инструментални съставки? По-специално, че тези инструменти могат да бъдат комбинирани, за да защитават един друг.

Много хора се привлекат от идеята да изградят контейнерни OCI-образи в рамките на Kubernetes или подобна система. Да предположим, че имаме CI/CD, което постоянно изгражда образи, тогава нещо подобно Red Hat OpenShift/Kubernetes было бы весьма полезно с точки зрения распределения нагрузки при сборке. До недавних пор большинство людей просто давали контейнерам доступ к Docker-сокету и разрешали выполнять команду docker build. Ние вече преди няколко години показахме, че това е много несигурно, всъщност, това е дори по-лошо от предоставянето на безпаролния root или sudo.

Затова хората постоянно се опитват да стартират Buildah в контейнер. В заключение, създадохме пример как, според нас, е най-добре да стартираме Buildah вътре в контейнера и сме публикували съответните образи на quay.io/buildah. Нека да започнем...

Настройка

Тези образи са изградени от Dockerfiles, които могат да бъдат намерени в репозитория Buildah в папката buildahimage.
Тук ще разгледаме стабилната версия на 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, имплементирана на ниво хост ядро, ние използваме програма fuse-overlay, тъй като в момента OverlayFS може да изпълнява монтиране само ако ѝ се предоставят права SYS_ADMIN чрез Linux capabilities. А ние искаме да стартираме нашите Buildah-контейнери без никакви привилегии на ниво root. Fuse-overlay работи доста бързо и по производителност е по-добър от драйвера за съхранение 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

След това създаваме каталог за допълнителни хранилища. Container/storage поддържа концепцията за свързване на допълнителни хранилища на образи с само-задаване. Например, можете да конфигурирате overlay storage area на една машина и след това да я подмонтирате на друга машина с NFS и да използвате образите от него без изтегляне чрез pull. Това хранилище ни е необходимо, за да можем да свържем хранилище на образи от хоста като том и да го използваме вътре в контейнера.

# 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. Ако е необходима максимална сигурност, за всеки контейнер може да се създаде собствена папка за containers/image и да се свърже с контейнера чрез volume-mount. Освен това, контекстната папка може да се разположи в самия контейнер, в папката /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-привилегии чрез capabilities, и към него се прилагат всички ограничения на 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 изтегли образа, той може да се използва във всякакви последващи изграждания в рамките на проекта.

Допълнителни хранилища

У containers\/storage има нещо страхотно, наречено допълнителни хранилища (additional stores), благодарение на което при стартиране и сборка на контейнери, контейнерните двигатели могат да използват външни хранилища на изображения в режим read-only оверлей. Всъщност, в файла 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 вътре в контейнерния образ, като казваме на storage-драйвера да използва “additionalimagestores” в папката /var/lib/shared. А в следващия ред създаваме обща папка и добавяме няколко lock-файла, за да избегнем конфликти от страна на containers/storage. Всъщност, просто създаваме празно хранилище за контейнерни изображения.

Ако монтирате containers/storage на ниво над тази папка, Buildah ще може да използва изображения.

Сега да се върнем към разгледания по-горе Вариант 2, когато Buildah-контейнерът може да чете и пише в containers/store на хостовете и следователно има максимална производителност благодарение на кеширането на изображения на ниво 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 вътре в контейнера в режим read-only. Затова, когато работи вътре в контейнера, Buildah може да използва всякакви изображения, които вече са били изтеглени чрез Podman/CRI-O (привет, бързина), но може да записва само в собственото си хранилище (привет, безопасност). Също така, обърнете внимание, че това се прави без изключване на разделението на SELinux за контейнера.

Важно уточнение

По никакъв начин не трябва да се изтриват изображения от основното хранилище. В противен случай Buildah-контейнерът може да се срине.

И това далеко не са всички предимства

Възможностите на допълнителните хранилища не се ограничават само до описания по-горе сценарий. Например, можете да съхранявате всички контейнерни образи в обща мрежова хранилище и да предоставите достъп до него на всички контейнери Buildah. Да предположим, че разполагаме с множество образи, които нашата CI/CD система редовно използва за сглобяване на контейнерни образи. Концентрираме всички тези образи на един единствен хост, а след това, използвайки предпочитаните мрежови средства за съхранение (NFS, Gluster, Ceph, ISCSI, S3…), отваряме общ достъп до това хранилище за всички нодовете на Buildah или Kubernetes.

Сега е достатъчно да монтирате това мрежово хранилище в контейнера Buildah на /var/lib/shared и всичко – контейнери Buildah вече не трябва да изтеглят образи чрез pull. По този начин изваждаме фазата на предварително попълване и веднага сме готови да разгръщаме контейнери.

И, разбира се, това може да се използва в рамките на съществуваща система Kubernetes или контейнерна инфраструктура, за да стартирате и изпълнявате контейнери навсякъде без изтегляне на образи чрез pull. Над и повече, регистърът на контейнерите, получаващ push-заявка за качване на актуализиран образ, може автоматично да изпрати този образ в общото мрежово хранилище, където той моментално става достъпен за всички ноди.

Размерите на контейнерните образи понякога могат да достигат до много гигабайти. Функционалността на допълнителните хранилища позволява да се избегне клонирането на такива образи между нодовете и прави стартирането на контейнерите практически мигновено.

Освен това, в момента работим по нова функция за overlay volume mounts, която ще ускори сглобяването на контейнерите още повече.

Заключение

Изпълнението на Buildah в контейнер в среда Kubernetes/CRI-O, Podman или дори в Docker е напълно реалистично, освен това е просто и значително по-сигурно от използването на docker.socket. Значително увеличихме гъвкавостта при работа с образите и сега можете да ги стартирате по различни начини за оптимален баланс между сигурност и производителност.

Функционалността на допълнителните хранилища позволява ускоряване или дори напълно премахване на изтеглянето на образи на нодовете.

Източник: habr.com