🍣 👼🏼 📑 सामग्री-आधारित टैगिंग में हर्फ कलेक्टर: क्यों और कैसे काम करता है? 🤴 🔚 🤙🏽

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

रोलबैक एक जीआईटी रिपॉजिटरी से माइक्रोसर्विस का एक सेट

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

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

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

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

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

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

Werf में Git commits से संबंधित टैगिंग रणनीति भी है।

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

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

, , Docker- .
merge-, , Docker- .
, Git, , Docker- .

Git-

Git शाखाओं के लिए टैगिंग रणनीति से संबंधित एक और मुद्दा है।

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

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

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

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

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

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

. - . , ;
Git. , Git- werf, -.

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

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

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

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

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

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

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

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

टीम के लिए संगत विकल्प दिखाई दिया 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हेल्म टेम्पलेट्स में उपयोग करते समय , कुछ भी बदलने की आवश्यकता नहीं है: ये फ़ंक्शन स्वचालित रूप से सही छवि नाम उत्पन्न करेंगे।

CI सिस्टम में उदाहरण विन्यास:

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

प्रलेखन में अधिक विन्यास जानकारी उपलब्ध है:

संपूर्ण

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

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

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

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

पुनश्च

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

" वेयरफ 1.1 रिलीज: बिल्डर टुडे एंड फ्यूचर प्लान्स में सुधार "
" 1.0% स्थिर का परिचय: GitOps को इसके साथ क्या करना है, स्थिति और योजनाएं "
" Werf Kubernetes में CI / CD के लिए हमारा उपकरण है (समीक्षा और वीडियो रिपोर्ट) ";
नोटों की श्रृंखला में एफईएफ में नवाचारों पर:

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