वेर्फ बिल्डरमध्ये सामग्री-आधारित टॅगिंग: ते का आणि कसे कार्य करते?

werf Kubernetes ला ऍप्लिकेशन तयार करण्यासाठी आणि वितरीत करण्यासाठी आमची मुक्त स्रोत GitOps CLI उपयुक्तता आहे. IN रिलीज v1.1 इमेज कलेक्टरमध्ये एक नवीन वैशिष्ट्य सादर केले गेले: सामग्रीद्वारे प्रतिमा टॅग करणे किंवा सामग्री-आधारित टॅगिंग. आत्तापर्यंत, werf मधील ठराविक टॅगिंग योजनेमध्ये Git टॅग, Git शाखा किंवा Git कमिट द्वारे डॉकर प्रतिमा टॅग करणे समाविष्ट होते. परंतु या सर्व योजनांचे तोटे आहेत जे नवीन टॅगिंग धोरणाने पूर्णपणे सोडवले आहेत. त्याबद्दलचे तपशील आणि ते इतके चांगले का आहे ते कट अंतर्गत आहे.

एका Git रिपॉजिटरीमधून मायक्रो सर्व्हिसेसचा संच रोल आउट करणे

जेव्हा एखादा अनुप्रयोग कमी-अधिक स्वतंत्र सेवांमध्ये विभागला जातो तेव्हा परिस्थिती सहसा उद्भवते. या सेवांचे प्रकाशन स्वतंत्रपणे होऊ शकते: एका वेळी एक किंवा अधिक सेवा रिलीझ केल्या जाऊ शकतात, तर उर्वरित कोणत्याही बदलाशिवाय कार्य करत राहणे आवश्यक आहे. परंतु कोड स्टोरेज आणि प्रोजेक्ट मॅनेजमेंटच्या दृष्टिकोनातून, अशा अनुप्रयोग सेवा एकाच भांडारात ठेवणे अधिक सोयीचे आहे.

अशी परिस्थिती असते जेव्हा सेवा खरोखर स्वतंत्र असतात आणि एका अनुप्रयोगाशी संबंधित नसतात. या प्रकरणात, ते स्वतंत्र प्रकल्पांमध्ये असतील आणि त्यांचे प्रकाशन प्रत्येक प्रकल्पामध्ये स्वतंत्र CI/CD प्रक्रियेद्वारे केले जाईल.

तथापि, प्रत्यक्षात, विकासक अनेकदा एकच अनुप्रयोग अनेक मायक्रोसर्व्हिसेसमध्ये विभाजित करतात, परंतु प्रत्येकासाठी स्वतंत्र भांडार आणि प्रकल्प तयार करणे... ही एक स्पष्ट ओव्हरकिल आहे. हीच परिस्थिती आहे ज्याची पुढे चर्चा केली जाईल: अशा अनेक सूक्ष्म सेवा एकाच प्रकल्प भांडारात स्थित आहेत आणि CI/CD मध्ये एकाच प्रक्रियेद्वारे रिलीज होतात.

Git शाखा आणि Git टॅगद्वारे टॅग करणे

समजा सर्वात सामान्य टॅगिंग धोरण वापरले जाते - टॅग-किंवा-शाखा. Git शाखांसाठी, शाखेच्या नावासह प्रतिमा टॅग केल्या जातात, एका वेळी एका शाखेसाठी त्या शाखेच्या नावाने फक्त एक प्रकाशित प्रतिमा असते. Git टॅगसाठी, टॅगच्या नावानुसार प्रतिमा टॅग केल्या जातात.

जेव्हा नवीन गिट टॅग तयार केला जातो - उदाहरणार्थ, जेव्हा नवीन आवृत्ती रिलीझ केली जाते तेव्हा - डॉकर रेजिस्ट्रीमधील सर्व प्रकल्प प्रतिमांसाठी एक नवीन डॉकर टॅग तयार केला जाईल:

• 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 बदललेल्या प्रतिमेच्या नावामुळे कुबर्नेट्स रिसोर्सेसमध्ये संबंधित संसाधने प्रकट होतात आणि रीस्टार्ट करणे.

समस्या: जेव्हा, खरं तर, मागील रोलआउट (गिट टॅग) पासून प्रतिमेची सामग्री बदलली नाही, परंतु केवळ त्याचा डॉकर टॅग, असे घडते अतिरिक्त हा अनुप्रयोग रीस्टार्ट करत आहे आणि त्यानुसार, काही डाउनटाइम शक्य आहे. जरी हे रीस्टार्ट करण्याचे कोणतेही खरे कारण नव्हते.

परिणामी, सध्याच्या टॅगिंग योजनेसह अनेक स्वतंत्र Git रिपॉझिटरीजना कुंपण घालणे आवश्यक आहे आणि या अनेक रेपॉजिटरीजचे रोलआउट आयोजित करण्यात समस्या उद्भवते. सर्वसाधारणपणे, अशी योजना ओव्हरलोड आणि जटिल असल्याचे दिसून येते. एकाच रेपॉजिटरीमध्ये अनेक सेवा एकत्र करणे आणि डॉकर टॅग तयार करणे चांगले आहे जेणेकरून कोणतेही अनावश्यक रीस्टार्ट होणार नाहीत.

Git कमिट द्वारे टॅग करणे

werf कडे Git कमिटशी संबंधित टॅगिंग धोरण देखील आहे.

Git-commit हे Git रेपॉजिटरीमधील सामग्रीसाठी एक अभिज्ञापक आहे आणि Git रेपॉजिटरीमधील फायलींच्या संपादन इतिहासावर अवलंबून आहे, म्हणून डॉकर रेजिस्ट्रीमध्ये प्रतिमा टॅग करण्यासाठी वापरणे तर्कसंगत आहे.

