Ի՞նչ զվարճալիություն ունի բաժանված կտրոնային իրագործման միջավայրի առանձնահատկությունների վրա: Անյունի, որ այդ գործիքները կարելի է համակցել՝ միմյանց պաշտպանելու համար.
Շատերին գրավում է գաղափարը, որ OCI-դիզայները հավաքագրենք կամ նման համակարգում: Հայցենք, որ մեզ ձգտում է CI/CD, որը անդադար հավաքագրում է դիզայններ, այդ դեպքում նմանատիպ /Kubernetes было бы весьма полезно с точки зрения распределения нагрузки при сборке. До недавних пор большинство людей просто давали контейнерам доступ к Docker-сокету и разрешали выполнять команду docker build. , որ դա շատ անապահով է, իրականում, դրանից էլ վատ է, քան առանց գաղտնաբառի root կամ sudo տրամադրելը:
Որպեսզի մարդիկ Անընդմիշտ փորձում են Buildah-ը կտրոնում գործարկել: Ի վերջո, մենք ստեղծեցինք այն, ինչպիսիք մենք կարծում ենք, որ լավագույնն է Buildah-ը կտրոնում գործարկել, և համապատասխան պատկերները տեղադրեցինք . Եկեք սկսենք…
Հավելված
Այս պատկերները ստեղծվել են Dockerfiles-ից, որոնք կարելի է գտնել Buildah-ի ռեպոզիտորիայում `buildahimage` թղթի մեջ: .
Stable 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 կարող է ծածկել միայն այն դեպքում, եթե նրան տրամադրի SYS_ADMIN լիազորությունները Linux կարողություններով: Մենք ցանկանում ենք, որ մեր Buildah-կտրոնները գործարկվելուն առանց root մակարդակի որևէ արտոնությունների: Fuse-overlay-ը աշխատում է բավական արագ և կատարողականությամբ լավ է, քան storage-մանամ VFS: Խնդրում ենք նկատի ունենալ, որ Buildah-կտրոնը գործարկելու ժամանակ, որն օգտագործում է Fuse, պետք է տրամադրվի սարք `\/dev\/fuse`: Դրանից հետո մենք ստեղծում ենք կատալոգ հավելվածային պահեստների համար.
Container\/storage
վերահսկում է լրացուցիչ read-only պահեստների գաղափարը: Օրինակ, կարող եք սահմանել overlay storage area մեկ մեքենայում, իսկ հետո NFS-ի միջոցով կցել այդ պահեստը մեկ այլ մեքենայում և օգտագործել դրա պատկերները՝ առանց քաշելու: Եվ վերջապես, օգտագործելով BUILDAH_ISOLATION միջավայրի փոփոխականը, մենք ասում ենք, որ ըստ կանխորոշմամբ Buildah-կտրոնը պետք է գործարկվի chroot-ի մեկուսացմանով: Ավելորդ մեկուսացում այստեղ անհրաժեշտ չէ, քանի որ մենք արդեն աշխատում ենք կտրոնում: Այնուամենայնիվ, որպեսզի Buildah-ը ստեղծի իր սեփական կտրոնները անվանումների տեղակայման բաժանմամբ, SYS_ADMIN արտոնություն է անհրաժեշտ, իսկ դրա համար container-ում SELinux և SECCOMP կանոնները պետք է թուլացվեն, ինչը հակասում է մեր տեղադրման մտքին՝ հավաքագրել անվտանգ կտրոնում:
# 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-ը գործարկում է կտրոնի ներսում
Buildah-ը կտրոնում գործարկում ենք
Մասնավորապես, վերոնշյալ Buildah-կոնտեյների պատկերառման սխեման թույլ է տալիս ճկուն կերպով փոփոխել այդ կոնտեյների գործարկման եղանակները։
Արագություն ընդդեմ անվտանգության
Համակարգչային անվտանգությունը միշտ ոմանց միջև փոխզիջում է, որը վերաբերում է գործընթացի կատարողական արագությանը և նրա շուրջ մատակարարված պաշտպանությանը: Այս հավանությունը կիրառելի է նաև կոնտեյներների հավաքման ժամանակ, այդ պատճառով մենք կքննարկենք այդ փոխզիջման տարբերակները։
Վերօգնված պատկերը կխնամի իր պահեստը /var/lib/containers-ում։ Ուստի հարկավոր է այս ֆայլըկցանել այդ папка, և նրա ձեւը մեծապես կազդի կոնտեյներային պատկերների հավաքման արագությանը։
Քննարկենք երեք տարբերակ։
Տվյալ 1։ Եթե առավելագույն անվտանգությունը պահանջվում է, ապա յուրաքանչյուր կոնտեյների համար կարելի է ստեղծել սեփական папка containers/image-ի համար և կապել այն կոնտեյններին volume-mount-ի միջոցով։ Եվ, անտուեյն, տեղադրել context directory-ն հենց կոնտեյներում, /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 մակարդակի արդյունավետություն, ապա կարելի է ֆայլըկցել container/storage-ն ուղղակի կոնտեյների ներսում։
# 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։ Այս մեթոդի essence-ն այն է, որ միավորվեն մի քանի պատկերներ մեկ նախագծում, ընդհանուր Docker պատկերների թղթապանակով։
# 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-ը ներլցնում է պատկերը, դա կարող է օգտագործվել ցանկացած հաջորդ կառուցումներում նախագծի շրջանակում։
Լրացուցիչ պահեստներ
Ու կա այսպիսի հրաշալի բան, ինչպես լրացուցիչ պահեստներ (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-ում, container-ում read-only ռեժիմով: Ուստի container-ում աշխատելիս, Buildah-ն կարող է օգտվել ցանկացած image-ից, որը նախապես ներբեռնվել է Podman/CRI-O-ի միջոցով (բարև, արագություն), սակայն կարող է գրել միայն իր սեփական պահեստային համակարգում (բարև, անվտանգություն): Այս ամենն իրականացվում է առանց SELinux բաժանման անջատելու container-ի համար:
Մանրամասն ասպեկտ
Ո՛չ մի դեպքում չպետք է ջնջել որևէ image ներքևի պահեստային համակարգից: Այլ դեպքում Buildah container-ը կարող է դուրս պրծնել:
և սա ամեն ինչ չէ առավելություններից
Հավելյալ պահեստների կարողությունները միայն նկարագրված սցենարներով չեն սահմանափակվում: Օրինակ, կարող եք տեղադրել բոլոր container image-ները ընդհանուր ցանցային պահեստում և թույլ տալ նրանց մուտք գործել բոլոր Buildah containers-ին: فرض کریں, մենք ունենք հարյուրավոր images, որոնք մեր CI/CD համակարգը կանոնավոր կերպով օգտագործում է container images-ների կառուցման համար: Концентриируем все эти образы на каком-то одном хосте-хранилище и затем, используя предпочтительные средства сетевого хранения (NFS, Gluster, Ceph, ISCSI, S3…), открываем общий доступ к этому хранилищу всем нодам Buildah или Kubernetes.
Այժմ բավական է այս ցանցային պահեստը կցել Buildah container-ին /var/lib/shared-ում և voila – Buildah containers-ին լրացուցիչ այլևս չի լինի անհրաժեշտության անհրաժեշտություն images-ը pull-ի միջոցով ներբեռնելու: Այսպիսով, մենք հրաժարվում ենք նախնական լցոնման փուլից (pre-population) և անմիջապես պատրաստ ենք container-ներ թողարկել:
Եվ, բնականաբար, սա կարող է օգտագործվել գործող Kubernetes կամ container ենթակառուցման շրջանակներում, որպեսզի container-ները գործարկվեն և իրականացվեն որտեղ էլ որ ցանկանաք առանց որևէ images pull-ի միջոցով ներբեռնելու: Ինչպես նաև, container registry-ն, ստանալով push-հարց, կարող է ավտոմատ կերպով մղել այս image-ը ընդհանուր ցանցային պահեստ, որտեղ այն անմիջապես հասանելի է բոլոր նոդերին:
Container images-ի չափերը երբեմն կարող են հասնել շատ գիգաբայթի: Հավելյալ պահեստների ֆունկցիան թույլ է տալիս խնայել նման images-ի քանդումը նոդերի վրա և դարձնել container-ների գործարկումը սթափ:
Բացի այդ, այժմ մենք աշխատում ենք overlay volume mounts նոր ֆունկցիայի վրա, որը կդարձնի container-ների կառուցումը նույնիսկ ավելի արագ:
Ավարտ
Buildah-ն իրականացնելու անընդունելի container-ի համար Kubernetes/CRI-O, Podman կամ նույնիսկ Docker միջավայրում հնարավոր է, բացի այն, որ դա հեշտ է և շատ ավելի անվտանգ է, քան օգտագործել docker.socket: Մենք զգալիորեն բարձրացրել ենք images-ի հետ աշխատանքի ճկունությունը, և այժմ դուք կարող եք գործարկել դրանք տարբեր ուղիներով՝ ապահովելու համար անվտանգություն և կատարողականատկություն:
Հավելյալ պահեստների ֆունկցիան թույլ է տալիս արագացնել կամ նույնիսկ ամբողջովին վերացնել images-ի ներբեռնումը նոդերի վրա:
Ընտանիք: habr.com
