Указания за изпълнение на Buildah в контейнер

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

Много хора са привлечени от идеята за изграждане на изображения на OCI контейнери Kubernetes или подобна система. Да кажем, че имаме CI / CD, който постоянно изгражда изображения, след това нещо подобно Red Hat OpenShift/Kubernetes би бил много полезен по отношение на балансирането на натоварването на компилацията. Доскоро повечето хора просто даваха на контейнерите достъп до Docker сокет и им позволяваха да изпълняват командата за изграждане на docker. Показахме го преди няколко годиниче това е много несигурно, всъщност е дори по-лошо от даването на 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, внедрен на ниво Linux ядро ​​на хоста, ние използваме програмата вътре в контейнера наслагване на предпазител, защото в момента OverlayFS може да се монтира само ако му дадете разрешения SYS_ADMIN чрез възможности на Linux. И ние искаме да стартираме нашите 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

След това създаваме директория за допълнителни хранилища. контейнер/склад поддържа концепцията за свързване на допълнителни хранилища за изображения само за четене. Например, можете да настроите област за съхранение с наслагване на една машина и след това да използвате 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

Security. Buildah, работещ в такъв контейнер, има максимална сигурност: не му се дават никакви root привилегии от способности и всички ограничения на SECOMP и SELinux се прилагат към него.Такъв контейнер може дори да се изпълнява с изолация на потребителското пространство чрез добавяне на опция като --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

Security. Това е най-малко сигурният начин за изграждане на контейнери, тъй като позволява на контейнера да променя хранилището на хоста и потенциално може да вмъкне злонамерено изображение в 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) между изпълненията, така че всички следващи компилации в рамките на проекта се възползват от кеширането.

Security. Нещо между опции 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/shared. И в следващия ред създаваме споделена папка и добавяме няколко заключващи файла, така че да няма злоупотреба от контейнери / хранилище. По същество ние просто създаваме празно хранилище за изображения на контейнер.

Ако монтирате контейнери/съхранение ниво над тази папка, 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 вече изобщо не трябва да изтеглят изображения чрез изтегляне. По този начин ние изхвърляме фазата преди популацията и веднага сме готови да разгърнем контейнерите.

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

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

Освен това в момента работим върху нова функция за монтиране на обемни наслагвания, която ще направи изграждането на контейнери още по-бързо.

Заключение

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

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

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