ब्लू-ग्रीन डिप्लॉयमेंट: शून्य डाउनटाइम के लिए DevOps रणनीति

जब मैंने पहली बार एक MLOps इंजीनियर के रूप में काम शुरू किया, तो मुझे एक छोटा एप्लिकेशन रोल आउट करना था जिसमें एक ML मॉडल शामिल था, जो इमेज क्लासिफिकेशन के लिए इस्तेमाल होता था। शुरुआती रोलआउट ठीक रहा। लेकिन जैसे ही मैंने मॉडल अपडेट किया, अफरा-तफरी मच गई। सबसे पहले, मेरा नया मॉडल होस्ट करने वाला Pod शुरू ही नहीं हुआ, क्योंकि मेरे टेस्ट एनवायरनमेंट और प्रोडक्शन एनवायरनमेंट के बीच कुछ अंतर थे। इसके अलावा, ग्राहक काम नहीं कर पा रहे थे क्योंकि पुराने मॉडल वाला Pod पहले ही मेरे नए, न चलने वाले Pod से बदल दिया गया था। यह एक बुरे सपने जैसा था। फिर मुझे मैन्युअल रूप से रोलबैक करना पड़ा और उस मॉडल के उपयोगकर्ताओं से माफी मांगनी पड़ी। 

हालाँकि, मैंने सबक सीखे और ब्लू-ग्रीन डिप्लॉयमेंट रणनीति का उपयोग करना शुरू किया। यह DevOps तरीका बिना डाउनटाइम या देर रात के रोलबैक के, नए अपडेट को सहजता से शिप करने में सक्षम बनाता है। 

इस गाइड में, मैं आपको बताऊँगा कि व्यवहार में ब्लू-ग्रीन डिप्लॉयमेंट कैसा दिखता है—इसे कैसे सेट करें, इसके ट्रेड-ऑफ क्या हैं, और वे सीखें जो आपको केवल डॉक्यूमेंटेशन से नहीं मिलेंगी। चाहे आप ML सेवाएँ, APIs, या फुल-स्टैक एप्लिकेशन बना रहे हों, यह तरीका आपकी टीम को वह सुरक्षा जाल देता है जिसकी जरूरत नई फीचर्स को आत्मविश्वास के साथ रोल आउट करने के लिए होती है।

ब्लू-ग्रीन डिप्लॉयमेंट को समझना

ब्लू-ग्रीन डिप्लॉयमेंट सुनने में जितना जटिल लगता है, उतना है नहीं (कम से कम मुझे तो पहली बार सुनकर कठिन लगा था)। 

यह उपयोगकर्ताओं को बाधित किए बिना नए वर्शन जारी करने की एक चतुर तरकीब है। यह ऐसा दो समान प्रोडक्शन एनवायरनमेंट बनाए रखकर और उनके बीच ट्रैफिक स्विच करके करता है। 

यदि आपने कभी यह समस्या देखी है कि आपका एप्लिकेशन स्टेजिंग में काम कर रहा था लेकिन प्रोडक्शन में क्रैश हो गया, तो यह रणनीति आपके लिए सही है!

कोर आर्किटेक्चर और ऑपरेशनल मैकेनिक्स

मूल विचार: आप दो समान प्रोडक्शन एनवायरनमेंट बनाए रखते हैं। एक को ब्लू कहा जाता है और दूसरे को ग्रीन।

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

इस रणनीति से कोई डाउनटाइम नहीं होता, कोई “सॉरी, हम अपडेट कर रहे हैं” नहीं। बस पर्दे के पीछे एक अदृश्य ट्रांज़िशन, जिसे उपयोगकर्ता महसूस भी नहीं करते।

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

यह रणनीति “लेकिन यह स्टेजिंग पर काम कर रहा था” वाले पल का समाधान करती है, जिसका सामना मैंने अपने नए ML मॉडल के साथ किया था। क्योंकि ग्रीन भी एक प्रोडक्शन एनवायरनमेंट है, आप वास्तविक दुनिया में ही परीक्षण करते हैं—उपयोगकर्ताओं तक पहुँचने से पहले।

यहाँ सामान्य फ्लो का एक त्वरित अवलोकन है: 

1. नए वर्शन को ग्रीन में डिप्लॉय करें।
2. इंटीग्रेशन और स्मोक टेस्ट चलाएँ।
3. लोड बैलेंसर का उपयोग करके ट्रैफिक स्विच करें। 
4. ग्रीन को किसी भी असामान्यता के लिए मॉनिटर करें।
5. यदि सब कुछ ठीक काम कर रहा है, तो ब्लू को डिग्रेड करें या रोलबैक के लिए संभाल कर रखें।

ब्लू-ग्रीन डिप्लॉयमेंट फेज़ 1: परीक्षण के लिए ग्रीन में नया एप्लिकेशन, ट्रैफिक अभी भी ब्लू की ओर रूटेड (छवि: लेखक)।

ब्लू-ग्रीन डिप्लॉयमेंट फेज़ 2: ट्रैफिक ग्रीन एनवायरनमेंट की ओर रीरूट (छवि: लेखक)। 

ऐतिहासिक विकास और उद्योग में अपनाना

ब्लू‑ग्रीन तरीका लगभग 2005 में ThoughtWorks के भीतर Daniel Terhorst‑North और Jez Humble द्वारा नामित और उपयोग किया गया था। बाद में इसे 2010 की किताब Continuous Delivery (Jez Humble और Dave Farley) में दस्तावेजीकृत और लोकप्रिय बनाया गया।

तब से, इसे स्टार्टअप्स से लेकर आज के क्लाउड-नेटिव दिग्गजों तक, जैसे Netflix और वे सभी जो बिना किसी हंगामे के दिन में कई बार डिप्लॉय करते हैं, हर जगह अपनाया गया है।

