🥇 მიგრაცია Nginx-დან Envoy Proxy-ში

გამარჯობა, ჰაბრ! თქვენს ყურადღებას ვაქცევ პოსტის თარგმანს: მიგრაცია Nginx-დან Envoy Proxy-ში.

Envoy არის მაღალი ხარისხის განაწილებული პროქსი სერვერი (დაწერილი C++), რომელიც შექმნილია ინდივიდუალური სერვისებისა და აპლიკაციებისთვის, ის ასევე არის საკომუნიკაციო ავტობუსი და „უნივერსალური მონაცემთა თვითმფრინავი“, რომელიც შექმნილია დიდი მიკროსერვისის „მომსახურების ქსელის“ არქიტექტურებისთვის. მისი შექმნისას მხედველობაში მიიღეს პრობლემების გადაწყვეტილებები, რომლებიც წარმოიშვა სერვერების განვითარების დროს, როგორიცაა NGINX, HAProxy, ტექნიკის დატვირთვის ბალანსერები და ღრუბლოვანი დატვირთვის ბალანსერები. Envoy მუშაობს თითოეულ აპლიკაციასთან ერთად და აბსტრაქტებს ქსელს, რათა უზრუნველყოს საერთო ფუნქციონირება პლატფორმის მიუხედავად. როდესაც ინფრასტრუქტურის მთელი სერვისის ტრაფიკი მიედინება Envoy mesh-ში, ადვილი ხდება პრობლემური ტერიტორიების ვიზუალიზაცია თანმიმდევრული დაკვირვებით, დაარეგულიროთ საერთო შესრულება და დაემატოს ძირითადი ფუნქციები კონკრეტულ ადგილას.

შესაძლებლობები

პროცესის გარეშე არქიტექტურა: envoy არის დამოუკიდებელი, მაღალი ხარისხის სერვერი, რომელიც იკავებს RAM-ის მცირე რაოდენობას. ის მუშაობს ნებისმიერ აპლიკაციის ენასთან ან ჩარჩოსთან ერთად.
http/2 და grpc მხარდაჭერა: envoy-ს აქვს პირველი კლასის http/2 და grpc მხარდაჭერა შემომავალი და გამავალი კავშირებისთვის. ეს არის გამჭვირვალე პროქსი http/1.1-დან http/2-მდე.
გაფართოებული დატვირთვის ბალანსირება: envoy მხარს უჭერს დატვირთვის დაბალანსების გაფართოებულ ფუნქციებს, მათ შორის ავტომატური განმეორებითი ცდების, ჯაჭვის გაწყვეტის, გლობალური სიჩქარის შეზღუდვის, მოთხოვნის დაჩრდილვის, ლოკალური ზონის დატვირთვის დაბალანსებას და ა.შ.
კონფიგურაციის მართვის API: envoy უზრუნველყოფს მძლავრ 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-ზე და თქვენ არ გჭირდებათ ზოგიერთი პარამეტრის კონფიგურაცია. Envoy Proxy-ს აქვს ოთხი ძირითადი ტიპი, რომელიც მხარს უჭერს NGINX-ის მიერ შემოთავაზებულ ძირითად ინფრასტრუქტურას. ბირთვი არის:

მსმენელები: ისინი განსაზღვრავენ, თუ როგორ იღებს Envoy Proxy შემოსულ მოთხოვნებს. Envoy Proxy ამჟამად მხარს უჭერს მხოლოდ TCP-ზე დაფუძნებულ მსმენელს. კავშირის დამყარების შემდეგ, იგი გადაეცემა ფილტრების კომპლექტს დასამუშავებლად.
ფილტრები: ისინი მილსადენის არქიტექტურის ნაწილია, რომელსაც შეუძლია შემომავალი და გამავალი მონაცემების დამუშავება. ეს ფუნქცია მოიცავს ფილტრებს, როგორიცაა Gzip, რომელიც შეკუმშავს მონაცემებს კლიენტისთვის გაგზავნამდე.
მარშრუტიზატორები: ისინი აგზავნიან ტრაფიკს საჭირო დანიშნულების ადგილამდე, განსაზღვრული როგორც კლასტერი.
კლასტერები: ისინი განსაზღვრავენ საბოლოო წერტილს ტრაფიკისა და კონფიგურაციის პარამეტრებისთვის.

ჩვენ გამოვიყენებთ ამ ოთხ კომპონენტს Envoy Proxy-ის კონფიგურაციის შესაქმნელად, რომელიც შეესაბამება კონკრეტულ NGINX კონფიგურაციას. Envoy-ის მიზანია API-ებთან მუშაობა და დინამიური კონფიგურაცია. ამ შემთხვევაში, საბაზისო კონფიგურაცია გამოიყენებს სტატიკური, მყარი კოდირებულ პარამეტრებს NGINX-ისგან.

ნაბიჯი 2 - NGINX კონფიგურაცია

