🥇Nginx से Envoy Proxy में माइग्रेशन

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

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

क्षमताओं

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

चरण 1 - उदाहरण एनजीआईएनएक्स कॉन्फ़िगरेशन

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

nginx स्रोत कॉन्फ़िगरेशन

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;
    }
  }
}

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

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

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

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

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

चरण 2 - एनजीआईएनएक्स कॉन्फ़िगरेशन

पहले भाग nginx.conf कुछ एनजीआईएनएक्स आंतरिकों को परिभाषित करता है जिन्हें कॉन्फ़िगर करने की आवश्यकता है।

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

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

worker_processes  2;

events {
  worker_connections   2000;
}

एन्वॉय प्रॉक्सी विभिन्न तरीकों से वर्कफ़्लो और कनेक्शन का प्रबंधन करता है।

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

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

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

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

ज्यादा जानकारी के लिये पधारें दूत प्रॉक्सी ब्लॉग.

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

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

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

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

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

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

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

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

दूत श्रोताओं

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

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

एन्वॉय प्रॉक्सी अपने कॉन्फ़िगरेशन के लिए YAML नोटेशन का उपयोग करता है। इस संकेतन के परिचय के लिए, यहां देखें लिंक.

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

परिभाषित करने की जरूरत नहीं सर्वर का नाम, चूंकि एन्वॉय प्रॉक्सी फ़िल्टर इसे संभाल लेंगे।

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

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

location / {
    proxy_pass         http://targetCluster/;
    proxy_redirect     off;

    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
}

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

दूत फ़िल्टर

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

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

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

अन्य लोड संतुलन नीतियों के बारे में अधिक जानकारी के लिए देखें दूत दस्तावेज़ीकरण.

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

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

  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 दूत लगातार और अतुल्यकालिक रूप से निर्दिष्ट DNS लक्ष्यों को हल करेगा। DNS परिणाम से लौटाए गए प्रत्येक आईपी पते को अपस्ट्रीम क्लस्टर में एक स्पष्ट होस्ट माना जाएगा। इसका मतलब यह है कि यदि कोई अनुरोध दो आईपी पते लौटाता है, तो दूत यह मान लेगा कि क्लस्टर में दो होस्ट हैं, और दोनों को लोड संतुलित होना चाहिए। यदि किसी होस्ट को परिणाम से हटा दिया जाता है, तो दूत मान लेगा कि यह अब मौजूद नहीं है और किसी भी मौजूदा कनेक्शन पूल से ट्रैफ़िक खींच लेगा।

अधिक जानकारी के लिए देखें दूत प्रॉक्सी दस्तावेज़ीकरण.

चरण 6 - लॉग एक्सेस और त्रुटियाँ

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

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

निम्नलिखित कॉन्फ़िगरेशन सभी एक्सेस लॉग को रीडायरेक्ट करेगा stdout (अनुवादक का नोट - डॉकर के अंदर दूत का उपयोग करने के लिए stdout आवश्यक है। यदि डॉकर के बिना उपयोग किया जाता है, तो /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:

डिफ़ॉल्ट रूप से, एन्वॉय के पास एक प्रारूप स्ट्रिंग होती है जिसमें 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 प्रारूप में भी आउटपुट किया जा सकता है json_format। उदाहरण के लिए:

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 से Envoy Proxy में स्थानांतरित कर दिया है। अंतिम चरण इसका परीक्षण करने के लिए एक एन्वॉय प्रॉक्सी इंस्टेंस लॉन्च करना है।

उपयोगकर्ता के रूप में चलाएँ

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

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

दूत प्रॉक्सी का शुभारंभ

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

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

परीक्षण

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

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

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

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

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

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

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

अतिरिक्त 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 }

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

एन्वॉय प्रॉक्सी स्थापित करने के निर्देश वेबसाइट पर पाए जा सकते हैं https://www.getenvoy.io/

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

सिस्टमड सेवा कॉन्फ़िगरेशन जोड़ें /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 कॉन्फिगरेशन डालना होगा।

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

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

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

क्या इस पोस्ट ने आपको दूत प्रॉक्सी स्थापित करने और उसका परीक्षण करने के लिए प्रोत्साहित किया?

हां
नहीं

75 उपयोगकर्ताओं ने मतदान किया। 18 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com

Nginx से एन्वॉय प्रॉक्सी में स्थानांतरण