Контейнердин ичинде Buildah иштетүү боюнча көрсөтмөлөр

Контейнердин иштөө убактысын өзүнчө курал компоненттерине ажыратуу кандай сонун? Атап айтканда, бул куралдар бири-бирин коргоо үчүн айкалыштыра баштаса болот.

Контейнердин ичинде Buildah иштетүү боюнча көрсөтмөлөр

Көптөгөн адамдар ичиндеги контейнердик OCI сүрөттөрүн куруу идеясына тартылышат Kubernetes же окшош система. Келгиле, бизде сүрөттөрдү тынымсыз чогултуучу CI/CD бар дейли RedHat OpenShift/Кубернетес куруу учурунда жүктү баланстоо жагынан абдан пайдалуу болмок. Жакында эле көпчүлүк адамдар контейнерлерге Docker розеткасына кирүү мүмкүнчүлүгүн берип, аларга докер куруу буйругун иштетүүгө уруксат беришкен. Бир нече жыл мурун көрсөткөнбүзбул абдан кооптуу экенин, чындыгында, бул сырсөзсүз root же sudo берүүдөн да жаман.

Ошондуктан адамдар дайыма Buildahты контейнерде иштетүүгө аракет кылышат. Кыскасы, биз түздүк мисал Кантип, биздин оюбузча, контейнердин ичинде Buildah иштетүү жакшы, жана тиешелүү сүрөттөрдү жайгаштырылган quay.io/buildah. Баштайлы...

тууралоо

Бул сүрөттөр папкадагы Buildah репозиторийинен тапса болот Dockerfiles'тен курулган куруу.
Бул жерде биз карап чыгабыз 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

Хост Linux ядро ​​деңгээлинде ишке ашырылган OverlayFS ордуна, биз контейнердин ичиндеги программаны колдонобуз сактагыч катмары, анткени учурда OverlayFS ага Linux мүмкүнчүлүктөрүн колдонуу менен SYS_ADMIN уруксаттарын бергенде гана орното алат. Жана биз Buildah контейнерлерибизди эч кандай тамыр артыкчылыктары жок иштеткибиз келет. Fuse-overlay абдан тез иштейт жана VFS сактагыч драйверине караганда жакшыраак иштешине ээ. Fuse колдонгон Buildah контейнерин иштетип жатканда, /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 максималдуу коопсуздукка ээ: ага мүмкүнчүлүктөрдү колдонуу менен эч кандай тамыр артыкчылыктары берилбейт жана ага бардык SECOMP жана SELinux чектөөлөрү колдонулат.Мындай контейнерди —uidmap 0 сыяктуу опцияны кошуу менен User Namespace изоляциясы менен да иштетсе болот: 100000:10000.

Performance. Бирок бул жерде иштөө минималдуу, анткени контейнер реестриндеги сүрөттөр ар дайым хостко көчүрүлүп турат жана кэш такыр иштебейт. Өз ишин аяктагандан кийин, 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 зыяндуу сүрөттү азыктандырышы мүмкүн. Мындан тышкары, Buildah контейнериндеги процесстер хосттогу сактагыч менен өз ара аракеттениши үчүн SELinux бөлүүнү өчүрүшүңүз керек болот. Бул параметр Docker розеткасына караганда дагы эле жакшы экенин эске алыңыз, анткени контейнер калган коопсуздук функциялары менен жабылган жана хостто контейнерди жөн эле иштете албайт.

Performance. Бул жерде бул максималдуу, анткени кэштөө толугу менен колдонулат. Эгер 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 сүрөт сактагычына жаман нерсени киргизе албайт. Башка жагынан алып караганда, анын дизайнынын бир бөлүгү катары, бир контейнер башка контейнерлердин чогулушуна тоскоол болушу мүмкүн.

Performance. Бул жерде хост деңгээлинде жалпы кэш колдонуудан да жаман, анткени Podman/CRI-O аркылуу буга чейин жүктөлүп алынган сүрөттөрдү колдоно албайсыз. Бирок, Buildah сүрөттү жүктөгөндөн кийин, сүрөттү долбоордун ичиндеги ар кандай кийинки конструкцияларда колдонсо болот.