क्लाउड प्लेटफ़ॉर्म्स ने इस बदलाव को तेज़ किया। Infrastructure-as-code, ऑटो-स्केलिंग ग्रुप्स, और Kubernetes जैसे कंटेनर ऑर्केस्ट्रेशन टूल्स के साथ, डुप्लीकेट एनवायरनमेंट्स को स्पिन-अप और मेंटेन करना आसान हो गया।

ब्लू-ग्रीन डिप्लॉयमेंट ने अन्य डिप्लॉयमेंट मॉडल्स को भी प्रेरित किया, जैसे कैनरी रिलीज़ और फीचर फ्लैग्स। यदि आप ब्लू-ग्रीन समझते हैं, तो आप दूसरों की बुनियाद भी समझ लेते हैं।

DevOps में नए हैं? DevOps Concepts कोर्स से शुरुआत करें। एक स्पष्ट, व्यावहारिक आधार जो उन्नत वर्कफ़्लोज़ में जाने से पहले मुख्य रणनीतियों को समझने में मदद करता है।

ब्लू-ग्रीन डिप्लॉयमेंट के प्रमुख लाभ

सच कहूँ तो, जब मैंने पहली बार ब्लू-ग्रीन डिप्लॉयमेंट के बारे में सुना, तो मुझे दो प्रोडक्शन एनवायरनमेंट बनाए रखना बिल्कुल तर्कसंगत नहीं लगा। लेकिन जब मैंने देखा कि नए ML मॉडल्स रोल आउट करना कितना आसान हो गया और उपयोगकर्ताओं से मिलने वाली शिकायतें व एस्केलेशन कितने कम हो गए, तब समझ आया कि यह मेहनत वाकई सार्थक है।

आगे के अध्यायों में, मैं ब्लू-ग्रीन डिप्लॉयमेंट के लाभों पर प्रकाश डालूँगा।

लगभग-शून्य डाउनटाइम

यह सबसे स्पष्ट लाभ है, क्योंकि कोई भी डाउनटाइम नहीं चाहता।

ब्लू-ग्रीन के साथ, आप पुराने से नए एनवायरनमेंट पर ट्रैफिक को तुरंत स्विच कर सकते हैं, सेवा में गिरावट का इंतज़ार किए बिना। आपके उपयोगकर्ता स्विच को नोटिस ही नहीं करते—और यही होना चाहिए।

जब आप यूज़र-फेसिंग APIs, डैशबोर्ड्स, या ऐसे ML पाइपलाइंस चला रहे हों जो कुछ मिनट का व्यवधान भी बर्दाश्त नहीं कर सकते, तब यह गेम-चेंजर होता है।

आसान रोलबैक

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

यह सुरक्षा स्तर टीमों को बार-बार शिप करने का आत्मविश्वास देता है। “कभी चल रहे सिस्टम को मत छेड़ो” जैसी बातें खत्म।

प्रोडक्शन में सुरक्षित परीक्षण

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

पारंपरिक स्टेजिंग एनवायरनमेंट्स के विपरीत, आप वही इंफ्रास्ट्रक्चर, वही कॉन्फ़िग और बाकी सब पर टेस्ट चलाते हैं।

इससे टेस्ट वास्तविकता को कहीं अधिक सटीक रूप से प्रतिबिंबित करते हैं।

A/B टेस्टिंग और चरणबद्ध रोलआउट का समर्थन

एक बार जब आपके दो समान प्रोडक्शन एनवायरनमेंट चल रहे हों, तो आप उनसे और भी कुछ कर सकते हैं। आप 90% ट्रैफिक को ब्लू वर्शन और 10% को ग्रीन वर्शन की ओर रूट कर सकते हैं। 

आप फीचर फ्लैग्स भी इंटीग्रेट कर सकते हैं ताकि यह नियंत्रित किया जा सके कि कौन-सी सुविधाएँ कब लाइव हों—जहाँ ब्लू-ग्रीन डिप्लॉयमेंट एक ठोस अंतर्निहित डिप्लॉयमेंट नींव के रूप में अच्छा समर्थन देता है। 

यदि आप प्रोग्रेसिव डिलीवरी में गहराई से जाना चाहते हैं, तो देखें CI/CD in Data Engineering। यह बताता है कि A/B टेस्टिंग और धीरे-धीरे रोलआउट का समर्थन करने वाली पाइपलाइंस कैसे सेट करें।

बेहतर उपयोगकर्ता अनुभव और बिज़नेस निरंतरता

ब्लू-ग्रीन डिप्लॉयमेंट मदद करता है:

• उपयोगकर्ताओं तक कम त्रुटियाँ पहुँचना।
• समस्या आने पर इंजीनियरिंग से तेज़ प्रतिक्रिया समय।
• बैकअप बहाली को सरल बनाना

यदि आप महत्वपूर्ण मशीन लर्निंग सेवाएँ या आंतरिक डेटा टूल्स डिप्लॉय कर रहे हैं जिन पर लोग रोज़ निर्भर हैं, तो यह बहुत मायने रखता है।

ब्लू-ग्रीन डिप्लॉयमेंट की योजना बनाना

ब्लू-ग्रीन डिप्लॉयमेंट लागू करने से पहले, इसे गहराई से समझना ज़रूरी है।

आइए समझते हैं कि आर्किटेक्चर, लागत संबंधी विचार और आंतरिक तैयारी के लिहाज से आपको क्या चाहिए होगा।

इन्फ्रास्ट्रक्चर आवश्यकताएँ

आपको दो समान प्रोडक्शन एनवायरनमेंट चाहिए। इसका मतलब सेटअप दोगुना और मेंटेनेंस दोगुना।

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

