अब आप नियमित डॉकरफाइल का उपयोग करके वेयरफ में डॉकर छवियां बना सकते हैं

देर आए दुरुस्त आए। या कैसे हमने एप्लिकेशन छवियां बनाने के लिए नियमित डॉकरफ़ाइल्स का समर्थन न करके लगभग एक गंभीर गलती की है।

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

• छवियाँ एकत्र करें और प्रकाशित करें,
• कुबेरनेट्स में एप्लिकेशन तैनात करें,
• विशेष नीतियों का उपयोग करके अप्रयुक्त छवियों को हटाएं।

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

पृष्ठभूमि: आपका अपना छवि संग्राहक

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

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

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

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

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

रूबी में डैप के लिए पुराना कॉन्फिगरेशन

YAML पर वेयरफ़ के लिए वर्तमान कॉन्फ़िगरेशन

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

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

समस्या के प्रति जागरूकता

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

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

NB: वैसे, आप वेयरफ़ का उपयोग क्यों करना चाहेंगे? मुख्य विशेषताएं निम्नलिखित हैं:

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

उनकी अधिक संपूर्ण सूची यहां पाई जा सकती है प्रोजेक्ट पेज.

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

कैसे उपयोग करें?

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

चलिए अगले की घोषणा करते हैं Dockerfile प्रोजेक्ट रूट में:

FROM ubuntu:18.04
RUN echo Building ...

और हम घोषणा करेंगे werf.yamlजो इसका उपयोग करता है Dockerfile:

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

सभी! बाएं रन werf build:

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

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

अंत में, यह अतिरिक्त बिल्ड पैरामीटर्स को पास करने का भी समर्थन करता है, जैसे --build-arg и --add-host - वेयरफ़ कॉन्फ़िगरेशन के माध्यम से। Dockerfile छवि कॉन्फ़िगरेशन का पूरा विवरण यहां उपलब्ध है दस्तावेज़ पृष्ठ.

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

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

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

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

• प्रकाशन प्रक्रिया;
• कुबेरनेट्स परिनियोजन प्रक्रिया के साथ एकीकरण;
• सफाई की प्रक्रिया.

टिप्पणियाँ और सावधानियाँ

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

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

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

सामान्यतया, एक निर्देशिका जोड़ना .git छवि में - एक भयानक कुप्रथा और इसका कारण यहाँ बताया गया है:

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

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

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

संपूर्ण

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

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

इसलिए, यदि आपके पास अचानक कुछ Dockerfiles पड़ी हों... कोशिश Werf!

विषय पर प्रलेखन की पीएस सूची

• त्वरित शुरुआत के लिए दिशानिर्देश;
• dockerfile बिल्डर कॉन्फ़िगरेशन;
• वेयरफ़ में स्टेज डिवाइस;
• छवि प्रकाशन प्रक्रिया;
• कुबेरनेट्स परिनियोजन प्रक्रिया के साथ एकीकरण;
• सफाई की प्रक्रिया;
• Dockerfile के विकल्प के रूप में स्टेपल बिल्डर.

हमारे ब्लॉग में भी पढ़ें: “werf - कुबेरनेट्स में CI / CD के लिए हमारा टूल (अवलोकन और वीडियो रिपोर्ट)'.

स्रोत: www.habr.com