🤘🏻 🛌🏼 🐉 एक कंटेनर के अंदर बिल्डह को चलाने के लिए सर्वोत्तम अभ्यास 👩🏽 🍉 🍠

कंटेनरों के रनटाइम को अलग-अलग वाद्य घटकों में विभाजित करने की सुंदरता क्या है? विशेष रूप से, यह तथ्य कि ये उपकरण एक दूसरे की सुरक्षा के लिए संयुक्त होने शुरू हो सकते हैं।

कुबेरनेट्स या इसी तरह की प्रणाली के भीतर कंटेनर ओसीआई के निर्माण के विचार से बहुत से लोग आकर्षित होते हैं। मान लें कि हमारे पास एक CI / CD है जो लगातार छवियों को एकत्र करता है, तो Red Hat OpenShift / Kubernetes जैसा कुछ असेंबली के दौरान लोड संतुलन के मामले में बहुत उपयोगी होगा। कुछ समय पहले तक, ज्यादातर लोगों ने कंटेनर को डॉक सॉकेट तक पहुंच दिया था और उसे डॉक बिल्ड कमांड को निष्पादित करने की अनुमति दी गई थी। हमने कई साल पहले दिखाया था कि यह बहुत असुरक्षित है, वास्तव में, यह पासवर्ड रहित रूट या सुडोल देने से भी बदतर है।

इसलिए, लोग लगातार एक कंटेनर में बिल्डह को चलाने की कोशिश कर रहे हैं। संक्षेप में, हमने एक उदाहरण बनाया कि, हमारी राय में, कंटेनर के अंदर बिल्डह को चलाने के लिए सबसे अच्छा है, और quay.io/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

मेज़बान के लिनक्स कर्नेल स्तर पर लागू ओवरलेफ़्स के बजाय, हम कंटेनर के अंदर फ्यूज-ओवरले कार्यक्रम का उपयोग करते हैं, क्योंकि इस समय ओवरलेएफएस केवल तभी माउंट कर सकते हैं जब इसे लिनक्स क्षमताओं द्वारा SYS_ADMIN विशेषाधिकार प्रदान किया जाता है। और हम अपने बिल्डह कंटेनर को बिना किसी रूट विशेषाधिकार के चलाना चाहते हैं। फ्यूज-ओवरले वीएफएस स्टोरेज ड्राइवर की तुलना में प्रदर्शन में बहुत तेज और बेहतर है। ध्यान दें कि फ़्यूज़ का उपयोग करके एक बिल्डह कंटेनर शुरू करते समय, आपको डिवाइस / देव / फ़्यूज़ प्रदान करना होगा।

 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 कंटेनर को क्रॉनिक अलगाव के साथ शुरू करना चाहिए। अतिरिक्त अलगाव की आवश्यकता यहाँ नहीं है, क्योंकि हम पहले से ही कंटेनर में काम करते हैं। नाम स्थान के पृथक्करण के साथ अपने स्वयं के कंटेनर बनाने के लिए बिल्डह के लिए, SYS_ADMIN विशेषाधिकार की आवश्यकता होती है, और इसके लिए कंटेनर के लिए SELinux और SECCOMP नियमों को कमजोर करना आवश्यक होगा, जो एक सुरक्षित कंटेनर से निर्माण करने के लिए इसकी स्थापना का विरोध करता है।

कंटेनर के अंदर Buildah चलाएँ

ऊपर चर्चा की गई बिल्डह कंटेनर छवि स्कीमा आपको लचीले ढंग से इस तरह के कंटेनरों को चलाने के तरीके को बदलता है।

स्पीड बनाम सुरक्षा

कंप्यूटर सुरक्षा हमेशा प्रक्रिया की गति और उसके चारों ओर घाव से सुरक्षा के बीच एक समझौता है। कंटेनरों को इकट्ठा करते समय यह कथन भी सही है, इसलिए नीचे हम इस तरह के एक समझौते के लिए विकल्पों पर विचार करेंगे।