दोनों एनवायरनमेंट्स सेट करने में ये चीजें मदद कर सकती हैं:

• Infrastructure-as-Code (जैसे, Terraform) ताकि एनवायरनमेंट्स को जल्दी रिप्लिकेट किया जा सके।
• कन्फ़िगरेशन मैनेजमेंट ताकि कन्फ़िगरेशन ड्रिफ्ट से होने वाली समस्याओं को रोका जा सके।
• Kubernetes में, ब्लू और ग्रीन के लिए अलग namespaces या डिप्लॉयमेंट ऑब्जेक्ट्स का उपयोग करें।

यह भी ध्यान रखें कि ऑन-प्रेम सेटअप में चीजें ज़्यादा जटिल हो जाती हैं, क्योंकि आपको यह सुनिश्चित करना होगा:

• लोड बैलेंसर्स इतने कॉन्फ़िगरेबल हों कि तुरंत ट्रैफिक स्विच कर सकें।
• आप तेज़ी से एनवायरनमेंट्स प्रोविजन कर सकें (शायद वर्चुअलाइजेशन या कंटेनर्स के जरिए)।
• बाहरी डिपेंडेंसी (जैसे, डेटाबेसेज़, APIs) सिंक और आइसोलेटेड हों।

आप अपने प्लेटफ़ॉर्म के लिए क्या आसान है, यह तय करने हेतु AWS, Azure और GCP सर्विस तुलना का संदर्भ ले सकते हैं।

लागत-लाभ विश्लेषण

संशयवादी हमेशा दो प्रोडक्शन एनवायरनमेंट बनाए रखने की बढ़ी हुई लागत पर जोर देते हैं। हाँ, दो एनवायरनमेंट चलाना मुफ़्त नहीं है। हालाँकि, दूसरे एनवायरनमेंट की बढ़ी हुई लागत और आपके व्यवसाय के लिए डाउनटाइम की लागत के बीच एक ट्रेडऑफ़ होता है। 

अपने आप से पूछें:

• फेल्ड डिप्लॉयमेंट का औसत प्रभाव (समय या डॉलर में) क्या है?
• डीबग, रोलबैक और आउटेज समझाने में कितने घंटे लगते हैं?
• आप कितनी बार दबाव में शिप करते हैं, यह उम्मीद करते हुए कि यह टूटेगा नहीं?

यही ब्लू-ग्रीन का बड़ा सेलिंग पॉइंट है: कम आउटेज, तेज़ इटरेशन, और कम इंजीनियरिंग दबाव और बर्नआउट। 

लागत अनुकूलन के सुझाव:

• ऑटो-स्केलिंग का उपयोग करके ग्रीन एनवायरनमेंट का साइज टेस्ट लोड के अनुसार रखें।
• ग्रीन एनवायरनमेंट के लिए स्पॉट इंस्टैंसेज़ या इफेमरल VMs अपनाएँ।
• ग्रीन वर्शन को अलग Kubernetes namespace में चलाएँ और कटओवर के बाद इसे ज़ीरो तक स्केल करें।

अच्छी तरह कॉन्फ़िगर की गई CI/CD पाइपलाइन यह स्केलिंग अपने आप भी संभाल सकती है।

पूर्वापेक्षाएँ और संगठनात्मक तैयारी

यह हिस्सा अक्सर नज़रअंदाज़ हो जाता है, लेकिन काफी ज़रूरी है।

भले ही आपके पास इन्फ्रास्ट्रक्चर और टूल्स के लिए बजट हो, जब तक आपकी टीम की संस्कृति और सिस्टम तैयार नहीं हैं, ब्लू-ग्रीन डिप्लॉयमेंट काम नहीं करेगा।

आपको इनकी ज़रूरत होगी: 

• CI/CD वर्कफ़्लोज़: ऐसी पाइपलाइंस जो स्वतंत्र रूप से ग्रीन में डिप्लॉय और टेस्ट कर सकें।
• मॉनिटरिंग और ऑब्ज़र्वेबिलिटी: ब्लू से ग्रीन पर ट्रैफिक स्विच करने से पहले मैट्रिक्स जाँचें।
• स्पष्ट रोलबैक रणनीति: आदर्श रूप से स्वचालित, और अभ्यासित।
• क्रॉस-फ़ंक्शनल अलाइनमेंट: डेवलपमेंट, ऑपरेशंस, QA और प्रोडक्ट टीम—सभी को प्रक्रिया समझनी चाहिए।

यदि आप निश्चित नहीं हैं कि आपकी टीम कहाँ खड़ी है, तो देखें CI/CD for Machine Learning। यह बताता है कि परिपक्व डिप्लॉयमेंट सेटअप कैसा दिखता है और उसे कैसे हासिल किया जाए।

तकनीकी कार्यान्वयन

अब तक हमने कवर किया कि आपको ब्लू-ग्रीन डिप्लॉयमेंट का उपयोग क्यों करना चाहिए। इस सेक्शन में, मैं बताऊँगा कि इसे लागू कैसे करें। 

मैं एक सामान्य ब्लू-ग्रीन डिप्लॉयमेंट लाइफ़साइकल को तोड़कर बताऊँगा, खासकर डेटाबेस हैंडलिंग जैसे चुनौतीपूर्ण पहलू पर फोकस करते हुए।

आप सीखेंगे क्या ऑटोमेट करना है, क्या मॉनिटर करना है, और क्या छोड़ना नहीं है।

मानक डिप्लॉयमेंट लाइफ़साइकल

अच्छी तरह से लागू ब्लू-ग्रीन डिप्लॉयमेंट एक सटीक क्रम का पालन करता है। व्यवहार में यह आमतौर पर ऐसा दिखता है:

