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

हमारे लक्ष्य

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

हम थोड़ा और प्रारंभिक सेटअप समय के साथ ठीक हैं यदि ऐसा करने से हमें भविष्य में कुछ सिरदर्द से बचा जा सकेगा।

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

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

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

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

क्या आप इलास्टिक बीनस्टॉक का उपयोग करते हैं? यदि हां, तो क्यों और किन कारणों से यह निर्णय लिया गया? आपको क्या पसंद और नापसंद है?

यदि आप इलास्टिक बीनस्टॉक का उपयोग नहीं करते हैं, लेकिन इस पर विचार करते हैं, तो आप क्या उपयोग करते हैं और आपने इलास्टिक बीनस्टॉक का उपयोग क्यों नहीं किया?

SOA के लिए इलास्टिक बीनस्टॉक आधारित परिनियोजन रणनीति के क्या फायदे और नुकसान हैं? यही है, क्या इलास्टिक बीनस्टॉक कई छोटे अनुप्रयोगों के साथ अच्छा काम करेगा जो काम करने के लिए एक दूसरे पर निर्भर हैं?

answer

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

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

समस्याएं जो मैं अपने आवेदन के साथ चला रहा था:

  • गिट आधारित तैनाती - मैं उन्हें प्यार करता हूँ लेकिन हमारा रेपो 1+ जीबी है। बल्कि नियमित आधार पर धक्का देने के लिए बड़ा। इस रेपो में लगभग 40 एप्लिकेशन भी शामिल हैं (जिन्हें वास्तव में विभाजित किया जाना चाहिए) लेकिन इसमें कुछ समय लगेगा। किसी भी प्रकार के पैकेज को अपलोड करना काम कर सकता है लेकिन हमारे अधिकांश एप्लिकेशन इसे पैकेज में बनाने के लिए बड़ी मात्रा में काम करेंगे।

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

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

मैं Asgard द्वारा प्रदान किए गए कुछ स्वचालन के बजाय AWS Autoscaling Groups का उपयोग करना चुनकर घायल हो गया यह मौजूदा कॉन्फ़िगरेशन/एप्लिकेशन कोड में सबसे छोटा बदलाव था और हमें वे लाभ प्रदान किए जिनकी हम तलाश कर रहे थे, AWS API के माध्यम से उपलब्ध कई सर्वरों का सरल प्रबंधन।

आपके आवेदन पर इलास्टिक बीनस्टॉक द्वारा लगाए गए प्रतिबंध बहुत मददगार हैं। आपको यह सुनिश्चित करना होगा कि आपका आवेदन ज्यादातर स्टेटलेस है, एक सेवा के लिए एक समापन बिंदु प्रदान करता है, और राज्य के लिए अन्य सेवाओं पर निर्भर करता है। यदि आप पुन: प्रयोज्य स्टैंड-अलोन सेवाओं को बनाने का प्रयास कर रहे हैं तो बीनस्टॉक में एकाधिक अनुप्रयोग एक अच्छी शुरुआत है।

यदि/जब आप अधिक कॉन्फ़िगरेशन चाहते हैं तो OpsWorks एक बेहतरीन अगला कदम है। पूर्वनिर्धारित भूमिकाओं को संक्रमण को शुरू करना आसान बनाना चाहिए और यह कई सर्वरों के प्रावधान के समन्वय में मदद करने के लिए शेफ के आसपास एक स्वचालन ढांचा प्रदान करता है।

मुझे नियंत्रण के नुकसान का बिंदु दिखाई देता है, लेकिन मैं अनिवार्य रूप से अनिवार्य स्टेटलेसनेस नहीं देखता। सभी ईबी वास्तव में ऑटोमेशन को तैनात करते हैं, जो कि कमाल है। मैं एक बड़े भंडार का बिंदु देखता हूं। मैं सामान्य रूप से सोचता हूं कि लॉजिकल ऐप फ़ंक्शंस को अलग-अलग बीन्स ऐप्स में अलग करना, और उसके बाद "स्टेजिंग" और "प्रोड" वातावरण नीचे है, वास्तव में अच्छा है। हमारे पास अपलोडर जैसे मॉड्यूल वातावरण हैं, यह बहुत कुछ नहीं करता है और सिद्धांत रूप में यह बहुत अधिक लागत जोड़ता है, लेकिन फिर आप छोटे उदाहरणों का उपयोग कर रहे हैं। हम एक केंद्रीकृत nginx चलाते हैं, और ऑटो स्केल नीति में परिवर्तनों के ngnix को सूचित करने के लिए बहुत से कस्टम sns संदेश हैंडल लिखने पड़ते हैं। एक और बड़ा मुद्दा यह है कि लोड बैलेंस को बंद करने में असमर्थता है, क्योंकि हम ngnix का उपयोग करते हैं, क्यों? एल्ब वेबसोकेट का समर्थन नहीं करता है।