🥇 Nginx बाट Envoy Proxy मा माइग्रेसन

नमस्ते, Habr! म तपाइँको ध्यानमा पोष्टको अनुवाद ल्याउँछु: Nginx बाट Envoy Proxy मा माइग्रेसन.

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

विशेषताहरू

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

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

यो लिपिले विशेष रूपमा क्राफ्ट गरिएको फाइल प्रयोग गर्दछ nginx.conf, बाट पूर्ण उदाहरणमा आधारित NGINX विकि। तपाईंले सम्पादकमा खोलेर कन्फिगरेसन हेर्न सक्नुहुन्छ 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;
    }
  }
}

NGINX कन्फिगरेसनहरूमा सामान्यतया तीन मुख्य तत्वहरू हुन्छन्:

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

सबै कन्फिगरेसनहरू Envoy Proxy मा लागू हुने छैनन्, र तपाईंले केही सेटिङहरू कन्फिगर गर्न आवश्यक छैन। राजदूत प्रोक्सी छ चार प्रमुख प्रकार, जसले NGINX द्वारा प्रस्ताव गरेको मुख्य पूर्वाधारलाई समर्थन गर्दछ। मूल हो:

श्रोताहरू: तिनीहरूले दूत प्रोक्सीले आगमन अनुरोधहरू कसरी स्वीकार गर्छ भनेर निर्धारण गर्छन्। Envoy Proxy ले हाल TCP-आधारित श्रोताहरूलाई मात्र समर्थन गर्दछ। एक पटक जडान स्थापित भएपछि, यसलाई प्रशोधनका लागि फिल्टरहरूको सेटमा पठाइन्छ।
फिल्टरहरू: तिनीहरू एक पाइपलाइन वास्तुकलाको भाग हुन् जसले आगमन र बहिर्गमन डेटा प्रशोधन गर्न सक्छ। यस प्रकार्यले Gzip जस्ता फिल्टरहरू समावेश गर्दछ, जसले ग्राहकलाई पठाउनु अघि डाटा कम्प्रेस गर्दछ।
राउटरहरू: तिनीहरूले आवश्यक गन्तव्यमा ट्राफिक फर्वार्ड गर्छन्, क्लस्टरको रूपमा परिभाषित।
क्लस्टरहरू: तिनीहरूले ट्राफिक र कन्फिगरेसन प्यारामिटरहरूको लागि अन्तिम बिन्दु परिभाषित गर्दछ।

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

चरण 2 - NGINX कन्फिगरेसन

पहिलो भाग nginx.conf कन्फिगर गर्न आवश्यक केही NGINX आन्तरिकहरू परिभाषित गर्दछ।

कार्यकर्ता जडानहरू

तलको कन्फिगरेसनले कार्यकर्ता प्रक्रिया र जडानहरूको संख्या निर्धारण गर्दछ। यसले NGINX कसरी माग पूरा गर्न मापन गर्नेछ भनेर संकेत गर्दछ।

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy ले विभिन्न तरिकामा कार्यप्रवाह र जडानहरू प्रबन्ध गर्दछ।

दूतले प्रणालीमा प्रत्येक हार्डवेयर थ्रेडको लागि कार्यकर्ता थ्रेड सिर्जना गर्दछ। प्रत्येक कार्यकर्ता थ्रेडले गैर-ब्लकिङ घटना लुप कार्यान्वयन गर्दछ जुन जिम्मेवार छ

प्रत्येक श्रोतालाई सुन्दै
नयाँ जडानहरू स्वीकार गर्दै
जडानको लागि फिल्टरहरूको सेट सिर्जना गर्दै
जडानको जीवनकालमा सबै I/O कार्यहरू प्रशोधन गर्नुहोस्।

सबै थप जडान प्रशोधन कार्यकर्ता थ्रेडमा पूर्ण रूपमा ह्यान्डल गरिन्छ, कुनै पनि फर्वार्डिङ व्यवहार सहित।