1. ग्रीन एनवायरनमेंट प्रोविजन करें: ऐसा प्रोडक्शन-ग्रेड एनवायरनमेंट स्पिन-अप करें जो आपके मौजूदा (ब्लू) एनवायरनमेंट का प्रतिरूप हो—क्लाउड, ऑन-प्रेम या Kubernetes पर।
2. नए वर्शन को ग्रीन में डिप्लॉय करें: आपकी CI/CD पाइपलाइन को यहाँ कोड बिल्ड और डिप्लॉय करना चाहिए, आदर्श रूप से इसे करंट रिलीज़ कैंडिडेट के रूप में टैग करते हुए।
3. स्वचालित टेस्ट चलाएँ: इसमें स्मोक टेस्ट, इंटीग्रेशन चेक्स और ऐसे हेल्थ प्रॉब्स शामिल हैं जो यूज़र व्यवहार का सिमुलेशन करते हैं। आप जाँचते हैं कि ग्रीन आपके उपयोगकर्ताओं के लिए तैयार है या नहीं।
4. लॉग्स और मैट्रिक्स मॉनिटर करें: यदि आपके डैशबोर्ड क्लीन दिखते हैं और कोई अलर्ट नहीं है, तो आप आगे बढ़ सकते हैं। वरना, समस्याएँ ठीक करें और ग्रीन पर फिर से डिप्लॉय करें।
5. ट्रैफिक को ग्रीन पर स्विच करें: अपने लोड बैलेंसर को पुन:कॉन्फ़िगर करें ताकि सारा ट्रैफिक ग्रीन सर्वर पर रूट हो।
6. ब्लू को निष्क्रिय करें: जब आपको ग्रीन पर भरोसा हो जाए, तो ब्लू को स्पिन-डाउन करें, या अगली रिलीज़ तक बैकअप के रूप में रखें।

रोलबैक स्टेप को रोलआउट जितना तेज़ बनाइए, ताकि कोई टीम सदस्य एक मिनट से कम में डिप्लॉयमेंट रिवर्स कर सके।

CI/CD in Data Engineering गाइड इन स्वचालित चरणों को सेट करने के लिए उत्कृष्ट संसाधन है।

डेटाबेस सिंक्रोनाइज़ेशन रणनीतियाँ

यह हिस्सा पेचीदा है। आपका ऐप stateless हो सकता है, लेकिन आपका डेटाबेस नहीं। 

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

तो इसे ऐसे संभालें:

1. बैकवर्ड-कम्पैटिबिलिटी के लिए डिज़ाइन करें: स्विचओवर के दौरान, कुछ मिलीसेकंड के लिए यूज़र अभी भी ब्लू एनवायरनमेंट को हिट कर सकते हैं। उस अवधि में आपकी स्कीमा दोनों ऐप वर्शन्स के लिए काम करनी चाहिए। 
1. फ़ील्ड्स को तुरंत ड्रॉप या रीनेम न करें।
2. नई कॉलम/टेबल जोड़ें, डिफ़ॉल्ट वैल्यूज़ का उपयोग करें।
3. हार्ड कंस्ट्रेंट्स से बचें जब तक कि दोनों वर्शन बदलाव का समर्थन न करें।
2. अपनी माइग्रेशंस को वर्शन करें: Java-आधारित सिस्टम्स के लिए Flyway या Liquibase, या Python + SQLAlchemy के लिए Alembic जैसे टूल्स का उपयोग करें। 
3. सेशन स्टेट हैंडल करें: यदि आपका ऐप इन-मेमोरी सेशन स्टोरेज का उपयोग करता है, तो एनवायरनमेंट स्विच करने से यूज़र लॉगआउट हो सकते हैं या फ़ंक्शनैलिटी टूट सकती है। इससे बचने के लिए Redis, Memcached या साझा DB का उपयोग करें।
4. स्विच के बाद डेटा कंसिस्टेंसी वैलिडेट करें: कंसिस्टेंसी सुनिश्चित करने के लिए महत्वपूर्ण डेटा पर स्वचालित चेक्स चलाएँ।
1. क्या उपयोगकर्ता लॉगिन कर सकते हैं? 
2. क्या हाल के बदलाव सेव हो रहे हैं? 
3. क्या एनालिटिक्स पाइपलाइन अभी भी सही तरीके से इनजेस्ट कर रही है?
5. धीमे ड्रिफ्ट्स मॉनिटर करें: कभी-कभी बदलाव एरर नहीं देते और काम करते हुए दिखते हैं, लेकिन वे सूक्ष्म समस्याएँ पैदा कर सकते हैं—जैसे इवेंट प्रोसेसिंग में देरी या खराब रिकॉर्ड्स। ऐसी समस्याओं को जल्द पकड़ने के लिए लॉगिंग और ऑब्ज़र्वेबिलिटी का उपयोग करें।

यदि आप जानना चाहते हैं कि प्रोडक्शन-ग्रेड स्तर पर MLOps का उपयोग कैसे करें, तो मैं कोर्स की सिफारिश करता हूँ MLOps Deployment and Life Cycling।

अन्य डिप्लॉयमेंट रणनीतियों के साथ तुलनात्मक विश्लेषण

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

आपकी आर्किटेक्चर, रिलीज़ आवृत्ति और जटिलता की इच्छा के आधार पर, विकल्पों पर विचार करें या कुछ तरीकों को मिलाकर एक नया दृष्टिकोण बनाएं।

आइए सबसे आम परिदृश्य की तुलना करें: ब्लू-ग्रीन बनाम कैनरी डिप्लॉयमेंट्स।

ब्लू-ग्रीन बनाम कैनरी डिप्लॉयमेंट्स

इन रणनीतियों को अक्सर मिलाया जाता है, लेकिन इनके लक्ष्य अलग हैं।

