Table of Contents

ब्लू-ग्रीन तैनाती एक रिलीज प्रबंधन रणनीति है जो दो समान उत्पादन वातावरण चलाने के द्वारा डाउनटाइम और जोखिम को कम करती है - वर्तमान में एक यातायात (नीले) और एक निष्क्रिय (हरी) की सेवा करती है। जब आवेदन का एक नया संस्करण तैयार हो जाता है, तो इसे निष्क्रिय वातावरण में तैनात किया जाता है, पूरी तरह से परीक्षण किया जाता है और फिर यातायात को चालू किया जाता है। यह दृष्टिकोण रखरखाव खिड़कियों की आवश्यकता को समाप्त करता है, तत्काल रोलबैक को सक्षम करता है, और पुराने और नए कोड के बीच एक साफ अलगाव प्रदान करता है। मूल रूप से मार्टिन फाउलर और जेज़ हंबल द्वारा लोकप्रिय, ब्लू-ग्रीन तैनाती आधुनिक देवऑप्स प्रथाओं का एक आधार बन गया है, खासकर जब मजबूत सीआई / सीडी पाइपलाइनों के साथ मिलकर।

क्यों ब्लू-ग्रीन तैनाती के मामले

पारंपरिक तैनाती के तरीके - जैसे रोलिंग अपडेट या कैनरी रिलीज - तब तक उपयोगकर्ताओं को संक्रमण के दौरान आंशिक डाउनटाइम या डिग्रेड्ड प्रदर्शन को उजागर करते हैं। ब्लू-ग्रीन तैनाती पुराने वातावरण को पूरी तरह से चालू रखने के द्वारा इस पते को संबोधित करती है जब तक कि नया सत्यापित नहीं हो जाता है। यह टीमों को अक्सर, यहां तक कि मिशन-क्रिटिकल सिस्टम पर तैनात करने का विश्वास देता है। प्रमुख लाभों में शामिल हैं:

  • ]Zero-downtime तैनाती: आवेदन के अनुपलब्ध होने पर समय की कोई खिड़की नहीं।
  • ]Instant रोलबैक: यदि मुद्दों पैदा होती है तो पुराने वातावरण में यातायात को फिर से चालू करें।
  • ]उत्पादन में पृथक परीक्षण: उपयोगकर्ताओं को प्रभावित किए बिना वास्तविक दुनिया की स्थिति के तहत नए संस्करण को मान्य करें।
  • ]Simplified डेटाबेस माइग्रेशन: को सावधानीपूर्वक स्कीमा संस्करण और पिछड़े संगतता के साथ संभाला जा सकता है।
  • ]Improved team वेग: डेवलपर्स अक्सर कम भय के साथ जारी कर सकते हैं।

CI/CD पाइपलाइनों के साथ ब्लू-ग्रीन तैनाती को एकीकृत करना

CI/CD पाइपलाइनों ने निर्माण, परीक्षण और तैनाती चरणों को स्वचालित किया। जब नीले-हरे के साथ संयुक्त हो तो पाइपलाइन पर्यावरण स्विचन का ऑर्केस्ट्रेटर बन जाती है। सामान्य प्रवाह इस तरह दिखता है:

  1. Build and Test: कोड एक निर्माण को ट्रिगर करता है। यूनिट परीक्षण, एकीकरण परीक्षण, और सुरक्षा स्कैन पाइपलाइन में चल रहे हैं।
  2. ]] निष्क्रिय पर्यावरण के लिए तैनात: पाइपलाइन वर्तमान में यातायात की सेवा नहीं पर्यावरण के लिए कलाकृतियों को तैनात (जैसे, यदि ब्लू सक्रिय है तो ग्रीन)।
  3. Smoke and Acceptance Test: स्वचालित परीक्षण कार्यक्षमता, प्रदर्शन और डेटा स्थिरता की पुष्टि करने के लिए नए वातावरण के खिलाफ चलाते हैं।
  4. Switch Traffic:] एक लोड बैलेंसर या DNS रिकॉर्ड को नए वातावरण में सभी उपयोगकर्ता यातायात को मार्ग में लाने के लिए अद्यतन किया गया है।
  5. पोस्ट-डिप्लॉयमेंट वैलिडेशन: स्वास्थ्य जांच और निगरानी एक ठंडी अवधि के लिए जारी रहती है।
  6. ]Cleanup (वैकल्पिक): पुराने वातावरण को या तो रोलबैक लक्ष्य के रूप में रखा जाता है या एक कूलडाउन अवधि के बाद नष्ट हो जाता है।

