कॉन्फ़िगरेशन प्रबंधक (जैसे कठपुतली / बावर्ची / Ansible) का उपयोग करना कब उचित है?

Question

अपने वर्तमान कार्यस्थल पर, मैं दो वीएमवेयर होस्ट मशीनों, एक ओपनबीएसडी भौतिक मशीन, तीन डेबियन वीएम और छह विंडोज सर्वर वीएम (2008/2012) की देखभाल करता हूं।

मैं कठपुतली या बावर्ची जैसे विन्यास प्रबंधन उपकरण को लागू करने पर विचार कर रहा हूं। क्या यह वाजिब है, या क्या इस टूल को सीखने का ओवरहेड लाभ से आगे निकल जाएगा? प्रबंधन और कार्यान्वयन लागत के बीच टिपिंग बिंदु कहां है?

Comments

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

— वॉरेन

यह इस बात पर निर्भर करता है कि आपको इन प्रणालियों के साथ क्या करना है।

— इविविट

Answer 1

IMHO यह सीखने लायक है, भले ही आप केवल एक ही सर्वर का प्रबंधन कर रहे हों,

हां, सीखने की अवस्था होगी। हां, तुम निराश हो जाओगे। हालांकि, उन लागतों के लिए, आपको विश्वसनीय, सुसंगत, एक-क्लिक तैनाती, संस्करण-नियंत्रित सर्वर कॉन्फ़िगरेशन, परीक्षण / देव वातावरण स्थापित करने में आसानी आदि के माध्यम से कई गुना वापस भुगतान किया जाएगा।

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

(Sidenote: साथ ही Ansible पर विचार यह मेरी पसंदीदा मुख्यमंत्री है, और है। बहुत आसान और के साथ चलाने के लिए - या तो कठपुतली या बावर्ची साथ ही, खिड़कियों Ansible में समर्थन अच्छी तरह से साथ आ रहा है की तुलना में बहुत आसान है।।)

Comments

ख़ूब कहा है। मैं घर पर एक रास्पबेरी पाई स्थापित करने जैसी तुच्छ चीजों पर अन्सिबल का उपयोग करके समाप्त करता हूं क्योंकि यह मेरे लिए प्रक्रिया का दस्तावेजीकरण करने का एक सुविधाजनक तरीका है।

— tderder42

पूर्ण रूप से! शेफ में शामिल होना मेरे लिए करियर की बड़ी जीत है। यहां असली बात यह है: एक दो साल में सीएम सभी के लिए आवश्यक / उम्मीद करेंगे लेकिन जूनियर SysAd नौकरी के लिए।

— ग्वेल्डो

पूरी तरह से सहमत। बहुत अधिक ध्यान इंस्टॉलेशन के स्वचालन पर है जो कि सीएम सिस्टम का केवल एक हिस्सा है। लोग भूल जाते हैं कि M का मतलब क्या है। आप 1 सर्वर से किए जाने वाले विभिन्न कॉन्फ़िगरेशन परिवर्तनों का ट्रैक कैसे रखते हैं। सर्वरों की संख्या कोई मायने नहीं रखती है। जब वह 1 सर्वर मर जाता है, तो आप बिना किसी संदेह के उसे फिर से बनाने में सक्षम होने के लिए खुश हैं।

— ईटीएल

Answer 2

मैं कठपुतली या बावर्ची जैसे विन्यास प्रबंधन उपकरण को लागू करने पर विचार कर रहा हूं। क्या यह वाजिब है, या क्या इस टूल को सीखने का ओवरहेड लाभ से आगे निकल जाएगा?

यह इस बात पर निर्भर करता है कि आपको कितना समय और पैसा जलाना है, और यह आपके पैसे हैं या नहीं जो आप जला रहे हैं।

एक विन्यास प्रबंधन उपकरण (उनमें से कोई भी) आज के बाजार में एक मूल्यवान कौशल बन रहा है।