ब्लू-ग्रीन एक पूर्ण स्विच रिलीज़ मॉडल है। आप ग्रीन में डिप्लॉय करते हैं, टेस्ट करते हैं, और तैयार होने पर 100% ट्रैफिक स्विच कर देते हैं।

वहीं, कैनरी एक क्रमिक स्विच है। आप पुराने वर्शन के साथ नया वर्शन भी डिप्लॉय करते हैं और संभावित समस्याओं की निगरानी करते हुए धीरे-धीरे छोटे प्रतिशत ट्रैफिक (जैसे 1%, फिर 10%, फिर 50%) को शिफ्ट करते हैं।

दोनों रणनीतियों के बीच मुख्य अंतर:

मैंने व्यक्तिगत रूप से नए ML मॉडल्स को प्रोडक्शन में डिप्लॉय करने के लिए ब्लू-ग्रीन का उपयोग किया है, लेकिन यूज़र बेस सीमित था। यदि मेरे मॉडल्स बड़े यूज़र बेस को एक्सपोज़ होते, तो मैं संभवतः कैनरी रिलीज़ को प्राथमिकता देता।

इन्फ्रास्ट्रक्चर और ऑपरेशनल ट्रेडऑफ़्स

दोनों रणनीतियों को अच्छे टूलिंग की ज़रूरत होती है, लेकिन जटिलताएँ अलग क्षेत्रों में होती हैं।

ब्लू-ग्रीन को समान एनवायरनमेंट्स चाहिए, जो इन्फ्रास्ट्रक्चर लागत बढ़ाता है। हालाँकि, रूटिंग काफी सरल है—सिर्फ एक एनवायरनमेंट से दूसरे पर ट्रैफिक स्विच करना। 

दूसरी ओर, कैनरी इन्फ्रास्ट्रक्चर लागत के लिहाज से हल्का है, लेकिन ट्रैफिक को धीरे-धीरे स्विच करने के लिए अधिक लॉजिक चाहिए। समस्याओं को जल्द पकड़ने के लिए अधिक विस्तृत ऑब्ज़र्वेबिलिटी की भी आवश्यकता होती है।

अन्य कारक जिन पर विचार करना चाहिए: 

• मॉनिटरिंग: कैनरी को ग्रैन्युलर मैट्रिक्स चाहिए (जैसे प्रति-यूज़र या प्रति-रिक्वेस्ट लेटेंसी), जबकि ब्लू-ग्रीन को बस यह जानना होता है कि ऐप स्वस्थ है। 
• ऑटोमेशन टूल्स: Argo Rollouts जैसे टूल्स Kubernetes में दोनों मॉडलों का समर्थन करते हैं, लेकिन कैनरी के लिए अधिक सेटअप चाहिए।
• डिप्लॉयमेंट समय: ब्लू-ग्रीन तेज़ है। कैनरी सावधान और समय लेने वाला।

तो, आपके लिए क्या सही है?

यदि आपकी टीम अभी CI/CD परिपक्वता बढ़ा रही है, तो ब्लू-ग्रीन आत्मविश्वास बनाने का सर्वोत्तम तरीका हो सकता है। ब्लू-ग्रीन एक अच्छा शुरुआती बिंदु भी है, जो आपको अनुभव जुटाने देता है। 

लेकिन यदि आपका यूज़र बेस बड़ा है या आप ऐसे बदलाव डिप्लॉय करते हैं जिनमें महत्वपूर्ण जोखिम है (जैसे प्राइसिंग लॉजिक), तो कैनरी उपयुक्त हो सकता है।

Azure-केंद्रित टीमों के लिए, Azure DevOps ट्यूटोरियल दिखाता है कि Azure पर अच्छा CI/CD कैसे लागू करें।

प्लेटफ़ॉर्म-विशिष्ट इंप्लीमेंटेशन

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

हर एक कुछ अलग सुविधाएँ देता है, पर मूल विचार वही रहता है। आपको दो समान एनवायरनमेंट्स चाहिए और एक ट्रैफिक स्विच।

Kubernetes ऑर्केस्ट्रेशन पैटर्न्स

Kubernetes के साथ ब्लू-ग्रीन डिप्लॉयमेंट लागू करना सीधा है, क्योंकि ज़रूरी टूल्स पहले से Kubernetes में बने हुए हैं। 

इसे सेट करने के कुछ तरीके हैं:

• अलग डिप्लॉयमेंट्स: my-app-blue और my-app-green को दो अलग डिप्लॉयमेंट्स के रूप में डिप्लॉय करें, जो लेबल्स और सर्विसेज़ साझा करें।
• एकल डिप्लॉयमेंट ऑब्जेक्ट विद रिवीज़न: कम सामान्य, लेकिन वर्शन्स को ट्रैक करने के लिए annotations का उपयोग करें तो संभव है।
• नेमस्पेसेज़: ब्लू और ग्रीन को पूर्ण आइसोलेशन के लिए अलग namespaces में चलाएँ।

यहाँ मुख्य घटक Kubernetes Service है। यह एक लोड बैलेंसर की तरह काम करता है, जो लेबल सेलेक्टर्स के जरिए ब्लू या ग्रीन पॉड्स को ट्रैफिक निर्देशित करता है।

मान लीजिए आपके पास है:

selector:  version: blue

ग्रीन वर्शन वैलिडेट करने के बाद, आप सर्विस सेलेक्टर को version: green में अपडेट करें और ट्रैफिक तुरंत रीरूट हो जाता है।

मैं readinessProbes का उपयोग करने की सलाह देता हूँ, ताकि किसी भी ट्रैफिक को रूट करने से पहले नया वर्शन पूरी तरह तैयार हो।

