इस्तियो में डार्क लॉन्च: गुप्त सेवाएँ

"खतरा मेरा मध्य नाम है," ऑस्टिन पॉवर्स, एक अंतरराष्ट्रीय रहस्यवादी व्यक्ति, कहा करते थे। लेकिन जिसे सुपर एजेंटों और खुफिया सेवाओं द्वारा उच्च सम्मान में रखा जाता है वह कंप्यूटर सेवाओं के लिए बिल्कुल भी उपयुक्त नहीं है, जहां बोरियत खतरे से कहीं बेहतर है।

और इस्तियो, ओपनशिफ्ट और कुबेरनेट्स के साथ मिलकर, माइक्रोसर्विसेज की तैनाती को वास्तव में उबाऊ और पूर्वानुमानित बनाता है - और यह बहुत अच्छा है। हम इस्तियो श्रृंखला की चौथी और अंतिम पोस्ट में इसके बारे में और बहुत कुछ बात करेंगे।

जब बोरियत सही हो

हमारे मामले में, बोरियत केवल अंतिम चरण में होती है, जब केवल बैठकर प्रक्रिया को देखना ही रह जाता है। लेकिन इसके लिए आपको पहले सब कुछ कॉन्फ़िगर करना होगा, और यहां बहुत सारी दिलचस्प चीजें आपका इंतजार कर रही हैं।

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

कृपया ध्यान दें कि पिछले पैराग्राफ के पहले वाक्य में "रिलीज़" के बजाय "तैनाती" शब्द का उपयोग किया गया है। आपको वास्तव में जितनी बार चाहें उतनी बार अपने माइक्रोसर्विस को तैनात करने और निश्चित रूप से उपयोग करने में सक्षम होना चाहिए। यह सेवा ट्रैफ़िक प्राप्त करने और संसाधित करने, परिणाम उत्पन्न करने और लॉग और मॉनिटर को लिखने में भी सक्षम होनी चाहिए। लेकिन साथ ही, इस सेवा को स्वयं उत्पादन में जारी करने की आवश्यकता नहीं है। सॉफ़्टवेयर परिनियोजन और रिलीज़ करना हमेशा एक ही बात नहीं होती है. आप जब चाहें तब तैनात कर सकते हैं, लेकिन रिलीज़ तभी करें जब आप तैयार हों।

बोरियत का आयोजन दिलचस्प है

निम्नलिखित इस्तियो रूटिंग नियम पर एक नज़र डालें, जो सभी HTTP अनुरोधों को माइक्रोसर्विस अनुशंसा v1 पर रूट करता है (सभी उदाहरण यहां से लिए गए हैं) इस्तियो ट्यूटोरियल गिटहब रेपो), साथ ही उन्हें अनुशंसा v2 माइक्रोसर्विस पर प्रतिबिंबित करते हुए:

लेबल पर ध्यान दें mirror: स्क्रीन के नीचे - यही ट्रैफ़िक मिररिंग सेट करता है। हाँ, यह इतना आसान है!

इस नियम का परिणाम यह होगा कि आपका उत्पादन सिस्टम (v1) आने वाले अनुरोधों को संसाधित करना जारी रखेगा, लेकिन अनुरोध स्वयं अतुल्यकालिक रूप से v2 पर प्रतिबिंबित होंगे, यानी, उनके पूर्ण डुप्लिकेट वहां जाएंगे। इस तरह, आप उत्पादन प्रणाली के संचालन में किसी भी तरह से हस्तक्षेप किए बिना - वास्तविक परिस्थितियों में - वास्तविक डेटा और ट्रैफ़िक पर - v2 का परीक्षण कर सकते हैं। क्या इससे परीक्षण का आयोजन उबाऊ हो जाता है? हाँ निश्चित रूप से। लेकिन यह दिलचस्प तरीके से किया गया है.

चलिए ड्रामा जोड़ते हैं

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

चलिए एक महत्वपूर्ण बात दोहराते हैं

