🥇 कन्टेनर भित्र Buildah चलाउनका लागि सिफारिसहरू

कन्टेनर रनटाइमलाई अलग टुलिङ कम्पोनेन्टहरूमा डिकपल गर्ने सुन्दरता के हो? विशेष गरी, यी उपकरणहरू संयोजन गर्न सुरु गर्न सकिन्छ ताकि तिनीहरूले एकअर्कालाई सुरक्षित राख्छन्।

धेरै मानिसहरू भित्र कन्टेनराइज्ड OCI छविहरू निर्माण गर्ने विचारमा आकर्षित हुन्छन् कुबर्नेट्स वा समान प्रणाली। मानौं हामीसँग सीआई/सीडी छ जसले निरन्तर तस्बिरहरू सङ्कलन गर्दछ, त्यसपछि केहि जस्तै रेड ह्याट ओपनशिफ्ट/Kubernetes निर्माण समयमा लोड सन्तुलन को मामला मा धेरै उपयोगी हुनेछ। भर्खरै सम्म, धेरै मानिसहरूले कन्टेनरहरूलाई डकर सकेटमा पहुँच दिए र तिनीहरूलाई डकर निर्माण आदेश चलाउन अनुमति दिए। धेरै वर्ष पहिले हामीले देखाउनुभयोकि यो धेरै असुरक्षित छ, वास्तवमा, यो पासवर्ड रहित रूट वा sudo दिनु भन्दा पनि खराब छ।

यही कारणले गर्दा मानिसहरूले लगातार कन्टेनरमा बिल्डा चलाउने प्रयास गर्छन्। छोटकरीमा, हामीले सिर्जना गर्यौं एक उदाहरण कसरी, हाम्रो विचारमा, एक कन्टेनर भित्र Buildah चलाउन उत्तम छ, र सम्बन्धित छविहरू पोस्ट quay.io/buildah। सुरु गरौं...

समायोजन

यी छविहरू Dockerfiles बाट बनाइएका छन्, जुन फोल्डरमा Buildah भण्डारमा फेला पार्न सकिन्छ छवि निर्माण गर्नुहोस्.
यहाँ हामी हेर्नेछौं 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 को सट्टा, होस्ट लिनक्स कर्नेल स्तरमा लागू गरिएको, हामी कन्टेनर भित्र प्रोग्राम प्रयोग गर्छौं। फ्यूज-ओभरले, किनभने हाल OverlayFS ले माउन्ट गर्न सक्छ यदि तपाईंले लिनक्स क्षमताहरू प्रयोग गरेर SYS_ADMIN अनुमति दिनुभयो भने। र हामी कुनै पनि रूट विशेषाधिकार बिना हाम्रो Buildah कन्टेनरहरू चलाउन चाहन्छौं। फ्यूज-ओभरले एकदम छिटो काम गर्दछ र VFS भण्डारण चालक भन्दा राम्रो प्रदर्शन छ। कृपया ध्यान दिनुहोस् कि फ्यूज प्रयोग गर्ने 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 र SECOMP नियमहरू आराम गर्न आवश्यक छ, जुन सुरक्षित कन्टेनरबाट निर्माण गर्ने हाम्रो प्राथमिकताको विपरीत हो।

कन्टेनर भित्र बिल्डा चलिरहेको छ

माथि छलफल गरिएको 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: 100000।

प्रदर्शन। तर यहाँ प्रदर्शन न्यूनतम छ, किनकि कन्टेनर रजिस्ट्रीहरूबाट कुनै पनि छविहरू प्रत्येक पटक होस्टमा प्रतिलिपि गरिन्छ, र क्यासिङले काम गर्दैन। यसको काम पूरा गर्दा, Buildah कन्टेनरले छविलाई रजिस्ट्रीमा पठाउनु पर्छ र होस्टमा रहेको सामग्री नष्ट गर्नुपर्छ। अर्को पटक कन्टेनर छवि बनाइएपछि, यसलाई फेरि रजिस्ट्रीबाट डाउनलोड गर्नुपर्नेछ, किनकि त्यस समयसम्म होस्टमा केही बाँकी रहनेछैन।

