साइट एएसपी.NET वेब एप्लिकेशन को फिर से प्रकाशित करना साइट पर लाइव है

Question

मैं साइट पर उपयोगकर्ताओं के दौरान एक लाइव, फ़ंक्शनिंग एएसपी.नेट (2.0 या अधिक) एप्लिकेशन के अपडेट को संभालने के तरीके पर समझने की कोशिश कर रहा हूं।

उदाहरण के लिए, मान लीजिए एसओ एक एएसपी.नेट वेब एप्लिकेशन प्रोजेक्ट है। प्रोजेक्ट कोड बीआईएन फ़ोल्डर में एकल डीएलएल को संकलित करता है। अब, SO पर निरंतर उपयोगकर्ता हैं, तो यदि आप साइट का उपयोग कर रहे हों, तो आप विज़ुअल स्टूडियो .NET "प्रकाशित करें" सुविधा (या केवल एफ़टीपी सब कुछ मैन्युअल रूप से) का उपयोग करेंगे, तो उपयोगकर्ताओं के कार्यों/सत्रों के साथ क्या होगा?

एक एएसपी.नेट वेब साइट बनाना, इसके बजाय, उपरोक्त परिदृश्य के साथ मौजूद किसी भी समस्या को कम या कम नहीं कर सकता है? मैं उपयोगकर्ता द्वारा संचालित वेब एप्लिकेशन के रूप में एक वेब साइट विकसित करना शुरू कर रहा हूं, और मैं यह सुनिश्चित करना चाहता हूं कि इसके साथ मेरा अनुभवहीनता संभावित रूप से [संभावित रूप से] कई उपयोगकर्ताओं को परेशान न करे जो मैं चाहता हूं कि 24/7 हो।

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

Answer 1

एएसपीनेट वेब साइट मॉडल में बदलना कोई प्रभाव नहीं पड़ेगा, क्योंकि रीसायकल भी होगा, कुछ बदलाव जो इसे सुनिश्चित करने के लिए ट्रिगर करते हैं: web.config, global.asax, app_code।

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

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

Answer 2

एक समाधान आपके आवेदन को लोड संतुलित वातावरण (वेब ​​फार्म) में तैनात करने के लिए हो सकता है।
जब कोई नया संस्करण तैनात करते हैं तो आप लोड बैलेंसर का उपयोग उस सर्वर पर अनुरोधों को पुनर्निर्देशित करने के लिए करेंगे, जिसे आप तैनात नहीं कर रहे हैं।

Answer 3

मुझे यकीन नहीं है कि यह कैसे संभालता है .. लेकिन हम आमतौर पर एक होल्डिंग पेज डालते हैं। तो उपयोगकर्ता ने जो भी किया है (प्रश्न या उत्तर देने वाले प्रश्न) को अद्यतन नहीं किया गया है। जैसे ही वह कुछ अपडेट करता है, उसे एक होल्डिंग पेज दिखाई देगा जो उसे कुछ समय बाद कोशिश करने के लिए कहता है।

और यदि मैं उपयोगकर्ता हूं तो मैं आमतौर पर बैक बटन दबाता हूं ताकि यह सुनिश्चित किया जा सके कि मैंने जो दर्ज किया है वह ब्राउज़र इतिहास में सहेजा गया है ताकि मैं बाद में पोस्ट कर सकूं।

कुछ साइट उपयोग उपयोग क्लस्टर पर्यावरण में हैं इसलिए मैं एक सर्वर ऑफ़लाइन लेता हूं और लोड बैलेंसर को सूचित करता हूं कि वह उपलब्ध नहीं होगी और एक बार जब मैं सुनिश्चित करूँ कि नया संस्करण ठीक काम कर रहा है तो मैं इसे लाइव बना देता हूं .. मैं करता हूं अगले सर्वर के लिए एक ही बात है।

क्या हमारे पास कोई अन्य विकल्प है?

Answer 4

App_offline.htm मुझे लगता है कि यह बहुत अच्छा समाधान है।

एसओ में हम तैनाती शुरू होने पर वर्तमान में अनुपलब्ध पृष्ठ एप्लिकेशन देखते हैं।

Answer 5