इस प्रक्रिया को Argo Rollouts और Flagger जैसे टूल्स का उपयोग करके स्वचालित किया जा सकता है, क्योंकि ये संभालते हैं:

• प्रोग्रेसिव ट्रैफिक शिफ्टिंग
• हेल्थ चेक्स और मॉनिटरिंग
• क्रैश होने पर स्वचालित रोलबैक

क्या आप ML-केंद्रित इन्फ्रा में गहराई तक जाना चाहते हैं? देखें Fully Automated MLOps।

क्लाउड-नेटिव मैनेज्ड सर्विसेज़

यदि आप AWS, Azure या GCP पर हैं, तो अच्छी खबर यह है कि ब्लू-ग्रीन डिप्लॉयमेंट पहले से निर्मित है—आपको बस इसे सक्षम करना है।

AWS CodeDeploy (Elastic Beanstalk या EC2 के साथ):

• समर्पित ब्लू-ग्रीन डिप्लॉयमेंट रणनीति प्रदान करता है
• आप तय करते हैं कि कौन-सा एनवायरनमेंट ग्रीन है, और CodeDeploy ट्रैफिक शिफ्टिंग और रोलबैक संभालता है

Azure Container Apps या Azure App Service:

• Azure आपको वर्शन्स को “slots” के रूप में स्टेज करने और उन्हें शून्य डाउनटाइम के साथ स्वैप करने देता है
• पूरी CI/CD ऑटोमेशन के लिए इसे Azure DevOps पाइपलाइंस के साथ मिलाएँ

Google Cloud (Cloud Run या GKE):

• Cloud Run रिवीज़न्स के बीच क्रमिक ट्रैफिक स्प्लिटिंग का समर्थन करता है, जो परीक्षण और रोलआउट के लिए बेहतरीन है
• GKE के साथ, लोड बैलेंसर रूल्स या Istio का उपयोग करके ब्लू-ग्रीन लॉजिक मैनेज करें

प्रत्येक क्लाउड प्रदाता की अपनी सेटअप और सुविधाएँ हैं, लेकिन वे आपका काम आसान बना देते हैं क्योंकि आपको बहुत कुछ खुद से लागू नहीं करना पड़ता। 

मैनेज्ड सर्विसेज़ का उपयोग करने का एक लाभ यह भी है कि आपको स्वयं मेंटेन नहीं करना पड़ता—क्लाउड प्रदाता अपनी सेवाओं को अपडेट करते रहते हैं और आपको सिर्फ उन्हें ठीक से कॉन्फ़िगर करना होता है।

GCP में नए हैं? देखें Cloud Run: GCP में कंटेनराइज़्ड ऐप्स डिप्लॉय करने की गाइड।

Cloud Foundry और अन्य टूल्स के साथ उदाहरण

Cloud Foundry एक ओपन-सोर्स प्लेटफ़ॉर्म-एज़-ए-सर्विस (PaaS) है जो अधिकांश अंतर्निहित इन्फ्रास्ट्रक्चर को अमूर्त कर देता है, जिससे डेवलपर्स कोड पुश करने पर ध्यान केंद्रित कर सकते हैं। यह अपने ऑटोमेशन, अनुपालन सुविधाओं और तेज़ डिप्लॉयमेंट वर्कफ़्लोज़ के कारण बड़े उद्यमों में विशेष रूप से लोकप्रिय है।

यहाँ बताया गया है कि Cloud Foundry में आधिकारिक CLI का उपयोग करके एक सामान्य ब्लू-ग्रीन डिप्लॉयमेंट कैसे काम करता है:

1. ब्लू वर्शन पुश करें अपने ऐप का सबडोमेन demo-time के साथ:

1. cf create-route example.com --hostname my-appcf push my-appcf map-route my-app example.com --hostname my-app

2. ब्लू अब चल रहा है, और राउटर सारा ट्रैफिक my-app.example.com पर भेजता है।
2. ग्रीन वर्शन पुश करें अपने ऐप का नए नाम और रूट के साथ:

1. cf create-route example.com --hostname my-app-tempcf push my-app-greencf map-route my-app-green example.com --hostname my-app-temp

2. एप्लिकेशन की दो इंस्टैंसेज़ अब चल रही हैं, लेकिन दो रूट्स ऑफ़र करती हैं जहाँ आप ट्रैफिक भेज सकते हैं (my-app.example.com ब्लू के लिए और my-app-temp.example.com ग्रीन के लिए)।
3. प्रोडक्शन रूट को ग्रीन पर मैप करें:

1. bashcf map-route my-app-green example.com -n my-app

2. इस बिंदु पर, पुराना (ब्लू) और नया (ग्रीन) दोनों वर्शन लाइव हैं, लेकिन जब तक आप ब्लू को स्पष्ट रूप से हटाते नहीं, ट्रैफिक दोनों की ओर रूट हो सकता है।
4. ग्रीन वर्शन वेरिफ़ाई करें कि वह सही तरह काम कर रहा है। आप उसके रूट के जरिए टेस्ट कर सकते हैं या स्विच के बाद रीयल ट्रैफिक मॉनिटर कर सकते हैं।
5. ब्लू से रूट अनमैप करें, और पूरी तरह ग्रीन डिप्लॉयमेंट पर स्विच करें:

1. cf unmap-route my-app example.com -n my-app

2. राउटर अब ब्लू की ओर ट्रैफिक नहीं भेजता।
6. पुराने ऐप को डिलीट करें और ग्रीन रूट (वैकल्पिक पर अनुशंसित) को अनमैप करें:

cf delete my-appcf unmap-route my-app-green example.com --hostname my-app-temp

यह प्रक्रिया डाउनटाइम को न्यूनतम करती है और आपको यह पूर्ण नियंत्रण देती है कि आप वर्शन्स को कब और कैसे स्विच करें।