दो पहचान वातावरण की स्थापना

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

डेटाबेस विचार

राज्यसभा सेवाओं-विशेषकर डेटाबेस- नीले-हरे तैनाती को जटिल बनाते हैं। आम दृष्टिकोणों में शामिल हैं:

  • ]backward-compatible migrations: पुराने और नए कोड (जैसे, कॉलम जोड़ें लेकिन उन्हें छोड़ें) दोनों के साथ काम करने वाले बदलाव लागू करें।
  • Replication and read प्रतिकृतिs: दोनों वातावरण को एक ही डेटाबेस में इंगित करें, लेकिन यह सुनिश्चित करें कि केवल सक्रिय वातावरण से ही लिखने का कार्य हो।
  • Schema-per-environment: प्रत्येक वातावरण के लिए डेटाबेस को अलग करें और माइग्रेशन टूल के साथ सिंक्रनाइज़ेशन को संभालें।

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

स्वचालित ट्रैफिक स्विचिंग

यातायात स्विच को लोड बैलेंसर (Layer 7), DNS (Layer 4/7), या रूटर स्तर पर लागू किया जा सकता है। क्लाउड-नेटिव तैनाती के लिए, AWS ALB जैसी सेवाएं, Google क्लाउड लोड बैलेंसर, या Kubernetes सर्विस+ इनग्रेसिव इस सरल बनाते हैं। CI/CD पाइपलाइन को API कॉल या कॉन्फ़िगरेशन अपडेट के माध्यम से स्विच को ट्रिगर करना चाहिए।

  • स्वास्थ्य जांच: लोड बैलेंसर को यातायात स्वीकार करने से पहले नए पर्यावरण को स्वस्थ रखने की पुष्टि करनी चाहिए।
  • ]Graceful draining: पुराने वातावरण को रोटेशन से बाहर निकलने से पहले इन-फ्लाइट अनुरोधों को समाप्त करना चाहिए।
  • Session दृढ़ता: यदि आपका ऐप चिपचिपा सत्रों का उपयोग करता है, तो यह सुनिश्चित करें कि स्विच उपयोगकर्ता संदर्भ को तोड़ नहीं देता है। बाह्य सत्र स्टोर (Redis, Memcached) पर विचार करें।

उपकरण जो कि सीआई / सीडी के साथ ब्लू-ग्रीन को सरलीकृत करते हैं

विभिन्न प्रकार के सीआई / सीडी प्लेटफॉर्म और तैनाती उपकरण में ब्लू-ग्रीन रणनीतियों के लिए देशी समर्थन है। नीचे कुछ सबसे लोकप्रिय हैं:

जेनकिंस विद एनिबल या स्पाइन्नेकर

जेनकिंस अत्यधिक लचीला है। आप पाइपलाइन चरणों को परिभाषित कर सकते हैं जो लोड बैलेंसर कॉन्फ़िगरेशन को अद्यतन करने या स्पिननेकर के अंतर्निहित लाल / काले रणनीति का उपयोग करने के लिए Ansible playbooks को बुलाते हैं। स्पिननेकर भी स्विच से पहले मैनुअल अनुमोदन के लिए एक दृश्य यूआई प्रदान करता है।

ऑटो डेवोप्स के साथ गिटलैब सीआई

