हेल्म बनाम कस्टोमाइज: 2020 में अपने अनुप्रयोगों को कैसे तैनात करें?

एक समय था जब हेर्म कंटेनरकरण और कुबेरनेटाइजेशन की इस महान नई दुनिया में सबसे अधिक नफरत करने वाले उपकरणों में से एक था!

और वह भी बिना वजह नहीं। लेकिन कुछ हफ़्ते पहले, वह समय आया जब मेरी टीम ने नए सिरे से शुरुआत की और यह तय करना पड़ा कि हम अपने कुबेरनेट क्लस्टर पर आवेदन की तैनाती को कैसे संभालना चाहते हैं।

इसलिए मैंने Google से पूछा कि इसे क्या करना है ...

… और इसने मुझे अकेला छोड़ दिया। Kustomize, Helm, ... बहुत सारी पुरानी तुलनाओं के साथ। तो उम्मीद है कि निम्नलिखित अध्याय आपको अपने निर्णय को सूचित करने में मदद करेंगे!

TLDR;

हेल्म v3 का उपयोग करें। आपको बहुत पसंद आएगा!

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

कारण 1: हेल्म एब्सट्रैक्शन की एक परत जोड़ता है जहां आप एक चाहते हैं

जब आप K8s पर एक एप्लिकेशन तैनात करते हैं, तो आप आमतौर पर इसे एक से अधिक बार तैनात करेंगे। उदाहरण के लिए, आप अपने माइक्रोसेव को दो वातावरणों (परीक्षण और मंचन) में तैनात करना चाहते हैं, या आपको दो अलग-अलग बैकेंड के लिए दो लोड-बैलेन्सर तैनात करने की आवश्यकता है।

एक ही आवेदन की हर तैनाती के लिए आपको निम्न-स्तर के K8 संसाधनों (तैनाती, सेवा, कॉन्फिगरेशन,…) का एक बड़ा सेट तैयार करना होगा, जो केवल कुबेटल का उपयोग करके जल्दी से बोझिल हो सकता है। इसके अलावा, ये संसाधन परिभाषाएँ आम तौर पर समान अनुप्रयोग (जैसे परीक्षण और स्टेजिंग) की व्यक्तिगत तैनाती के बीच 90% समान होती हैं, लेकिन फिर भी छोटे ट्वीक्स की आवश्यकता होती है (उदाहरण के लिए स्टेजिंग तैनाती को एक स्टेजिंग डेटाबेस क्लस्टर को इंगित करने की आवश्यकता होती है)।

जैसा कि हम सभी जानते हैं कि कोड डुप्लीकेशन बहुत खराब है, हम चाहते हैं कि एक ऐसा सिस्टम हो जहां 90% समान सामान केवल एक बार लिखा जाना चाहिए, जबकि अभी भी हमें उस सामान को ट्विस्ट करने की अनुमति देता है।

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

यदि बाद वाला जटिल लगता है, तो ऐसा इसलिए है क्योंकि यह है! और यह उन्हीं मुद्दों से ग्रस्त है जो विरासत में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं में हैं: यह अक्सर एक टपका हुआ अमूर्त है - या दूसरे शब्दों में, यह नाजुक आधार वर्ग समस्या जैसे मुद्दों का परिचय देता है। समस्या को दो वाक्यों में संक्षेप में प्रस्तुत करने के लिए: जब आप अपने आवेदन की तैनाती को कॉन्फ़िगर करने के लिए अपनी kustomization.yaml फ़ाइल लिखते हैं, तो आपको उस जेनेरिक एप्लिकेशन विवरण के कार्यान्वयन के विवरण को जानना होगा जो आप विरासत में प्राप्त कर रहे हैं। और यह बदतर हो गया है: अब से आप भी अपनी तैनाती को तोड़े बिना अपना जेनेरिक एप्लिकेशन विवरण नहीं बदल सकते हैं, क्योंकि ये दोनों चीजें कसकर युग्मित हैं!

दूसरी ओर, हेल्म, कपलिंग को कम करने और आसान दीर्घकालिक स्थिरता बनाए रखने के लिए इन दो तत्वों (एप्लिकेशन और इसके कॉन्फ़िगरेशन) के बीच एक अच्छा इंटरफ़ेस रखता है।

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

हेल्म के साथ तैनाती करते समय, आपको यह ध्यान रखने की आवश्यकता नहीं है कि इस कॉन्फिगरेशन के नाम क्या संसाधन है, जिसे कुछ लॉगिंग साइडकार कंटेनर की जरूरत है

