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