तथापि, Git कमिटद्वारे टॅगिंगचे Git शाखा किंवा Git टॅगद्वारे टॅग करण्यासारखेच तोटे आहेत:

• एक रिक्त कमिट तयार केले जाऊ शकते जे कोणत्याही फायली बदलत नाही, परंतु प्रतिमेचा डॉकर टॅग बदलला जाईल.
• एक मर्ज कमिट तयार केले जाऊ शकते जे फाइल्स बदलत नाही, परंतु इमेजचा डॉकर टॅग बदलला जाईल.
• एक वचनबद्धता केली जाऊ शकते जी Git मधील त्या फायली बदलते ज्या प्रतिमेमध्ये आयात केल्या जात नाहीत आणि प्रतिमेचा डॉकर टॅग पुन्हा बदलला जाईल.

Git शाखेचे नाव टॅग करणे प्रतिमा आवृत्ती प्रतिबिंबित करत नाही

Git शाखांसाठी टॅगिंग धोरणाशी संबंधित आणखी एक समस्या आहे.

शाखेच्या नावाने टॅग करणे जोपर्यंत त्या शाखेवरील कमिट कालानुक्रमिक क्रमाने एकत्रित केले जातात तोपर्यंत कार्य करते.

जर सध्याच्या स्कीममध्ये वापरकर्त्याने एखाद्या विशिष्ट शाखेशी संबंधित जुन्या कमिटची पुनर्बांधणी सुरू केली, तर werf संबंधित डॉकर टॅग वापरून जुन्या कमिटसाठी इमेजच्या नव्याने तयार केलेल्या आवृत्तीसह प्रतिमा पुन्हा लिहितो. आतापासून हा टॅग वापरत असलेल्या उपयोजनांमुळे पॉड्स रीस्टार्ट करताना इमेजची वेगळी आवृत्ती खेचण्याचा धोका असतो, परिणामी आमचा अनुप्रयोग CI सिस्टमशी कनेक्शन गमावेल आणि डिसिंक्रोनाइझ होईल.

या व्यतिरिक्त, एका शाखेत एकामागोमाग पुश केल्याने त्यांच्या दरम्यान कमी कालावधीसह, जुनी कमिट नवीनपेक्षा नंतर संकलित केली जाऊ शकते: इमेजची जुनी आवृत्ती Git शाखा टॅग वापरून नवीन ओव्हरराइट करेल. अशा समस्या CI/CD प्रणालीद्वारे सोडवल्या जाऊ शकतात (उदाहरणार्थ, GitLab CI मध्ये नंतरची पाइपलाइन कमिटच्या मालिकेसाठी लाँच केली जाते). तथापि, सर्व प्रणाली यास समर्थन देत नाहीत आणि अशा मूलभूत समस्या टाळण्यासाठी अधिक विश्वासार्ह मार्ग असणे आवश्यक आहे.

सामग्री-आधारित टॅगिंग म्हणजे काय?

तर, सामग्री-आधारित टॅगिंग म्हणजे काय - सामग्रीद्वारे प्रतिमा टॅग करणे.

डॉकर टॅग तयार करण्यासाठी, ते 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 कमिटला प्रतिरोधक फायली बदलतात जे प्रतिमेशी संबंधित नाहीत.
• शाखेच्या जुन्या गिट कमिटसाठी बिल्ड रीस्टार्ट करताना प्रतिमेची वर्तमान आवृत्ती ओव्हरहॉल करण्याची समस्या उद्भवत नाही.

हे आता शिफारस केलेले टॅगिंग धोरण आहे आणि सर्व 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 किंवा हा पर्याय निर्दिष्ट करू नका, 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 हेल्म टेम्प्लेट्समध्ये काहीही बदलण्याची गरज नाही: ही फंक्शन्स आपोआप योग्य प्रतिमा नावे तयार करतील.

सीआय सिस्टममधील कॉन्फिगरेशनचे उदाहरण:

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 वर डॉकर टॅग नावाची लवचिकता प्रतिमेशी असंबद्ध फाइल्स बदलते.
• गीट शाखांसाठी जुन्या गिट कमिटसाठी बिल्ड रीस्टार्ट करताना इमेजची वर्तमान आवृत्ती ओव्हरहॉल करण्याची समस्या उद्भवत नाही.

वापर करा! आणि आम्हाला येथे भेट द्यायला विसरू नका GitHubसमस्या निर्माण करण्यासाठी किंवा विद्यमान शोधण्यासाठी, एक प्लस जोडा, एक PR तयार करा किंवा फक्त प्रकल्पाचा विकास पहा.

PS

आमच्या ब्लॉगवर देखील वाचा:

• «werf 1.1 प्रकाशन: आज बिल्डर सुधारणा आणि भविष्यासाठी योजना»
• «सादर करत आहोत werf 1.0 स्थिर: GitOps चा त्याच्याशी काय संबंध आहे, स्थिती आणि योजना»
• «werf - Kubernetes मधील CI/CD साठी आमचे साधन (विहंगावलोकन आणि व्हिडिओ अहवाल)";
• werf मधील नवकल्पनांबद्दल नोट्सची मालिका:
  • «werf मध्ये 3-वे विलीनीकरण: हेल्मसह कुबर्नेट्सला “स्टिरॉइड्सवर” तैनात करा";
  • «जटिल हेल्म चार्ट रोल आउट करण्यासाठी werf वापरणे";
  • «werf मधील मोनोरेपो आणि मल्टीरेपोसाठी समर्थन आणि डॉकर रजिस्ट्रीचा त्याच्याशी काय संबंध आहे";
  • «तुम्ही आता नियमित Dockerfile वापरून werf मध्ये डॉकर प्रतिमा तयार करू शकता».

स्त्रोत: www.habr.com