एक में मैंने एक महीने पहले लिखा था, मैंने इस बारे में बात की थी कि कैसे अपने पायथन वेब एप्लिकेशन को प्रोडक्शन (या प्री-डेव/स्टेजिंग) वातावरण में लगातार तैनात किया जाए। लेख आप अपने एप्लिकेशन को किसी अन्य भाषा में तैनात करने के लिए पिछले लेख का संदर्भ ले सकते हैं। बस वर्कफ़्लो फ़ाइल को संशोधित करना सुनिश्चित करें। मुझे हाल ही में दो आवाजों से मेल खाने के लिए एक माइक्रोसर्विस (पायथन और फास्टएपीआई का उपयोग करके) बनाने का काम सौंपा गया था और अगर वे दोनों मैच थे या नहीं तो एक भविष्यवाणी स्कोर दें। हितधारकों ने वॉयस अनलॉक सुविधा का अनुरोध किया था। हमारी एक इंजीनियरिंग बैठक थी, और मैं कार्य लेने के लिए खड़ा हुआ (या मेरा नेतृत्व मेरे लिए खड़ा हुआ, हाहा)। यह एक दिलचस्प काम था, क्योंकि मैंने पहले कभी एमएल मॉडल के साथ काम नहीं किया (प्रशिक्षित या क्या नहीं)। AWS EC2 उदाहरण के लिए कोड को डिज़ाइन करने, बनाने और शिप करने में मुझे एक सप्ताह का समय लगा। मैं CI/CD का बहुत बड़ा प्रशंसक हूं, इसलिए मैंने वह उपयोग किया जिसके साथ मैं सबसे अधिक सहज था- GitHub क्रियाएं। एक सप्ताह बाद... परिवर्तनों का अनुरोध किया गया था, और मैं एक नई [तैनाती] तकनीक को आज़माना चाहता था जिस पर मैं शोध कर रहा था। मुझे AWS EC2 इंस्टेंस पर शानदार ढंग से चलने वाले dockerized microservice एप्लिकेशन की आवश्यकता थी, जब मैं फिर से तैनात करता हूं तो किसी भी डाउनटाइम का अनुभव नहीं होता। और मेरी आस्तीन में एकदम सही चाल थी। वह युक्ति है: । नीली-हरी तकनीक ब्लू/ग्रीन परिनियोजन पर AWS श्वेतपत्र के अनुसार, यह एक परिनियोजन रणनीति है जिसमें आप दो अलग-अलग, लेकिन समान वातावरण बनाते हैं। एक वातावरण (नीला) वर्तमान अनुप्रयोग संस्करण चला रहा है और एक वातावरण (हरा) नया अनुप्रयोग संस्करण चला रहा है। नीले/हरे परिनियोजन रणनीति का उपयोग करने से अनुप्रयोग की उपलब्धता बढ़ जाती है और परिनियोजन विफल होने पर रोलबैक प्रक्रिया को सरल बनाकर परिनियोजन जोखिम को कम कर देता है। एक बार हरे पर्यावरण पर परीक्षण पूरा हो जाने के बाद, लाइव एप्लिकेशन ट्रैफ़िक को हरे पर्यावरण पर निर्देशित किया जाता है और नीले वातावरण को बहिष्कृत कर दिया जाता है। सरल शब्दों में, नीली/हरी परिनियोजन तकनीक दो समान उत्पादन वातावरण चलाकर डाउनटाइम और जोखिम को कम करने का एक तरीका है। यदि आप इस तरह की परिनियोजन तकनीक को पहली बार सुन रहे हैं, तो डरने की कोई बात नहीं है, मैं आपको विस्तृत कदम प्रदान करूँगा जो आपको ब्लू-ग्रीन परिनियोजन प्राप्त करने में सहायता करेगा। हम उदाहरण के उद्देश्यों के लिए एक काल्पनिक उत्पाद का उपयोग करेंगे क्योंकि मैं एनडीए कारणों से अपनी कंपनी के लिए बनाए गए उत्पाद के साथ परिनियोजन चरणों से नहीं चलना चाहता। हाहा। आइए सीधे चरणों में जाएं: अपने अपडेट किए गए कोड के साथ एक नई डॉकर छवि बनाकर प्रारंभ करें, और इसे एक नए संस्करण संख्या के साथ टैग करें। $ docker build -t myexample:v2 . यह वर्तमान निर्देशिका में उपयोग करके टैग के साथ एक नई डॉकर छवि बनाएगा। Dockerfile myexample:v2 जहाँ नव निर्मित डॉकटर छवि का नाम है। मेरे मामले में, यह एमएल प्रोजेक्ट का नाम था। उदाहरण के लिए, myexample:v2 docker build -t companyx-servicename-backend:v2 नई छवि से एक नया डॉकटर कंटेनर शुरू करें, लेकिन इसे अभी तक बाहरी दुनिया के सामने उजागर न करें। $ docker run -d --name myexample-v2 myexample:v2 यह छवि से नाम के साथ एक नया डॉकटर कंटेनर शुरू करेगा। myexample:v2 myexample-v2 नए कंटेनर के शुरू होने और आरंभ होने की प्रतीक्षा करें, सुनिश्चित करें कि यह ठीक से काम कर रहा है। $ docker logs myexample-v2 यह सुनिश्चित करने के लिए नए कंटेनर के लॉग की जांच करने के लिए डॉकर लॉग कमांड का उपयोग करें कि यह ठीक से शुरू हो गया है और प्रारंभ हो गया है। ट्रैफ़िक को पुराने और नए दोनों कंटेनरों में रूट करने के लिए NGINX जैसे रिवर्स प्रॉक्सी का उपयोग करें। अनुरोधों को सुनने के लिए अपने रिवर्स प्रॉक्सी को कॉन्फ़िगर करें, और उन्हें पुराने और नए दोनों कंटेनरों में अग्रेषित करें। इससे आप ट्रैफ़िक को धीरे-धीरे नए कंटेनर में स्थानांतरित कर सकेंगे. यहां NGINX कॉन्फ़िगरेशन का एक उदाहरण दिया गया है जो दो कंटेनरों को रूट करता है: upstream myexample { server myexample-v1:8000; server myexample-v2:8000 backup; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } } यह कॉन्फ़िगरेशन myexample नामक एक अपस्ट्रीम समूह को दो सर्वरों के साथ सेट करता है: और । कीवर्ड का उपयोग दूसरे सर्वर को बैकअप के रूप में चिह्नित करने के लिए किया जाता है। अपस्ट्रीम समूह को अनुरोधों को अग्रेषित करने के लिए निर्देश का उपयोग किया जाता है। myexample-v1 myexample-v2 backup myexample proxy_pass अपने एप्लिकेशन के नाम और पोर्ट को दर्शाने के लिए रिवर्स प्रॉक्सी कॉन्फ़िगरेशन को अपडेट करना सुनिश्चित करें। रिवर्स प्रॉक्सी कॉन्फ़िगरेशन को समायोजित करके धीरे-धीरे पुराने कंटेनर से नए कंटेनर में ट्रैफ़िक स्थानांतरित करें। ट्रैफ़िक को नए कंटेनर में स्थानांतरित करने के लिए, नए कंटेनर को अधिक भार देने के लिए रिवर्स प्रॉक्सी कॉन्फ़िगरेशन समायोजित करें। यह सर्वर निर्देश से बैकअप कीवर्ड को हटाकर किया जा सकता है: upstream myexample { server myexample-v1:8000; server myexample-v2:8000; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } } यह NGINX को कंटेनर में और अधिक अनुरोध भेजने का कारण बनेगा। अपने एप्लिकेशन की निगरानी करें, और जब तक सभी ट्रैफ़िक नए कंटेनर में प्रवाहित न हो जाए, तब तक आवश्यकतानुसार कॉन्फ़िगरेशन समायोजित करें। myexample-v2 एक बार जब सारा ट्रैफ़िक नए कंटेनर में आने लगे, तो आप पुराने कंटेनर को सुरक्षित रूप से रोक सकते हैं और हटा सकते हैं। $ docker stop myexample-v1 $ docker rm myexample-v1 यह सर्वर पर संसाधनों को मुक्त करते हुए पुराने कंटेनर को रोक देगा और हटा देगा। निष्कर्ष यदि आपका एप्लिकेशन रिलेशनल डेटाबेस पर निर्भर करता है, तो ब्लू-ग्रीन परिनियोजन रणनीति अपडेट किए जाने पर ब्लू और ग्रीन डेटाबेस के बीच असंगतता पैदा कर सकती है। उच्चतम स्तर की डेटा अखंडता सुनिश्चित करने के लिए, एक एकीकृत डेटाबेस स्थापित करने की अनुशंसा की जाती है जो पिछले और भविष्य दोनों संस्करणों के साथ संगत हो। मैं इस तकनीक के लिए नया हूं, और जाहिर है, इसके बारे में ज्यादा जानकारी नहीं है। लेकिन मैं इसके ट्रेडऑफ़ और अन्य तकनीकों के बारे में सीखना जारी रखूंगा जो बेहतर काम करेंगी। क्या आपके पास कोई ऐसी तरकीब है जो आप मेरे साथ साझा करना चाहेंगे? मैं इसकी सराहना करूंगा। मुझे इसे लेने दो (टिप्पणी अनुभाग में)। ओ ओ। मेरे उबाऊ न्यूज़लेटर की सदस्यता लेना न भूलें। मैंने Q1 के बाद से बहुत कुछ सीखा है और जल्द ही उन्हें साझा करूंगा। सियाओ।