ट्रैफ़िक मिररिंग (डार्क लॉन्च/रिक्वेस्ट मिररिंग) के साथ गुप्त लॉन्च किसी भी तरह से कोड को प्रभावित किए बिना किया जा सकता है।

सोच के लिए भोजन

क्या होगा यदि वह स्थान जहां अनुरोध प्रतिबिंबित होते हैं उनमें से कुछ को v1 पर नहीं, बल्कि v2 पर भेजता है? उदाहरण के लिए, सभी अनुरोधों का एक प्रतिशत या केवल उपयोगकर्ताओं के एक निश्चित समूह से अनुरोध। और फिर, पहले से ही देख रहे हैं कि v2 कैसे काम करता है, धीरे-धीरे सभी अनुरोधों को नए संस्करण में स्थानांतरित करें। या इसके विपरीत, यदि v1 में कुछ गलत हो जाता है तो सब कुछ v2 पर लौटा दें। मुझे लगता है कि इसे कैनरी परिनियोजन कहा जाता है। खनन पर वापस चला जाता है, और यदि यह रूसी मूल का होता, तो संभवतः इसमें इसका संदर्भ होता बिल्ली की), और अब हम इस पर अधिक विस्तार से विचार करेंगे।

इस्तियो में कैनरी परिनियोजन: कमीशनिंग को सरल बनाना

सावधानी से और धीरे-धीरे

कैनरी परिनियोजन परिनियोजन मॉडल का सार बेहद सरल है: जब आप अपने सॉफ़्टवेयर का एक नया संस्करण लॉन्च करते हैं (हमारे मामले में, एक माइक्रोसर्विस), तो आप पहले इसे उपयोगकर्ताओं के एक छोटे समूह तक पहुंच प्रदान करते हैं। यदि सब कुछ ठीक रहता है, तो आप धीरे-धीरे इस समूह को तब तक बढ़ाते हैं जब तक कि नया संस्करण काम करना शुरू न कर दे, या - यदि ऐसा नहीं होता है - अंततः सभी उपयोगकर्ताओं को इसमें स्थानांतरित कर दें। सोच-समझकर और धीरे-धीरे एक नया संस्करण पेश करके और उपयोगकर्ताओं को नियंत्रित तरीके से उस पर स्विच करके, आप जोखिमों को कम कर सकते हैं और प्रतिक्रिया को अधिकतम कर सकते हैं।

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

ब्राउज़र को फ़िल्टर करना

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

आइए इस रूटिंग नियम को लागू करें और फिर कमांड का उपयोग करें curl हम एक लूप में माइक्रोसर्विस के लिए वास्तविक अनुरोधों का अनुकरण करेंगे। जैसा कि आप स्क्रीनशॉट में देख सकते हैं, वे सभी v1 पर जाते हैं:

V2 पर ट्रैफ़िक कहाँ है? चूँकि हमारे उदाहरण में सभी अनुरोध केवल हमारी अपनी कमांड लाइन से आए थे, यह अस्तित्व में ही नहीं है। लेकिन ऊपर स्क्रीन में नीचे की पंक्तियों पर ध्यान दें: यह इस तथ्य की प्रतिक्रिया है कि हमने सफ़ारी ब्राउज़र से एक अनुरोध निष्पादित किया, जिसने बदले में यह उत्पन्न किया:

असीमित शक्ति

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

अब तक आपको शायद अंदाज़ा हो गया होगा कि रेगुलर एक्सप्रेशन क्या कर सकते हैं।

समझदारी से काम लें

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

में रुचि रखते हैं?

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

इस्तियो निकास: स्मारिका दुकान से बाहर निकलें

रेड हैट ओपनशिफ्ट और कुबेरनेट्स के साथ इस्तियो का उपयोग करके, आप माइक्रोसर्विसेज के साथ अपने जीवन को बहुत आसान बना सकते हैं। इस्तियो का सर्विस मेश कुबेरनेट्स पॉड्स के अंदर छिपा हुआ है, और आपका कोड (ज्यादातर) अलगाव में चलता है। प्रदर्शन, परिवर्तन में आसानी, ट्रेसिंग इत्यादि - साइडकार कंटेनरों के उपयोग के कारण इन सभी का उपयोग करना आसान है। लेकिन क्या होगा यदि आपके माइक्रोसर्विस को आपके ओपनशिफ्ट-कुबेरनेट्स सिस्टम के बाहर स्थित अन्य सेवाओं के साथ संचार करने की आवश्यकता है?

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