यदि आप इस वर्कफ़्लो को विज़ुअल पाइपलाइंस, मैनुअल अप्रूवल्स या स्वचालित रोलबैक के साथ और बेहतर बनाना चाहते हैं, तो Octopus Deploy, Codefresh या Spinnaker बेहतरीन विकल्प हैं। ये CI/CD पाइपलाइंस के साथ सहजता से इंटीग्रेट होते हैं और टीमों को जटिल डिप्लॉयमेंट लाइफ़साइकल्स को ऑटोमेट करने में सक्षम बनाते हैं।

श्रेष्ठ प्रथाएँ और अनुकूलन रणनीतियाँ

ब्लू-ग्रीन डिप्लॉयमेंट सुनने में शानदार लगता है और बहुत मददगार भी है, लेकिन यदि आप लागत, जोखिम या ऑटोमेशन को सही से प्रबंधित नहीं करते, तो चीजें जल्दी बिखर सकती हैं। मैंने टीमों को अत्यधिक जटिल सेटअप या अप्रत्याशित किनारों के मामलों से जूझते देखा है। 

आइए देखें कि इससे कैसे बचें और अपनी ब्लू-ग्रीन डिप्लॉयमेंट रणनीति को सफल बनाएं।

लागत प्रबंधन तकनीकें

एनवायरनमेंट्स को डुप्लिकेट करना, बेशक, अतिरिक्त लागत लाता है। 

लेकिन आप नीचे दी गई रणनीतियों से इन्हें कम कर सकते हैं:

• ऑटो-स्केलिंग: हॉरिज़ॉन्टल पॉड ऑटोस्केलर्स या क्लाउड-नेटिव ऑटोस्केलिंग का उपयोग करके वास्तविक वर्कलोड से मिलाएँ और व्यर्थ संसाधनों को रोकें।
• स्पॉट इंस्टैंसेज़ और प्रीएम्प्टिबल्स: ग्रीन एनवायरनमेंट के लिए बढ़िया, यदि आप सिर्फ टेस्ट कर रहे हैं (और संभावित इंटरप्शन स्वीकार्य हैं)।
• अस्थायी प्रोविजनिंग: ग्रीन एनवायरनमेंट को ज़रूरत से ज़्यादा समय तक न चलाएँ। अपनी CI/CD पाइपलाइन के जरिए इसे स्पिन-अप करें और बाद में टियर-डाउन कर दें।
• कंटेनराइज़ेशन: ये हल्के, तेज़ और लागत-कुशल हैं, खासकर Kubernetes या Azure Container Apps जैसे प्लेटफ़ॉर्म्स पर।

स्वचालित वैलिडेशन फ्रेमवर्क्स

जब तक आपको पूरी तरह भरोसा न हो कि आपका ग्रीन एप्लिकेशन अपेक्षा के अनुसार काम कर रहा है, तब तक ट्रैफिक स्विच कभी न करें। 

स्विच से पहले भरोसा बनाने के लिए इन टेस्टिंग लेयर्स का उपयोग करें:

• स्मोक टेस्ट्स: क्या प्रमुख एंडपॉइंट्स जीवित और स्वस्थ हैं?
• इंटीग्रेशन टेस्ट्स: क्या प्रमुख वर्कफ़्लोज़ (ऑथ, डेटा एक्सेस, आदि) ग्रीन वर्शन में काम करते हैं?
• एंड-टू-एंड टेस्ट्स: अस्थायी ग्रीन रूट के खिलाफ वास्तविक यूज़र व्यवहार का सिमुलेशन करें (खासकर Cloud Foundry और Azure में उपयोगी)।

इन्हें अपनी CI/CD पाइपलाइन में इंटीग्रेट करें ताकि सफल डिप्लॉयमेंट के बाद ये स्वतः चलें।

क्या इन फ्लोज़ को बनाने पर रिफ्रेशर चाहिए? CI/CD for Machine Learning बताता है कि स्वचालित वैलिडेशंस को अपने डिप्लॉयमेंट लाइफ़साइकल में कैसे संरचित करें।

डेटाबेस माइग्रेशन कार्यप्रणालियाँ

यह एक पेचीदा हिस्सा है, क्योंकि आपका ऐप दो एनवायरनमेंट्स में चल सकता है, पर आपका डेटाबेस आम तौर पर दोनों के लिए अंततः वही रहता है। 

यहाँ सुरक्षित रूप से ट्रांज़िशन कैसे करें:

• बैकवर्ड-कम्पैटिबल स्कीमा बदलाव: हमेशा मानकर चलें कि ग्रीन लाइव होने पर भी ब्लू वर्शन डेटाबेस का उपयोग कर सकता है।
• फ़ीचर टॉगल्स: स्कीमा-निर्भर फ़ीचर्स केवल तब रोल आउट करें जब नया स्कीमा डिप्लॉय हो चुका हो।
• वर्शनड माइग्रेशंस: Flyway, Alembic या Liquibase जैसे टूल्स का उपयोग करें ताकि बदलाव ट्रैकेबल और रिवर्सिबल रहें।
• सेशन/डेटा कंसिस्टेंसी: यदि आप सेशन स्टेट पर निर्भर हैं, तो ऐसे एक्सटर्नल स्टोर्स (जैसे Redis) का उपयोग करें जिन्हें दोनों एनवायरनमेंट्स साझा कर सकें।

फ़ीचर फ्लैग्स और प्रोग्रेसिव डिलीवरी

ब्लू-ग्रीन को फीचर फ्लैग्स के साथ मिलाकर उपयोग करने से और भी अधिक लचीलापन मिलता है।

फ़्लैग्स के साथ, आप:

