ऑटोमेशन प्रक्रिया “एक कदम आगे” लेते हुए शेफ के साथ जुजू “सह-अस्तित्व” कैसे करता है?

Question

इस पोस्ट से स्पष्ट है कि जूजू शेफ सर्वर की तुलना में एक अलग परत पर बैठता है। जूजू ऑर्केस्ट्रेशन या सर्विस लेयर पर बैठता है, जबकि शेफ व्यक्तिगत सर्वर या कॉन्फ़िगरेशन लेयर पर अधिक बैठता है ।

पर विहित के मुख्य Juju पृष्ठों में से एक है, यह कहा गया है कि Juju बावर्ची और कठपुतली जैसे उपकरणों के साथ "सह-अस्तित्व", इस प्रक्रिया को ले जा "एक कदम आगे" करने के लिए बनाया गया है। मैंने इस विषय पर पिछले कई हफ्तों से इंटरनेट को बिखेर दिया है और इस बात की अच्छी व्याख्या नहीं कर पा रहा हूँ कि , हालाँकि, Chef जैसा उपकरण Juju के साथ सह-अस्तित्व में होगा ।

इसलिए, शीर्षक में ओवररचिंग प्रश्न को तोड़ने के लिए: (एक शेफ सर्वर के साथ मिलकर काम करने वाले जूजू में विशेष रुचि)

• "शेफ में लिखा" एक आकर्षण का एक उदाहरण है? क्या यह बस बैश में लिखा गया एक आकर्षण है जो तब chef-soloकमांड को कॉल करता है ? यदि हां, तो क्या एक आकर्षण chef-clientएक शेफ सर्वर के साथ कॉन्सर्ट में काम करने के लिए कमांड को बुला सकता है ?
• जूजू और शेफ के बीच ओवरलैप कहां है? उदाहरण के लिए, अपाचे 2 के आकर्षण में इसका config-changedहुक है जहां यह विन्यास में बदलाव करता है, जो कि शेफ की दुनिया में, एक टेम्पलेट फ़ाइल को लागू करके एक नुस्खा में होगा। अगर अपूज 2 सर्विस (क्लस्टर) को तैनात करने पर शेफ कुकबुक के साथ-साथ एक जूजू आकर्षण काम करना था, तो यह लगभग प्रतीत होता है कि "अपाचे 2-शेफ" आकर्षण को लिखना होगा ताकि आप कार्यों को अलग कर सकें। इस मामले में, चार्म स्टोर में Apache2 आकर्षण मददगार से कम नहीं होगा।
• यदि आपके पास जूडू द्वारा तैनात / प्रबंधित की गई नोड्स (सेवा इकाइयाँ) पर रसोइये की भूमिकाएँ हैं और आपका sysadmin किसी विशेष सर्वर भूमिका के लिए फ़ायरवॉल नियमों को बदलने का निर्णय लेता है और Chef भूमिका में ऐसा करता है, तो क्या जूजू कभी उन परिवर्तनों को अधिलेखित करने जा रहा है?
• और अधिक, क्या जूजू आयरनफैन की तरह शेफ सर्वर रैपर हो सकता है ?

मैं के रूप में बावर्ची सर्वर देखने कैसे जबकि Juju कर सकते हैं कि कैसे , लेकिन यह भी लाता है क्या मेज पर। इसका मतलब है कि सेवाओं और मशीनों की वास्तविक वर्तमान स्थिति पर ध्यान दिया जा सकता है और उन पर कार्रवाई की जा सकती है। आप इसे शेफ सर्वर में नहीं कर सकते। मेरा लक्ष्य जूजू की जागरूकता और सेवा ऑर्केस्ट्रेशन क्षमता को शेफ सर्वर-प्रबंधित बुनियादी ढांचे में लाना है।

यह लगभग लगता है कि आकर्षण का एक पूरा सेट लिखना होगा जहां सभी बावर्ची-प्रबंधित कार्य / कॉन्फ़िगरेशन जानकारी छोड़ दी जाती है।

मैं कैनोनिकल (जोर्ज कास्त्रो की तरह) और ओप्सकोड (जैसे ए। जैकब या जे। टिम्बरमैन) से किसी को वेट-इन सुनना पसंद करूंगा।

Answer 1

भयानक सवाल!

tl; डॉ

मैं आपके प्रश्न को कुछ टिप्पणियों में तोड़ना चाहूंगा ... सबसे पहले, यहाँ महाराज और जुजू को एकीकृत करने के लिए सामान्य दृष्टिकोण के एक जोड़े हैं:

• आकर्षण हुक मौजूदा शेफ व्यंजनों का उपयोग कर सकते हैं जो सेवा इकाइयों पर एकल-शैली चलाते हैं (अनुशंसित)

• जूजू सेवा इकाइयां एक शेफ-नोड अधीनस्थ सेवा का उपयोग करके एक मौजूदा शेफ-सर्वर के साथ पंजीकृत होती हैं

