कुबेरनेट्स: एक क्लस्टर में डॉकर छवियों का निर्माण

आप डंकर के बिना करते हुए डंकर छवियों को कंटेनर में बनाने के लिए कनीको का उपयोग कर सकते हैं। आइए जानें कि स्थानीय रूप से और कुबेरनेट समूह में काइको कैसे चलाया जाए।

आगे एक मल्टी-बुक होगी

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

हम Docker-in-Docker और इसके वैकल्पिक, kaniko के बारे में भी बात करेंगे, जिसके साथ आप Docker का उपयोग किए बिना Docker चित्र बना सकते हैं। अंत में, हम सीखेंगे कि कुबेरनेट क्लस्टर में छवि असेंबली को कैसे कॉन्फ़िगर किया जाए।

कुबेरनेट्स का एक सामान्य विवरण "कुबेरनेट्स इन एक्शन" ("कुबेरनेट्स इन एक्शन") पुस्तक में है ।

वास्तविक उदाहरण

मूल वेब में, हमारे पास कई निजी डॉकर छवियां हैं जिन्हें कहीं संग्रहीत करने की आवश्यकता है। इसलिए हमने एक निजी डॉकर हब लागू किया। पब्लिक डॉकर हब में दो विशेषताएं हैं, जिनमें हम विशेष रूप से रुचि रखते हैं।

सबसे पहले, हम एक कतार बनाना चाहते थे जो डोनर इमेज को कुबेरनेट्स में अतुल्य रूप से एकत्रित करेगी। दूसरे, एकत्र छवियों को निजी डोकर रजिस्ट्री में भेजने का कार्यान्वयन करें।

आमतौर पर, डॉकर सीएलआई का उपयोग सीधे इन कार्यों को लागू करने के लिए किया जाता है:

$ docker build ... $ docker push ... 

लेकिन कुबेरनेट्स क्लस्टर में, हम छोटे और प्राथमिक लिनक्स छवियों के आधार पर कंटेनरों की मेजबानी करते हैं, जिसमें डोकर डिफ़ॉल्ट रूप से निहित नहीं है। अगर अब हम डॉकटर (जैसे docker build... ) का उपयोग किसी कंटेनर में करना चाहते हैं, तो हमें डोकर-इन-डॉकर जैसी किसी चीज की जरूरत है।

डॉकटर-इन-डॉकर में क्या गलत है?

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

कानिको के साथ परिचित होना

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

बस यह ध्यान रखें कि कानिको अभी भी विकास के अधीन है और सभी डॉकफाइल कमांड का समर्थन नहीं करता है, उदाहरण के लिए - COPY लिए --chownflag ।

कानिको लांच

यदि आप kaniko चलाना चाहते हैं, तो आपको kaniko कंटेनर के लिए कई तर्क निर्दिष्ट करने की आवश्यकता है। सबसे पहले अपने सभी आश्रितों के साथ डिकोफराइल को कानिको कंटेनर में डालें। स्थानीय रूप से (डॉकर में), -v <__>:<__> विकल्प का उपयोग इसके लिए किया जाता है -v <__>:<__> कंटेनर_पैथ -v <__>:<__> , और कुबेरनेट्स के पास वॉल्यूम हैं ।

Kaniko कंटेनर में निर्भरता Dockerfile सम्मिलित करने के बाद, तर्क --context जोड़ें, यह संलग्न निर्देशिका (कंटेनर के अंदर) के लिए पथ को इंगित करेगा। अगला तर्क है - --dockerfile । यह डॉकरफाइल (नाम सहित) के लिए पथ को इंगित करता है। एक अन्य महत्वपूर्ण तर्क डॉकरी रजिस्ट्री (नाम और छवि टैग सहित) के लिए पूर्ण URL के साथ --destination ।

स्थानीय लॉन्च

कनीको कई तरीकों से शुरू होता है। उदाहरण के लिए, डॉकर का उपयोग कर रहे स्थानीय कंप्यूटर पर (ताकि कुबेरनेट क्लस्टर के साथ गड़बड़ न हो)। निम्न आदेश के साथ रन kaniko:

 $ docker run \ -v $(pwd):/workspace \ gcr.io/kaniko-project/executor:latest \ --dockerfile=<path-to-dockerfile> \ --context=/workspace \ --destination=<repo-url-with-image-name>:<tag> 

यदि प्रमाणीकरण को डॉकर रजिस्ट्री में सक्षम किया गया है, तो kaniko को पहले लॉग इन करना होगा। ऐसा करने के लिए, निम्न आदेश का उपयोग करके कांजीको कंटेनर में डॉक रजिस्ट्री के लिए क्रेडेंशियल्स के साथ स्थानीय डॉकर config.jsonfile को कनेक्ट करें:

 $ docker run \ -v $(pwd):/workspace \ -v ~/.docker/config.json:/kaniko/.docker/config.json \ gcr.io/kaniko-project/executor:latest \ --dockerfile=<path-to-dockerfile> \ --context=/workspace \ --destination=<repo-url-with-image-name>:<tag> 