सीएम टूल को सीखने और कार्यान्वित करने के लिए समय व्यतीत करना आपके व्यवसाय या पर्यावरण के दृष्टिकोण से सबसे कुशल बात नहीं हो सकती है, लेकिन आपके कौशल से यह सार्थक हो सकता है।

प्रबंधन और कार्यान्वयन लागत के बीच टिपिंग बिंदु कहां है?

अधिकांश कॉन्फ़िगरेशन प्रबंधन उपकरण कैविट के साथ मुफ्त में उपलब्ध हैं जो उन्हें स्थापित करने और प्राप्त करने के लिए कठिन हैं।

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

यदि आपको वास्तव में अपने बुनियादी ढाँचे को पूर्वानुमेय और बुनियादी स्थिति में लागू करने की आवश्यकता है, तो हो सकता है कि यह बहुत ही मूल बातें जैसे SaltStack या Ansible को लेने के लिए बहुत नुकसान न करे।

मेरे व्यक्तिगत अनुभव में, नमक को सर्वर पर जाना और बूटस्ट्रैप करना बहुत आसान है, और इसका उपयोग बहुत ही बुनियादी रिमोट निष्पादन और रिपोर्टिंग के लिए किया जा सकता है, जो आपके पर्यावरण में पहले से ही लागू नहीं होने पर काम आ सकता है।

ध्यान रहे, मैं पक्षपाती हूं। आपको प्रत्येक सीएम टूल का मूल्यांकन खुद से करना चाहिए।

Answer 3

जैसे @EEAA ने कहा - सर्वरों की संख्या अप्रासंगिक है। आप एकल मशीन के साथ विन्यास प्रबंधन का उपयोग कर लाभ उठा सकते हैं:

• प्रलेखित सेटअप (सीएम लिपियों के माध्यम से प्रलेखित)
• विश्वसनीय परिनियोजन (आप [पुनः] आप पर और फिर से सेटअप कर सकते हैं
• सेटअप की लचीलापन (वर्तमान सर्वर क्रोक - एक नया स्पिन)
• पुन: उपयोग करें (जब आप एक दूसरे सर्वर होने के एक बिंदु पर आते हैं - आपके पास पहले से ही सीएम स्क्रिप्ट हैं जिन्हें आप पहले एक से रीसायकल कर सकते हैं)
• उन्नयन (यह एक नए सेटअप की तरह है, बस एक अलग मंच के ऊपर)

मैं कह सकता हूं कि मुझे अपने सभी व्यक्तिगत सर्वरों के लिए सीएम को लागू करना था क्योंकि मैं वहां काम करता हूं और सभी छोटे विवरणों को भूल जाता हूं। सीएम स्क्रिप्ट के होने में समय लग सकता है (यह है) पेबैक इसके लायक है। लंबे समय तक आप अधिक समय बचाएंगे कि आप चीजों को स्थापित करने में खर्च करेंगे।

Answer 4

मेरे पास पपेट और अन्सिबल के साथ अनुभव है। अन्सिबल IMO सरल है, क्योंकि यह प्रक्रियात्मक है, जबकि कठपुतली घोषणात्मक है। दोनों के पक्ष और विपक्ष हैं, लेकिन मैंने पपेट की गूढ़ त्रुटियों के कारण पर्याप्त बाल खींचे हैं।

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

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

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

Answer 5

कठपुतली या कोई अन्य प्रबंधन प्रणाली महान लाभ लाती है जो सभी को यहां अन्य उत्तरों से उजागर किया गया है, लेकिन जब प्रबंधन की बात आती है तो कोई चांदी की गोली नहीं होती है।

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

इसके अलावा आपको यह पता लगाने की आवश्यकता है कि आप अपनी कक्षाओं में नियंत्रित तरीके से किए गए परिवर्तनों को कैसे रोल आउट करने की योजना बनाते हैं, और अपने मैनिफ़ेस्ट के विभिन्न संस्करणों को कैसे बनाए रखें।

आपको यह भी विचार करना चाहिए कि समय आने पर अपने प्रबंधन समाधान को अपग्रेड करने के बारे में कैसे जाना चाहिए।

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

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