ऊपर चर्चा की गई कंटेनर की छवि अपनी रिपॉजिटरी को / var / lib / कंटेनरों में रखेगी। इसलिए, हमें इस फ़ोल्डर में सामग्री को माउंट करने की आवश्यकता है, और जिस तरह से हम ऐसा करते हैं वह कंटेनर छवियों की विधानसभा गति को बहुत प्रभावित करेगा।

आइए तीन विकल्पों पर विचार करें।

विकल्प 1. यदि अधिकतम सुरक्षा की आवश्यकता है, तो प्रत्येक कंटेनर के लिए आप कंटेनर / छवि के लिए अपना स्वयं का फ़ोल्डर बना सकते हैं और इसे वॉल्यूम-माउंट के माध्यम से कंटेनर से जोड़ सकते हैं। और इसके अलावा, संदर्भ निर्देशिका को कंटेनर में / बिल्ड फ़ोल्डर में रखें:

 # 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

सुरक्षा। ऐसे कंटेनर में चल रहे बिल्डह में अधिकतम सुरक्षा है: इसे क्षमताओं के साथ कोई रूट विशेषाधिकार नहीं दिया गया है, और सभी SECOMP और SELinux प्रतिबंध इस पर लागू होते हैं। आप इस तरह के कंटेनर को यूजर नेमस्पेस अलगाव के साथ भी चला सकते हैं जैसे: Ouidmap 0: 100000: 10000 ।

प्रदर्शन। लेकिन यहां प्रदर्शन न्यूनतम है, क्योंकि कंटेनर रजिस्ट्रियों से कोई भी चित्र हर बार मेजबान को कॉपी किया जाता है, और कैशिंग शब्द "कोई रास्ता नहीं" से काम नहीं करता है। अपना काम पूरा करते समय, बिल्डह कंटेनर को छवि को रजिस्ट्री को भेजना चाहिए और मेजबान पर सामग्री को नष्ट करना चाहिए। जब अगली बार कंटेनर छवि एकत्र की जाती है, तो उसे फिर से रजिस्ट्री से डाउनलोड करना होगा, क्योंकि उस समय तक मेजबान पर कुछ भी नहीं रहेगा।

विकल्प 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

सुरक्षा। कंटेनर बनाने का यह सबसे कम सुरक्षित तरीका है, क्योंकि यहां कंटेनर को होस्ट पर भंडारण को संशोधित करने की अनुमति है, और संभावित रूप से यह पॉडमैन या सीआरआई-ओ में दुर्भावनापूर्ण छवि में फिसल सकता है। इसके अलावा, आपको SELinux जुदाई को अक्षम करना होगा ताकि 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 के बीच कुछ। एक तरफ, कंटेनरों की मेजबानी पर सामग्री तक पहुंच नहीं है और, तदनुसार, पॉडमैन / सीआरआई-ओ छवि भंडारण में कुछ बुरा नहीं फिसल सकता है। दूसरी ओर, अपनी परियोजना के हिस्से के रूप में, एक कंटेनर अन्य कंटेनरों की विधानसभा के साथ हस्तक्षेप कर सकता है।

प्रदर्शन। यहां होस्ट स्तर पर साझा कैश का उपयोग करते समय यह बदतर है, क्योंकि आप पॉडमैन / सीआरआई-ओ का उपयोग करके पहले से डाउनलोड की गई छवियों का उपयोग नहीं कर सकते हैं। हालाँकि, बिल्डह छवि डाउनलोड करने के बाद, इस छवि का उपयोग परियोजना के बाद के किसी भी निर्माण में किया जा सकता है।

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