वैसे: इस लेख के परिशिष्ट को देखें, अपने K8s विन्यास Git रिपॉजिटरी के लिए एक संभावित निर्देशिका लेआउट खोजने के लिए।

कारण 2: स्पष्ट बेहतर है तो निहित है

Kustomize

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

# फ़ाइल: microserviceA- स्टेजिंग / kustomization.yaml कुर्सियां: - ../_bases/microserviceA/
आमलैबल्स: ऐप: माइक्रोसेवा-स्टेजिंग

'आधार' कीवर्ड जेनेरिक माइक्रोसैसवेरा संसाधनों से सभी K8 संसाधनों को प्राप्त करने का ध्यान रखता है। हालाँकि, इन सभी संसाधनों के लिए हम एक अतिरिक्त लेबल ऐप जोड़ेंगे: microserviceA-staging।

यह निश्चित रूप से अच्छा और आसान है। हालाँकि, सामान्यबल वास्तव में आपकी संसाधन परिभाषाओं में मेटाडेटा.लैबल्स फ़ील्ड को बदलने की तुलना में बहुत अधिक जादू करता है:

  • यह पॉड टेम्प्लेट में लेबल भी जोड़ता है
  • यह लेबल को चयनकर्ताओं में तैनाती, सेवाओं या प्रगति संसाधनों में भी जोड़ता है

मुझे गलत न समझें: यह _good_ है जो Kustomize करता है। क्योंकि यह पूरे दृष्टिकोण को काम करता है और मानक usecases के लिए काफी आसान है! हालाँकि, यह प्रलेखित नहीं है, यह संभवतः अधिकांश नए उपयोगकर्ताओं और काफी अपारदर्शी के लिए अप्रत्याशित है!

मैं व्यवहार के अतिरिक्त उदाहरणों को सूचीबद्ध कर सकता हूं जो 'अजीब' और अनिर्दिष्ट है:

  • नाम स्थान फ़ील्ड को आधारों में सूचीबद्ध फ़ाइलों से विरासत में नहीं मिला है
  • आवश्यक कॉन्फ़िगरेशन फ़ाइलों को जोड़ने के लिए configMapGenerator का उपयोग करते समय, इन फ़ाइलों को संशोधित किया जा रहा है (newlines और व्हॉट्सएप को अलग करना)। यह व्हाट्सएप-संवेदी कॉन्फिग फाइल या बायनेरिज़ को तोड़ सकता है (और करता है)
  • ...

संचालन, पतवार

पिछले अनुभाग की तुलना निम्न हेल्म टेम्पलेट और इंस्टॉलेशन कमांड से करें:

# फ़ाइल: _charts / microserviceA / टेम्पलेट्स / secret.yaml apiVersion: v1 तरह: गुप्त मेटाडेटा: नाम: mysecret प्रकार: Opaque stringData: database_password: {{.Valc.databasePassword}}।

और चरणबद्ध तैनाती का उपयोग कर स्थापित करें:

helm install \ --set databasePassword = mypassword \ microserviceA-staging ./_charts/microsNSA

मुझे लगता है कि हम सब समझ सकते हैं कि 10 सेकंड से भी कम समय में यहां क्या हो रहा है।

कारण 3: यह बनाए गए संसाधनों को ट्रैक करता है

Kustomize मूल रूप से एक संकलक है, जो संदर्भित जेनेरिक Kubernetes संसाधनों के 'अनुकूलित' संस्करण बनाता है। ये तो सीधे इस तरह एक kubectl कमांड का उपयोग करके लागू किया जा सकता है:

kustomize बिल्ड। | कुबेकेल लागू -f -

हालांकि यह एक बहुत 'यूनिक्स-वाई' दृष्टिकोण है, लेकिन इसका नुकसान यह है कि यह आपके कुबेरनेट क्लस्टर में किए गए परिवर्तनों को ट्रैक नहीं करता है ... और आसानी से उन्हें वापस रोल करने का कोई तरीका नहीं है। या पुराने, अब अप्रयुक्त संसाधनों को पीछे छोड़ने के लिए जोखिम के बिना, आपकी तैनाती का एक नया और बेहतर संस्करण लागू करना।

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

परिणामस्वरूप, हेलम में केवल एक इंस्टाल कमांड नहीं है:

