वेयरफ़ बिल्डर में सामग्री-आधारित टैगिंग: यह क्यों और कैसे काम करती है?

Werf — Kubernetes पर एप्लिकेशन बनाने और वितरित करने के लिए हमारी ओपन-सोर्स GitOps CLI उपयोगिता। में रिलीज़ v1.1 इमेज बिल्डर में एक नई सुविधा शुरू की गई: सामग्री या द्वारा छवियों को टैग करना सामग्री-आधारित टैगिंग. अब तक, werf में सामान्य टैगिंग योजना में Git टैग, Git शाखा, या Git कमिट द्वारा Docker छवियों को टैग करना शामिल था। लेकिन इन सभी योजनाओं में कमियां हैं जो नई टैगिंग रणनीति से पूरी तरह हल हो जाती हैं। इसके बारे में विस्तृत जानकारी तथा यह इतना अच्छा क्यों है, इसकी जानकारी नीचे दी गई है।

एकल Git रिपोजिटरी से माइक्रोसर्विसेज का एक सेट शुरू करना

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

ऐसी स्थितियाँ होती हैं जहाँ सेवाएँ वास्तव में स्वतंत्र होती हैं और किसी एकल अनुप्रयोग से बंधी नहीं होती हैं। इस मामले में, वे अलग-अलग परियोजनाओं में स्थित होंगे और उनकी रिलीज प्रत्येक परियोजना में अलग-अलग CI/CD प्रक्रियाओं के माध्यम से की जाएगी।

हालाँकि, वास्तविकता में, डेवलपर्स अक्सर एक ही एप्लिकेशन को कई माइक्रोसर्विसेज में विभाजित करते हैं, लेकिन प्रत्येक के लिए एक अलग रिपोजिटरी और प्रोजेक्ट बनाना... स्पष्ट रूप से ज़रूरत से ज़्यादा है। यह वह स्थिति है जिस पर हम आगे चर्चा करेंगे: ऐसी कई माइक्रोसर्विसेज एक ही प्रोजेक्ट रिपोजिटरी में स्थित होती हैं और रिलीज CI/CD में एक ही प्रक्रिया के माध्यम से होती है।

Git शाखा और Git टैग द्वारा टैगिंग

मान लीजिए कि सबसे आम टैगिंग रणनीति का उपयोग किया जाता है - टैग-या-शाखा. Git शाखाओं के लिए, छवियों को शाखा नाम के साथ टैग किया जाता है, और किसी दी गई शाखा के लिए शाखा नाम के साथ एक समय में केवल एक ही प्रकाशित छवि होती है। Git टैग के लिए, छवियों को टैग नाम के अनुसार टैग किया जाता है।

जब एक नया Git टैग बनाया जाता है - उदाहरण के लिए, जब एक नया संस्करण जारी किया जाता है - तो Docker रजिस्ट्री में सभी प्रोजेक्ट छवियों के लिए एक नया Docker टैग बनाया जाएगा:

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

इन नए छवि नामों को हेल्म टेम्पलेट्स के माध्यम से कुबेरनेट्स कॉन्फ़िगरेशन में भेजा जाता है। जब आप परिनियोजन आदेश चलाते हैं werf deploy फ़ील्ड को अपडेट किया जा रहा है image Kubernetes संसाधन मैनिफ़ेस्ट में छवि नाम बदलने के कारण संबंधित संसाधनों को पुनः आरंभ करना।

समस्या: उस स्थिति में जब छवि की सामग्री वास्तव में पिछले रोलआउट (Git टैग) के बाद से नहीं बदली है, लेकिन केवल उसका Docker टैग बदला है, अतिरिक्त इस एप्लिकेशन को पुनः आरंभ करने से कुछ डाउनटाइम संभव है। हालाँकि इस रीबूट को करने का कोई वास्तविक कारण नहीं था।

परिणामस्वरूप, वर्तमान टैगिंग योजना के साथ, कई अलग-अलग Git रिपॉजिटरी बनाना आवश्यक है, और इन कई रिपॉजिटरी के रोलआउट को व्यवस्थित करने की समस्या उत्पन्न होती है। सामान्यतः ऐसी योजना अतिभारित एवं जटिल हो जाती है। कई सेवाओं को एक ही रिपॉजिटरी में संयोजित करना और डॉकर टैग बनाना बेहतर है ताकि अनावश्यक पुनरारंभ न हो।

Git कमिट द्वारा टैगिंग

werf में Git कमिट्स से संबंधित टैगिंग रणनीति भी है।

Git-commit, Git रिपोजिटरी की सामग्री का पहचानकर्ता है और Git रिपोजिटरी में फ़ाइलों के संशोधन इतिहास पर निर्भर करता है, इसलिए Docker रजिस्ट्री में छवियों को टैग करने के लिए इसका उपयोग करना तर्कसंगत लगता है।

