के साथ ब्लू/ग्रीन डिप्लोमेंट्स मैं वर्तमान में Azure ServiceFabric पर विश्वसनीय डोमेन फ्रेमवर्क का उपयोग कर एक एप्लिकेशन बना रहा हूं। जैसे-जैसे हम बड़े होते हैं, मैं नीले/हरे रंग की तैनाती कर रहा हूं। मैं देख सकता हूं कि एक स्टेटलेस सिस्टम का उपयोग करके इसे कैसे किया जाए। क्या राज्य के कलाकारों का उपयोग करके ऐसा करने का कोई तरीका है?Azure ServiceFabric
सेवा फैब्रिक वीआईपी स्वैप की तरह तैनाती स्वैप की बजाय अपग्रेड रोलिंग के बारे में है। स्टेटलेस और स्टेटफुल दोनों सेवाओं को एक ही तरीके से अपग्रेड किया गया है, लेकिन कुछ अतिरिक्त बारीकियों के बारे में बताया गया है कि मैं बाद में उल्लेख करूंगा।
अपग्रेड रोलिंग करके, मेरा मतलब है कि एक आवेदन में अपग्रेड किया जाता है, एक समय में एक अपग्रेड डोमेन, ताकि कोई डाउनटाइम न हो और अचानक स्विच न हो। सेवा फैब्रिक में एक रोलिंग अपग्रेड एक सुरक्षित "प्रबंधित" मोड में किया जा सकता है जहां मंच अगले अपग्रेड डोमेन पर जाने से पहले स्वास्थ्य जांच करेगा, और यदि स्वास्थ्य जांच विफल हो जाती है तो स्वचालित रूप से वापस आ जाएगी।
ठीक है, यह सब अच्छा लगता है। लेकिन जब आप उन्नयन हमेशा उन्नयन कर रहे होते हैं तो आप नीले/हरे रंग की तैनाती कैसे करते हैं?
यह जहां एप्लिकेशन प्रकार और संस्करण आते हैं। दो "वातावरण" रखने के बजाय दो चल रहे अनुप्रयोगों को पकड़ने के बजाय, सेवा फैब्रिक में संस्करण वाले अनुप्रयोग प्रकारों की यह अवधारणा है, जिससे एप्लिकेशन उदाहरण बनाए जा सकते हैं। यहां यह एक उदाहरण दिया गया है कि यह कैसे काम करता है:
मान लें कि मैं फ़ू नामक एक एप्लिकेशन बनाना चाहता हूं। मेरा फू एप्लिकेशन को एप्लिकेशन प्रकार के रूप में परिभाषित किया गया है, इसे फूटाइप कहते हैं। यह सी # में एक कक्षा को परिभाषित करने के समान है। और सी # में कक्षा की तरह, मैं अपने प्रकार के उदाहरण बना सकता हूं। प्रत्येक इंस्टेंस में एक अद्वितीय नाम होता है, इस तरह कि किसी वर्ग के प्रत्येक ऑब्जेक्ट उदाहरण में एक अद्वितीय चर नाम होता है। लेकिन सी # में कक्षाओं के विपरीत, मेरे फूटाइप में संस्करण संख्या है। तब मैं "पंजी" कर सकते हैं आवेदन के प्रकार और मेरी क्लस्टर में संस्करण:
FooType 1.0
, मुझे लगता है कि आवेदन का एक उदाहरण बना सकते हैं: अब
"fabric:/FooApp" of FooType 1.0
, मान लीजिए कि मैं संस्करण 2.0 का विकास करते हैं मेरे आवेदन का इसलिए मैं क्लस्टर में मेरी FooType के संस्करण 2.0 रजिस्टर:
FooType 1.0
FooType 2.0
अब मैं FooType के दोनों संस्करणों पंजीकृत किया है, और मैं अभी भी 1.0 चल रहा है का एक उदाहरण है:
"fabric:/FooApp" of FooType 1.0
यहाँ जहां यह मजेदार हो जाता है । मैं कुछ दिलचस्प चीजें कर सकता हूं:
मैं "कपड़े:/FooApp" ले सकता हूं - FooType 1.0 का एक उदाहरण - और इसे FooType 2.0 में अपग्रेड करें। यह उस चल रहे एप्लिकेशन का एक रोलिंग अपग्रेड होगा।
या .. मैं "कपड़े:/FooApp" छोड़ सकते हैं अकेले, और एक नई मेरी संस्करण 2.0 आवेदन के उदाहरण बनाने के लिए:
"fabric:/FooApp" of FooType 1.0
"fabric:/FooAppv2Test" of FooType 2.0
, एक ही क्लस्टर में। एक 1.0 का एक उदाहरण है, और दूसरा 2.0 का एक उदाहरण है। पोर्ट्स और एप्लिकेशन एंडपॉइंट्स के कुछ कॉन्फ़िगर करने के साथ, मैं यह सुनिश्चित कर सकता हूं कि 2.0 इंस्टॉलेशन का परीक्षण करते समय उपयोगकर्ता अभी भी 1.0 इंस्टेंस पर जा रहे हैं।
बढ़िया, तो मेरे सभी परीक्षण 2.0 उदाहरण के खिलाफ गुजरते हैं, इसलिए अब मैं सुरक्षित रूप से 1 ले सकता हूं।0 उदाहरण और अपग्रेड 2.0 को FooType में अपग्रेड करें। दोबारा, यह उस उदाहरण (कपड़े:/FooApp) का एक रोलिंग अपग्रेड है, यह उपयोगकर्ताओं को नए इंस्टेंस (कपड़े:/FooAppv2Test) में माइग्रेट नहीं कर रहा है। बाद में मैं कपड़े जाउंगा और हटा दूंगा:/FooAppv2Test क्योंकि यह सिर्फ परीक्षण के लिए था।
नीले/हरे रंग के लाभों में से एक हालांकि अगर कोई नया विफल रहता है तो अन्य तैनाती पर वापस आना सक्षम हो रहा है। खैर, आपके पास अभी भी FooType पंजीकृत 1.0 और 2.0 दोनों हैं। इसलिए यदि आपका एप्लिकेशन 1.0 से 2.0 तक अपग्रेड के बाद गलत व्यवहार करना शुरू कर देता है, तो आप इसे वापस "अपग्रेड" कर सकते हैं 1.0! वास्तव में, आप अपने आवेदन प्रकार के कई अलग-अलग संस्करणों के बीच एक एप्लिकेशन इंस्टेंस को "अपग्रेड" कर सकते हैं! और आपके पास उदाहरण आपके स्वैपिंग वातावरण में चल रहे सभी एप्लिकेशन संस्करणों की आवश्यकता नहीं है, आपके पास केवल अलग-अलग संस्करण पंजीकृत हैं और एक एकल एप्लिकेशन उदाहरण है जो संस्करणों के बीच "अपग्रेड" कर सकता है।
मैंने राज्यव्यापी सेवाओं के साथ चेतावनी का उल्लेख किया। राज्यव्यापी सेवाओं के साथ याद रखने की बड़ी बात यह है कि आवेदन स्थिति - आपके उपयोगकर्ता का डेटा - एप्लिकेशन इंस्टेंस (कपड़े:/FooApp) में निहित है, इसलिए आपके उपयोगकर्ताओं को उनके डेटा देखने के लिए आपको उन्हें उस उदाहरण पर रखने की आवश्यकता है। यही कारण है कि हम तैनाती स्वैप के बजाय रोलिंग उन्नयन करते हैं।
यह सिर्फ मूल विचार है। आपके लक्ष्य क्या हैं और आपका एप्लिकेशन कैसे काम करता है, इस पर निर्भर करता है कि आप एप्लिकेशन प्रकारों, संस्करणों और उदाहरणों के साथ अन्य तरीकों से खेल सकते हैं, लेकिन यह एक और समय के लिए है।
यह सहायक था, धन्यवाद Vaclav। नीले/हरे रंग की शैली की तैनाती के मेरे दिमाग में लाभों में से एक यह है कि मैं दूसरी सेवा के माध्यम से एक ट्रिकल कर सकता हूं ताकि यह सुनिश्चित किया जा सके कि मैं पूरे स्वैप करने से पहले काम कर रहा हूं, आमतौर पर लोड बैलेंसर के माध्यम से इसे निर्देशित करके। क्या एसएफ पर समान सत्यापन करने का कोई तरीका है? – blackSphere
स्टेटलेस सेवा के लिए, निश्चित रूप से, आप इसे v1.0 और v2.0 का एक उदाहरण बना सकते हैं, और अपने स्वयं के कुछ रूटिंग के माध्यम से आप v2.0 पर यातायात को फ़नल कर सकते हैं जबकि धीरे-धीरे इसे स्केल कर सकते हैं और v1.0 को स्केल कर सकते हैं । राज्यव्यापी सेवाओं के लिए यह थोड़ा सा ट्रिकियर है क्योंकि राज्य स्वयं ही एप्लिकेशन इंस्टेंस के अंदर है, इसलिए यदि आप एप्लिकेशन के नए इंस्टेंस में उपयोगकर्ताओं को भेजते हैं, तो उनका डेटा वहां नहीं होगा। यह सामान्य रूप से राज्य की चीजों की प्रकृति है, और यही कारण है कि सेवा फैब्रिक में बहुत मजबूत, प्रथम श्रेणी के रोलिंग अपग्रेड हैं। –
मैं यह भी तर्क दूंगा कि एक रोलिंग अपग्रेड एक अर्थ में "ट्रिकलिंग" है क्योंकि आपका पूरा एप्लिकेशन एक ही समय में अपग्रेड नहीं किया गया है। यह एक समय में एक टुकड़ा अपग्रेड कर रहा है, और यदि किसी भी समय एक स्वास्थ्य जांच विफल हो जाती है (आप कस्टम स्वास्थ्य जांच कर सकते हैं), तो यह वापस रोल करेगा। तो आप इसे एक स्वचालित चाल के माध्यम से तैनाती के रूप में सोच सकते हैं, और हम हमें कुछ स्वचालन पसंद करते हैं! –