🕙 🕘 🦃 Nginx से Envoy Proxy की ओर पलायन 🌏 🙆🏾 🎨

नमस्कार, हेब्र! मैं आपके ध्यान में पोस्ट का अनुवाद लाता हूं: Nginx से Envoy प्रॉक्सी में प्रवासन ।

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

संभावनाएं

आउट ऑफ़ प्रोसेस आर्किटेक्चर: envoy एक स्टैंडअलोन, उच्च-प्रदर्शन सर्वर है जो थोड़ी मात्रा में RAM का उपभोग करता है। यह किसी भी एप्लीकेशन लैंग्वेज या फ्रेमवर्क के साथ मिलकर काम करता है।
Http / 2 और grpc के लिए समर्थन: envoy में इनबाउंड और आउटबाउंड कनेक्शन के लिए http / 2 और grpc के लिए प्रथम श्रेणी का समर्थन है। यह http / 1.1 से http / 2 तक एक पारदर्शी प्रॉक्सी है।
उन्नत लोड संतुलन: envoy उन्नत भार संतुलन सुविधाओं का समर्थन करता है, जिसमें स्वचालित रिट्रीस, ओपन सर्किट, वैश्विक गति सीमा, अनुरोधों को कम करना, स्थानीय क्षेत्र लोड संतुलन, आदि शामिल हैं।
कॉन्फ़िगरेशन प्रबंधन API: envoy अपने कॉन्फ़िगरेशन को गतिशील रूप से प्रबंधित करने के लिए एक मजबूत एपीआई प्रदान करता है।
अवलोकन: गहरी L7 ट्रैफिक वेधशाला, वितरित ट्रेसिंग और मोंगोडब, डायनबोडब और कई अन्य अनुप्रयोगों के अवलोकन के लिए अंतर्निहित समर्थन।

चरण 1 - उदाहरण NGINX कॉन्फ़िगरेशन

यह स्क्रिप्ट NGINX विकी के पूर्ण उदाहरण के आधार पर विशेष रूप से बनाई गई nginx.conf फ़ाइल का उपयोग करती है। आप nginx.conf खोलकर संपादक में कॉन्फ़िगरेशन देख सकते हैं

स्रोत nginx config