इग्रेस आपको उपरोक्त आईपी तालिकाओं को बायपास करने की अनुमति देता है, या तो इग्रेस नियमों के आधार पर या आईपी पते की एक श्रृंखला पर।

मान लीजिए कि हमारे पास एक जावा प्रोग्राम है जो httpbin.org/headers को GET अनुरोध करता है।

(httpbin.org आउटगोइंग सेवा अनुरोधों के परीक्षण के लिए एक सुविधाजनक संसाधन है।)

यदि आप कमांड लाइन पर प्रवेश करते हैं curl http://httpbin.org/headers, हम निम्नलिखित देखेंगे:

या आप ब्राउज़र में वही पता खोल सकते हैं:

जैसा कि आप देख सकते हैं, वहां स्थित सेवा बस उसे दिए गए हेडर लौटा देती है।

हम आयात को सीधे तौर पर प्रतिस्थापित कर रहे हैं

आइए अब इस सेवा का जावा कोड लें, जो हमारे सिस्टम के बाहर है, और इसे अपने आप चलाएं, जहां, याद रखें, इस्तियो स्थापित है। (आप संपर्क करके स्वयं ऐसा कर सकते हैं हमारा इस्तियो ट्यूटोरियल.) उपयुक्त छवि बनाने और इसे ओपनशिफ्ट प्लेटफॉर्म पर लॉन्च करने के बाद, हम इस सेवा को कमांड के साथ कॉल करेंगे curl egresshttpbin-istioegress.$(minishift ip).nip.io, जिसके बाद हम इसे स्क्रीन पर देखेंगे:

उफ़, क्या हुआ? सब कुछ बस काम किया. नॉट फाउंड का क्या मतलब है? हमने बस यह उसके लिए किया curl.

संपूर्ण इंटरनेट पर आईपी तालिकाओं का विस्तार करना

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

नीचे दिया गया इग्रेशन नियम इस्तियो को आवश्यक सेवा के लिए (यदि आवश्यक हो, तो पूरे इंटरनेट पर) खोज करने के लिए मजबूर करता है, इस मामले में, httpbin.org। जैसा कि आप इस फ़ाइल (egress_httpbin.yml) से देख सकते हैं, यहाँ कार्यक्षमता काफी सरल है:

बस इस नियम को लागू करना बाकी है:

istioctl create -f egress_httpbin.yml -n istioegress

आप कमांड के साथ इग्रेशन नियम देख सकते हैं istioctl get egressrules:

और अंत में, हम कमांड को फिर से चलाते हैं कर्ल - और हम देखते हैं कि सब कुछ काम करता है:

हम खुलकर सोचते हैं

जैसा कि आप देख सकते हैं, इस्तियो आपको बाहरी दुनिया के साथ बातचीत को व्यवस्थित करने की अनुमति देता है। दूसरे शब्दों में, आप अभी भी ओपनशिफ्ट सेवाएँ बना सकते हैं और उन्हें कुबेरनेट्स के माध्यम से प्रबंधित कर सकते हैं, पॉड्स में सब कुछ रखते हुए, आवश्यकतानुसार ऊपर और नीचे स्केल कर सकते हैं। और साथ ही, आप अपने परिवेश से बाहर की सेवाओं तक सुरक्षित रूप से पहुंच सकते हैं। और हाँ, हम एक बार फिर दोहराते हैं कि यह सब आपके कोड को किसी भी तरह से छुए बिना किया जा सकता है।

यह इस्तियो पर श्रृंखला की आखिरी पोस्ट थी। देखते रहिए - आगे बहुत सारी दिलचस्प चीज़ें हैं!

स्रोत: www.habr.com