'एकल सर्वर एकाधिक व्यवस्थापक' के लिए कॉन्फ़िगरेशन प्रबंधन


9

हमने एक सर्वर स्थापित किया है जो एक छोटे संघ के लिए बुनियादी ढाँचा चला रहा है। अब तक, हमने Ansible के साथ कॉन्फ़िगरेशन को प्रबंधित करने की कोशिश की है, लेकिन यह एक बड़ी सफलता नहीं रही है। शायद हम गलत कर रहे हैं।

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

जब भी हम कुछ सेट करना चाहते थे, तो हम एक साफ स्थापना के साथ शुरुआत में भूमिका निभाते हुए शुरू हुए (nginx, phpfpm, पोस्टफिक्स, फ़ायरवॉल, sftp, munin, ..)। शायद हमारी अनुभवहीनता के कारण, हम निश्चित रूप से कभी भी उस तरह से काम करने वाले कार्यों का एक सेट टाइप करने में सक्षम नहीं होते हैं, जिस तरह से हमें एक बार में इसकी आवश्यकता होती है, क्योंकि कॉन्फ़िगरेशन थोड़ा परीक्षण और त्रुटि प्रक्रिया है। इसका मतलब है कि व्यवहार में, हम आम तौर पर पहले जो भी सेवा हम सर्वर पर चलाना चाहते थे, कॉन्फ़िगर करते हैं , और फिर अनसुने कार्यों में अनुवाद करते हैं। जहाँ यह जा रहा है वहां आप देख सकते हैं। लोग तब कार्य का परीक्षण करना भूल जाते हैं, या चीजों को तोड़ने के जोखिम पर ऐसा करने से डरते हैं, या इससे भी बदतर: हम चीजों को जोड़ने योग्य चीजों को जोड़ने के लिए भूल जाते हैं या उपेक्षा करते हैं।

आज, हमारे पास बहुत कम विश्वास है कि वास्तविक कॉन्फ़िगरेशन वास्तव में दर्शाता है कि सर्वर पर क्या कॉन्फ़िगर किया गया है।

वर्तमान में मुझे तीन मुख्य समस्याएं दिखाई देती हैं:

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

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

क्या कोई व्यवहार्य विकल्प है जो अभी भी कुछ गारंटी और चेक प्रदान करता है (कुछ में Ansible फ़ाइलों को मर्ज करने के लिए तुलनीय है master) जो "चीजों को कॉन्फ़िगर करता है और जो आपने किया था वह लिखता है" प्रदान करने में विफल रहता है?

संपादित करें: हम विचार करने के /etcलिए प्रतिबद्ध है। क्या इस तरह से गोपनीयता (निजी कुंजी, आदि) की रक्षा करने का एक उचित तरीका है, लेकिन अभी भी सर्वर के बाहर कॉन्फ़िगरेशन रिपॉजिटरी उपलब्ध है?

जवाबों:


10

बस एक परीक्षण / स्टेजिंग वीएम को स्पिन करें जो आप अपने परिवर्तनों को मान्य करने के लिए उपयोग कर सकते हैं। मैन्युअल रूप से पहले परिवर्तन करने की आपकी वर्तमान पद्धति निराशाजनक रूप से टूटी हुई है और विफलता के लिए बर्बाद है। आपको और आपकी टीम को सीएम का सही उपयोग करने के लिए प्रतिबद्ध होने की आवश्यकता है और इसका एक हिस्सा परीक्षण प्रणाली उपलब्ध है। यहां तक ​​कि सिर्फ एक स्थानीय योनि वीएम पर्याप्त होगा।

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

रखने में / etc / git में: नहीं, यह मत करो। यह निर्देशिका केवल एक छोटा सा हिस्सा है जो कि परिवर्तनशील है, और जगह में गिट होने से केवल स्थानीय परिवर्तन करने के लिए लोगों को प्रोत्साहित किया जाएगा।

अपनी ansible playbooks को git में रखें। अनुमतियों को प्रतिबंधित करने पर विचार करें, ताकि आप केवल लाइव सर्वर पर ही परिवर्तन कर सकें। अन्य लोग अपने परिवर्तनों के साथ पुल अनुरोध प्रस्तुत कर सकते हैं, जिन्हें आप समीक्षा कर सकते हैं और यदि आवश्यक हो तो मास्टर में विलय कर सकते हैं।


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

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

3
मूल रूप से, यह वास्तव में एक सांस्कृतिक और संसाधन समस्या है, न कि तकनीकी समस्या। आपने कॉन्फ़िगरेशन प्रबंधन का उपयोग करने के लिए प्रतिबद्ध नहीं किया है। आप एक कंपनी हैं या नहीं अप्रासंगिक हैं। आप चीजों को सही तरीके से करने के बारे में मदद के लिए पूछ रहे हैं, और एक मचान वातावरण उसी का हिस्सा है।
EEAA 12

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

4
@ThomWiggers मैं आपको दो अनुमान लगाने जा रहा हूं क्योंकि आप "हम" का उपयोग करते थे, उसी टीम में हैं। ठीक है, आपने पूछा कि यह कैसे ठीक से करना है। मैंने जवाब दिया। या तो आप इसे ठीक से करना चाहते हैं या आप नहीं करते हैं। सीएम को ठीक से करने में समय, पैसा और जानबूझकर लगता है। यदि आपके पास LE के माध्यम से समारोहों को खरीदने और तैनात करने जैसी आवश्यकताएं हैं, तो डिजिटल महासागर के साथ $ 5US / महीने की आभासी मशीन खड़ी करें और परीक्षण के लिए उपयोग करें। हेक, आप इसे केवल डिमांड पर तैनात कर सकते हैं जब आप परिवर्तनों का परीक्षण करना चाहते हैं और फिर इसे मार सकते हैं।
EEAA