विकल्प 2। यदि तपाइँलाई डकर-स्तर प्रदर्शन चाहिन्छ भने, तपाइँ होस्ट कन्टेनर/भण्डारण सिधै कन्टेनरमा माउन्ट गर्न सक्नुहुन्छ।

# 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

सुरक्षा। यो कन्टेनरहरू निर्माण गर्ने सबैभन्दा कम सुरक्षित तरिका हो किनभने यसले कन्टेनरलाई होस्टमा भण्डारण परिमार्जन गर्न अनुमति दिन्छ र सम्भावित रूपमा पोडम्यान वा CRI-O लाई खराब छवि फिड गर्न सक्छ। थप रूपमा, तपाईंले SELinux विभाजन असक्षम गर्न आवश्यक छ ताकि Buildah कन्टेनरमा भएका प्रक्रियाहरूले होस्टमा भण्डारणसँग अन्तरक्रिया गर्न सकून्। ध्यान दिनुहोस् कि यो विकल्प अझै पनि डकर सकेट भन्दा राम्रो छ किनभने कन्टेनर बाँकी सुरक्षा सुविधाहरूद्वारा बन्द गरिएको छ र होस्टमा कन्टेनर चलाउन सक्दैन।

प्रदर्शन। यहाँ यो अधिकतम छ, किनकि क्यासिंग पूर्ण रूपमा प्रयोग गरिएको छ। यदि 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 ले छवि डाउनलोड गरेपछि, छवि परियोजना भित्र कुनै पनि पछिल्लो निर्माणहरूमा प्रयोग गर्न सकिन्छ।

अतिरिक्त भण्डारण

У कन्टेनर / भण्डारण त्यहाँ अतिरिक्त स्टोरहरू (अतिरिक्त स्टोरहरू) जस्ता राम्रो चीजहरू छन्, जसको लागि धन्यवाद कन्टेनरहरू सुरू गर्दा र निर्माण गर्दा, कन्टेनर इन्जिनहरूले पढ्ने-मात्र ओभरले मोडमा बाह्य छवि स्टोरहरू प्रयोग गर्न सक्छन्। अनिवार्य रूपमा, तपाईँले भण्डारण सुरु गर्दा, कन्टेनर इन्जिनले चाहिने छवि खोज्नको लागि store.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" प्रयोग गर्न भन्छौं। र अर्को लाइनमा हामी साझा फोल्डर सिर्जना गर्छौं र कन्टेनर/भण्डारणबाट कुनै दुरुपयोग नहोस् भनेर केही लक फाइलहरू थप्छौं। अनिवार्य रूपमा, हामी केवल एउटा खाली कन्टेनर छवि भण्डार सिर्जना गर्दैछौं।

यदि तपाइँ यस फोल्डर भन्दा उच्च स्तरमा कन्टेनर/भण्डारण माउन्ट गर्नुहुन्छ भने, बिल्डाह छविहरू प्रयोग गर्न सक्षम हुनेछ।

अब माथि छलफल गरिएको विकल्प 2 मा फर्कौं, जब Buildah कन्टेनरले होस्टहरूमा कन्टेनर/स्टोरमा पढ्न र लेख्न सक्छ र, तदनुसार, पोडम्यान/सीआरआई-ओ स्तरमा छविहरू क्यास गर्ने कारणले अधिकतम प्रदर्शन छ, तर न्यूनतम सुरक्षा प्रदान गर्दछ। किनकि यसले सिधै भण्डारणमा लेख्न सक्छ। अब यहाँ थप भण्डारण थप्नुहोस् र दुबै संसारको उत्कृष्ट पाउनुहोस्।

# 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 (hello, speed) को प्रयोग गरेर डाउनलोड गरिएको थियो, तर यसको आफ्नै भण्डारणमा मात्र लेख्न सक्छ (नमस्ते, सुरक्षा)। यो पनि ध्यान दिनुहोस् कि यो कन्टेनरको लागि SELinux विभाजन असक्षम नगरी गरिन्छ।

महत्वपूर्ण न्यूनन्स

