एक नज़र में जूजू

दूसरे दिन मैं एक कैनोनिकल जूजू टूल में आया।

इंटरनेट से स्क्रैप का दावा है कि यह शेफ, अंसिबल या कठपुतली की तरह एक कॉन्फ़िगरेशन प्रबंधन उपकरण है।

मैंने इस पर बहुत ही बारीकी से डॉक पढ़ा, आकर्षण-मॉड्यूल (कुकबुक या प्लेबुक का एनालॉग) के साथ रिपॉजिटरी में देखा और तर्क दिया कि ऐसा नहीं है।

जूजू एक वीएम-अज्ञेय ऑर्केस्ट्रा (जैसे घुमंतू या कुबेरनेट्स) की तरह है। उस पर, आप घोषणात्मक रूप से आवेदन के बुनियादी ढांचे के विन्यास का वर्णन कर सकते हैं: हम कौन से अनुप्रयोग चलाते हैं, किस मशीन पर, कितनी प्रतियों में, वे अन्य सेवाओं के साथ कैसे जुड़े हैं।
लेकिन कुबेरनेट्स के विपरीत, यह न केवल डॉकर के साथ काम कर सकता है, बल्कि किसी भी प्रकार की आभासी मशीनों के साथ भी काम कर सकता है।

वे कहते हैं कि कर्नेल, एजेंट और क्लाइंट को गोलंग में लिखा गया है - और मैंने उनकी तरफ नहीं देखा।

कॉन्फ़िगरेशन से संबंधित हिस्सा आमतौर पर YAML और पायथन के संयोजन में वर्णित है (डॉक कहते हैं कि आप अजगर के अलावा अन्य भाषाओं का उपयोग कर सकते हैं)।

यह सब कैसे काम करता है?

डिस्क्लेमर : यह लेख पूर्ण और सटीक विवरण होने का दावा नहीं करता है, मैं इसे उन लोगों के लिए प्रवेश सीमा को कम करने के तरीके के रूप में देखता हूं जो जूजू पर एक नज़र रखना चाहते हैं और प्रलेखन नेविगेट करने में मदद करते हैं।

पूर्ण प्रलेखन यहाँ है: https://docs.jujucharms.com/

जैसा कि पहले ही लिखा जा चुका है, जूजू में कई घटक हैं:

• नियंत्रक वह सर्वर भाग है जो आभासी मशीनों को आवंटित करता है। प्रत्येक [क्लाउड] प्रदाता का अपना कंट्रोलर होता है ( सर्विस के रूप में स्थानीय LXD या मेटल जैसे क्लाउड क्लाउड प्रदाता के लिए भी नहीं)।
  नियंत्रक एक घटक से एक अखंड अनुप्रयोग है। प्रत्येक प्रदाता में कम से कम एक नियंत्रक प्रति अवश्य होनी चाहिए। कुछ हा है, लेकिन मैंने इसमें तल्लीन नहीं किया।
• एजेंट - प्रत्येक वर्चुअल मशीन पर डाल दिया। दो प्रकार के एजेंट हैं - मशीन के लिए और यूनिट के लिए। ऐसा लगता है कि उनमें से एक को मेजबान मशीन पर रखा गया है, और एक आभासी मशीन में - मुझे इसमें विस्तार से नहीं जाना है।
• ग्राहक इस सभी अर्थव्यवस्था के प्रबंधन के लिए एक CLI उपकरण है।
• जीयूआई
• सभी उपयोगकर्ता घटकों (अनुप्रयोगों, मशीनों, आदि) का एक घोषणात्मक विवरण
• एक अलग वर्चुअल मशीन स्थापित करने के लिए कस्टम कोड, इसे आकर्षण कहा जाता है

(वास्तव में, घटकों का एक बड़ा पेड़ है, लेकिन इस कहानी के लिए हम इसे सरल करेंगे ताकि यह समझना आसान हो जाए कि क्या है)

एक घोषणात्मक विवरण पर, आप लगभग निम्नलिखित घटकों के ढांचे का निर्माण कर सकते हैं (ग्राफ़ जीयूआई द्वारा स्वचालित रूप से तैयार किए जाते हैं):