कुबेरनेट्स में लॉन्च

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

सबसे आसान तरीका यह है कि PersistentVolumeClaim ऑब्जेक्ट (हमारे उदाहरण में, इसे kaniko-workspace कहा जाता है) का उपयोग करके एक kaniko कंटेनर में एक निर्भरता Dockerfile इंजेक्ट करें। यह एक निर्देशिका के रूप में कंटेनर के लिए बाध्य होगा, और सभी डेटा पहले से ही kaniko-workspace में होना चाहिए। मान लीजिए कि एक अन्य कंटेनर में पहले से ही kaniko-workspace में /my-build kaniko-workspace में निर्भरता के साथ एक डॉकफाइल है।

मत भूलो कि AWS में PersistentVolumeClaim के साथ परेशानी है। यदि आप AWS में PersistentVolumeClaim बनाते हैं, तो यह AWS क्लस्टर में केवल एक नोड पर दिखाई देगा और केवल वहीं उपलब्ध होगा। (अपडेट: वास्तव में, एक पीवीसी बनाते समय, आपके क्लस्टर के एक यादृच्छिक उपलब्धता क्षेत्र में एक RDS वॉल्यूम बनाया जाएगा। तदनुसार, यह वॉल्यूम इस ज़ोन में सभी मशीनों के लिए उपलब्ध होगा। कुबेरनेट्स खुद को नियंत्रित करता है कि इस पीवीसी का उपयोग करते हुए इसे उपलब्धता क्षेत्र में एक नोड पर लॉन्च किया जाएगा। RDS volyuma। - लगभग।) तो, यदि आप जॉब kaniko चलाते हैं और यह कार्य किसी अन्य नोड पर है, तो यह प्रारंभ नहीं होगा, क्योंकि PersistentVolumeClaim उपलब्ध नहीं है। आशा करते हैं कि अमेज़न इलास्टिक फाइल सिस्टम जल्द ही कुबेरनेट पर उपलब्ध होगा और समस्या दूर हो जाएगी। (अपडेट: कुबेरनेट्स में ईएफएस को भंडारण प्रावधान द्वारा समर्थित है। - लगभग ।)

डॉकर छवियों के निर्माण के लिए नौकरी संसाधन आमतौर पर इस तरह दिखता है:

 apiVersion: batch/v1 kind: Job metadata: name: build-image spec: template: spec: containers: - name: build-image image: gcr.io/kaniko-project/executor:latest args: - "--context=/workspace/my-build" - "--dockerfile=/workspace/my-build/Dockerfile" - "--destination=<repo-url-with-image-name>:<tag>" volumeMounts: - name: workspace mountPath: /workspace volumes: - name: workspace persistentVolumeClaim: claimName: kaniko-workspace restartPolicy: Never backoffLimit: 3 

यदि गंतव्य डॉक रजिस्ट्री को प्रमाणीकरण की आवश्यकता है, तो kaniko कंटेनर में क्रेडेंशियल्स के साथ config.json फ़ाइल पास करें। सबसे आसान तरीका यह है कि PersistentVolumeClaim को उस कंटेनर से कनेक्ट करें जिसमें पहले से ही config.json फ़ाइल है। यहाँ PersistentVolumeClaim एक निर्देशिका के रूप में नहीं, बल्कि /kaniko/.docker/config.json कंटेनर में /kaniko/.docker/config.json पथ में एक फ़ाइल के रूप में /kaniko/.docker/config.json :

 apiVersion: batch/v1 kind: Job metadata: name: build-image spec: template: spec: containers: - name: build-image image: gcr.io/kaniko-project/executor:latest args: - "--context=/workspace/my-build" - "--dockerfile=/workspace/my-build/Dockerfile" - "--destination=<repo-url-with-image-name>:<tag>" volumeMounts: - name: config-json mountPath: /kaniko/.docker/config.json subPath: config.json - name: workspace mountPath: /workspace volumes: - name: config-json persistentVolumeClaim: claimName: kaniko-credentials - name: workspace persistentVolumeClaim: claimName: kaniko-workspace restartPolicy: Never backoffLimit: 3 

यदि आप kubectl बिल्ड जॉब की स्थिति की जांच करना चाहते हैं, तो kubectl उपयोग kubectl । stdout द्वारा स्थिति को फ़िल्टर करने के लिए, कमांड चलाएँ:

 $ kubectl get job build-image -o go-template='{{(index .status.conditions 0).type}}' 

परिणाम

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