हालाँकि, Git कमिट द्वारा टैगिंग में वही कमियाँ हैं जो Git शाखाओं या Git टैग द्वारा टैगिंग में हैं:

• एक खाली कमिट बनाया जा सकता है जो किसी भी फ़ाइल को परिवर्तित नहीं करता है, और छवि का डॉकर टैग बदल दिया जाएगा।
• एक मर्ज कमिट बनाया जा सकता है जो किसी भी फ़ाइल को नहीं बदलता है, लेकिन छवि का डॉकर टैग बदल जाएगा।
• एक कमिट बनाया जा सकता है जो Git में उन फ़ाइलों को बदल देता है जिन्हें छवि में आयात नहीं किया गया है, और छवि का Docker टैग फिर से बदल दिया जाएगा।

Git शाखा नाम से टैग करने पर छवि संस्करण प्रतिबिंबित नहीं होता

गिट शाखा टैगिंग रणनीति के साथ एक और समस्या है।

शाखा नाम से टैगिंग तब तक काम करती है जब तक उस शाखा पर किए गए कार्य कालानुक्रमिक क्रम में क्रमिक रूप से एकत्रित किए जाते हैं।

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

इसके अतिरिक्त, एक ही शाखा में लगातार पुश करने के बीच थोड़े समय का अंतराल होने पर, पुराना कमिट नए कमिट की तुलना में बाद में बनाया जा सकता है: छवि का पुराना संस्करण Git शाखा टैग द्वारा नए संस्करण को अधिलेखित कर देगा। ऐसी समस्याओं को CI/CD प्रणाली द्वारा हल किया जा सकता है (उदाहरण के लिए, GitLab CI में, बाद की पाइपलाइन को कमिट की एक श्रृंखला के लिए लॉन्च किया जाता है)। हालाँकि, सभी प्रणालियाँ इसका समर्थन नहीं करती हैं और ऐसी मौलिक समस्या को रोकने के लिए अधिक विश्वसनीय तरीका होना चाहिए।

सामग्री-आधारित टैगिंग क्या है?

तो फिर, सामग्री-आधारित टैगिंग क्या है?

Docker टैग बनाने के लिए, हम Git प्राइमिटिव्स (Git शाखा, Git टैग...) का उपयोग नहीं करते हैं, बल्कि इसके साथ जुड़े चेकसम का उपयोग करते हैं:

• छवि सामग्री. छवि पहचानकर्ता टैग उसकी सामग्री को प्रतिबिंबित करता है। नया संस्करण बनाते समय, यदि छवि में फ़ाइलें नहीं बदली गई हैं तो यह पहचानकर्ता नहीं बदलेगा;
• Git में इस छवि निर्माण का इतिहास. विभिन्न Git शाखाओं और werf के माध्यम से विभिन्न निर्माण इतिहास से जुड़ी छवियों में अलग-अलग ID टैग होंगे।

तथाकथित टैग ऐसे ही पहचानकर्ता के रूप में कार्य करता है। छवि मंच हस्ताक्षर.

प्रत्येक छवि में चरणों का एक सेट शामिल होता है: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch आदि। प्रत्येक चरण में एक पहचानकर्ता होता है जो उसकी सामग्री को दर्शाता है, मंच हस्ताक्षर (मंच हस्ताक्षर).

इन चरणों से मिलकर बनी अंतिम छवि को इन चरणों के समूह के तथाकथित हस्ताक्षर के साथ टैग किया जाता है - चरण हस्ताक्षर, - जो छवि के सभी चरणों के लिए सामान्यीकरण है।

कॉन्फ़िगरेशन से प्रत्येक छवि werf.yaml सामान्यतः, ऐसा एक हस्ताक्षर होगा और तदनुसार, एक डॉकर टैग होगा।

स्टेज सिग्नेचर इन सभी समस्याओं का समाधान करता है:

• खाली Git प्रतिबद्धताओं के प्रति लचीला।
• Git प्रतिबद्धताओं के प्रति लचीला, जो छवि से अप्रासंगिक फ़ाइलों को परिवर्तित कर देता है।
• शाखा के पुराने Git कमिट्स के लिए बिल्ड को पुनः आरंभ करने पर छवि के वर्तमान संस्करण को मिटाने की समस्या उत्पन्न नहीं होती है।

यह अब अनुशंसित टैगिंग रणनीति है और सभी CI प्रणालियों के लिए werf में डिफ़ॉल्ट रूप से इसका उपयोग किया जाता है।

werf में सक्षम और उपयोग कैसे करें

टीम में संबंधित विकल्प दिखाई दिया werf publish: --tag-by-stages-signature=true|false

