Ո՞րն է կոնտեյների աշխատանքի ժամանակը առանձին գործիքների բաղադրիչների բաժանելու գեղեցկությունը: Մասնավորապես, այդ գործիքները կարող են սկսել համակցվել այնպես, որ նրանք պաշտպանեն միմյանց:
Շատերին գրավում է ներսում կոնտեյներային OCI պատկերներ կառուցելու գաղափարը կամ նմանատիպ համակարգ։ Ենթադրենք, մենք ունենք CI/CD, որն անընդհատ պատկերներ է հավաքում, հետո նման բան /Kubernetes-ը բավականին օգտակար կլիներ կառուցումների ժամանակ բեռի հավասարակշռման առումով: Մինչև վերջերս, մարդկանց մեծամասնությունը պարզապես կոնտեյներներին թույլ էր տալիս մուտք գործել Docker վարդակից և թույլ էր տալիս նրանց գործարկել docker build հրամանը: որ սա շատ անապահով է, իրականում դա նույնիսկ ավելի վատ է, քան առանց գաղտնաբառի root կամ sudo տալը:
Ահա թե ինչու մարդիկ անընդհատ փորձում են Buildah-ը վարել կոնտեյներով: Մի խոսքով, մենք ստեղծեցինք ինչպես է, մեր կարծիքով, լավագույնս Buildah-ը բեռնարկղի ներսում գործարկել և տեղադրել համապատասխան պատկերները . Եկեք սկսենք...
հարմարեցում
Այս պատկերները կառուցված են Dockerfiles-ից, որը կարելի է գտնել պանակի Buildah պահոցում: .
Այստեղ մենք կանդրադառնանք .
# 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 կոնտեյներները առանց որևէ արմատային արտոնությունների: 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: Եթե առավելագույն անվտանգություն է պահանջվում, ապա յուրաքանչյուր կոնտեյների համար դուք կարող եք ստեղծել ձեր սեփական թղթապանակը կոնտեյներների/պատկերի համար և միացնել այն կոնտեյների հետ 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-ն ունի առավելագույն անվտանգություն. նրան տրված չեն որևէ արմատային արտոնություններ՝ օգտագործելով հնարավորությունները, և 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 համակարգում կամ կոնտեյներային ենթակառուցվածքում՝ ցանկացած վայրում բեռնարկղերը գործարկելու և գործարկելու համար՝ առանց նկարների ձգողական ներբեռնման: Ավելին, կոնտեյների ռեեստրը, ստանալով թարմացված պատկեր ներբեռնելու push հարցում, կարող է ավտոմատ կերպով ուղարկել այս պատկերը ընդհանուր ցանցային պահեստ, որտեղ այն անմիջապես հասանելի է դառնում բոլոր հանգույցներին:
Կոնտեյներների պատկերները երբեմն կարող են հասնել բազմաթիվ գիգաբայթերի: Լրացուցիչ պահեստի ֆունկցիոնալությունը թույլ է տալիս խուսափել նման պատկերների կլոնավորումից հանգույցներում և բեռնարկղերի գործարկումը դարձնում է գրեթե ակնթարթային:
Բացի այդ, մենք ներկայումս աշխատում ենք նոր գործառույթի վրա, որը կոչվում է overlay volume mounts, որն էլ ավելի արագ կդարձնի բեռնարկղերի կառուցումը:
Ամփոփում
Kubernetes/CRI-O-ում, Podman-ում կամ նույնիսկ Docker-ում Buildah-ի գործարկումը կոնտեյների ներսում հնարավոր է, պարզ և շատ ավելի անվտանգ, քան docker.socket-ի օգտագործումը: Մենք մեծապես մեծացրել ենք պատկերների հետ աշխատելու ճկունությունը, այնպես որ կարող եք դրանք գործարկել տարբեր եղանակներով՝ օպտիմալացնելու անվտանգության և կատարողականի հավասարակշռությունը:
Լրացուցիչ պահեստի ֆունկցիոնալությունը թույլ է տալիս արագացնել կամ նույնիսկ ամբողջությամբ վերացնել պատկերների ներբեռնումը հանգույցներում:
Source: www.habr.com