Кошумча сактагыч

У контейнерлер/сактоо Кошумча дүкөндөр (кошумча дүкөндөр) сыяктуу сонун нерсе бар, анын аркасында контейнерлерди ишке киргизүүдө жана курууда контейнер кыймылдаткычтары окуу үчүн гана кабатталган режимде тышкы сүрөт дүкөндөрүн колдоно алат. Негизи, сиз бир же бир нече окуу үчүн гана сактагычтарды storage.conf файлына кошо аласыз, андыктан контейнерди ишке киргизгениңизде, контейнер кыймылдаткычы алардан керектүү сүрөттү издейт. Мындан тышкары, ал реестрден сүрөттү ушул сактагычтардын биринде таппаса гана жүктөп алат. Контейнердин кыймылдаткычы жазыла турган сактагычка гана жаза алат...

Эгер сиз жогору сыдырып, 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 файлын контейнер сүрөтүнүн ичинде өзгөртүп, сактоочу драйверге /var/lib/shared папкасында “additionalimagestores” колдонуусун айтып беребиз. Ал эми кийинки сапта биз жалпы папканы түзүп, контейнерлерден/сактоодон эч кандай кыянатчылык болбошу үчүн бир нече кулпу файлдарын кошобуз. Негизи, биз жөн гана бош контейнер сүрөт дүкөнүн түзүп жатабыз.

Эгер сиз контейнерлерди/сактагычты бул папкадан жогорураак деңгээлде орнотсоңуз, 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 түйүндөрүнө бул сактагычка жалпы кирүү мүмкүнчүлүгүн ачабыз.

Эми бул тармак сактагычты /var/lib/shared дарегиндеги Buildah контейнерине орнотуу жетиштүү жана ушуну менен бүттү - Buildah контейнерлери мындан ары тартуу аркылуу сүрөттөрдү жүктөөнүн кереги жок. Ошентип, биз популяцияга чейинки фазаны ыргытып, дароо контейнерлерди жайылтууга даярбыз.

Анан, албетте, бул жандуу Kubernetes тутумунда же контейнер инфраструктурасында сүрөттөрдү эч кандай жүктөөсүз каалаган жерде контейнерлерди ишке киргизүү жана иштетүү үчүн колдонсо болот. Мындан тышкары, контейнер реестри, ага жаңыланган сүрөттү жүктөө үчүн push өтүнүчүн алуу менен, бул сүрөттү автоматтык түрдө жалпы тармактык сактагычка жөнөтө алат, ал ошол замат бардык түйүндөр үчүн жеткиликтүү болот.

Контейнер сүрөттөрү кээде көп гигабайтка жетет. Кошумча сактагычтын функционалдуулугу мындай сүрөттөрдү түйүндөр боюнча клондоштуруудан качууга мүмкүндүк берет жана контейнерлерди бир заматта ишке киргизет.

Кошумчалай кетсек, учурда биз контейнерлерди курууну тезирээк кыла турган үстүнкү көлөмүн орнотуу деп аталган жаңы функциянын үстүндө иштеп жатабыз.

жыйынтыктоо

Kubernetes/CRI-O, Podman, жада калса Docker'де контейнердин ичинде Buildah иштетүү docker.socketти колдонууга караганда мүмкүн, жөнөкөй жана алда канча коопсуз. Биз сүрөттөр менен иштөөнүн ийкемдүүлүгүн бир топ жогорулаттык, ошондуктан сиз аларды коопсуздук менен аткаруунун ортосундагы тең салмактуулукту оптималдаштыруу үчүн ар кандай жолдор менен иштете аласыз.

Кошумча сактагычтын функционалдуулугу сүрөттөрдү түйүндөргө жүктөөнү тездетүүгө же толугу менен жок кылууга мүмкүндүк берет.

Source: www.habr.com

Комментарий кошуу