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

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

एक Git रिपॉजिटरी से माइक्रोसर्विसेज का एक सेट लॉन्च करना

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

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

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

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 रिपॉजिटरी को घेरना आवश्यक है और इन कई रिपॉजिटरी के रोलआउट को व्यवस्थित करने में समस्या उत्पन्न होती है। सामान्य तौर पर, ऐसी योजना अतिभारित और जटिल साबित होती है। कई सेवाओं को एक ही रिपॉजिटरी में संयोजित करना और डॉकर टैग बनाना बेहतर है ताकि कोई अनावश्यक पुनरारंभ न हो।

Git प्रतिबद्ध द्वारा टैगिंग

वेयरफ़ के पास Git कमिट से जुड़ी एक टैगिंग रणनीति भी है।

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

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

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

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

Git शाखाओं के लिए टैगिंग रणनीति से जुड़ी एक और समस्या है।

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

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

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

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

तो, सामग्री-आधारित टैगिंग क्या है - सामग्री के आधार पर छवियों को टैग करना।

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

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

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

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

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

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

मंच हस्ताक्षर इन सभी समस्याओं का समाधान करता है:

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

यह अब अनुशंसित टैगिंग रणनीति है और सभी सीआई प्रणालियों के लिए वेयरफ़ में डिफ़ॉल्ट है।

वेयरफ़ में कैसे सक्षम करें और उपयोग करें

कमांड में अब एक संबंधित विकल्प है werf publish: --tag-by-stages-signature=true|false

सीआई प्रणाली में, टैगिंग रणनीति कमांड द्वारा निर्दिष्ट की जाती है werf ci-env. पहले इसके लिए पैरामीटर परिभाषित किया गया था werf ci-env --tagging-strategy=tag-or-branch. अब, यदि आप निर्दिष्ट करें werf ci-env --tagging-strategy=stages-signature या इस विकल्प को निर्दिष्ट न करें, वेयरफ़ डिफ़ॉल्ट रूप से टैगिंग रणनीति का उपयोग करेगा 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 हेल्म टेम्प्लेट में कुछ भी बदलने की आवश्यकता नहीं है: ये फ़ंक्शन स्वचालित रूप से सही छवि नाम उत्पन्न करेंगे।

सीआई प्रणाली में उदाहरण विन्यास:

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

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

• निर्देशिका → प्रकाशन (प्रकाशन);
• सीआई/सीडी के साथ कार्य करना → सामान्य जानकारी → चरण-हस्ताक्षर;
• 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), फिर टैगिंग रणनीति पर स्विच करना सुनिश्चित करें चरण-हस्ताक्षर.
• नई परियोजनाओं को तुरंत नई टैगिंग योजना में बदलना बेहतर है।
• वेयरफ़ 1.1 में स्थानांतरित करते समय, पुरानी परियोजनाओं को नई टैगिंग योजना में बदलने की सलाह दी जाती है, लेकिन पुरानी टैग-या-शाखा अभी भी समर्थित है.

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

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

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

पुनश्च

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

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

स्रोत: www.habr.com