პირველი ნაწილი nginx.conf განსაზღვრავს ზოგიერთ NGINX ინტერიერს, რომელიც საჭიროებს კონფიგურაციას.

მუშათა კავშირები

ქვემოთ მოცემული კონფიგურაცია განსაზღვრავს მუშათა პროცესებისა და კავშირების რაოდენობას. ეს მიუთითებს იმაზე, თუ როგორ გაიზრდება NGINX მოთხოვნის დასაკმაყოფილებლად.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy მართავს სამუშაო პროცესებსა და კავშირებს სხვადასხვა გზით.

Envoy ქმნის მუშა ძაფს სისტემის თითოეული ტექნიკის ძაფისთვის. თითოეული მუშა თემა ახორციელებს არადაბლოკვის ღონისძიების ციკლს, რომელიც პასუხისმგებელია

თითოეული მსმენელის მოსმენა
ახალი კავშირების მიღება
ფილტრების ნაკრების შექმნა კავშირისთვის
დაამუშავეთ ყველა I/O ოპერაცია კავშირის მთელი პერიოდის განმავლობაში.

ყველა შემდგომი კავშირის დამუშავება მთლიანად მუშავდება მუშა ძაფში, ნებისმიერი გადამისამართების ქცევის ჩათვლით.

Envoy-ში თითოეული მუშა ძაფისთვის არის კავშირის აუზი. ასე რომ, HTTP/2 კავშირის აუზი ამყარებს მხოლოდ ერთ კავშირს გარე ჰოსტზე ერთდროულად, თუ ოთხი მუშა თემა იქნება, იქნება ოთხი HTTP/2 კავშირი თითო გარე ჰოსტზე სტაბილურ მდგომარეობაში. ყველაფრის ერთ მუშა ძაფში შენახვით, თითქმის ყველა კოდი შეიძლება დაიწეროს დაბლოკვის გარეშე, თითქოს ერთი ნაკადი იყოს. თუ მეტი მუშა ძაფები გამოიყოფა, ვიდრე საჭიროა, ამან შეიძლება გამოიწვიოს მეხსიერების გაფუჭება, შექმნას უმოქმედო კავშირების დიდი რაოდენობა და შეამციროს კავშირების აუზში დაბრუნების რაოდენობა.

დამატებითი ინფორმაციისთვის ეწვიეთ Envoy Proxy ბლოგი.

HTTP კონფიგურაცია

შემდეგი NGINX კონფიგურაციის ბლოკი განსაზღვრავს HTTP პარამეტრებს, როგორიცაა:

რა მიმების ტიპებია მხარდაჭერილი
ნაგულისხმევი ვადები
Gzip კონფიგურაცია

ამ ასპექტების მორგება შეგიძლიათ Envoy Proxy-ის ფილტრების გამოყენებით, რომელზეც მოგვიანებით განვიხილავთ.

ნაბიჯი 3 - სერვერის კონფიგურაცია

HTTP კონფიგურაციის ბლოკში, NGINX კონფიგურაცია განსაზღვრავს მოსმენას 8080 პორტზე და უპასუხოს შემომავალ მოთხოვნებს დომენებისთვის. one.example.com и www.one.example.com.

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

Envoy-ის შიგნით, მას აკონტროლებენ მსმენელები.

დესპანი მსმენელები

Envoy Proxy-ის დაწყების ყველაზე მნიშვნელოვანი ასპექტია თქვენი მსმენელის განსაზღვრა. თქვენ უნდა შექმნათ კონფიგურაციის ფაილი, რომელიც აღწერს, თუ როგორ გსურთ Envoy ინსტანციის გაშვება.

ქვემოთ მოცემული ფრაგმენტი შექმნის ახალ მსმენელს და დააკავშირებს მას 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-ში, მდებარეობის ბლოკი განსაზღვრავს, თუ როგორ უნდა დამუშავდეს და სად გაატაროს ტრაფიკი. შემდეგ ფრაგმენტში, საიტის მთელი ტრაფიკი გადადის ზემოთ დინებაში (მთარგმნელის შენიშვნა: upstream ჩვეულებრივ აპლიკაციის სერვერია) კლასტერში სახელად targetCluster. ზედა ნაკადის კლასტერი განსაზღვრავს კვანძებს, რომლებმაც უნდა დაამუშაონ მოთხოვნა. ამაზე განვიხილავთ შემდეგ ეტაპზე.

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

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

Envoy-ში ამას Filters აკეთებს.

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

სახელი დესპანი.http_connection_manager არის ჩაშენებული ფილტრი Envoy Proxy-ში. სხვა ფილტრები მოიცავს Redis, Mongo, TCP. სრული სია შეგიძლიათ ნახოთ აქ დოკუმენტაცია.

დამატებითი ინფორმაციისთვის დატვირთვის დაბალანსების სხვა პოლიტიკის შესახებ ეწვიეთ დესპანის დოკუმენტაცია.