गिटलाब ऑटो देवऑप्स में एक अंतर्निहित "नीले-हरे तैनाती" चरण शामिल है जब कुबेर्नेट्स में तैनात किया गया था। यह दो तैनाती (नीले और हरे) बनाता है और एक ऐसी सेवा जो `सक्रिय चयनकर्ता लेबल फ्लिप करती है। Gitlab's प्रलेखन एक कदम दर कदम गाइड प्रदान करता है।

AWS CodeDeploy साथ गिटहब एक्शन

AWS CodeDeploy मूल रूप से नीले-हरे तैनाती का समर्थन करता है। एक गिटहब एक्शन वर्कफ़्लो एक S3 बाल्टी को कोड धक्का दे सकता है और फिर एक कोड डिप्लॉय एप्लिकेशन संशोधन को ट्रिगर कर सकता है। तैनाती समूह स्वचालित रूप से नए उदाहरणों, स्वास्थ्य की जांच करता है और यातायात को स्थानांतरित करता है। AWS प्रलेखन सेटअप बताता है।

Arrozilla, arrozna, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aurgo, aur

Argo Rollouts नीले-हरे सहित उन्नत तैनाती रणनीतियों प्रदान करता है। यह यातायात स्थानांतरण को स्वचालित करने के लिए प्रवेश नियंत्रकों और सेवा जाल के साथ एकीकृत करता है। रोलबैक निर्णायक हैं और स्वचालित रूप से मीट्रिक के आधार पर ट्रिगर किया जा सकता है। Aargo Rollouts के बारे में अधिक जानें।

उत्पादन ग्रेड तैनाती के लिए सर्वश्रेष्ठ अभ्यास

ब्लू-ग्रीन को लागू करने से सिर्फ स्विच करने वाले सर्वर से अधिक है। आम नुकसान से बचने के लिए, इन सर्वोत्तम प्रथाओं का पालन करें:

सब कुछ

मैनुअल कदम त्रुटि पेश करते हैं पूरी पाइपलाइन - इमारत से लेकर यातायात तक - स्वचालित हो सकती है। संस्करण-नियंत्रित पाइपलाइन परिभाषाओं का उपयोग करें (उदाहरण के लिए, `Jenkinsfile`, `.gitlab-ci.yml`, वर्कफ़्लो YAML) और सुनिश्चित करने के लिए परीक्षण प्रत्येक तैनाती पर स्वचालित रूप से चल रहे हैं।

फ़ीचर झंडे का उपयोग करें

रिलीज से अलग तैनाती के लिए फीचर झंडे के साथ नीले-हरे को मिलाएं। आप नए फीचर्स के साथ कोड को छिपा सकते हैं और उन्हें धीरे-धीरे फ्लैग मैनेजमेंट टूल (LaunchDarkly, PostHog, Unleash) के माध्यम से सक्षम कर सकते हैं। यह पूरे वातावरण को वापस रोल करने की आवश्यकता से बचाता है यदि कोई फीचर विफल हो जाता है।

व्यापक परीक्षण को लागू करना

धूम्रपान परीक्षण बुनियादी प्रतिक्रियाओं HTTP, डेटाबेस कनेक्टिविटी और महत्वपूर्ण उपयोगकर्ता यात्राओं की पुष्टि करना चाहिए। स्विच करने से पहले निष्क्रिय वातावरण के खिलाफ ब्राउज़र परीक्षण चलाने के लिए सिंथेटिक निगरानी उपकरण (जैसे चेकली, डेटाडॉग सिंथेटिक्स) का उपयोग करें। प्रदर्शन प्रतिगमन को पकड़ने के लिए लोड परीक्षण शामिल करें।

लगातार निगरानी

स्विच के बाद, एप्लिकेशन मीट्रिक, त्रुटि दर, विलंबता और व्यवसाय KPI की निगरानी करें। अगर एनीमाली थ्रेसहोल्ड का उल्लंघन किया जाता है तो स्वचालित रोलबैक को ट्रिगर करने के लिए चेतावनी (पैजरड्यूटी, ओप्सजेनी) का उपयोग करें। उदाहरण के लिए, यदि 5xx त्रुटियां 50% तक बढ़ जाती हैं, तो पुराने वातावरण में यातायात को पलट दें।

राज्यसभा घटक के लिए योजना

फ़ाइल अपलोड, उपयोगकर्ता सत्र और नौकरियों के कतार को सावधानीपूर्वक हैंडलिंग की आवश्यकता होती है। बाहरी साझा भंडारण (S3, EFS) का उपयोग करें और कैश (Redis, Memcached) वितरित करें कि दोनों वातावरण एक्सेस कर सकते हैं। कतार के लिए, सुनिश्चित करें कि स्विच के दौरान संदेश खो नहीं जाते हैं।

कूलडाउन अवधि को परिभाषित करें

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

Them को कैसे ओवरकॉम करें

डेटाबेस स्कीमा माइग्रेशन

सबसे बड़ी चुनौती डेटाबेस परिवर्तनों को संभालने वाली है जो पिछड़े संगतता को तोड़ती है। समाधानों में शामिल हैं:

  • केवल additive माइग्रेशन का प्रयोग करें (उनमें से कोई भी स्तंभ नहीं है)।
  • पुराने स्तंभों को अलग-अलग, पोस्ट-स्विच माइग्रेशन में निकालें।
  • नए ऐप संस्करण से पहले डेटाबेस में बदलाव की तैनाती, पुराने कोड को अभी भी चला सकते हैं।

लागत

दो समान उत्पादन वातावरण में चल रहे बुनियादी ढांचे की लागत दोगुनी होती है। शमन: परीक्षण के दौरान निष्क्रिय वातावरण के लिए छोटे उदाहरणों का उपयोग करें, या अंतर्निहित संसाधनों को साझा करने के लिए कंटेनरीकरण का उपयोग करें। क्लाउड ऑटो स्केलिंग भी अपशिष्ट को कम कर सकता है।

सत्र और कैश वार्म-अप

जब यातायात स्विच, कैश ठंडा होते हैं। स्विच करने से पहले विशिष्ट उपयोगकर्ता अनुरोधों का अनुकरण करके नए पर्यावरण को पूर्व-warm करना।

नेटवर्क विन्यास

फायरवॉल नियम, DNS रिकॉर्ड और SSL प्रमाणपत्र वातावरण में समान होना चाहिए। स्थिरता सुनिश्चित करने के लिए IaC का उपयोग करें। यदि DNS-आधारित स्विचिंग का उपयोग किया जाता है, तो प्रचार समय (TTL) के लिए खाता।

रियल-वर्ल्ड उदाहरण: ई-कॉमर्स प्लेटफॉर्म

10 मिलियन दैनिक आगंतुकों के साथ एक ऑनलाइन खुदरा विक्रेता को हर सप्ताह नए फीचर्स को डाउनटाइम के बिना तैनात करने की आवश्यकता थी। उन्होंने निम्नलिखित सेटअप के साथ ब्लू-ग्रीन तैनाती को अपनाया:

  • AWS Auto Scaling groups (blue, green) a ALB के पीछे।
  • समान अवसंरचना के प्रावधान के लिए टेरेफॉर्म।
  • GitLab CI पाइपलाइन: निर्माण, परीक्षण, हरे रंग में तैनात, प्लेराइट स्मोक टेस्ट चलाएं, फिर ALB लक्ष्य समूह स्विच को ट्रिगर करें।
  • सत्रों के लिए रेडिस वातावरण में साझा किया गया।
  • डेटाबेस माइग्रेशन: पिछड़े अनुकूल, फ्लाईवे के साथ।
  • यदि त्रुटि दर> पहले 5 मिनट में 1% है तो स्वचालित रोलबैक।

परिणाम: तैनाती आवृत्ति मासिक से साप्ताहिक तक बढ़ी, जिसमें छह महीने से अधिक शून्य डाउनटाइम घटनाएं शामिल थीं।

निष्कर्ष

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