मैं आईआईएस में दो वेबसाइटें बनाता हूं। एक उत्पादन वेबसाइट है, और दूसरा एक एचटीपीएचंडलर के साथ एक स्थिर वेबसाइट है जो सभी अनुरोधों को एक ही स्थिर "हम अपडेट कर रहे हैं" HTTP पृष्ठ को HTTP 503 सेवा अनुपलब्ध के साथ प्रस्तुत करता है। आमतौर पर अद्यतन वेबसाइट बंद कर दिया जाता है। जब अपडेट करने का समय होता है, तो हम उत्पादन वेबसाइट को रोकते हैं, अपडेट वेबसाइट शुरू करते हैं, और अब हम उत्पादन वेबसाइट के साथ परेशान हो सकते हैं, जो हम चाहते हैं कि डीएलएल लॉक होने के बारे में चिंता किए बिना या कार्यकर्ता प्रक्रियाओं को कम करने की आवश्यकता हो।

मैं क्योंकि

• App_Offline.htm वास्तव में वेब गार्डन, जो हम प्रयोग में अच्छी तरह से काम नहीं करता है यह कर शुरू कर दिया।
• App_Offline.htm अपने पृष्ठ को 404 के रूप में कार्य करता है, जो कि यदि आप सार्थक अवधि के लिए नीचे हैं तो यह बुरा है।
• हम संशोधित सेटिंग्स (केवल स्थानीयहोस्ट पर सुनकर) के साथ अपग्रेड किए गए उत्पादन वेबसाइट को शुरू कर सकते हैं, जहां हम आखिरी मिनट की स्वीकृति/सत्यापन कर सकते हैं कि स्विच स्विच करने से पहले सबकुछ काम कर रहा है, अद्यतन वेबसाइट को बंद कर रहा है और फिर उत्पादन वेबसाइट को सक्षम करना।

हालात इस का समाधान नहीं करता शामिल

• किसी भी रखरखाव कि सर्वर के प्रारंभ करने की आवश्यकता - आप अभी भी डाउनटाइम जहां कोई पेज परोसा जाता है की है।
• कोई भी रखरखाव जो .NET रनटाइम के साथ डूबता है, जैसे नवीनतम सर्विस पैक में अपग्रेड करना।

अन्य दृष्टिकोण मैंने देखा है

• दो सर्वर होने शामिल हैं। सभी लोड संतुलन अनुरोधों को एक सर्वर पर भेजें, दूसरे को अपग्रेड करें; फिर कुल्ला और दोहराना। हम में से अधिकांश को यह विलासिता नहीं है।
• बिन-1.0.0.0 और बिन-1.1.0.0 जैसे एकाधिक बिन निर्देशिकाएं बनाना और एएसपी.NET को बताएं जो वेब.कॉन्फिग फ़ाइल में उपयोग करने के लिए बिन निर्देशिका है। (इसका एक फायदा यह है कि पिछली बाइनरी पर वापस लौटना सिर्फ एक कॉन्फ़िगरेशन फ़ाइल को संपादित करना है। एक नुकसान यह है कि उन संसाधनों को वापस करना मुश्किल है जो आपकी बाइनरी में समाप्त नहीं होते हैं, जैसे टेम्पलेट्स और छवियों और ऐसे।) याद रखें कि यह वास्तव में कैसे काम करता था - मुझे लगता है कि एप्लिकेशन ने अपने ग्लोबल.एक्सएक्स में अपने वेब.कॉन्फिग सेक्शन में कुछ देर से असेंबली लोडिंग की थी (चूंकि आपने web.config को छुआ था, ऐप फिर से शुरू हुआ था, इसलिए यह ठीक था)।

यदि आपको एक बेहतर तरीका मिल गया है, तो मुझे बताएं!

Answer 6

यह एक तकनीकी समाधान नहीं है, लेकिन एक निर्धारित रखरखाव विंडो स्थापित है। आप पहले से ही अपने उपयोगकर्ता आधार निष्पक्ष चेतावनी देकर घोषणा कर सकते हैं कि एक संभावना है कि आवेदन उस समय सीमा के दौरान उपलब्ध नहीं होगा।