🥇 कंटेनरमध्ये बिल्डा चालवण्याच्या शिफारसी

कंटेनर रनटाइमला स्वतंत्र टूलींग घटकांमध्ये डीकपलिंग करण्याचे सौंदर्य काय आहे? विशेषतः, ही साधने एकत्र करणे सुरू होऊ शकते जेणेकरून ते एकमेकांचे संरक्षण करतील.

अनेक लोक कंटेनरीकृत OCI प्रतिमा तयार करण्याच्या कल्पनेकडे आकर्षित होतात कुबेरनेट्स किंवा तत्सम प्रणाली. समजा आमच्याकडे एक CI/CD आहे जी सतत प्रतिमा संकलित करते, नंतर असे काहीतरी रेड हॅट ओपनशिफ्ट/कुबर्नेट्स बिल्ड दरम्यान लोड बॅलन्सिंगच्या दृष्टीने उपयुक्त ठरतील. अलीकडे पर्यंत, बहुतेक लोकांनी कंटेनरला डॉकर सॉकेटमध्ये प्रवेश दिला आणि त्यांना डॉकर बिल्ड कमांड चालवण्याची परवानगी दिली. काही वर्षांपूर्वी आम्ही दाखवलेकी हे खूप असुरक्षित आहे, खरेतर, हे पासवर्डलेस रूट किंवा sudo देण्यापेक्षाही वाईट आहे.

म्हणूनच लोक सतत कंटेनरमध्ये बिल्डा चालवण्याचा प्रयत्न करतात. थोडक्यात, आम्ही तयार केले उदाहरण आमच्या मते, कंटेनरमध्ये बिल्डा चालवणे कसे चांगले आहे आणि संबंधित प्रतिमा यावर पोस्ट केल्या आहेत quay.io/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 ऐवजी, आम्ही कंटेनरच्या आत प्रोग्राम वापरतो फ्यूज-आच्छादन, कारण सध्या OverlayFS फक्त माउंट करू शकते जर तुम्ही Linux क्षमता वापरून SYS_ADMIN परवानग्या दिल्या. आणि आम्हाला आमचे Buildah कंटेनर कोणत्याही मूळ विशेषाधिकाराशिवाय चालवायचे आहेत. फ्यूज-ओव्हरले खूप लवकर कार्य करते आणि VFS स्टोरेज ड्रायव्हरपेक्षा चांगले कार्यप्रदर्शन आहे. कृपया लक्षात घ्या की फ्यूज वापरणारा बिल्डा कंटेनर चालवताना, तुम्ही /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 मध्ये ठेवेल. म्हणून, आम्हाला या फोल्डरमध्ये सामग्री माउंट करणे आवश्यक आहे आणि आम्ही हे कसे करतो याचा कंटेनर प्रतिमा तयार करण्याच्या गतीवर मोठ्या प्रमाणात परिणाम होईल.

चला तीन पर्यायांचा विचार करूया.

व्हेरिएंट एक्सएनयूएमएक्स. जास्तीत जास्त सुरक्षितता आवश्यक असल्यास, प्रत्येक कंटेनरसाठी आपण कंटेनर/प्रतिमेसाठी आपले स्वतःचे फोल्डर तयार करू शकता आणि व्हॉल्यूम-माउंटद्वारे कंटेनरशी कनेक्ट करू शकता. आणि याशिवाय, /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.

कामगिरी परंतु येथे कार्यप्रदर्शन अत्यल्प आहे, कारण कंटेनर रेजिस्ट्रीमधील कोणत्याही प्रतिमा प्रत्येक वेळी होस्टवर कॉपी केल्या जातात आणि कॅशिंग अजिबात कार्य करत नाही. त्याचे कार्य पूर्ण करताना, बिल्डा कंटेनरने रेजिस्ट्रीमध्ये प्रतिमा पाठविली पाहिजे आणि होस्टवरील सामग्री नष्ट केली पाहिजे. पुढील वेळी कंटेनर प्रतिमा तयार केल्यावर, ती पुन्हा रेजिस्ट्रीमधून डाउनलोड करावी लागेल, कारण तोपर्यंत होस्टवर काहीही शिल्लक राहणार नाही.

व्हेरिएंट एक्सएनयूएमएक्स. तुम्हाला डॉकर-स्तरीय कामगिरीची आवश्यकता असल्यास, तुम्ही होस्ट कंटेनर/स्टोरेज थेट कंटेनरमध्ये माउंट करू शकता.

# 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 कंटेनरमधील प्रक्रिया होस्टवरील स्टोरेजशी संवाद साधू शकतील. लक्षात घ्या की हा पर्याय डॉकर सॉकेटपेक्षा अजूनही चांगला आहे कारण कंटेनर उर्वरित सुरक्षा वैशिष्ट्यांद्वारे लॉक केलेला आहे आणि होस्टवर फक्त कंटेनर चालवू शकत नाही.

कामगिरी येथे ते कमाल आहे, कारण कॅशिंग पूर्णपणे वापरले जाते. जर पॉडमॅन किंवा CRI-O ने यजमानाला आवश्यक प्रतिमा आधीच डाउनलोड केली असेल, तर कंटेनरमधील बिल्डाह प्रक्रियेला ती पुन्हा डाउनलोड करावी लागणार नाही आणि या प्रतिमेवर आधारित पुढील बिल्ड देखील कॅशेमधून आवश्यक ते घेऊ शकतील. .

व्हेरिएंट एक्सएनयूएमएक्स. कंटेनर प्रतिमांसाठी एका सामान्य फोल्डरसह एका प्रकल्पात अनेक प्रतिमा एकत्र करणे हे या पद्धतीचे सार आहे.

# 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" वापरण्यास सांगतो. आणि पुढील ओळीत आम्ही एक सामायिक फोल्डर तयार करतो आणि काही लॉक फाइल्स जोडतो जेणेकरून कंटेनर/स्टोरेजचा गैरवापर होणार नाही. मूलत:, आम्ही फक्त एक रिक्त कंटेनर प्रतिमा स्टोअर तयार करत आहोत.

तुम्ही कंटेनर/स्टोरेज या फोल्डरपेक्षा वरच्या स्तरावर माउंट केल्यास, 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 वर फक्त-वाचनीय मोडमध्ये माउंट केले आहे. म्हणून, कंटेनरमध्ये काम करताना, बिल्डा पूर्वी पॉडमॅन/सीआरआय-ओ (हॅलो, स्पीड) वापरून डाउनलोड केलेल्या कोणत्याही प्रतिमा वापरू शकते, परंतु केवळ स्वतःच्या स्टोरेजवर (हॅलो, सुरक्षा) लिहू शकते. हे देखील लक्षात घ्या की हे कंटेनरसाठी SELinux पृथक्करण अक्षम न करता केले जाते.

महत्त्वपूर्ण प्रेरणा

कोणत्याही परिस्थितीत तुम्ही अंतर्निहित भांडारातून कोणतीही प्रतिमा हटवू नये. अन्यथा, बिल्डाह कंटेनर क्रॅश होऊ शकतो.

आणि हे सर्व फायदे नाहीत

अतिरिक्त स्टोरेजची शक्यता वरील परिस्थितीपुरती मर्यादित नाही. उदाहरणार्थ, तुम्ही सर्व कंटेनर प्रतिमा शेअर केलेल्या नेटवर्क स्टोरेजवर ठेवू शकता आणि सर्व 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

कंटेनरमध्ये बिल्डा चालवण्यासाठी शिफारसी