कुछ शब्दों में, कैनरी रिलीज़ के पीछे का विचार केवल कुछ उपयोगकर्ताओं के लिए एक नया सॉफ़्टवेयर संस्करण वितरित करना, परिणामों का विश्लेषण करना और यह तय करना है कि आगे बढ़ना है या नहीं। यदि परिणाम अपेक्षाओं के अनुरूप नहीं हैं, तो वापस लौटें; यदि वे हैं, तो उजागर होने वाले उपयोगकर्ताओं की संख्या तब तक बढ़ाएं जब तक कि सभी उपयोगकर्ताओं को नए संस्करण से लाभ न मिल जाए।
इस पोस्ट में, मैं इस परिचय को संक्षेप में बताना चाहता हूं, अंश को परिभाषित करने के विभिन्न तरीकों की व्याख्या करना चाहता हूं, और यह दिखाना चाहता हूं कि इसे Apache APISIX के साथ कैसे निष्पादित किया जाए।
"कैनरी" शब्द की उत्पत्ति कोयला खनन उद्योग से हुई है। खनन करते समय, जहरीली गैसों का निकलना असामान्य नहीं है: एक छोटी सी बंद जगह में, इसका मतलब त्वरित मृत्यु हो सकता है। इससे भी बदतर, गैस गंधहीन हो सकती है, इसलिए खनिक इसे तब तक सांस लेते रहेंगे जब तक कि निकलने में बहुत देर न हो जाए। कोयला खदानों में कार्बन मोनोऑक्साइड काफी आम है और मानव इंद्रियों द्वारा इसका पता नहीं लगाया जा सकता है।
इस कारण से, खनिक अपने साथ भूमिगत कैनरी लाते थे। यदि कैनरी अचानक मृत अवस्था में गिर जाती है, तो संभावना अधिक है कि ऐसी गैस की थैली में सेंध लग गई है, और उस स्थान को छोड़ने का समय आ गया है।
वर्षों पहले, हम एक नया सॉफ़्टवेयर संस्करण जारी करने के लिए यह दृष्टिकोण लेकर आए थे। सादृश्य इस प्रकार है: खनिक संस्करण को तैनात करने वाली ऑप्स टीम हैं, कैनरी में रिलीज के प्रभाव को मापने के लिए सभी उपकरण शामिल हैं, और गैस एक (महत्वपूर्ण) बग है।
सबसे महत्वपूर्ण हिस्सा यह है कि आपको रिलीज़ के प्रभाव को मापने की ज़रूरत है , जिसमें विफलता दर, HTTP स्थिति कोड इत्यादि शामिल हैं, और पिछले संस्करण के साथ उनकी तुलना करें। यह इस पोस्ट के दायरे से बाहर है, लेकिन फिर भी, यदि आप कैनरी रिलीज़ से लाभ उठाना चाहते हैं तो यह महत्वपूर्ण है। दूसरा सबसे महत्वपूर्ण हिस्सा यदि नया संस्करण खराब है तो तेजी से वापस रोल करने की क्षमता है।
ध्यान दें कि कैनरी रिलीज़ नए कोड जारी करने के जोखिम को प्रबंधित करने का एकमात्र तरीका नहीं है। उदाहरण के लिए, फीचर फ़्लैग एक अन्य लोकप्रिय तरीका है:
फ़ीचर फ़्लैग रोलबैक के प्रति अधिक चुस्त दृष्टिकोण (शब्द के सही अर्थ में) का प्रतिनिधित्व करते हैं। यदि 10 में से एक सुविधा ख़राब है, तो आपको नए संस्करण को पुनः तैनात करने की आवश्यकता नहीं है; आप केवल बग्गी सुविधा को निष्क्रिय करें। हालाँकि, यह महाशक्ति अतिरिक्त कोडबेस जटिलता की कीमत पर आती है, भले ही आप तीसरे पक्ष के उत्पादों पर भरोसा करते हों या इसे स्वयं लागू करते हों।
दूसरी ओर, कैनरी को इच्छानुसार तैनाती और तैनाती रद्द करने में सक्षम होने के लिए एक परिपक्व तैनाती पाइपलाइन की आवश्यकता होती है।
कैनरी रिलीज़ के पीछे का विचार केवल कुछ ही उपयोगकर्ताओं को नए संस्करण तक पहुंचने की अनुमति देना है। अधिकांश कैनरी परिभाषाएँ केवल "अंश" को उपयोगकर्ताओं के प्रतिशत के रूप में परिभाषित करती हैं। हालाँकि, इसमें और भी बहुत कुछ है।
पहला कदम केवल सत्यापित उपयोगकर्ताओं को यह जांचने की अनुमति देना हो सकता है कि उत्पादन वातावरण में तैनाती अपेक्षा के अनुरूप काम करती है। इस मामले में, आप केवल आंतरिक उपयोगकर्ताओं के एक विशिष्ट समूह, जैसे परीक्षक, को नए संस्करण में अग्रेषित कर सकते हैं। यदि आप लोगों को पहले से जानते हैं, और सिस्टम उपयोगकर्ताओं को प्रमाणित करता है, तो आप इसे पहचान के आधार पर कॉन्फ़िगर कर सकते हैं; यदि नहीं, तो आपको कुछ सामान्य तरीके पर वापस जाने की आवश्यकता है, उदाहरण के लिए , HTTP हेडर - X-Canary: Let-Me-Go-To-v2
।
याद रखें कि विसंगतियों को देखने के लिए हमें पुरानी और नई प्रणालियों की निगरानी करनी चाहिए। यदि कुछ भी दिखाई नहीं देता है, तो नए संस्करण में अग्रेषित उपयोगकर्ताओं के पूल को बढ़ाने का यह एक उत्कृष्ट समय है। मैं मानता हूं कि आप अपने कुत्ते का खाना खुद खाते हैं, यानी ; टीम के सदस्य उस सॉफ़्टवेयर का उपयोग करते हैं जिसे वे विकसित कर रहे हैं। उदाहरण के लिए, यदि आपके पास लक्जरी कारों के लिए कोई ई-कॉमर्स साइट नहीं है, तो इस अनुभाग को छोड़ने के लिए आपका स्वागत है।
जोखिमों को सीमित करते हुए उपयोगकर्ताओं के अंश को बढ़ाने के लिए, अब हम आंतरिक उपयोगकर्ताओं को अंधाधुंध नया संस्करण प्रदान कर सकते हैं। ऐसा करने के लिए हम क्लाइंट आईपी के आधार पर नए संस्करण को अग्रेषित करने के लिए सिस्टम को कॉन्फ़िगर कर सकते हैं। ऐसे समय में जब लोग साइट पर काम कर रहे थे, यह आसान था क्योंकि उनके आईपी एक विशिष्ट सीमा में थे। रिमोट में ज्यादा बदलाव नहीं होता है क्योंकि उपयोगकर्ता संभवतः वीपीएन के माध्यम से कंपनी के नेटवर्क तक पहुंचते हैं।
फिर से, इस बिंदु पर निगरानी करें और तुलना करें।
इस बिंदु पर, सब कुछ आंतरिक उपयोगकर्ताओं, कुछ या सभी के लिए अपेक्षा के अनुरूप काम करना चाहिए। लेकिन जिस तरह कोई भी योजना दुश्मन के संपर्क से बच नहीं पाती, उसी तरह कोई भी उपयोग उत्पादन कार्यभार की संपूर्ण विविधता की नकल नहीं कर सकता। संक्षेप में, हमें नियमित उपयोगकर्ताओं को नए संस्करण तक पहुंचने की अनुमति देने की आवश्यकता है, लेकिन नियंत्रित तरीके से, जैसे हमने धीरे-धीरे अब तक उपयोगकर्ताओं की संख्या में वृद्धि की है: एक छोटे से अंश से शुरू करें, इसकी निगरानी करें, और यदि सब कुछ ठीक है, तो अंश बढ़ाएं .
अपाचे APISIX के साथ इसे कैसे करें यहां बताया गया है। Apache APISIX एक प्लगइन-आधारित आर्किटेक्चर प्रदान करता है और एक प्लगइन प्रदान करता है जो हमारी आवश्यकताओं को पूरा करता है, अर्थात् traffic-split
प्लगइन।
traffic-split
प्लगइन का उपयोग ट्रैफ़िक के कुछ हिस्सों को विभिन्न अपस्ट्रीम सेवाओं पर गतिशील रूप से निर्देशित करने के लिए किया जा सकता है।यह
match
कॉन्फ़िगर करके किया जाता है, जो ट्रैफ़िक को विभाजित करने के लिए कस्टम नियम हैं, औरweighted_upstreams
जो ट्रैफ़िक को निर्देशित करने के लिए अपस्ट्रीम का एक सेट है।
आइए कुछ बुनियादी अपस्ट्रीम से शुरुआत करें, प्रत्येक संस्करण के लिए एक:
upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1
हम अधिकांश ट्रैफ़िक को v1 और कुछ अंश को v2 पर अग्रेषित करने के लिए traffic-split
प्लगइन का उपयोग कर सकते हैं:
routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3
फिर, हम हर चीज़ की निगरानी करते हैं और सुनिश्चित करते हैं कि परिणाम अपेक्षा के अनुरूप हों। फिर, हम अग्रेषित ट्रैफ़िक के अंश को v2 तक बढ़ा सकते हैं, उदाहरण के लिए :
routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1
ध्यान दें कि Apache APISIX प्रत्येक सेकंड में फ़ाइल में परिवर्तनों को पुनः लोड करता है। इसलिए, आप ट्रैफ़िक को लगभग वास्तविक समय में विभाजित करते हैं। वैकल्पिक रूप से, आप इसे प्राप्त करने के लिए एडमिन एपीआई का उपयोग कर सकते हैं।
उपरोक्त में, मैं आंतरिक उपयोगकर्ताओं से बाहरी उपयोगकर्ताओं के एक अंश की ओर चला गया। शायद आपके संगठन में प्रत्येक आंतरिक उपयोगकर्ता को रिलीज़ करना बहुत बड़ा जोखिम है, और आपको और भी अधिक नियंत्रण की आवश्यकता है। ध्यान दें कि आप इस मामले में traffic-split
प्लगइन को और कॉन्फ़िगर कर सकते हैं।
routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95
X-Canary
HTTP हेडर में कॉन्फ़िगर मान है तो केवल ट्रैफ़िक को विभाजित करें।
निम्न आदेश हमेशा v1 पर अग्रेषित होता है:
curl http://localhost:9080
निम्न आदेश भी हमेशा v1 पर अग्रेषित होता है:
curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080
निम्न आदेश ट्रैफ़िक को कॉन्फ़िगर किए गए भार के अनुसार विभाजित करता है, अर्थात , 95/5:
curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080
इस पोस्ट में कैनरी रिलीज़ के बारे में बताया गया है और आप Apache APISIX के माध्यम से इसे कैसे कॉन्फ़िगर कर सकते हैं। आप अलग-अलग प्राथमिकताओं वाले कई मार्गों से शुरुआत कर सकते हैं और traffic-split
प्लगइन पर आगे बढ़ सकते हैं। बाद वाले को अधिक जटिल उपयोग के मामलों की अनुमति देने के लिए और भी कॉन्फ़िगर किया जा सकता है।
इस पोस्ट का संपूर्ण स्रोत कोड GitHub पर पाया जा सकता है।
आगे जाने के लिए:
मूल रूप से 3 दिसंबर, 2023 को ए जावा गीक में प्रकाशित