user www www; pid /var/run/nginx.pid; worker_processes 2; events { worker_connections 2000; } http { gzip on; gzip_min_length 1100; gzip_buffers 4 8k; gzip_types text/plain; log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $bytes_sent ' '"$http_referer" "$http_user_agent" ' '"$gzip_ratio"'; log_format download '$remote_addr - $remote_user [$time_local] ' '"$request" $status $bytes_sent ' '"$http_referer" "$http_user_agent" ' '"$http_range" "$sent_http_content_range"'; upstream targetCluster { 172.18.0.3:80; 172.18.0.4:80; } server { listen 8080; server_name one.example.com www.one.example.com; access_log /var/log/nginx.access_log main; error_log /var/log/nginx.error_log info; location / { proxy_pass http://targetCluster/; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } }

NGINX कॉन्फ़िगरेशन में आमतौर पर तीन प्रमुख तत्व होते हैं:

NGINX सर्वर, लॉग संरचना और Gzip कार्यक्षमता को कॉन्फ़िगर करना। यह सभी मामलों में विश्व स्तर पर निर्धारित होता है।
पोर्ट 8080 पर one.example.com होस्ट के लिए अनुरोध स्वीकार करने के लिए NGINX कॉन्फ़िगर करना।
अपना गंतव्य स्थान सेट करना, URL के विभिन्न हिस्सों के लिए ट्रैफ़िक को कैसे संभालना है।

सभी कॉन्फ़िगरेशन Envoy प्रॉक्सी पर लागू नहीं होंगे, और आपको कुछ सेटिंग्स कॉन्फ़िगर करने की आवश्यकता नहीं है। एनवॉय प्रॉक्सी में चार प्रमुख प्रकार हैं जो एनजीआईएनएक्स द्वारा पेश किए गए अंतर्निहित बुनियादी ढांचे का समर्थन करते हैं। कोर है:

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

विशिष्ट NGINX कॉन्फ़िगरेशन से मेल खाने के लिए Envoy Proxy कॉन्फ़िगरेशन बनाने के लिए हम इन चार घटकों का उपयोग करेंगे। एनवॉय का लक्ष्य एपीआई और गतिशील कॉन्फ़िगरेशन के साथ काम कर रहा है। इस स्थिति में, मूल कॉन्फ़िगरेशन NGINX से स्थिर, हार्ड-कोडित मापदंडों का उपयोग करेगा।

चरण 2 - NGINX कॉन्फ़िगर करें

Nginx.conf का पहला भाग कुछ आंतरिक NGINX घटकों को परिभाषित करता है जिन्हें कॉन्फ़िगर करने की आवश्यकता होती है।

कार्यकर्ता कनेक्शन

नीचे दिया गया कॉन्फ़िगरेशन कार्य प्रक्रियाओं और कनेक्शनों की संख्या निर्धारित करता है। यह दर्शाता है कि NGINX मांग को पूरा करने के लिए कैसे पैमाना होगा।

 worker_processes 2; events { worker_connections 2000; }

Envoy प्रॉक्सी वर्कफ़्लो और कनेक्शन को अलग-अलग तरीके से प्रबंधित करता है।

Envoy सिस्टम में प्रत्येक हार्डवेयर थ्रेड के लिए एक वर्कफ़्लो बनाता है। प्रत्येक वर्कर थ्रेड एक नॉन-ब्लॉकिंग ईवेंट लूप चलाता है जो इसके लिए जिम्मेदार है

प्रत्येक श्रोता की बात सुनना
नए कनेक्शन स्वीकार करें
कनेक्शन के लिए एक फ़िल्टर सेट बनाना
एक कनेक्शन के जीवनकाल में सभी I / O संचालन को संभालना।

आगे के सभी प्रसंस्करण प्रसंस्करण पूरी तरह से वर्कफ़्लो में संसाधित होते हैं, जिसमें किसी भी अग्रेषण व्यवहार शामिल है।

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

अधिक जानकारी के लिए, Envoy प्रॉक्सी ब्लॉग पर जाएँ ।

HTTP कॉन्फ़िगरेशन

निम्न NGINX कॉन्फ़िगरेशन ब्लॉक HTTP सेटिंग्स को परिभाषित करता है, जैसे:

क्या माइम प्रकार समर्थित हैं
डिफ़ॉल्ट टाइमआउट
Gzip कॉन्फ़िगरेशन

आप इन पहलुओं को Envoy प्रॉक्सी में फ़िल्टर का उपयोग करके कॉन्फ़िगर कर सकते हैं, जिसके बारे में हम बाद में चर्चा करेंगे।

चरण 3 - सर्वर कॉन्फ़िगरेशन

HTTP कॉन्फ़िगरेशन ब्लॉक में, NGINX कॉन्फ़िगरेशन आपको पोर्ट 8080 पर सुनने और डोमेन one.example.com और www.one.example.com के लिए आने वाले अनुरोधों का जवाब देने का निर्देश देता है।

  server { listen 8080; server_name one.example.com www.one.example.com;

एनवॉय के अंदर, श्रोता इसे नियंत्रित करते हैं।

दूत श्रोता

एनवॉय प्रॉक्सी के साथ शुरुआत करने का सबसे महत्वपूर्ण पहलू श्रोताओं की पहचान करना है। आपको एक कॉन्फ़िगरेशन फ़ाइल बनाने की आवश्यकता है जो बताती है कि आप एनवॉय उदाहरण कैसे चलाना चाहते हैं।

नीचे दिया गया स्निपेट एक नया श्रोता बना देगा और इसे 8080 पोर्ट के साथ संबद्ध कर देगा। कॉन्फ़िगरेशन एन्वायॉय प्रॉक्सी को बताता है कि आने वाले अनुरोधों के लिए इसे किन पोर्ट्स पर बाध्य किया जाना चाहिए।

Envoy प्रॉक्सी अपने विन्यास के लिए YAML अंकन का उपयोग करता है। इस अंकन के साथ खुद को परिचित करने के लिए, यहां लिंक देखें।

 Copy to Editorstatic_resources: listeners: - name: listener_0 address: socket_address: { address: 0.0.0.0, port_value: 8080 }

सर्वर_नाम को परिभाषित करने की आवश्यकता नहीं है, क्योंकि एनवॉय प्रॉक्सी फिल्टर इसे संभाल सकते हैं।

चरण 4 - स्थान विन्यास

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

 location / { proxy_pass http://targetCluster/; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

एनवॉय में, फ़िल्टर्स ऐसा करता है।

दूत छानता है

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

 Copy to Editor filter_chains: - filters: - name: envoy.http_connection_manager config: codec_type: auto stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: backend domains: - "one.example.com" - "www.one.example.com" routes: - match: prefix: "/" route: cluster: targetCluster http_filters: - name: envoy.router

Envoy.http_connection_manager नाम Envoy प्रॉक्सी में एक अंतर्निहित फ़िल्टर है। अन्य फिल्टर में रेडिस , मोंगो , टीसीपी शामिल हैं । आप दस्तावेज़ में पूरी सूची पा सकते हैं।

अन्य लोड संतुलन नीतियों के बारे में अधिक जानकारी के लिए, दूत दस्तावेज पर जाएं ।

चरण 5 - प्रॉक्सी और अपस्ट्रीम कॉन्फ़िगरेशन

NGINX में, अपस्ट्रीम कॉन्फ़िगरेशन लक्ष्य सर्वरों के सेट को परिभाषित करता है जो ट्रैफ़िक को संभालेंगे। इस मामले में, दो समूहों को सौंपा गया था।

  upstream targetCluster { 172.18.0.3:80; 172.18.0.4:80; }

एनवॉय में, यह क्लस्टर प्रबंधित है।

दूत का समूह

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

 Copy to Editor clusters: - name: targetCluster connect_timeout: 0.25s type: STRICT_DNS dns_lookup_family: V4_ONLY lb_policy: ROUND_ROBIN hosts: [ { socket_address: { address: 172.18.0.3, port_value: 80 }}, { socket_address: { address: 172.18.0.4, port_value: 80 }} ]

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

अधिक जानकारी के लिए, एनवॉय प्रॉक्सी दस्तावेज़ देखें।

चरण 6 - प्रवेश प्रवेश और त्रुटियां

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

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

निम्न कॉन्फ़िगरेशन सभी एक्सेस लॉग को stdout में बदल देगा (अनुवादक का नोट - stdout, docker के अंदर env का उपयोग करने के लिए आवश्यक है। यदि आप docker के बिना उपयोग करते हैं, तो / dev / stdout को नियमित लॉग फ़ाइल के पथ के साथ बदलें)। कनेक्शन प्रबंधक के लिए कॉन्फ़िगरेशन अनुभाग में स्निपेट की प्रतिलिपि बनाएँ:

 Copy to Clipboardaccess_log: - name: envoy.file_access_log config: path: "/dev/stdout"

परिणाम इस तरह दिखना चाहिए:

  - name: envoy.http_connection_manager config: codec_type: auto stat_prefix: ingress_http access_log: - name: envoy.file_access_log config: path: "/dev/stdout" route_config:

डिफ़ॉल्ट रूप से, Envoy में एक प्रारूप स्ट्रिंग है जिसमें HTTP अनुरोध का विवरण शामिल है:

 [%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"\n

इस प्रारूप स्ट्रिंग का परिणाम:

 [2018-11-23T04:51:00.281Z] "GET / HTTP/1.1" 200 - 0 58 4 1 "-" "curl/7.47.0" "f21ebd42-6770-4aa5-88d4-e56118165a7d" "one.example.com" "172.18.0.4:80"

आउटपुट की सामग्री को प्रारूप फ़ील्ड सेट करके अनुकूलित किया जा सकता है। उदाहरण के लिए:

 access_log: - name: envoy.file_access_log config: path: "/dev/stdout" format: "[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"\n"

JSON_format फ़ील्ड सेट करके JSON प्रारूप में लॉग स्ट्रिंग भी आउटपुट किया जा सकता है। उदाहरण के लिए:

 access_log: - name: envoy.file_access_log config: path: "/dev/stdout" json_format: {"protocol": "%PROTOCOL%", "duration": "%DURATION%", "request_method": "%REQ(:METHOD)%"}

दूत पंजीकरण तकनीकों के बारे में अधिक जानकारी के लिए, पर जाएँ

https://www.envoyproxy.io/docs/envoy/latest/configuration/access_log#config-access-log-format-dictionaries

लॉग करना केवल एन्वॉय प्रॉक्सी के साथ काम करने का विचार प्राप्त करने का एकमात्र तरीका नहीं है। इसमें ट्रेसिंग और मेट्रिक्स के लिए बिल्ट-इन एडवांस फीचर्स हैं। आप ट्रेसिंग प्रलेखन में या इंटरएक्टिव ट्रेसिंग स्क्रिप्ट के माध्यम से और अधिक जानकारी प्राप्त कर सकते हैं।

चरण 7 - लॉन्च

अब आपने एनजीआईएनएक्स से एनवॉय प्रॉक्सी के लिए कॉन्फ़िगरेशन स्थानांतरित कर दिया है। अंतिम चरण का परीक्षण करने के लिए एनवॉय प्रॉक्सी का एक उदाहरण चलाना है।

उपयोगकर्ता से चलाएँ

NGINX कॉन्फ़िगरेशन के शीर्ष पर, लाइन उपयोगकर्ता www www; इंगित करता है कि NGINX को सुरक्षा बढ़ाने के लिए कम विशेषाधिकार वाले उपयोगकर्ता के रूप में लॉन्च किया गया है।

Envoy प्रॉक्सी एक क्लाउड-आधारित दृष्टिकोण का प्रबंधन करने के लिए लेता है जो प्रक्रिया का मालिक है। जब हम कंटेनर के माध्यम से Envoy प्रॉक्सी चलाते हैं, तो हम एक उपयोगकर्ता को कम विशेषाधिकार स्तर के साथ निर्दिष्ट कर सकते हैं।

Envoy प्रॉक्सी लॉन्च करें

नीचे दिए गए आदेश होस्ट पर डॉक कंटेनर के माध्यम से एनवॉय प्रॉक्सी को लॉन्च करेंगे। यह कमांड Envoy को पोर्ट 80 के माध्यम से आने वाले अनुरोधों को सुनने की क्षमता प्रदान करता है। हालांकि, जैसा कि श्रोता विन्यास में संकेत दिया गया है, Envoy Proxy आने वाले ट्रैफिक को पोर्ट 8080 के माध्यम से सुनता है। यह प्रक्रिया को कम विशेषाधिकार वाले उपयोगकर्ता के रूप में चलाने की अनुमति देता है।

 docker run --name proxy1 -p 80:8080 --user 1000:1000 -v /root/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoy

परीक्षण

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

 curl -H "Host: one.example.com" localhost -i

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

 docker run -d katacoda/docker-http-server; docker run -d katacoda/docker-http-server;

उपलब्ध सेवाओं के साथ, Envoy अपने गंतव्य के लिए यातायात को सफलतापूर्वक प्रॉक्सी कर सकता है।

 curl -H "Host: one.example.com" localhost -i

आपको एक प्रतिक्रिया दिखाई देनी चाहिए जो बताती है कि डॉकटर कंटेनर ने अनुरोध को संसाधित किया है। Envoy प्रॉक्सी लॉग में, आपको प्रदर्शित एक्सेस स्ट्रिंग भी देखनी चाहिए।

अतिरिक्त HTTP प्रतिक्रिया हेडर

वास्तविक अनुरोध के प्रतिक्रिया शीर्षकों में आपको अतिरिक्त HTTP हेडर दिखाई देंगे। शीर्ष लेख उस समय को प्रदर्शित करता है जो अपस्ट्रीम होस्ट अनुरोध को संसाधित करने में खर्च करता है। यह मिलीसेकंड में व्यक्त किया जाता है। यह उपयोगी है यदि क्लाइंट नेटवर्क विलंबता की तुलना में सेवा समय निर्धारित करना चाहता है।

 x-envoy-upstream-service-time: 0 server: envoy

अंतिम विन्यास

 static_resources: listeners: - name: listener_0 address: socket_address: { address: 0.0.0.0, port_value: 8080 } filter_chains: - filters: - name: envoy.http_connection_manager config: codec_type: auto stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: backend domains: - "one.example.com" - "www.one.example.com" routes: - match: prefix: "/" route: cluster: targetCluster http_filters: - name: envoy.router clusters: - name: targetCluster connect_timeout: 0.25s type: STRICT_DNS dns_lookup_family: V4_ONLY lb_policy: ROUND_ROBIN hosts: [ { socket_address: { address: 172.18.0.3, port_value: 80 }}, { socket_address: { address: 172.18.0.4, port_value: 80 }} ] admin: access_log_path: /tmp/admin_access.log address: socket_address: { address: 0.0.0.0, port_value: 9090 }

अनुवादक से अतिरिक्त जानकारी

Envoy प्रॉक्सी इंस्टॉलेशन निर्देश https://www.getenvoy.io/ पर देखे जा सकते हैं

आरपीएम में डिफ़ॉल्ट रूप से कोई सिस्टमड सर्विस कॉन्फिगर नहीं है।

Systemd service config /etc/systemd/system/envoy.service जोड़ें:

 [Unit] Description=Envoy Proxy Documentation=https://www.envoyproxy.io/ After=network-online.target Requires=envoy-auth-server.service Wants=nginx.service [Service] User=root Restart=on-failure ExecStart=/usr/bin/envoy --config-path /etc/envoy/config.yaml [Install] WantedBy=multi-user.target

आपको निर्देशिका / etc / envoy / बनाने और config.yaml config को वहां रखने की आवश्यकता है।

Envoy प्रॉक्सी द्वारा एक टेलीग्राम चैट होती है: https://t.me/envoyproxy_ru

Envoy प्रॉक्सी स्थिर सामग्री वितरण का समर्थन नहीं करता है। तो सुविधा के लिए कौन वोट कर सकता है: https://github.com/envoyproxy/envoy/issues/378

Nginx से Envoy Proxy की ओर पलायन