इन विचारों को अभी तक शेफ के लिए लागू / परीक्षण नहीं किया गया है , लेकिन कठपुतली समकक्ष मौजूद हैं।

... उम .. नहीं-तो छोटा सा जवाब

यहाँ शेफ और जूजू को एकीकृत करने के लिए दो दृष्टिकोणों के टूटने का एक और तरीका है:

जूजू शीर्ष कुत्ते के रूप में

यहां जीजू शो चलाते हैं। सबसे बड़ा मूल्य जूजू प्रदान करता है वितरित कॉन्फ़िगरेशन प्रबंधन के दौरान घटना समन्वय ... इसलिए "सेवा ऑर्केस्ट्रेशन" मॉनीकर। जूजू चार्म्स में हुक शामिल होते हैं जिन्हें सेवा प्रबंधन समन्वय करते समय "सही समय" पर जूजू द्वारा बुलाया जाता है। इन हुक का कार्यान्वयन बहुत अधिक खुला है। वे खोल स्क्रिप्ट, स्रोत कोड, कठपुतली मैनिफ़ेस्ट, या ... महाराज व्यंजनों।

जूजू किसी भी सेवा के बिट्स को कॉन्फ़िगर करता है:

• "स्थापना" .. बिट्स जो नोड पर एक विशेष सेवा को स्थापित करने के लिए विशिष्ट हैं

• "संबंध" .. विन्यास के बिट्स जो उस सेवा को किसी अन्य सेवा से संबंधित करने के लिए आवश्यक हैं

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

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

शीर्ष कुत्ते के रूप में बावर्ची

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

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

राय

यदि संभव हो तो मैं निश्चित रूप से 1 विधि की सिफारिश करूंगा। कॉन्फ़िगरेशन उपकरण के शीर्ष पर समन्वय परत होने से संभवतः अच्छी तरह से दीर्घकालिक काम करेगा। कहने की जरूरत नहीं है, वास्तविक दुनिया के इन्फ्रास्ट्रक्चर कुछ कॉम्बो या समय की अवधि के लिए दोनों दृष्टिकोणों के भिन्न हो सकते हैं ... विशेष रूप से प्रवास के दौरान। विधि 2 का उपयोग करके नियोजित सह-अस्तित्व शायद केवल तभी काम करेगा जब दोनों उपकरण द्वारा प्रबंधित घटक एक दूसरे के लिए कुछ हद तक रूढ़िवादी थे। निश्चित रूप से निश्चित नहीं है कि यह कैसा दिखेगा। शायद जूजू और शेफ अलग-अलग अपेक्षाकृत डिकौल्ड सेवाओं का प्रबंधन करते हैं? मुझे संदेह है कि यह जूजू को प्राथमिक सेवाओं का प्रबंधन करने और अधिक बुनियादी ढाँचे के पहलुओं को प्रबंधित करने के लिए अच्छी तरह से काम कर सकता है। पता नहीं। हालांकि यह थोड़ी लंबी चर्चा है :)

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

मैं ऊपर उल्लिखित दोनों प्रकार के शेफ एकीकरण के और अधिक उदाहरण देखना पसंद करूंगा ... यह मेरी इच्छा पर है / कुछ समय के लिए टूडू सूची में, लेकिन अभी तक प्राथमिकता के लिए पर्याप्त उच्च बुलबुला करना है ... कृपया मदद करें आप रुचि रखते हैं!

ठीक है, यह जुआ का एक अच्छा हिस्सा है:) ... चलो वहां शुरू करते हैं, फिर हम बाद के टिप्पणी ब्लॉकों में अधिक विस्तार से जा सकते हैं।

Comments

यहाँ बढ़िया सामान। "मुझे संदेह है कि यह जूजू को प्राथमिक सेवाओं का प्रबंधन करने और अधिक बुनियादी ढाँचे के पहलुओं को प्रबंधित करने के लिए अच्छी तरह से काम कर सकता है।" यह वही है जो मैं वास्तव में दिलचस्पी लेता हूं, क्योंकि हम इसी संदेह को साझा करते हैं। जैसा आपने कहा, कॉन्फ़िगरेशन के लिए शेफ का डीएसएल और टेम्प्लेटिंग बहुत अच्छा है। हालाँकि, शेफ सर्वर (डेटा बैग) के अन्य पहलू हैं जिन्हें आपके पहले तरीके में जाने देना मुश्किल होगा। जूजू, सेवा स्तर पर होने के नाते, शीर्ष कुत्ता होना चाहिए, लेकिन मुझे लगता है कि इसे शेफ को यह करने की अनुमति देनी चाहिए कि यह शेफ सर्वर मॉडल में सबसे अच्छा क्या करता है। देव और प्रवेश दोनों के लिए काम करना चाहिए। लेकिन शायद शेफ सर्वर की कोई जरूरत नहीं है।

— इयान डी। रॉसी