• ग्रीन एनवायरनमेंट के भीतर उपयोगकर्ताओं के एक सबसेट को नई सुविधाएँ रोल आउट कर सकते हैं
• फ़ीचर्स डिप्लॉय कर सकते हैं लेकिन उन्हें छिपाकर रख सकते हैं
• पूरे फीचर सेट को एक्सपोज़ किए बिना एज केसेज़ या प्रदर्शन प्रभावों का सुरक्षित परीक्षण कर सकते हैं

LaunchDarkly, ConfigCat, या Unleash जैसे टूल्स का उपयोग करें ताकि बिना कोड बदलाव के प्रबंधन सरल हो।

मजबूत मॉनिटरिंग और ऑब्ज़र्वेबिलिटी

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

आपके पास यह होना चाहिए: 

• हेल्थ चेक्स: Kubernetes readinessProbes, Azure रिवीज़न URLs, आदि।
• लॉगिंग: केंद्रीयकृत, सर्चेबल, और एनवायरनमेंट (ब्लू बनाम ग्रीन) के टैग्स के साथ।
• अलर्टिंग: थ्रेशहोल्ड सेट करें और एरर रेट बढ़ने पर नोटिफिकेशन पाएँ।
• ट्रैफिक विश्लेषण: ब्लू और ग्रीन के बीच व्यवहार की तुलना करें (जैसे, लेटेंसी, एरर रेट, थ्रूपुट)।

हालाँकि, मजबूत मॉनिटरिंग और ऑब्ज़र्वेबिलिटी आपकी इन्फ्रास्ट्रक्चर का हिस्सा वैसे भी होना चाहिए—चाहे आप ब्लू-ग्रीन डिप्लॉयमेंट करें या नहीं।

रोलबैक और डिज़ास्टर रिकवरी की योजना

कभी-कभी चीज़ें गलत होंगी ही। लक्ष्य यह है कि विफलता से उबरना जितना आसान और तेज़ हो सके उतना करें। 

ऐसा कैसे करें:

• तुरंत रोलबैक: हमेशा ब्लू एनवायरनमेंट को तब तक चालू रखें जब तक आप सुनिश्चित न हों कि ग्रीन स्थिर है।
• स्वचालित रोलबैक ट्रिगर्स: Argo Rollouts या Spinnaker जैसे टूल्स का उपयोग करें ताकि प्रमुख मैट्रिक्स फेल होने पर ट्रैफिक रिवर्ट हो जाए।
• रनबुक्स और प्लेबुक्स: टीम के लिए पूर्वलिखित स्टेप्स ताकि सभी को पता हो कि क्या करना है।

और अधिक व्यावहारिक DevOps ऑटोमेशन टिप्स के लिए देखें Azure DevOps ट्यूटोरियल।

सुरक्षा सुदृढ़ीकरण

दो एनवायरनमेंट होने का मतलब दो संभावित अटैक पॉइंट्स भी हैं।

उचित सुरक्षा के लिए कुछ सुझाव:

• एनवायरनमेंट्स को आइसोलेट करें: अलग सबनेट्स, namespaces, या क्लाउड रिसोर्स ग्रुप्स का प्रयोग करें।
• सीक्रेट्स अक्सर रोटेट करें: खासकर जब ब्लू और ग्रीन के बीच साझा क्रेडेंशियल्स का उपयोग हो।
• दोनों एनवायरनमेंट्स को पैच करें: केवल इसलिए ग्रीन को सिक्योरिटी अपडेट्स में पीछे न रहने दें कि वह अभी लाइव नहीं है।
• ऑडिट लॉग्स: ट्रेसएबिलिटी के लिए डिप्लॉयमेंट इवेंट्स और एनवायरनमेंट स्विचेज़ कैप्चर करें।

निष्कर्ष

ब्लू-ग्रीन डिप्लॉयमेंट कोई ऐसी फैंसी रणनीति नहीं है जिसे सिर्फ़ ज़रूरत से ज़्यादा इंजीनियर की गई प्रक्रियाएँ अपनाती हों। यह उन टीमों के लिए व्यावहारिक और भरोसेमंद रणनीति है जो अपटाइम, तेज़ फीडबैक और सुकूनभरी नींद को प्राथमिकता देती हैं।

यह आपको देता है:

• चीजें गलत होने पर तुरंत रोलबैक
• वास्तविक उपयोगकर्ता जोखिम के बिना प्रोडक्शन-ग्रेड परीक्षण
• क्लीनर, अधिक आत्मविश्वासी रिलीज़, यहाँ तक कि शुक्रवार को भी (मज़ाक नहीं)

लेकिन क्या यह हर स्थिति के लिए परफेक्ट है? मैं कहूँगा नहीं। आपको एक ठोस CI/CD सेटअप चाहिए, ऐसे टूल्स के साथ जो इस यात्रा का समर्थन करें। नहीं तो चीजें जल्दी गड़बड़ा सकती हैं।

लेकिन यह इसे टालने का कारण नहीं है। बल्कि यह संकेत है कि आपको अपनी डिप्लॉयमेंट प्रैक्टिसेज़ में सुधार करना चाहिए।

हमने ब्लू-ग्रीन डिप्लॉयमेंट्स अपनाकर अपने रिलीज़ फ्लो में जबरदस्त सुधार किया है और उसके बाद से रिलीज़ के दिन काफी आरामदायक रहे हैं—यहाँ तक कि शुक्रवार को भी हम आत्मविश्वास के साथ रिलीज़ करते रहे।

यदि आप और गहराई में जाना चाहते हैं, तो DevOps Concepts या MLOps Deployment and Life Cycling से शुरुआत करें—ये ब्लू-ग्रीन की नींव बनाने में मदद करेंगे।

अब जाएँ और अपने एप्लिकेशन को आत्मविश्वास के साथ शिप करें।