🐉 👨🏻‍✈️ 🐨 डॉक चित्र भी सामान्य डॉकफाइल के उपयोग से वेयरफ में बनाए जा सकते हैं 🧕🏼 🤴🏿 🈷️

देर से कभी बेहतर। या कैसे हमने लगभग एक गंभीर गलती की, आवेदन छवियों के निर्माण के लिए साधारण डॉकफाइल्स का समर्थन नहीं किया।

हम werf , एक GitOps उपयोगिता के बारे में बात करेंगे जो कि किसी भी CI / CD सिस्टम के साथ एकीकृत होती है और आपको संपूर्ण एप्लिकेशन जीवन चक्र पर नियंत्रण प्रदान करती है, जिससे आप निम्न कर सकते हैं:

छवियों को इकट्ठा और प्रकाशित करें
कुबेरनेट्स में अनुप्रयोगों को तैनात करें
विशेष नीतियों का उपयोग करके अप्रयुक्त छवियों को हटा दें।

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

बैकग्राउंड: योर इमेज कलेक्टर

यह वही है जो वसेफ में इमेज कलेक्टर के साथ हुआ था: हमारे पास सामान्य डॉकरीफाइल नहीं था। यदि आप जल्दी से परियोजना के इतिहास में उतर जाते हैं, तो यह समस्या खुद के पहले संस्करणों में प्रकट हुई (तब भी डैप के रूप में जाना जाता है )।

डॉकर छवियों में अनुप्रयोगों के निर्माण के लिए एक उपकरण बनाना, हमने जल्दी ही महसूस किया कि डॉकफाइल कुछ बहुत ही विशिष्ट कार्यों के लिए उपयुक्त नहीं था:

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

आज हमारे कलेक्टर में कई अन्य संभावनाएं हैं, लेकिन शुरुआती इच्छाएं और आग्रह थे।

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

रूबी पर डैप के लिए पुराना विन्यास

YAML पर werf के लिए वर्तमान विन्यास

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

नायब : फिलहाल, हमारा कलेक्टर, जो अपने विन्यास (YAML में) के साथ काम करता है और जिसे स्टेपल-कलेक्टर कहा जाता है, पहले से ही एक काफी शक्तिशाली उपकरण के रूप में विकसित हो चुका है। इसका विस्तृत विवरण अलग लेखों का हकदार है, और मुख्य विवरण प्रलेखन में पाया जा सकता है।

समस्या जागरूकता

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

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

NB : वैसे, तुम भी क्यों werf का उपयोग करना चाहते हैं? मुख्य विशेषताएं इस प्रकार हैं:

छवि सफाई सहित पूर्ण अनुप्रयोग प्रबंधन चक्र;
एक ही विन्यास से कई छवियों की विधानसभा को नियंत्रित करने की क्षमता;
बेहतर हेल्म संगत चार्ट परिनियोजन प्रक्रिया।

उनकी एक पूरी सूची परियोजना पृष्ठ पर पाई जा सकती है।

इसलिए, अगर पहले हम अपने कॉन्फिगरेशन के लिए डॉकरीफाइल को फिर से लिखने का सुझाव देंगे, तो अब हम यह कहते हुए खुश होंगे: "लेट वेयरफ ने आपके डॉकरफाइल्स का निर्माण किया!"

कैसे करें इस्तेमाल?

इस सुविधा का पूर्ण कार्यान्वयन वेयरफ v1.0.3-beta.1 रिलीज में दिखाई दिया। सामान्य सिद्धांत सरल है: उपयोगकर्ता werf config में मौजूदा Dockerfile के लिए पथ निर्दिष्ट करता है, और फिर werf build ... कमांड चलाता है और यही है - werf छवि एकत्र करेगा। एक सार उदाहरण पर विचार करें।

परियोजना की जड़ में निम्नलिखित Dockerfile :

 FROM ubuntu:18.04 RUN echo Building ...

और इस Dockerfile का उपयोग करने वाले werf.yaml घोषणा करें:

 configVersion: 1 project: dockerfile-example --- image: ~ dockerfile: ./Dockerfile

वह सब है! यह चलाने के लिए बनी हुई है werf build :

इसके अलावा, आप एक ही बार में विभिन्न डॉकफाइल्स से कई छवियों के निर्माण के लिए निम्न werf.yaml घोषणा कर सकते हैं:

 configVersion: 1 project: dockerfile-example --- image: backend dockerfile: ./dockerfiles/Dockerfile-backend --- image: frontend dockerfile: ./dockerfiles/Dockerfile-frontend

अंत में, यह अतिरिक्त बिल्ड मापदंडों के हस्तांतरण का भी समर्थन करता है - जैसे कि --build-arg और --add-host - werf config के माध्यम से। प्रलेखन पृष्ठ पर डॉकफाइल छवि विन्यास का पूरा विवरण उपलब्ध है।

यह कैसे काम करता है?

निर्माण प्रक्रिया के दौरान, डॉकर कार्यों में मानक स्थानीय परत कैश। हालांकि, महत्वपूर्ण रूप से, वेयरफ भी अपने बुनियादी ढांचे में डॉकरफाइल कॉन्फ़िगरेशन को एकीकृत करता है । इसका क्या मतलब है?