CI सिस्टम में, टैगिंग रणनीति कमांड द्वारा निर्धारित की जाती है werf ci-env. पहले इसके लिए एक पैरामीटर निर्धारित किया गया था werf ci-env --tagging-strategy=tag-or-branch. अब, यदि हम निर्दिष्ट करें werf ci-env --tagging-strategy=stages-signature या यदि आप यह विकल्प निर्दिष्ट नहीं करते हैं, तो werf डिफ़ॉल्ट रूप से टैगिंग रणनीति का उपयोग करेगा stages-signature. टीम werf ci-env टीम के लिए आवश्यक झंडे स्वचालित रूप से सेट कर देगा werf build-and-publish (या werf publish), इसलिए इन कमांडों के लिए कोई अतिरिक्त विकल्प निर्दिष्ट करने की आवश्यकता नहीं है।

उदाहरण के लिए, आदेश:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

… निम्नलिखित चित्र बना सकते हैं:

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

यहां 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d - यह छवि चरणों का हस्ताक्षर है backendऔर f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 — छवि चरणों के हस्ताक्षर frontend.

विशेष कार्यों का उपयोग करते समय werf_container_image и werf_container_env हेल्म टेम्पलेट्स में कुछ भी बदलने की आवश्यकता नहीं है: ये फ़ंक्शन स्वचालित रूप से सही छवि नाम उत्पन्न करेंगे।

CI प्रणाली में कॉन्फ़िगरेशन का उदाहरण:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

सेटअप के बारे में अधिक जानकारी दस्तावेज़ में उपलब्ध है:

• निर्देशिका → प्रकाशन (प्रकाशित करें);
• CI/CD के साथ कार्य करना → सामान्य जानकारी → चरण-हस्ताक्षर;
• GitLab CI/CD के साथ एकीकरण → .gitlab-ci.yml.

कुल मिलाकर

• नया विकल्प werf publish --tag-by-stages-signature=true|false.
• विकल्प का नया मूल्य werf ci-env --tagging-strategy=stages-signature|tag-or-branch (यदि निर्दिष्ट नहीं है, तो डिफ़ॉल्ट होगा stages-signature).
• यदि आपने पहले Git कमिट टैगिंग विकल्पों का उपयोग किया है (WERF_TAG_GIT_COMMIT या विकल्प werf publish --tag-git-commit COMMIT), तो टैगिंग रणनीति पर स्विच करना आवश्यक है चरण-हस्ताक्षर.
• बेहतर होगा कि नई परियोजनाओं को तुरंत नई टैगिंग योजना में बदल दिया जाए।
• पुरानी परियोजनाओं को werf 1.1 में स्थानांतरित करते समय, नई टैगिंग योजना पर स्विच करना उचित है, हालाँकि, पुरानी टैग-या-शाखा अभी भी समर्थित है.

सामग्री-आधारित टैगिंग लेख में शामिल सभी समस्याओं का समाधान करती है:

• खाली Git प्रतिबद्धताओं के लिए Docker टैग नाम लचीलापन।
• Git कमिट्स के प्रति Docker टैग नाम की लचीलापन, उन फ़ाइलों को परिवर्तित करता है जो छवि के लिए अप्रासंगिक हैं।
• Git शाखाओं के लिए पुराने Git प्रतिबद्धताओं के लिए बिल्ड को पुनः आरंभ करने पर छवि के वर्तमान संस्करण को मिटाने में समस्या नहीं होती है।

आनंद लेना! और हमसे मिलने आना मत भूलना GitHub, कोई मुद्दा बनाने या किसी मौजूदा मुद्दे को खोजने के लिए, प्लस लगाएं, पीआर बनाएं या सिर्फ परियोजना के विकास को देखें।

पुनश्च

हमारे ब्लॉग पर भी पढ़ें:

• «वेयरफ़ 1.1 रिलीज़: बिल्डर में आज सुधार और भविष्य के लिए योजनाएँ»
• «werf 1.0 स्थिर का परिचय: GitOps का इससे क्या संबंध है, स्थिति और योजनाएँ»
• «werf - कुबेरनेट्स में CI / CD के लिए हमारा टूल (अवलोकन और वीडियो रिपोर्ट)";
• वेयरफ़ में नवाचारों के बारे में नोट्स की एक श्रृंखला:
  • «वेयरफ़ में 3-तरफ़ा विलय: "स्टेरॉयड पर" हेल्म के साथ कुबेरनेट्स में तैनाती";
  • «जटिल हेल्म चार्ट को रोल आउट करने के लिए वेयरफ़ का उपयोग करना";
  • «Werf में मोनोरेपो और मल्टीरेपो के लिए समर्थन और डॉकर रजिस्ट्री का इससे क्या लेना-देना है";
  • «अब आप नियमित डॉकरफाइल का उपयोग करके वेयरफ में डॉकर छवियां बना सकते हैं'.

स्रोत: www.habr.com