🥇 Nginx वरून Envoy Proxy मध्ये स्थलांतर

हॅलो, हॅब्र! मी पोस्टचे भाषांतर तुमच्या लक्षात आणून देतो: Nginx वरून Envoy Proxy मध्ये स्थलांतर.

दूत हा वैयक्तिक सेवा आणि अनुप्रयोगांसाठी डिझाइन केलेला उच्च-कार्यक्षमता वितरित प्रॉक्सी सर्व्हर (C++ मध्ये लिहिलेला) आहे, तो एक कम्युनिकेशन बस आणि "युनिव्हर्सल डेटा प्लेन" देखील आहे जो मोठ्या मायक्रोसर्व्हिस "सर्व्हिस मेश" आर्किटेक्चरसाठी डिझाइन केलेला आहे. ते तयार करताना, एनजीआयएनएक्स, एचएप्रॉक्सी, हार्डवेअर लोड बॅलन्सर्स आणि क्लाउड लोड बॅलन्सर्स सारख्या सर्व्हरच्या विकासादरम्यान उद्भवलेल्या समस्यांचे निराकरण विचारात घेतले गेले. दूत प्रत्येक ऍप्लिकेशनच्या बाजूने कार्य करतो आणि प्लॅटफॉर्मची पर्वा न करता सामान्य कार्यक्षमता प्रदान करण्यासाठी नेटवर्कचे सार तयार करतो. जेव्हा इन्फ्रास्ट्रक्चरमधील सर्व सेवा ट्रॅफिक एंवॉय मेशमधून वाहते, तेव्हा समस्या क्षेत्रे सुसंगत निरीक्षणक्षमतेसह दृश्यमान करणे, एकूण कार्यप्रदर्शन ट्यून करणे आणि विशिष्ट ठिकाणी मुख्य कार्यक्षमता जोडणे सोपे होते.

वैशिष्ट्ये

आउट-ऑफ-प्रोसेस आर्किटेक्चर: दूत हा एक स्वयंपूर्ण, उच्च-कार्यक्षमता सर्व्हर आहे जो थोड्या प्रमाणात 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 इंटर्नल्स परिभाषित करते ज्यांना कॉन्फिगर करणे आवश्यक आहे.

कामगार कनेक्शन

खालील कॉन्फिगरेशन कामगार प्रक्रिया आणि कनेक्शनची संख्या निर्धारित करते. हे सूचित करते की मागणी पूर्ण करण्यासाठी एनजीआयएनएक्स कसे स्केल करेल.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy वेगवेगळ्या प्रकारे वर्कफ्लो आणि कनेक्शन व्यवस्थापित करते.

दूत प्रणालीमधील प्रत्येक हार्डवेअर थ्रेडसाठी वर्कर थ्रेड तयार करतो. प्रत्येक वर्कर थ्रेड नॉन-ब्लॉकिंग इव्हेंट लूप कार्यान्वित करतो ज्यासाठी जबाबदार आहे

प्रत्येक श्रोत्याचे ऐकणे
नवीन कनेक्शन स्वीकारत आहे
कनेक्शनसाठी फिल्टरचा संच तयार करणे
कनेक्शनच्या कार्यकाळात सर्व I/O ऑपरेशन्सवर प्रक्रिया करा.

पुढील सर्व कनेक्शन प्रक्रिया पूर्णपणे वर्कर थ्रेडमध्ये हाताळल्या जातात, कोणत्याही फॉरवर्डिंग वर्तनासह.

Envoy मधील प्रत्येक वर्कर थ्रेडसाठी, एक कनेक्शन पूल आहे. त्यामुळे 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 त्याच्या कॉन्फिगरेशनसाठी 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;
}

Envoy येथे, फिल्टर्स हे करतात.

दूत फिल्टर

स्थिर कॉन्फिगरेशनसाठी, येणार्‍या विनंत्यांची प्रक्रिया कशी करायची हे फिल्टर ठरवतात. या प्रकरणात आम्ही जुळणारे फिल्टर सेट करतो सर्व्हर_नावे मागील चरणात. जेव्हा येणार्‍या विनंत्या येतात ज्या विशिष्ट डोमेन आणि मार्गांशी जुळतात, तेव्हा रहदारी क्लस्टरकडे राउट केली जाते. हे 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;
  }

Envoy मध्ये, हे क्लस्टरद्वारे व्यवस्थापित केले जाते.

दूत क्लस्टर्स

अपस्ट्रीम समतुल्य क्लस्टर्स म्हणून परिभाषित केले आहे. या प्रकरणात, रहदारीची सेवा देणारे यजमान ओळखले गेले आहेत. यजमानांवर प्रवेश करण्याचा मार्ग, जसे की कालबाह्य, क्लस्टर कॉन्फिगरेशन म्हणून परिभाषित केले जाते. हे लेटन्सी आणि लोड बॅलन्सिंग सारख्या पैलूंवर अधिक बारीक नियंत्रण ठेवण्यास अनुमती देते.

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 पत्ता अपस्ट्रीम क्लस्टरमध्ये एक स्पष्ट होस्ट मानला जाईल. याचा अर्थ असा की जर विनंतीने दोन IP पत्ते परत केले, तर दूत असे गृहीत धरेल की क्लस्टरमध्ये दोन होस्ट आहेत आणि दोन्ही लोड संतुलित असणे आवश्यक आहे. परिणामातून होस्ट काढून टाकल्यास, दूत हे यापुढे अस्तित्वात नाही असे गृहीत धरेल आणि कोणत्याही विद्यमान कनेक्शन पूलमधून रहदारी खेचून घेईल.

अधिक माहितीसाठी पहा दूत प्रॉक्सी दस्तऐवजीकरण.

चरण 6 - लॉग ऍक्सेस आणि त्रुटी

अंतिम कॉन्फिगरेशन म्हणजे नोंदणी. त्रुटी लॉग डिस्कवर ढकलण्याऐवजी, Envoy Proxy क्लाउड-आधारित दृष्टीकोन घेते. सर्व अनुप्रयोग लॉग आउटपुट आहेत 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; सुरक्षितता सुधारण्यासाठी NGINX ला कमी-विशेषाधिकार प्राप्त वापरकर्ता म्हणून चालवण्यास निर्दिष्ट करते.

एन्वॉय प्रॉक्सी प्रक्रिया कोणाच्या मालकीची आहे हे व्यवस्थापित करण्यासाठी क्लाउड-आधारित दृष्टीकोन घेते. जेव्हा आम्ही कंटेनरद्वारे एन्वॉय प्रॉक्सी चालवतो, तेव्हा आम्ही कमी विशेषाधिकार असलेला वापरकर्ता निर्दिष्ट करू शकतो.

दूत प्रॉक्सी लाँच करत आहे

खालील कमांड होस्टवरील डॉकर कंटेनरद्वारे दूत प्रॉक्सी चालवेल. हा आदेश एंवॉयला पोर्ट 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

कोणत्या डॉकर कंटेनरने विनंतीवर प्रक्रिया केली हे दर्शविणारा प्रतिसाद तुम्हाला दिसला पाहिजे. एन्वॉय प्रॉक्सी लॉगमध्ये तुम्हाला ऍक्सेस स्ट्रिंग आउटपुट देखील दिसेल.

अतिरिक्त 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 मध्ये स्थलांतर