Dockerfile से एकत्र की गई प्रत्येक छवि में dockerfile नामक एक चरण शामिल dockerfile ( dockerfile में कौन से चरण हैं, आप यहाँ पढ़ सकते हैं)।
स्टेज के लिए, dockerfile वसेफ हस्ताक्षर की गणना करता है, जो डॉकरफाइल कॉन्फ़िगरेशन की सामग्री पर निर्भर करता है। जब Dockerfile कॉन्फ़िगरेशन को बदल दिया जाता है, तो dockerfile स्टेज सिग्नेचर dockerfile और werf नए Dockerfile कॉन्फिगरेशन के साथ इस स्टेज के पुनर्निर्माण की पहल करता है। यदि हस्ताक्षर नहीं बदलता है, तो वेयरफ छवि को कैश से लेता है ( इस रिपोर्ट में वेयरफ में हस्ताक्षर के उपयोग पर अधिक विवरण वर्णित थे) ।
इसके अलावा, एकत्रित छवियों werf publish कमांड (या werf build-and-publish ) werf publish प्रकाशित किया जा सकता है और कुबेरनेट्स में तैनाती के लिए उपयोग किया जाता है। डॉकर रजिस्ट्री में प्रकाशित छवियां मानक वेयरफ क्लीनर के साथ साफ हो जाएंगी, अर्थात। यह स्वचालित रूप से पुरानी छवियों (N दिनों से अधिक पुरानी), गैर-मौजूद Git शाखाओं और अन्य नीतियों से जुड़ी छवियां साफ़ कर देगा।

आप प्रलेखन से यहाँ वर्णित बिंदुओं के बारे में अधिक जान सकते हैं:

नोट्स और सावधानियां

1. ADD में बाहरी URL समर्थित नहीं है

वर्तमान में ADD निर्देश में बाहरी URL का उपयोग करना समर्थित नहीं है। जब कोई संसाधन निर्दिष्ट URL में बदलता है, तो Werf पुनर्निर्माण की शुरुआत नहीं करेगा। जल्द ही इस सुविधा को जोड़ने की योजना है।

आप एक छवि के लिए .git जोड़ नहीं सकते

आम तौर पर बोलना, एक छवि के लिए .git निर्देशिका को जोड़ना एक ~~शातिर~~ बुरा व्यवहार है, और यहाँ क्यों है:

यदि .git अंतिम छवि में रहता है, तो यह 12 फ़ैक्टर ऐप के सिद्धांतों का उल्लंघन करता है: चूंकि अंतिम छवि को एक कमिट के साथ जोड़ा जाना चाहिए, इसलिए एक मनमाने ढंग से कमिट git checkout करना संभव नहीं होना चाहिए।
.git छवि का आकार बढ़ाता है (रिपॉजिटरी इस तथ्य के कारण बड़ी हो सकती है कि बड़ी फ़ाइलों को एक बार इसमें जोड़ा गया था और फिर हटा दिया गया था)। कार्य-वृक्ष का आकार, केवल एक विशिष्ट प्रतिबद्ध के साथ जुड़ा हुआ है, जो गिट में संचालन के इतिहास पर निर्भर नहीं करेगा। एक ही समय में, अंतिम छवि से .git को जोड़ने और फिर काम करने से काम नहीं चलेगा: छवि को अभी भी एक अतिरिक्त परत मिलेगी - यह है कि डॉकर कैसे काम करता है।
डॉकर अनावश्यक पुनर्निर्माण की शुरुआत कर सकता है, भले ही एक ही प्रतिबद्ध बनाया जा रहा हो, लेकिन विभिन्न कार्य-वृक्षों से। उदाहरण के लिए, समानांतर विधानसभा सक्षम होने पर /home/gitlab-runner/builds/HASH/[0-N]/yourproject में अलग क्लोन निर्देशिका /home/gitlab-runner/builds/HASH/[0-N]/yourproject है। अतिरिक्त पुनर्निर्माण इस तथ्य के कारण होगा कि .git निर्देशिका समान रिपॉजिटरी के अलग-अलग क्लोन संस्करणों में भिन्न होती है, भले ही वही प्रतिबद्ध एकत्र किया गया हो।

अंतिम बिंदु का परिणाम है जब वेयरफ का उपयोग किया जाता है। Werf के लिए आवश्यक है कि एकत्रित कैश तब मौजूद हो जब कुछ कमांड चलाए जाते हों (उदाहरण के लिए, werf deploy )। ऐसे आदेशों के संचालन के दौरान, werf, werf.yaml में निर्दिष्ट चित्रों के लिए चरण हस्ताक्षर की गणना करता है, और उन्हें असेंबली कैश में होना चाहिए - अन्यथा टीम काम करना जारी रखने में सक्षम नहीं होगी। यदि चरणों का हस्ताक्षर .git की सामग्री पर निर्भर करता है, तो हमें एक कैश मिलता है जो अप्रासंगिक फाइलों में बदलाव के लिए अस्थिर है, और werf ऐसी गलती को माफ नहीं कर पाएंगे (अधिक विवरण के लिए प्रलेखन देखें)।

सामान्य तौर पर, किसी भी मामले में ADD निर्देश के माध्यम से केवल कुछ आवश्यक फाइलों को जोड़ने से लिखित Dockerfile की दक्षता और विश्वसनीयता बढ़ जाती है, और गिट में अप्रासंगिक परिवर्तनों के खिलाफ इस Dockerfile द्वारा संकलित कैश की स्थिरता में भी सुधार होता है।

परिणाम

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

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

तो अगर तुम अचानक Dockerfiles की एक जोड़ी के आसपास पड़ा था ... Tryf !

पुनश्च संबंधित दस्तावेज की सूची

हमारे ब्लॉग पर यह भी पढ़ें: " Kubernetes में हमारे CI / CD टूल हैं (समीक्षा और वीडियो रिपोर्ट) ।"

डॉक चित्र भी सामान्य डॉकफाइल के उपयोग से वेयरफ में बनाए जा सकते हैं