werf कलेक्टरमा सामग्री-आधारित ट्यागिङ: किन र कसरी यसले काम गर्छ?

वाफ Kubernetes मा अनुप्रयोगहरू निर्माण र डेलिभर गर्नको लागि हाम्रो खुला स्रोत GitOps CLI उपयोगिता हो। IN रिलीज v1.1 छवि कलेक्टरमा नयाँ सुविधा प्रस्तुत गरिएको थियो: सामग्री द्वारा छविहरू ट्याग गर्ने वा सामग्री आधारित ट्यागिङ। अहिले सम्म, werf मा विशिष्ट ट्यागिङ योजना Git ट्याग, Git शाखा वा Git कमिट द्वारा डकर छविहरू ट्याग गर्ने समावेश थियो। तर यी सबै योजनाहरूमा बेफाइदाहरू छन् जुन नयाँ ट्यागिङ रणनीतिले पूर्ण रूपमा समाधान गरेको छ। यसको बारेमा विवरणहरू र यो किन यति राम्रो छ कट अन्तर्गत छन्।

एउटा Git भण्डारबाट माइक्रो सेवाहरूको सेट रोल आउट गर्दै

एउटा अवस्था प्रायः तब हुन्छ जब अनुप्रयोग धेरै वा कम स्वतन्त्र सेवाहरूमा विभाजित हुन्छ। यी सेवाहरूको रिलीज स्वतन्त्र रूपमा हुन सक्छ: एक वा धेरै सेवाहरू एक पटकमा जारी गर्न सकिन्छ, जबकि बाँकी कुनै परिवर्तन बिना काम गर्न जारी राख्नुपर्छ। तर कोड भण्डारण र परियोजना व्यवस्थापनको दृष्टिकोणबाट, यस्तो अनुप्रयोग सेवाहरू एकल भण्डारमा राख्न अधिक सुविधाजनक छ।

त्यहाँ परिस्थितिहरू छन् जब सेवाहरू साँच्चै स्वतन्त्र छन् र एकल अनुप्रयोगसँग सम्बन्धित छैनन्। यस अवस्थामा, तिनीहरू अलग-अलग परियोजनाहरूमा अवस्थित हुनेछन् र तिनीहरूको रिलीज प्रत्येक परियोजनाहरूमा अलग-अलग CI/CD प्रक्रियाहरू मार्फत गरिनेछ।

यद्यपि, वास्तविकतामा, विकासकर्ताहरूले प्रायः एउटै अनुप्रयोगलाई धेरै माइक्रोसर्भिसेसहरूमा विभाजन गर्छन्, तर प्रत्येकको लागि छुट्टै भण्डार र परियोजना सिर्जना गर्ने... स्पष्ट ओभरकिल हो। यो अवस्था हो जुन थप छलफल गरिनेछ: धेरै त्यस्ता लघु सेवाहरू एकल परियोजना भण्डारमा अवस्थित छन् र CI/CD मा एकल प्रक्रिया मार्फत रिलीजहरू हुन्छन्।

Git शाखा र 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

यी नयाँ छवि नामहरू हेल्म टेम्प्लेटहरू मार्फत Kubernetes कन्फिगरेसनमा पठाइन्छ। आदेशको साथ तैनाती सुरु गर्दा werf deploy क्षेत्र अद्यावधिक भइरहेको छ image परिवर्तन गरिएको छवि नामको कारणले Kubernetes संसाधनमा सम्बद्ध स्रोतहरू प्रकट र पुन: सुरु गर्दै।

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

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

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

werf सँग Git कमिटसँग सम्बन्धित ट्यागिङ रणनीति पनि छ।

Git-commit एक Git भण्डारको सामग्रीहरूको लागि एक पहिचानकर्ता हो र Git भण्डारमा फाइलहरूको सम्पादन इतिहासमा निर्भर गर्दछ, त्यसैले यसलाई डकर रजिस्ट्रीमा छविहरू ट्याग गर्न प्रयोग गर्न तार्किक देखिन्छ।

