एक कंटेनर के अंदर Buildah चलाने के लिए अनुशंसाएँ

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

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

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

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

# 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 नियमों को शिथिल करने की आवश्यकता होगी, जो एक सुरक्षित कंटेनर से निर्माण करने की हमारी प्राथमिकता के विपरीत है।

एक कंटेनर के अंदर बिल्डाह चलाना

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

गति बनाम सुरक्षा

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

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

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

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

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

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

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

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

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

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

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

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

किसी भी परिस्थिति में आपको अंतर्निहित रिपॉजिटरी से कोई भी छवि नहीं हटानी चाहिए। अन्यथा, बिल्डाह कंटेनर क्रैश हो सकता है।

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

अतिरिक्त भंडारण की संभावनाएँ उपरोक्त परिदृश्य तक सीमित नहीं हैं। उदाहरण के लिए, आप सभी कंटेनर छवियों को एक साझा नेटवर्क स्टोरेज पर रख सकते हैं और सभी बिल्डाह कंटेनरों तक इसकी पहुंच दे सकते हैं। मान लीजिए कि हमारे पास सैकड़ों छवियां हैं जिनका उपयोग हमारा सीआई/सीडी सिस्टम नियमित रूप से कंटेनर छवियां बनाने के लिए करता है। हम इन सभी छवियों को एक स्टोरेज होस्ट पर केंद्रित करते हैं और फिर, पसंदीदा नेटवर्क स्टोरेज टूल्स (एनएफएस, ग्लस्टर, सेफ, आईएससीएसआई, एस3...) का उपयोग करके, हम सभी बिल्डाह या कुबेरनेट्स नोड्स के लिए इस स्टोरेज तक सामान्य पहुंच खोलते हैं।

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

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

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

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

निष्कर्ष

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

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

स्रोत: www.habr.com