Microsoft Azure में किसी अनुप्रयोग के लिए शून्य डाउनग्रेड अपग्रेड करें। भाग 1: पा

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



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

वेब परिनियोजन

यह अद्यतन तंत्र केवल परीक्षण और विकास प्रक्रिया में अधिक हद तक लागू होता है। जैसा कि हम जानते हैं, Microsoft Azure दो एप्लिकेशन परिनियोजन तंत्रों का समर्थन करता है: PaaS और IaaS। Web Deploy वेरिएंट PaaS के हिस्से के रूप में चलता है। सामान्य शब्दों में, विजुअल स्टूडियो से किसी एप्लिकेशन के लिए प्रकाशन तंत्र निम्नानुसार है:

• सभी आश्रितों के साथ एक आवेदन बनाएँ
• संग्रह
• Azure Storage पर अपलोड करें
• एक छवि से एक आभासी मशीन की तैनाती
• Azure Storage से वर्चुअल मशीन डिस्क पर आर्काइव कॉपी करें
• संग्रह को अनपैक करना
• IIS सेटअप

मान लीजिए कि विकास टीम के लोग अब सक्रिय रूप से नई कार्यक्षमता का परिचय दे रहे हैं, जिनमें से कुछ को पहले से ही परीक्षकों द्वारा जांचा जा सकता है। पूर्ण तैनाती की प्रक्रिया में बहुत समय लगता है, इसलिए कुछ मामूली बदलावों के कारण, इसे हर बार चलाना अनावश्यक है। इस स्थिति में, आप WebDeploy तंत्र का उपयोग कर सकते हैं। इसकी योजना नीचे प्रस्तुत की गई है:







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







आइए अब इस दृष्टिकोण के पेशेवरों और विपक्षों को देखें।

पेशेवरों:

• अनुप्रयोग के नए संस्करण के लिए परिनियोजन समय कम कर देता है
• छोटे आकार में परिवर्तन
• विजुअल स्टूडियो से सीधे प्रकाशित करें

विपक्ष:

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

जैसा कि हम देखते हैं कि इस पद्धति को शायद ही उत्पादन माना जा सकता है, लेकिन इसके अपने फायदे भी हैं, इसलिए, इसे जीवन का अधिकार है।

वीआईपी स्वैप

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



मान लीजिए कि हमारा ग्राहक हमारे एप्लिकेशन संस्करण 1.0 का उपयोग करता है (contoso.cloudapp.net)। हमारा कार्य उपयोगकर्ता के लिए एप्लिकेशन संस्करण को अदृश्य रूप से 1.1 में अपडेट करना है।



Microsoft Azure क्लाउड सेवाओं में स्लॉट की एक सुविधाजनक अवधारणा प्रदान करता है। जब हम विजुअल स्टूडियो के माध्यम से क्लाउड पर अपना एप्लिकेशन प्रकाशित करते हैं, तो हमें हमेशा पूछा जाता है कि हम अपने एप्लिकेशन को किस स्लॉट में प्रकाशित करना चाहते हैं: स्टेजिंग या प्रोडक्शन।







तदनुसार, इन स्लॉट्स के बीच का अंतर केवल इतना है कि उत्पादन स्लॉट में DNS एक विशिष्ट नाम (हमारे परीक्षण test-app-1.cloudapp.net में) से जुड़ा हुआ है, और स्टेजिंग का नाम GUID.cloudapp.net है। इस प्रकार, आप एक ही सेवा के कई संस्करणों को एक क्लाउड सेवा में रख सकते हैं। जैसा कि मैंने ऊपर बताया, ग्राहक उत्पादन स्लॉट का उपयोग करता है, और हम स्टेजिंग का उपयोग परीक्षण के लिए या रिलीज के लिए पर्यावरण तैयार करने के लिए कर सकते हैं।







क्लाउड सेवा बनाते समय, Azure का आंतरिक लोड बैलेंसर एक विशिष्ट DNS नाम से संबंधित IP पतों की एक तालिका बनाता है। VIP स्वैप का विचार बहुत सरल है - यह स्टेजिंग स्लॉट से बंधी मशीनों के IP पतों को उत्पादन स्लॉट से बंधी मशीनों के IP पतों के साथ बदल रहा है। Azure Load Balancer का आंतरिक IP पता तालिका अद्यतन कार्रवाई कुछ सेकंड का समय लेती है। इस प्रकार, उपयोगकर्ता के दृष्टिकोण से, एप्लिकेशन को नए संस्करण में अपडेट करना तुरंत होता है।







आइए अब इस दृष्टिकोण के पेशेवरों और विपक्षों को देखें।

पेशेवरों:

• लोड बैलेंसर टेबल में IP पते बदलने में सेकंड लगते हैं
• परीक्षण और उत्पादन वातावरण एक दूसरे से अलग-थलग हैं
• यदि आवश्यक हो, तो "सब कुछ वापस लौटाने" की संभावना है (विपरीत दिशा में स्वैप)
• वेब भूमिकाओं और कार्यकर्ता दोनों के लिए समर्थन
• विजुअल स्टूडियो से सीधे तैनात करें

विपक्ष:

• स्टेजिंग और प्रोडक्शन स्लॉट में वर्चुअल मशीनों का कॉन्फ़िगरेशन समान होना चाहिए
• IaaS के तहत तैनात आभासी मशीनों के लिए कोई समर्थन नहीं
• एक समानांतर खांचे में तैनात आभासी मशीनों के लिए अतिरिक्त लागत

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



आज के लिए, यह सब मैं तुम्हारे बारे में बताना चाहता था। अगली बार हम देखेंगे कि IaaS के एक भाग के रूप में तैनात एप्लिकेशन को अपग्रेड करने के लिए Microsoft Azure टूल का उपयोग किया जा सकता है। स्विच मत करो!