Istio मा गाढा प्रक्षेपण: गोप्य सेवा

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

र Istio, OpenShift र Kubernetes सँगसँगै, microservices को तैनाती साँच्चै बोरिंग र अनुमानित बनाउँछ - र यो राम्रो छ। हामी Istio श्रृंखला को चौथो र अन्तिम पोस्ट मा यस बारे र धेरै कुरा गर्नेछौं।

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

हाम्रो अवस्थामा, बोरियत अन्तिम चरणमा मात्र हुन्छ, जब बाँकी सबै बसेर प्रक्रिया हेर्नु हो। तर यसको लागि तपाईंले पहिले सबै कुरा कन्फिगर गर्न आवश्यक छ, र धेरै रोचक चीजहरू यहाँ तपाईंलाई पर्खिरहेका छन्।

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

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

बोरियतलाई व्यवस्थित गर्नु रोचक छ

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

लेबलमा ध्यान दिनुहोस् mirror: स्क्रिनको तल - यो हो जसले ट्राफिक मिररिङ सेट गर्दछ। हो, यो एकदम सरल छ!

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

ड्रामा थपौं

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

एउटा महत्त्वपूर्ण बिन्दु दोहोर्याउनुहोस्

ट्राफिक मिररिङको साथ गोप्य प्रक्षेपण (गाढा लन्च/अनुरोध मिररिङ) कुनै पनि तरिकाले कोडलाई असर नगरी गर्न सकिन्छ।

विचारको लागि खाना

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

Istio मा क्यानरी तैनाती: कमिसन सरलीकरण

सावधानीपूर्वक र बिस्तारै

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

निस्सन्देह, Istio बुद्धिमान अनुरोध मार्ग को लागी धेरै राम्रो विकल्पहरु प्रदान गरेर क्यानरी तैनाती को सरल बनाउँछ। र हो, यो सबै तपाइँको स्रोत कोडलाई कुनै पनि तरिकाले नछोइकन गर्न सकिन्छ।

ब्राउजर फिल्टर गर्दै

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

यो रूटिङ नियम लागू गरौं र त्यसपछि आदेश प्रयोग गर्नुहोस् curl हामी एक लुप मा microservice लाई वास्तविक अनुरोध अनुकरण गर्नेछ। तपाईले स्क्रिनसटमा देख्न सक्नुहुन्छ, तिनीहरू सबै v1 मा जान्छन्:

v2 मा ट्राफिक कहाँ छ? हाम्रो उदाहरणमा सबै अनुरोधहरू हाम्रो आफ्नै आदेश रेखाबाट मात्र आएको हुनाले, यो केवल अवस्थित छैन। तर माथिको स्क्रिनमा तल्लो रेखाहरूमा ध्यान दिनुहोस्: यो तथ्यको प्रतिक्रिया हो कि हामीले सफारी ब्राउजरबाट अनुरोध कार्यान्वयन गर्यौं, जसले फलस्वरूप यो उत्पादन गर्‍यो:

असीमित शक्ति

हामीले पहिले नै लेखेका छौं कि रेगुलर एक्सप्रेशनले अनुरोधहरू राउटिङका ​​लागि धेरै शक्तिशाली क्षमताहरू प्रदान गर्दछ। निम्न उदाहरणमा एक नजर राख्नुहोस् (हामीलाई लाग्छ कि यसले के गर्छ भन्ने कुरा बुझ्नुहुन्छ):

अहिले सम्म तपाईलाई रेगुलर एक्सप्रेशनले के गर्न सक्छ भन्ने कुरा थाहा पाउनु भएको छ।

स्मार्ट कार्य गर्नुहोस्

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

रुचि छ?

के तपाईं आफ्नो कम्प्युटरमा Istio, Kubernetes र OpenShift प्रयोग गर्न उत्सुक हुनुहुन्छ? टोली Red Hat विकासकर्ता टोली एक उत्कृष्ट तयार पाठ्यपुस्तक यस विषयमा र सबै सँगै फाइलहरू सार्वजनिक रूपमा उपलब्ध गराए। त्यसोभए अगाडि बढ्नुहोस् र आफैलाई केहि अस्वीकार नगर्नुहोस्।
 

Istio Egress: स्मारिका पसल मार्फत बाहिर निस्कनुहोस्

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

यो जहाँ Istio Egress उद्धार गर्न आउँछ। संक्षेपमा, यसले तपाइँलाई स्रोतहरू पहुँच गर्न अनुमति दिन्छ (पढ्नुहोस्: "सेवाहरू") जुन तपाइँको Kubernetes पोडहरूको प्रणालीको भाग होइन। यदि तपाइँ अतिरिक्त कन्फिगरेसन गर्नुहुन्न भने, त्यसपछि Istio Egress वातावरणमा ट्राफिक पोडको क्लस्टर भित्र र आन्तरिक IP तालिकाहरूमा आधारित त्यस्ता क्लस्टरहरू बीच मात्र रुट गरिन्छ। र त्यस्ता प्युपेशनले उत्कृष्ट काम गर्दछ जबसम्म तपाईंलाई बाहिरबाट सेवाहरूमा पहुँच आवश्यक पर्दैन।

Egress ले तपाईंलाई माथिको IP तालिकाहरू बाइपास गर्न अनुमति दिन्छ, या त Egress नियमहरूमा वा IP ठेगानाहरूको दायरामा आधारित।

मानौं हामीसँग जाभा प्रोग्राम छ जसले httpbin.org/headers मा GET अनुरोध गर्दछ।

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

यदि तपाइँ कमाण्ड लाइनमा प्रविष्ट गर्नुहुन्छ curl http://httpbin.org/headers, हामी निम्न देख्नेछौं:

वा तपाइँ ब्राउजरमा उही ठेगाना खोल्न सक्नुहुन्छ:

तपाईले देख्न सक्नुहुने रूपमा, त्यहाँ अवस्थित सेवाले यसलाई पास गरेको हेडरहरू मात्र फर्काउँछ।

हामी आयातलाई हेड-अन प्रतिस्थापन गर्दैछौं

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

उफ्, के भयो? सबै काम मात्र भयो। फेला परेन भनेको के हो? हामीले उहाँको लागि मात्र गर्यौं curl.

सम्पूर्ण इन्टरनेटमा IP तालिकाहरू विस्तार गर्दै

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

तलको Egress नियमले Istio लाई आवश्यक सेवा खोज्न (आवश्यक भएमा, सम्पूर्ण इन्टरनेटमा) खोज्न बाध्य पार्छ, यस अवस्थामा, httpbin.org। तपाईंले यो फाइल (egress_httpbin.yml) बाट देख्न सक्नुहुन्छ, यहाँ कार्यक्षमता एकदम सरल छ:

यो नियम लागू गर्न बाँकी छ:

istioctl create -f egress_httpbin.yml -n istioegress

तपाईं आदेश संग Egress नियम हेर्न सक्नुहुन्छ istioctl get egressrules:

र अन्तमा, हामी फेरि आदेश चलाउँछौं दोब्र्याइएको - र हामी देख्छौं कि सबै काम गर्दछ:

हामी खुलेर सोच्दछौं

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

यो Istio मा श्रृंखला मा अन्तिम पोस्ट थियो। सम्पर्कमा रहनुहोस् - त्यहाँ धेरै रोचक चीजहरू छन्!

स्रोत: www.habr.com