ნაბიჯი 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 Envoy განუწყვეტლივ და ასინქრონულად გადაწყვეტს მითითებულ DNS მიზნებს. თითოეული დაბრუნებული IP მისამართი DNS შედეგიდან ჩაითვლება აშკარა ჰოსტად ზედა ნაკადის კლასტერში. ეს ნიშნავს, რომ თუ მოთხოვნა დააბრუნებს ორ IP მისამართს, Envoy ჩათვლის, რომ კლასტერში ორი ჰოსტია და ორივე უნდა იყოს დაბალანსებული. თუ ჰოსტი ამოღებულია შედეგიდან, Envoy ჩათვლის, რომ ის აღარ არსებობს და ამოიღებს ტრაფიკს ნებისმიერი არსებული კავშირის აუზებიდან.

დამატებითი ინფორმაციისათვის იხ დესპანის მარიონეტული დოკუმენტაცია.

ნაბიჯი 6 - ჟურნალის წვდომა და შეცდომები

საბოლოო კონფიგურაცია არის რეგისტრაცია. იმის ნაცვლად, რომ შეცდომების ჟურნალი დისკზე გადაიტანოს, Envoy Proxy იყენებს ღრუბელზე დაფუძნებულ მიდგომას. ყველა განაცხადის ჟურნალი გამომავალია მკაცრი и უფროსი.

როდესაც მომხმარებლები აკეთებენ მოთხოვნას, წვდომის ჟურნალები არჩევითია და ნაგულისხმევად გამორთულია. HTTP მოთხოვნებისთვის წვდომის ჟურნალების ჩასართავად, ჩართეთ კონფიგურაცია შესვლის_ლოგი HTTP კავშირის მენეჯერისთვის. ბილიკი შეიძლება იყოს ისეთი მოწყობილობა, როგორიცაა მკაცრი, ან ფაილი დისკზე, თქვენი მოთხოვნებიდან გამომდინარე.

შემდეგი კონფიგურაცია გადამისამართებს წვდომის ყველა ჟურნალს მკაცრი (მთარგმნელის შენიშვნა - stdout საჭიროა დოკერის შიგნით envoy-ის გამოსაყენებლად. თუ გამოიყენება დოკერის გარეშე, მაშინ შეცვალეთ /dev/stdout ჩვეულებრივი log ფაილის გეზით). დააკოპირეთ ფრაგმენტი კავშირის მენეჯერის კონფიგურაციის განყოფილებაში:

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 ფორმატში ველის დაყენებით 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-ში. ბოლო ნაბიჯი არის Envoy Proxy ინსტანციის გაშვება მის შესამოწმებლად.

გაუშვით როგორც მომხმარებელი

NGINX კონფიგურაციის ხაზის ზედა ნაწილში მომხმარებელი www www; განსაზღვრავს NGINX-ის გაშვებას, როგორც დაბალი პრივილეგირებულ მომხმარებელს უსაფრთხოების გასაუმჯობესებლად.

Envoy Proxy იყენებს ღრუბელზე დაფუძნებულ მიდგომას იმის მართვისთვის, თუ ვინ ფლობს პროცესს. როდესაც ჩვენ ვატარებთ Envoy Proxy-ს კონტეინერში, ჩვენ შეგვიძლია მიუთითოთ დაბალი პრივილეგირებული მომხმარებელი.

Envoy Proxy-ის გაშვება

ქვემოთ მოყვანილი ბრძანება გაუშვებს Envoy Proxy-ს ჰოსტის Docker კონტეინერში. ეს ბრძანება აძლევს 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 Proxy-ს არ აქვს მოთხოვნისთვის ხელმისაწვდომი მიმართულებები. შემდეგი ბრძანება დაიწყებს HTTP სერვისების სერიას, რომელიც ემთხვევა Envoy-სთვის განსაზღვრულ კონფიგურაციას.

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

ხელმისაწვდომი სერვისებით, Envoy-ს შეუძლია წარმატებით მოახდინოს მარიონეტული ტრაფიკი დანიშნულების ადგილზე.

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

თქვენ უნდა ნახოთ პასუხი, რომელიც მიუთითებს, რომელ Docker კონტეინერმა დაამუშავა მოთხოვნა. 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 }

დამატებითი ინფორმაცია მთარგმნელისგან

Envoy Proxy-ის დაყენების ინსტრუქცია შეგიძლიათ იხილოთ ვებგვერდზე 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

Envoy Proxy-ს არ აქვს სტატიკური კონტენტის სერვისის მხარდაჭერა. ამიტომ, ვის შეუძლია ხმა მისცეს ფუნქციას: https://github.com/envoyproxy/envoy/issues/378

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

ამ პოსტმა მოგანიჭათ, დააინსტალიროთ და გამოსცადოთ envoy proxy?

დიახ
არარის

მისცა ხმა 75 მომხმარებელმა. 18-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com

მიგრაცია Nginx-დან Envoy Proxy-ში