6

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

जबकि वहाँ (एक परीक्षण वातावरण नहीं होने की तरह) अन्य मुद्दे हैं, आप नहीं कर रही द्वारा एक बड़ा सुधार हो सकता है यह

में से एक Ansible के मुख्य डिजाइन लक्ष्यों हो रहा है idempotent है, जो मतलब है कि आपके प्लेबुक कई बार चल रहा है कुछ भी परिवर्तन नहीं होना चाहिए (आप नाटकों बदल दिया है जब तक)। इस प्रकार, जब मैं सॉफ्टवेयर के एक नए टुकड़े को कॉन्फ़िगर कर रहा हूं, मेरे कदम हैं:

  1. परिवर्तनशील कार्यों में परिवर्तन करें।
  2. प्लेबुक चलाएं।
  3. सिस्टम की जाँच करें, और यदि यह सही नहीं है, तो चरण 1 पर लौटें।
  4. मेरे परिवर्तन करें।

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


हाँ, यह बहुत अच्छी सलाह है। ऐसा करना, और यह सुनिश्चित करना कि आप हमेशा अपने सर्वर को एक ज्ञात-अच्छी स्थिति में वापस ला सकते हैं , बहुत ही मुक्त है - अगर चीजें दक्षिण में जाती हैं, तो बस सर्वर को न्यूक करें और फिर से तैनात करें।
EEAA

ठीक है, मैं मानता हूं कि यह बहुत ठोस मध्य-मैदान है जहां हम अभी हैं और हमें कहां होना चाहिए। बेशक, इस तरह से हमने शुरुआत की। मुझे लगता है कि मुख्य कारण है कि हम जहां हम अब कर रहे हैं करने के लिए बहाव है कि चरण 2 पूरे चक्र बहुत लंबा बना रहा था। यह हो सकता है कि हम प्लेबुक गलत कर रहे थे। अब जब हमने कुछ और विवादास्पद कार्यों को लिखने में पारंगत कर लिया है, तो यह फिर से प्रयास करने के लिए शायद सार्थक है। आपके अनुभव में, एक पूरा चक्र कितना समय लगेगा और कितनी बार एक पुनरावृति होगी? मुझे लगता है कि कोई भी संख्या सभी प्रकार की मान्यताओं पर आधारित होने जा रही है ..
जोस्ट

2
इस पुनरावृत्ति प्रक्रिया के साथ आई एक अलग समस्या तब होती है जब आप एक ऐसा कार्य लिखते हैं जो परिवर्तन करता है, सर्वर में परिवर्तन करता है, पता चलता है कि परिवर्तन गलत हैं, अपने कार्य को अपडेट करें और प्लेबुक को फिर से लागू करें। अब सर्वर में परिवर्तनों के दो सेटों का मिश्रण होता है: कार्य के पहले पुनरावृत्ति से वाले, और दूसरे से। आमतौर पर दूसरा पुनरावृत्ति पहले को अधिलेखित कर देगा, लेकिन जरूरी नहीं कि हमेशा। क्या 1) के बजाय मैन्युअल रूप से SSH'ing को पूर्ववत करने के लिए 'क्लीन अप' का एक उचित तरीका है, या 2) हर बार एक साफ स्थापना से शुरू होता है?
Joost

इसके अतिरिक्त, यदि आप केवल एक ही है तो
Thom Wiggers

"आपके अनुभव में, एक पूरा चक्र कितना समय लगेगा और कितनी बार एक पुनरावृति होगी?" - मैंने जनवरी में Ansible का उपयोग करना शुरू कर दिया; लगभग जून तक, मैं उस बिंदु पर पहुंच गया, जहां मैं ज्यादातर कार्यों के लिए हाथ की तुलना में Ansible में पूरी प्रक्रिया को तेजी से कर रहा हूं । पाठ्यक्रम का विशिष्ट समय कुछ मिनटों से लेकर कुछ हफ्तों (कुछ विशेष रूप से कैंटीनरी सॉफ्टवेयर के लिए) पर निर्भर करता है। यदि आप पाते हैं कि प्लेबुक का चलना ही आपको धीमा कर रहा है, तो हो सकता है कि आप टैग्स का उपयोग करके देखना चाहते हों कि आपके इट्रिएशन लूप्स के दौरान एक सबसेट चलाने के लिए।
मोनिका सेलियो

0

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

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

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

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

तो आदेश modifactaion के अधीन है, जाहिर है क्योंकि कार्यान्वयन इस बात पर निर्भर करता है कि आपके वर्तमान राज्य के लिए कौन सा मार्ग कम से कम विघटनकारी है।

  1. किसी भी व्यवसाय से संबंधित वर्कफ़्लो संबंधित सिस्टम कार्य को एक समर्पित रंडेक में ले जाएं।

  2. बॉक्स पर कार्यों को विभाजित करें, आपके पास अभी एक या दो बॉक्स हो सकते हैं।

  3. अपने सीएम को और अधिक संरचित तरीके से लागू करें, और बेहतर व्यवहार योग्य प्रथाओं का पालन करें, वस्तुओं या कार्यों का प्रतिनिधित्व नहीं करने वाली प्लेबुक। प्रत्येक प्रणाली को एक नाटक में वर्णित किया जाना चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.