कुनै पनि परिस्थितिमा तपाईंले अन्तर्निहित भण्डारबाट कुनै पनि छविहरू मेटाउनु हुँदैन। अन्यथा, Buildah कन्टेनर दुर्घटना हुन सक्छ।

र यी सबै फाइदाहरू छैनन्

थप भण्डारणको सम्भावनाहरू माथिको परिदृश्यमा सीमित छैनन्। उदाहरणका लागि, तपाईंले साझा नेटवर्क भण्डारणमा सबै कन्टेनर छविहरू राख्न सक्नुहुन्छ र यसलाई सबै Buildah कन्टेनरहरूमा पहुँच दिन सक्नुहुन्छ। मानौं हामीसँग सयौं छविहरू छन् जुन हाम्रो CI/CD प्रणालीले कन्टेनर छविहरू निर्माण गर्न नियमित रूपमा प्रयोग गर्दछ। हामी यी सबै छविहरूलाई एउटा भण्डारण होस्टमा केन्द्रित गर्छौं र त्यसपछि, मनपर्ने नेटवर्क भण्डारण उपकरणहरू (NFS, Gluster, Ceph, ISCSI, S3...) प्रयोग गरेर, हामी यस भण्डारणमा सबै Buildah वा Kubernetes नोडहरूमा सामान्य पहुँच खोल्छौं।

अब यो नेटवर्क भण्डारणलाई /var/lib/shared मा Buildah कन्टेनरमा माउन्ट गर्न पर्याप्त छ र यो हो - Buildah कन्टेनरहरूले अब पुल मार्फत छविहरू डाउनलोड गर्नुपर्दैन। यसरी, हामी पूर्व-जनसंख्या चरण बाहिर फ्याँक्छौं र तुरुन्तै कन्टेनरहरू रोल आउट गर्न तयार छौं।

र निस्सन्देह, यो लाइभ कुबर्नेट्स प्रणाली वा कन्टेनर पूर्वाधार भित्र प्रयोग गर्न सकिन्छ र कन्टेनरहरू कुनै पनि छविहरूको कुनै पुल डाउनलोड बिना नै सुरु गर्न र चलाउन सकिन्छ। यसबाहेक, कन्टेनर रजिस्ट्री, यसमा अद्यावधिक गरिएको छवि अपलोड गर्न पुश अनुरोध प्राप्त गर्दै, स्वचालित रूपमा यो छवि साझा नेटवर्क भण्डारणमा पठाउन सक्छ, जहाँ यो तुरुन्तै सबै नोडहरूमा उपलब्ध हुन्छ।

कन्टेनर छविहरू कहिलेकाहीँ धेरै गीगाबाइट साइजमा पुग्न सक्छ। अतिरिक्त भण्डारणको कार्यक्षमताले तपाईंलाई नोडहरूमा त्यस्ता छविहरू क्लोन गर्नबाट बच्न अनुमति दिन्छ र कन्टेनरहरू लन्च गर्न लगभग तुरुन्तै बनाउँदछ।

थप रूपमा, हामी हाल ओभरले भोल्युम माउन्ट भनिने नयाँ सुविधामा काम गर्दैछौं, जसले निर्माण कन्टेनरहरू अझ छिटो बनाउँदछ।

निष्कर्षमा

Kubernetes/CRI-O, Podman, वा Docker मा कन्टेनर भित्र Buildah चलाउनु सम्भव, सरल, र docker.socket प्रयोग गर्नु भन्दा धेरै सुरक्षित छ। हामीले तस्बिरहरूसँग काम गर्ने लचिलोपनलाई धेरै बढाएका छौं, त्यसैले तपाईंले तिनीहरूलाई सुरक्षा र कार्यसम्पादन बीचको सन्तुलनलाई अनुकूलन गर्न विभिन्न तरिकामा चलाउन सक्नुहुन्छ।

अतिरिक्त भण्डारणको कार्यक्षमताले तपाईंलाई नोडहरूमा छविहरूको डाउनलोडलाई गति बढाउन वा पूर्ण रूपमा हटाउन अनुमति दिन्छ।

स्रोत: www.habr.com

कन्टेनर भित्र Buildah चलाउनका लागि सिफारिसहरू