क्या इलास्टिक बीनस्टॉक एंटरप्राइज-ग्रेड सीडी के लिए उपयुक्त है?


11

मैं एक ऐसी परियोजना के साथ काम कर रहा हूं, जो कि इलास्टिक बीनस्टॉक को माइक्रोसिंक बनाने और तैनात करने के लिए जेनकिंस का उपयोग कर रही है। हम एक परीक्षण पर्यावरण के लिए एक एकीकरण शाखा तैनात करते हैं, एक मंचन पर्यावरण के लिए शाखाएं जारी करते हैं, और फिर उत्पादन के लिए एक अंतिम मास्टर निर्माण करते हैं। मुझे इस तरह से करने के साथ कुछ चिंताएं हैं: पहला, इसका मतलब है कि हम प्रति प्रोजेक्ट प्रति पर्यावरण के एक मैट्रिक्स के साथ समाप्त होते हैं, प्रयासों को दोहराते हैं; और दो, इसका मतलब है कि हम उसी निर्माण कलाकृतियों को उत्पादन के लिए तैनात नहीं कर रहे हैं जो मंचन में मान्य थे।

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

नोट : उसी बिल्ड विरूपण साक्ष्य को बढ़ावा देना बिल्कुल वही है जो मैं करना चाहता हूं, लेकिन डॉक्स से मुझे ऐसा करने का कोई स्पष्ट तरीका नहीं दिखता है; यह बताता है कि अपने ऐप स्रोत से ईबी को कैसे तैनात किया जाए, लेकिन किसी अन्य वातावरण में मौजूदा संस्करण को कैसे बढ़ावा दिया जाए, जब तक कि मैं इसे सही तरीके से स्क्रॉल करने में कामयाब न हो। यदि यह EB में ही उपलब्ध है, तो जेनकिंस EB परिनियोजन प्लगइन में एक सीमा हो सकती है जो इसे विशेष रूप से जेनकिंस में होने से रोकता है, लेकिन मैंने इसे करने का कोई तरीका नहीं देखा है।


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

आप परीक्षण के बाद अन्य परिसंपत्तियों को उसी संपत्ति को बढ़ावा देने के बजाय अपनी संपत्ति का पुनर्निर्माण क्यों कर रहे हैं?
इवगेनी

जवाबों:


4

IMO की राय में आपका मुद्दा उस परिदृश्य में इलास्टिक बीनस्टॉक के साथ नहीं है, यह जेनकिंस के साथ है, या कम से कम जिस तरह से आप इसका उपयोग कर रहे हैं। आपको वास्तव में केवल एक बार "एक चीज" बनाने पर ध्यान केंद्रित करना चाहिए, चाहे वह चीज कोई भी हो।

पूर्ण प्रकटीकरण: मैं ThoughtWorks के लिए काम करता हूं और अविश्वसनीय रूप से GoCD का पक्षपाती हूं। मैं यह समझने की कोशिश करूंगा कि जितना मैं कर सकता हूं उतना तटस्थ हूं। मैं हमारे टूल के डॉक्स का उपयोग करूंगा उदाहरण हैं, लेकिन उम्मीद है कि लोग अपने सिस्टम को एक्सट्रपलेशन कर सकते हैं।

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

उदाहरण के लिए...

  1. मैं एक .jar फ़ाइल का निर्माण करता हूं और उस पर कुछ यूनिट टेस्ट चलाता हूं, बेसिक सी / आई स्टफ। यदि यह गुजरता है, तो .jar फ़ाइल और परीक्षणों का आउटपुट उस विशिष्ट पाइपलाइन नौकरी पर अपलोड हो जाता है ।
  2. अगली पाइपलाइन अधिक जटिल परीक्षण वातावरण में आपकी तैनाती हो सकती है। यह सटीक जार को सटीक नौकरी से लाना चाहिए जिसने इसे बनाया था। इसके बाद उस जार को सही वातावरण में तैनात करने के लिए इलास्टिक बीनस्टॉक निष्पादित करता है।
  3. अगली पाइपलाइन आपकी चरणबद्ध तैनाती है। यह पहली पाइपलाइन पर वापस जाता है और इसे बनाने वाले सटीक काम से सटीक जार प्राप्त करता है। तब निष्पादन योग्य इलास्टिक बीनस्टॉक में उस जार को सही वातावरण में तैनात करने के लिए।

ये प्रत्येक अलग-अलग पाइपलाइन हैं क्योंकि इससे आप समानांतर में या अवरुद्ध किए बिना मांग पर अधिक चल सकते हैं

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

इस तरह की चीजों को हल करने के लिए गोसीडी , शेफ ऑटोमेट और कॉनकोर्ससी जैसे निरंतर डिलीवरी सर्वर विशेष रूप से बनाए गए थे।


हां, मेरा लक्ष्य एक बार निर्माण करना और उत्पादन को बढ़ावा देना है। मेरा प्रश्न यह है कि क्या बीनस्टॉक इस प्रकार के उपयोग के अनुकूल है। मैं जो बता सकता हूं, वह वास्तव में प्रतीत नहीं होता है; उदाहरण के लिए, .NET एप्लिकेशन को लागू करने की अनुशंसित विधि दृश्य स्टूडियो से ऐसा करने के लिए है, जो कि सबसे खराब अभ्यास के बारे में है जो मैं सोच सकता हूं।
एड्रियन

मैंने इसे व्यक्तिगत रूप से उपयोग नहीं किया है, लेकिन ऐसा लगता है कि यदि आप "प्रमोशन" शब्द को "परिनियोजित" में बदलते हैं। आपका सीडी सिस्टम परीक्षण के लिए तैनात करने के लिए बीनस्टॉक को कॉल करता है, कुछ परीक्षण चलाता है और फिर सफलता / विफलता की रिपोर्ट करता है। यदि यह सफल होता है, तो आपका सीडी सिस्टम मंचन के लिए बीनस्टॉक को कॉल करता है, और इसी तरह। तो, प्रचार आपके ऑर्केस्ट्रेशन टूल द्वारा किया जाता है, परिनियोजन आपके परिनियोजन उपकरण द्वारा किया जाता है। (FYI करें, यही कारण है कि शेफ जैसी कंपनियों में हाइबरनेट (चीज),
ऑटोमेट

FYI करें, ऐसा लगता है कि आप इसे स्क्रिप्ट कर सकते हैं (इन्फ्रास्ट्रक्चर कोड के रूप में "अच्छी बात है") docs.aws.amazon.com/elasticbeanstalk/latest/dg/… - लेकिन फिर से, बिल्कुल 0 व्यक्तिगत अनुभव।
केन मुग्रेग

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

आह, इसके बारे में क्षमा करें। मैं ~/eb$ eb deploy Creating application version archive "app-150630_014338". Uploading elastic-beanstalk-example/app-150630_014338.zip to S3किसी भी ज़िप फ़ाइल का मतलब निकालने की व्याख्या कर रहा था जिसे आप उस निर्देशिका में अटका रहे थे। सौभाग्य!
केन मुगरेज
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.