यद्यपि, Git कमिट द्वारा ट्याग गर्ने Git शाखाहरू वा Git ट्यागहरू द्वारा ट्यागिङको रूपमा समान हानिहरू छन्:

• एउटा खाली कमिट सिर्जना गर्न सकिन्छ जसले कुनै पनि फाइलहरू परिवर्तन गर्दैन, तर छविको डकर ट्याग परिवर्तन हुनेछ।
• मर्ज कमिट सिर्जना गर्न सकिन्छ जसले फाइलहरू परिवर्तन गर्दैन, तर छविको डकर ट्याग परिवर्तन हुनेछ।
• एउटा प्रतिबद्धता सिर्जना गर्न सकिन्छ जसले Git मा ती फाइलहरू परिवर्तन गर्दछ जुन छविमा आयात गरिएको छैन, र छविको डकर ट्याग फेरि परिवर्तन हुनेछ।

Git शाखा नाम ट्याग गर्दै छवि संस्करण प्रतिबिम्बित गर्दैन

Git शाखाहरूको लागि ट्यागिङ रणनीतिसँग सम्बन्धित अर्को समस्या छ।

शाखाको नामबाट ट्यागिङले काम गर्दछ जबसम्म त्यो शाखामा कमिटहरू क्रमिक रूपमा सङ्कलन गरिन्छ।

यदि हालको योजनामा ​​प्रयोगकर्ताले निश्चित शाखासँग सम्बन्धित पुरानो प्रतिबद्धतालाई पुन: निर्माण गर्न थाल्छ भने, werf ले पुरानो प्रतिबद्धताको लागि छविको नयाँ निर्मित संस्करणसँग सम्बन्धित डकर ट्याग प्रयोग गरेर छविलाई पुन: लेख्नेछ। अबदेखि यो ट्याग प्रयोग गर्ने डिप्लोइमेन्टहरूले पोडहरू पुन: सुरु गर्दा छविको फरक संस्करण तान्ने जोखिम चलाउँछ, जसको परिणाम स्वरूप हाम्रो अनुप्रयोगले CI प्रणालीसँग जडान गुमाउनेछ र डिसिङ्क्रोनाइज हुनेछ।

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

सामग्री-आधारित ट्यागिङ के हो?

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

डकर ट्यागहरू सिर्जना गर्न, यो Git primitives (Git branch, Git ट्याग...) होइन जुन प्रयोग गरिन्छ, तर यससँग सम्बन्धित चेकसम:

• छवि को सामग्री। छवि आईडी ट्यागले यसको सामग्री प्रतिबिम्बित गर्दछ। नयाँ संस्करण निर्माण गर्दा, यो पहिचानकर्ता परिवर्तन हुने छैन यदि छविमा फाइलहरू परिवर्तन भएन भने;
• Git मा यो छवि सिर्जना गर्ने इतिहास। werf मार्फत बिभिन्न Git शाखाहरू र बिभिन्न निर्माण इतिहाससँग सम्बन्धित छविहरूमा फरक 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 कमिटहरूमा डकर ट्याग नाम प्रतिरोध।
• Git मा डकर ट्याग नामको लचिलोपनले छविमा अप्रासंगिक फाइलहरू परिवर्तन गर्दछ।
• Git शाखाहरूको लागि पुरानो Git कमिटहरूको लागि निर्माणहरू पुन: सुरु गर्दा छविको हालको संस्करणलाई ओभरहाल गर्ने समस्याको नेतृत्व गर्दैन।

यसको प्रयोग गर! र हामीलाई भ्रमण गर्न नबिर्सनुहोस् GitHubएउटा मुद्दा सिर्जना गर्न वा अवस्थित एउटा फेला पार्न, प्लस दिनुहोस्, PR सिर्जना गर्नुहोस्, वा केवल परियोजनाको विकास हेर्नुहोस्।

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

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

स्रोत: www.habr.com