दूतमा प्रत्येक कार्यकर्ता थ्रेडको लागि, त्यहाँ जडान पूल छ। त्यसैले HTTP/2 जडान पूलहरूले एक पटकमा प्रति बाह्य होस्टमा एउटा जडान मात्र स्थापना गर्दछ, यदि त्यहाँ चार कार्यकर्ता थ्रेडहरू छन् भने त्यहाँ स्थिर अवस्थामा प्रति बाह्य होस्टमा चार HTTP/2 जडानहरू हुनेछन्। एक कार्यकर्ता थ्रेडमा सबै कुरा राखेर, लगभग सबै कोडहरू ब्लक नगरी लेख्न सकिन्छ, मानौं यो एकल थ्रेड गरिएको थियो। यदि आवश्यक भन्दा बढी कार्यकर्ता थ्रेडहरू आवंटित गरियो भने, यसले मेमोरीलाई बर्बाद गर्न सक्छ, धेरै संख्यामा निष्क्रिय जडानहरू सिर्जना गर्न सक्छ, र पुन: पूलमा जडानहरू फिर्ता हुने संख्यालाई घटाउँछ।

थप जानकारीको लागि भ्रमण गर्नुहोस् दूत प्रोक्सी ब्लग.

HTTP कन्फिगरेसन

निम्न NGINX कन्फिगरेसन ब्लकले HTTP सेटिङहरू परिभाषित गर्दछ जस्तै:

कुन माइम प्रकारहरू समर्थित छन्
पूर्वनिर्धारित टाइमआउटहरू
Gzip कन्फिगरेसन

तपाईंले दूत प्रोक्सीमा फिल्टरहरू प्रयोग गरेर यी पक्षहरूलाई अनुकूलन गर्न सक्नुहुन्छ, जसलाई हामी पछि छलफल गर्नेछौं।

चरण 3 - सर्भर कन्फिगरेसन

HTTP कन्फिगरेसन ब्लकमा, NGINX कन्फिगरेसनले पोर्ट 8080 मा सुन्न र डोमेनहरूको लागि आगमन अनुरोधहरूको जवाफ दिन निर्दिष्ट गर्दछ। one.example.com и www.one.example.com.

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

दूत भित्र, यो श्रोताहरू द्वारा नियन्त्रित छ।

दूत श्रोताहरू

Envoy Proxy सँग सुरु गर्ने सबैभन्दा महत्त्वपूर्ण पक्ष भनेको तपाईका श्रोताहरूलाई परिभाषित गर्नु हो। तपाईंले कन्फिगरेसन फाइल सिर्जना गर्न आवश्यक छ जसले वर्णन गर्दछ कि तपाईं कसरी दूत उदाहरण चलाउन चाहनुहुन्छ।

तलको स्निपेटले नयाँ श्रोता सिर्जना गर्नेछ र यसलाई पोर्ट 8080 मा बाँध्नेछ। कन्फिगरेसनले Envoy Proxy लाई आगमन अनुरोधहरूको लागि कुन पोर्टहरू बाँध्नुपर्छ भनेर बताउँछ।

Envoy Proxy ले यसको कन्फिगरेसनको लागि YAML नोटेशन प्रयोग गर्दछ। यस नोटेशनको परिचयको लागि, यहाँ हेर्नुहोस् लिङ्क.

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

परिभाषित गर्न आवश्यक छैन सर्भर_नाम, किनकि Envoy Proxy फिल्टरहरूले यसलाई ह्यान्डल गर्नेछन्।

चरण 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 Proxy मा निर्मित फिल्टर हो। अन्य फिल्टरहरू समावेश छन् Redis, मोन्गो, टीसीपी। तपाईं मा पूरा सूची पाउन सक्नुहुन्छ कागजात.

अन्य लोड सन्तुलन नीतिहरूको बारेमा थप जानकारीको लागि, भ्रमण गर्नुहोस् दूत दस्तावेज.

चरण 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 दूतले निर्दिष्ट DNS लक्ष्यहरूलाई निरन्तर र एसिन्क्रोनस रूपमा समाधान गर्नेछ। DNS परिणामबाट प्रत्येक फिर्ता गरिएको IP ठेगानालाई अपस्ट्रीम क्लस्टरमा स्पष्ट होस्ट मानिनेछ। यसको मतलब यो हो कि यदि अनुरोधले दुई आईपी ठेगानाहरू फर्काउँछ भने, दूतले क्लस्टरमा दुई होस्टहरू छन् भनी मान्नेछ, र दुबै लोड सन्तुलित हुनुपर्छ। यदि परिणामबाट होस्ट हटाइयो भने, दूतले यो अब अवस्थित छैन भनी मान्नेछ र कुनै पनि अवस्थित जडान पूलहरूबाट ट्राफिक तान्नुहुनेछ।

