उत्पादन में WAR की चिकनी पुनर्निर्माण?

Question

मैं सोच रहा था कि एक उत्पादन सर्वर (जावा, कोई ओएसजीआई) में जावा वॉर को पुन: नियोजित करने का 'आसान तरीका' है?

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

आपका दृष्टिकोण क्या है?

Answer 1

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

हमारा वर्तमान दृष्टिकोण सभी सर्वरों के सामने लोड-बैलेंसर के साथ स्विच का उपयोग करना है। हम एप्लिकेशन सर्वर के कम से कम 2 उदाहरण चलाते हैं। जब हम रखरखाव के लिए एक सर्वर को बंद करते हैं, तो यातायात स्वचालित रूप से दूसरे पर जाता है।

कुछ स्विच वास्तव में सस्ती हैं। यदि आपके पास एक नया बॉक्स उचित ठहराने के लिए पर्याप्त भार नहीं है और आपके 2 उदाहरण एक ही बॉक्स पर चल सकते हैं।

कुछ परिस्थितियों में, स्विच वास्तव में पैसे बचा सकते हैं। उदाहरण के लिए, हमारे पास एक एसएसएल पेज है जो 6 बक्से का उपयोग करता था और अब यह स्विच में एसएसएल त्वरण के साथ 2 बक्से पर ठीक चलता है।

Answer 2

आप JRebel पर एक नज़र डाल सकते हैं, हालांकि मैं इसे उत्पादन में उपयोग नहीं करता। उत्पादन में हम मूल रूप से वही करते हैं, हालांकि हमारा मालिक गर्म पुनर्वितरण का सपना देखता रहता है। दुर्भाग्य से वे ज्यादातर कागज पर समर्थित हैं - अधिकांश जटिल अनुप्रयोगों में कुछ गर्म पुनर्वितरण के साथ हमेशा गलत होता है। वृद्धिशील गर्म पुनर्वितरण के लिए भी वही है ...

Answer 3

आमतौर पर, mv old.war new.war और एएस इसे वहां से ले जाने दें, हालांकि बहुत व्यस्त 24/7 सेवाओं के साथ, मुझे लगता है कि यह एक विकल्प नहीं होगा।

Answer 4

कुछ एप्लिकेशन सर्वर सेवा के बाधा के बिना पुनर्वितरण का समर्थन करते हैं। यह वेबलॉगिक के लिए कम से कम सच है, Using Production Redeployment to Update Applications देखें। ध्यान दें कि यह गर्म तैनाती नहीं है (और मैं कभी भी उत्पादन सर्वर के साथ गर्म तैनाती का उपयोग नहीं करता)।

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

Answer 5

आमतौर पर स्टार्ट-अप समय को अनुकूलित करना संभव है। हमारा वेब एप्लिकेशन जेटी के साथ 5-7 सेकेंड में शुरू होता है। अन्य जावा वेब सर्वर खराब हैं, क्योंकि वे बहुत धीमी गति से शुरू होते हैं।

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

Answer 6

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

location /best-app-ever/ { proxy_pass host-address:8080/some-app-1.1 root /home/www/some-app-1.1 }

स्विचिंग संस्करण के रूप में अच्छी तरह से चिकनी किया जाना चाहिए। यह मानते हुए कि आप पहले से ही आवेदन के नए संस्करण तैनात किया है सिर्फ nginx विन्यास फाइल को बदलने और लागू परिवर्तन:

location /best-app-ever/ { proxy_pass host-address:8080/some-app-1.2 root /home/www/some-app-1.2 }

sudo nginx -t
sudo service nginx restart

चेतावनी दी हो कि इस मामले में अपने वेब अनुप्रयोग स्टेटफुल है और/या शामिल कुछ चल रहे या अनुसूचित प्रक्रियाओं, तैनाती और अनावश्यकता चिकनी नहीं हो सकती है।