पतवार सूची <...> # वर्तमान में स्थापित संकुल स्थापित करें पतवार स्थापित करें <...> # एक नया पैकेज स्थापित करें हेलमेट अपग्रेड <...> # पहले से स्थापित संकुल हेलम को अपग्रेड करें मान प्राप्त करें <...> # का कॉन्फ़िगरेशन दिखाएं एक इंस्टालेशन हेल्म अनइंस्टॉल <...> # पहले से स्थापित पैकेज को हटा दें

तल - रेखा

यह लेख मेरे लिए, हेल्म और कस्तूमीय दोनों को आजमाने का परिणाम है, जिससे हमें अपने K8 की तैनाती बनाए रखने में मदद मिली।

खुद को पूरी तरह से प्रकट करने के लिए: इस परीक्षण में मैंने पहली बार हेल्म v3 की कोशिश की और इसे पसंद किया। हालाँकि, मैं Kustomize में एक गहरी डुबकी करना चाहता था, यह समझने के लिए कि यह कैसे उपयोग किया जा रहा है ... और मुझे Helm 3 से कई तुलनाएं नहीं मिल सकीं।

Kustomize का प्रयास करते समय, इसके बारे में मेरी भावनाएँ निम्नलिखित क्रम में लगभग बदल गईं:

  1. मुझे शुरुआत से नफरत थी, क्योंकि मुझे वास्तव में समझ नहीं आया कि यह कैसे काम करना चाहिए - और इसमें कुछ समय लगा
  2. मुझे इसका पता चला, और सोचा 'यह इतना बुरा नहीं है'
  3. मैं सभी अजीब किनारे के मामलों और दस्तावेज की कमी पर ठोकर खाई

... जो आखिरकार मुझे खुश जगह पर वापस जाने के लिए प्रेरित करता है, हेल्म :-)।

इसके बाद में, मैंने अपनी भावनाओं को 'औपचारिक' करने की पूरी कोशिश की - जिसके परिणामस्वरूप यह लेख आया। मुझे उम्मीद है कि यह कम से कम आपको कुछ दिलचस्प तर्क देगा, जब यह तय करने की कोशिश की जाएगी कि आप किस दिशा में जाना चाहते हैं! और नमक के एक दाने के साथ ले लो, शायद मैं सही ढंग से Kustomize समझ में नहीं आया, आखिर ...

परिशिष्ट: अपने क्लस्टर पैकेज / कॉन्फ़िगरेशन रिपॉजिटरी को कैसे व्यवस्थित करें

उदाहरण के लिए, मान लें कि हम अपने Kubernetes क्लस्टर पर निम्नलिखित एप्लिकेशन को तैनात करना चाहते हैं: दो अलग-अलग प्रकार के बैकेंड, जहां प्रत्येक बैकएंड का अपना एपीआई गेटवे है, जो इसके सामने तैनात है।

मेरा सुझाव है कि एक गिट रिपॉजिटरी में निम्नलिखित दोनों चीजों को स्टोर करें:

  • आपके सामान्य अनुप्रयोग पैकेज (हेलम चार्ट)
  • आपके व्यक्तिगत परिनियोजन का विन्यास (मान फ़ाइलें)
_charts / backendA / Chart.yaml Values.yaml ... backendB / ... api-Gateway / ... ठेस / backendA_values.yaml backendB_values.yaml api-gateway__vendA_values.yaml api-gateway_backendB_values.yaml स्टेजिंग / बैकेंड / स्टेजिंग / बैकएंडएजेंस। YAML

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

पतवार-एन ठेस उन्नयन \ _ ठेस / backendB_values.yaml backendB ./_charts/backpB

बेशक यह लेआउट आरंभ करने के लिए एक संभावित उदाहरण है। सबसे महत्वपूर्ण बात यह है कि पैकेजों को न केवल स्रोत नियंत्रण में रखना है, बल्कि कॉन्फ़िगरेशन भी है! यह ऊपर दिखाया गया है, या यहां तक ​​कि एक पूरी तरह से अलग भंडार में भी किया जा सकता है।

और निश्चित रूप से आप अपनी पसंद के सभी शनीगनों को जोड़ना शुरू कर सकते हैं, जैसे कि नामस्थान- या क्लस्टर-वाइड कॉन्फ़िगरेशन सेटिंग्स (जैसे केंद्रीय लॉगिंग सर्वर) के लिए अतिरिक्त सामान्यतः उपयोग किए जाने वाले 'मान' फाइलें।