👩‍⚖️ 👧🏽 👉🏼 इस्तियो में डार्क लॉन्च: सीक्रेट सर्विसेज 🛵 👉🏼 🎇

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

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

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

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

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

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

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

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

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

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

नाटक जोड़ें

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

महत्वपूर्ण बिंदु दोहराएं

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

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

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

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

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

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

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

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

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

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

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

असीमित शक्ति

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

अब आप शायद पहले से ही जानते हैं कि कौन से नियमित भाव सक्षम हैं।

एक्ट स्मार्ट है

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

के इच्छुक?

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

Istio Egress: उपहार की दुकान के माध्यम से बाहर निकलें

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

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

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

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

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

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

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

जैसा कि आप देख सकते हैं, वहां स्थित सेवा केवल हेडर को पारित कर देती है।

माथे में आयात प्रतिस्थापन

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

उफ़ क्या हुआ? फिर भी, यह सिर्फ काम किया। नहीं मिला क्या मतलब है? हमने बस उसके लिए किया curl।

पूरे इंटरनेट पर आईपी टेबल बढ़ाएँ

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

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

यह केवल इस नियम को लागू करने के लिए बनी हुई है:

istioctl create -f egress_httpbin.yml -n istioegress

आप कमांड के साथ Egress के नियम देख सकते हैं istioctl get egressrules:

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

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

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

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

इस्तियो में डार्क लॉन्च: सीक्रेट सर्विसेज