सर्वर का हिस्सा किसी तरह से वर्चुअल मशीन बनाता है, निर्भरता को खींचता है, उनके बीच संबंध स्थापित करता है, उन संकेतों की निगरानी करता है जो उत्पन्न होते हैं - अन्य ऑर्केस्ट्रा के लिए सब कुछ बहुत मानक लगता है।

और यहां वर्चुअल मशीनों को चार्म्स (यूनिट - आकर्षण) को कॉन्फ़िगर करने के लिए मॉड्यूल हैं, चलो एक करीब से देखें।

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

आकर्षण यंत्र

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

इनमें मेटाडेटा / डिक्लेक्टिव पार्ट, पेर्मेप्टरी हुक (घटनाओं पर प्रतिक्रिया) और सभी तरह की डेटा फाइलें जैसे अतिरिक्त स्क्रिप्ट, डॉक्यूमेंटेशन या टिपिकल कॉन्फिग शामिल हैं।

घोषणात्मक भाग आकर्षण निर्भरता इंटरफेस का वर्णन करता है (उदाहरण के लिए, वर्डप्रेस आकर्षण mysql पर निर्भर करता है, और mysql आकर्षण इस इंटरफ़ेस को प्रदान करता है), सिस्टम संगतता, टैग, कॉन्फ़िगरेशन पैरामीटर (जैसे कुकी विशेषताएँ) और प्रोग्राम की परतें अन्य आकर्षण के आधार पर ( उदाहरण के लिए, अधिकांश आकर्षण में एक layer:basic शामिल layer:basic )।

अनिवार्य हुक में, सभी प्रकार की बाहरी घटनाओं की प्रतिक्रिया का वर्णन किया गया है। उदाहरण के लिए, हम install इवेंट पर आवश्यक पैकेज install , इसे configure इवेंट पर configure करते हैं, और start इवेंट पर सेवा start ।

यह सब डेकोरेटर के साथ एक साधारण अजगर पर लिखा गया है (कहीं मैंने यह कथन पढ़ा कि आप किसी भी चीज़ पर लिख सकते हैं, यहां तक ​​कि एक बैश पर भी, लेकिन मैंने कोई उदाहरण नहीं देखा है)।

एक क्लासिक हल्का उदाहरण NTP है: https://github.com/lampkicking/charm-ntp

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

NTP के लिए उदाहरण: https://jaas.ai/ntp/32 ( पृष्ठ के दाईं ओर फ़ाइलों की सूची देखें)।

सारांश

जूजू में बुनियादी ढांचे का वर्णन करने और स्थापित करने के लिए एक बहुत ही रोचक और असामान्य दृष्टिकोण है।

सबसे अधिक संभावना है, जूजू में शेफ की तुलना में एक उच्च प्रवेश दहलीज है, सबसे अधिक संभावना है कि कुकबुक और प्लेबुक की तुलना में विकसित करने के लिए धीमी हैं और अधिक प्रोग्रामिंग कौशल की आवश्यकता होती है।

दूसरी ओर, मुझे लगता है कि ईवेंट हुक के साथ एक मॉडल आपको अधिक सही कोड लिखने के लिए प्रोत्साहित करता है।

मुझे ऐसा लग रहा था कि जूजू बुनियादी ढांचे के प्रोग्रामर्स (जिन्होंने 5-7 साल पहले लिनक्स में अजगर पर कई सीएलआई उपकरण लिखे थे) के उद्देश्य से हैं, जिन्हें अब सर्वरों को कॉन्फ़िगर करने की आवश्यकता है, जबकि शेफ / अन्सिबल - एक के बजाय -अब आपको सौ या दो सर्वरों को कॉन्फ़िगर करने की आवश्यकता है।

क्या मुझे 2019 में जूजू का उपयोग करना चाहिए?
निश्चित नहीं:

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

यदि आप जूजू के साथ काम करते हैं, तो उन टिप्पणियों में लिखें जहां मैंने गलती की है - आखिरकार, मैंने केवल 2-3 घंटे उसके लिए डॉक पढ़ा।