कंटेनर / स्टोरेज में अतिरिक्त स्टोर के रूप में ऐसी शांत चीज होती है, जिसके लिए कंटेनर इंजन लॉन्च करते समय और कंटेनर बनाते समय केवल ओवरले मोड में बाहरी छवि स्टोर का उपयोग कर सकते हैं। वास्तव में, आप स्टोरेज में एक या एक से अधिक रीड-ओनली स्टोरेज जोड़ सकते हैं। फाइल जब कंटेनर शुरू होता है, तो कंटेनर इंजन उन में वांछित छवि के लिए दिखता है। इसके अलावा, वह छवि को रजिस्ट्री से तभी डाउनलोड करेगा जब वह इनमें से किसी भी रिपॉजिटरी में नहीं मिलेगा। कंटेनर इंजन केवल लिखने योग्य भंडारण के लिए लिखने में सक्षम होगा ...

यदि आप स्क्रॉल करते हैं और 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 को संशोधित करते हैं, भंडारण ड्राइवर को "varimagestores" / var / lib / साझा फ़ोल्डर में उपयोग करने के लिए कह रहे हैं। और अगली पंक्ति में, एक साझा फ़ोल्डर बनाएं और लॉक फ़ाइलों की एक जोड़ी जोड़ें, ताकि कंटेनरों / भंडारण से कोई दुरुपयोग न हो। असल में, हम सिर्फ एक खाली कंटेनर इमेज स्टोरेज बनाते हैं।

यदि आप इस फ़ोल्डर के ऊपर कंटेनरों / भंडारण को माउंट करते हैं, तो बिल्डह छवियों का उपयोग करने में सक्षम होगा।

अब ऊपर दिए गए विकल्प 2 पर चर्चा करें, जब एक Buildah कंटेनर मेजबानों पर / कंटेनरों में स्टोर को पढ़ और लिख सकता है और, तदनुसार, पॉडमैन / 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 / कंटेनर्स / स्टोरेज होस्ट / var / lib / में साझा किया गया है, केवल-पढ़ने के लिए मोड में कंटेनर के अंदर साझा किया गया है। इसलिए, एक कंटेनर में काम करते हुए, बिल्डहा किसी भी चित्र का उपयोग कर सकता है जो पहले पॉडमैन / सीआरआई-ओ (हाय, गति) का उपयोग करके डाउनलोड किया गया था, लेकिन केवल अपने स्वयं के भंडार (हाय, सुरक्षा) को लिख सकता है। यह भी ध्यान दें कि यह कंटेनर के लिए SELinux जुदाई को अक्षम किए बिना किया गया है।

महत्वपूर्ण बारीकियों

किसी भी स्थिति में आपको अंतर्निहित भंडारण से कोई चित्र नहीं हटाना चाहिए। अन्यथा, Buildah कंटेनर बाहर उड़ सकता है।

और यह सभी फायदे नहीं हैं।

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

अब यह नेटवर्क स्टोरेज को Buildah कंटेनर में / var / lib / साझा पर माउंट करने के लिए पर्याप्त है और सभी - Buildah कंटेनर को अब पुल के माध्यम से चित्र डाउनलोड नहीं करना है। इस प्रकार हम पूर्व-जनसंख्या के चरण को समाप्त कर देते हैं और कंटेनरों को बाहर निकालने के लिए तुरंत तैयार हो जाते हैं।

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

कंटेनर छवियों का आकार कभी-कभी कई गीगाबाइट तक पहुंच सकता है। अतिरिक्त स्टोरेज की कार्यक्षमता आपको नोड्स द्वारा ऐसी छवियों को क्लोन करने के बिना करने की अनुमति देती है और कंटेनरों को लगभग तुरंत लॉन्च करती है।

इसके अलावा, हम वर्तमान में एक नए ओवरले वॉल्यूम माउंट फ़ंक्शन पर काम कर रहे हैं जो कंटेनर असेंबली को और भी तेज कर देगा।

निष्कर्ष

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

अतिरिक्त स्टोरेज की कार्यक्षमता आपको नोड्स में छवियों के डाउनलोड को गति देने या पूरी तरह से समाप्त करने की अनुमति देती है।

एक कंटेनर के अंदर बिल्डह को चलाने के लिए सर्वोत्तम अभ्यास