अधिक जानकारी को लागी हेर्नुहोस् दूत प्रोक्सी कागजात.

चरण 6 - लग पहुँच र त्रुटिहरू

अन्तिम कन्फिगरेसन दर्ता हो। त्रुटि लगहरूलाई डिस्कमा धकेल्नुको सट्टा, Envoy Proxy ले क्लाउड-आधारित दृष्टिकोण लिन्छ। सबै अनुप्रयोग लगहरू आउटपुट हुन् stdout и stderr.

प्रयोगकर्ताहरूले अनुरोध गर्दा, पहुँच लगहरू ऐच्छिक हुन्छन् र पूर्वनिर्धारित रूपमा असक्षम हुन्छन्। HTTP अनुरोधहरूको लागि पहुँच लगहरू सक्षम गर्न, कन्फिगरेसन सक्षम गर्नुहोस् access_log 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

Envoy Proxy सँग काम गर्ने अन्तरदृष्टि प्राप्त गर्ने एक मात्र तरिका लगिङ होइन। यसमा उन्नत ट्रेसिङ र मेट्रिक्स क्षमताहरू छन्। तपाईं मा थप पत्ता लगाउन सक्नुहुन्छ ट्रेसिङ कागजात वा मार्फत अन्तरक्रियात्मक ट्रेसिङ स्क्रिप्ट.

चरण 7 - सुरु गर्नुहोस्

तपाईंले अब आफ्नो कन्फिगरेसन NGINX बाट Envoy Proxy मा स्थानान्तरण गर्नुभएको छ। अन्तिम चरण यो परीक्षण गर्न एक दूत प्रोक्सी उदाहरण सुरु गर्नु हो।

प्रयोगकर्ताको रूपमा चलाउनुहोस्

NGINX कन्फिगरेसन लाइनको शीर्षमा प्रयोगकर्ता www www; सुरक्षा सुधार गर्न NGINX लाई कम विशेषाधिकार प्राप्त प्रयोगकर्ताको रूपमा चलाउन निर्दिष्ट गर्दछ।

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

दूत प्रोक्सी सुरु गर्दै

तलको आदेशले होस्टमा डकर कन्टेनर मार्फत दूत प्रोक्सी चलाउनेछ। यो आदेशले दूतलाई पोर्ट 80 मा आगमन अनुरोधहरू सुन्न सक्ने क्षमता दिन्छ। यद्यपि, श्रोता कन्फिगरेसनमा निर्दिष्ट गरिए अनुसार, Envoy प्रोक्सीले पोर्ट 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। यो किनभने अपस्ट्रीम जडानहरू काम गरिरहेका छैनन् र उपलब्ध छैनन्। त्यसकारण, दूत प्रोक्सीसँग अनुरोधको लागि कुनै उपलब्ध गन्तव्यहरू छैनन्। निम्न आदेशले HTTP सेवाहरूको शृङ्खला सुरु गर्नेछ जुन दूतका लागि परिभाषित कन्फिगरेसनसँग मेल खान्छ।

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

उपलब्ध सेवाहरूको साथ, राजदूतले सफलतापूर्वक आफ्नो गन्तव्यमा ट्राफिक प्रोक्सी गर्न सक्छ।

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

तपाईंले कुन डकर कन्टेनरले अनुरोधलाई प्रशोधन गर्यो भनेर संकेत गर्ने प्रतिक्रिया देख्नुपर्छ। Envoy Proxy लगहरूमा तपाईंले पहुँच स्ट्रिङ आउटपुट पनि देख्नुपर्छ।

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

पूर्वनिर्धारित रूपमा, rpm सँग systemd सेवा कन्फिगरेसन छैन।

systemd सेवा कन्फिगरेसन थप्नुहोस् /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 बाट Envoy Proxy मा माइग्रेसन