🥇Migrācija no Nginx uz Envoy Proxy

Sveiki, Habr! Piedāvāju jūsu uzmanībai tulkojumu ierakstam: Migrācija no Nginx uz Envoy Proxy.

Envoy ir augstas veiktspējas izplatīts starpniekserveris (rakstīts C++), kas paredzēts atsevišķiem pakalpojumiem un lietojumprogrammām. Tas arī kalpo kā komunikāciju autobuss un "universālais datu plāns", izstrādāts lielām mikroservisu arhitektūrām "service mesh". Tā izstrādē tika ņemtas vērā problēmas, kas radās, izstrādājot tādus serverus kā NGINX, HAProxy, aparatūras slodzes balansētājus un mākoņu slodzes balansētājus. Envoy darbojas kopā ar katru lietojumprogrammu un abstrahē tīklu, nodrošinot kopīgas funkcijas neatkarīgi no platformas. Kad viss pakalpojumu satiksmes plūsmas infrastruktūrā plūst caur Envoy tīklu, kļūst viegli vizualizēt problēmu jomas, izmantojot saskaņotu uzraudzību, konfigurējot kopējo veiktspēju un pievienojot pamata funkcijas konkrētā vietā.

Iespējas

Ārpus procesa arhitektūra: Envoy ir autonoms, augstas veiktspējas serveris, kas izmanto nelielu operatīvo atmiņu. Tas darbojas kopā ar jebkuru lietojumprogrammas valodu vai ietvaru.
Http/2 un grpc atbalsts: Envoy piedāvā izcilu http/2 un grpc atbalstu ienākošajām un izejošajām savienojumiem. Tas ir caurspīdīgs starpniekserveris no http/1.1 uz http/2.
Paplašināta slodzes balansēšana: Envoy atbalsta paplašinātas slodzes balansēšanas funkcijas, tostarp automātiskas atkārtotas mēģināšanas, ķēdes pārtraukšanu, globālās ātruma ierobežojuma noteikšanu, pieprasījumu ēnošanu, vietējo zonas slodzes balansēšanu utt.
Konfigurācijas vadības API: Envoy nodrošina uzticamu API dinamiskai tās konfigurācijas pārvaldībai.
Uzraudzība: padziļināta L7 satiksmes uzraudzība, iebūvēta atbalsts sadalītai izsekošanai un uzraudzībai mongodb, dynamodb un daudzām citām lietojumprogrammām.

1. solis — NGINX konfigurācijas piemērs

Šajā scenārijā tiek izmantota speciāli izveidota faili nginx.conf, balstoties uz pilnu piemēru no NGINX Wiki. Jūs varat apskatīt konfigurāciju redaktorā, atverot nginx.conf

Sākotnējā nginx konfigurācija

lietotājs  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 konfigurācija parasti sastāv no trim galvenajiem elementiem:

NGINX servera iestatījums, žurnālu struktūra un Gzip funkcionalitāte. Tas tiek noteikts globāli visos gadījumos.
NGINX iestatījums, lai pieņemtu pieprasījumus uz host one.example.com uz portu 8080.
Mērķa atrašanās vietas iestatījums, kā apstrādāt datplūsmu dažādām URL daļām.

Ne visi iestatījumi tiks piemēroti Envoy Proxy, un jums nav jāiestata daži parametri. Envoy Proxy atbalsta četru galveno veidu, kas nodrošina NGINX piedāvāto pamata infrastruktūru. Šīs pamatelementi ir:

Listeneri: Tie nosaka, kā Envoy Proxy pieņem ienākošos pieprasījumus. Pašlaik Envoy Proxy atbalsta tikai TCP bāzes listenerus. Tiklīdz savienojums ir izveidots, tas tiek nodots filtrēšanas kopai apstrādei.
Filtri: Tie ir konveijera arhitektūras daļa, kas var apstrādāt ienākošos un izejošos datus. Šī funkcionalitāte ietver filtrus, piemēram, Gzip, kas saspiest datus pirms to nosūtīšanas klientam.
Maršrutētāji: Tie novirza datplūsmu uz prasīto galamērķi, ko nosaka kā klasteris.
Klasteri: Tie nosaka galapunktu datplūsmā un konfigurācijas parametrus.

Mēs izmantosim šos četrus komponentus, lai izveidotu Envoy Proxy konfigurāciju, kas atbilst noteiktajai NGINX konfigurācijai. Envoy mērķis ir darboties ar API un dinamiski konfigurēties. Šajā gadījumā pamata konfigurācija izmantos statiskus, stingri noteiktus parametrus no NGINX.

2. solis — NGINX konfigurācija

Pirma daļa nginx.conf nosaka dažas iekšējās NGINX komponentes, kas jāiestata.

Worker Connections (Darba savienojumi)

Zemāk sniegtā konfigurācija nosaka darba procesu un savienojumu skaitu. Tas norāda, kā NGINX tiks skalots, lai apmierinātu pieprasījumu.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy atšķirīgi pārvalda darba procesus un savienojumus.

Envoy rada darba pavedienu katram aparatūras pavedienam sistēmā. Katrs darba pavediena veic nebloķētu notikumu ciklu, kas ir atbildīgs par

Katra klausītāja (listener) uzklausīšana
Jaunu pieslēgumu pieņemšana
Filtru kopas izveide savienojumam
Visu ievades/izvades operāciju apstrāde savienojuma pastāvēšanas laikā.

Visu turpmāko savienojuma apstrādi pilnībā veic darba pavedienā, tostarp to, kā tiek veikta pāradresācija.

Katram darba pavedienam Envoy ir savienojums pētījumā. Tādējādi HTTP/2 savienojumu grupas izveido tikai vienu savienojumu attiecībā uz katru ārējo hostu, ja ir četri darba pavedieni, stabilas valsts laikā tiks pieci HTTP/2 savienojumi katram ārējam hostam. Saglabājot visu vienā darba pavedienā, gandrīz visu kodu var rakstīt bez bloķēšanas, kā tas būtu vienpavediena režīmā. Ja tiek pieallocated vairāk darba pavedienu, nekā nepieciešams, tas var novest pie neracionālas atmiņas izmantošanas, daudz nevajadzīgu savienojumu izveidošanas un samazinātas savienojumu atgriešanas skaita atpakaļ pētījumā.

Lai iegūtu papildinformāciju, apmeklējiet Envoy Proxy blogs.

HTTP konfigurācija

Nākamais NGINX konfigurācijas bloks nosaka HTTP iestatījumus, piemēram:

Kādi MIME tipi tiek atbalstīti
Ieslēgšanas laiki pēc noklusējuma
Gzip konfigurācija

Jūs varat konfigurēt šos aspektus, izmantojot filtrus Envoy Proxy, par ko mēs runāsim vēlāk.

3. solis — Servera konfigurācija

HTTP konfigurācijas blokā NGINX konfigurācija norāda klausīties portu 8080 un atbildēt uz ienākošiem pieprasījumiem domēniem one.example.com un www.one.example.com.

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

Iekšējo Envoy to pārvalda klausītāji.

Envoy klausītāji

Visnozīmīgākais aspekts, uzsākot darbu ar Envoy Proxy, ir klausītāju definēšana. Jums ir jāizveido konfigurācijas fails, kas apraksta, kā vēlaties palaist Envoy instance.

Apmeklējot zem esošo fragmentu, tiks izveidots jauns klausītājs, kas tiks saistīts ar portu 8080. Konfigurācija norāda Envoy Proxy, kuriem portiem tas jābūt piesaistītam ienākošajiem pieprasījumiem.

Envoy Proxy izmanto YAML notāciju savai konfigurācijai. Lai iepazītos ar šo notāciju, skatiet šeit. saites.

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

Nav nepieciešams definēt server_name, jo Envoy Proxy filtri ar to tiks galā.

4. solis — Vietas konfigurācija

Kad pieprasījums nonāk NGINX, vietas blokam ir jānosaka, kā apstrādāt un uz kurieni novirzīt trafiku. Zemāk esošajā fragmentā viss trafiks uz vietni tiek nodots upstream (piezīme tulkotājam: upstream — parasti tas ir lietojumserveru) klasterim ar nosaukumu targetCluster. Upstream klasteris nosaka mezglus, kuriem jāapstrādā pieprasījums. Mēs to apspriedīsim nākamajā solī.

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

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

To Envoy veic filtri.

Envoy Filters

Statiskai konfigurācijai filtri nosaka, kā apstrādāt ienākošos pieprasījumus. Šajā gadījumā mēs iestatām filtrus, kas atbilst server_names iepriekšējā solī. Kad ienākošie pieprasījumi, kas atbilst noteiktiem domēniem un maršrutiem, nonāk pieprasījumos, trafiks tiek novirzīts uz klasteri. Tas ir ekvivalents NGINX augšējai konfigurācijai.

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

Vārds envoy.http_connection_manager ir iebūvēts filtrs Envoy Proxy. Citi filtri ir Redis, Mongo, TCP. Varat atrast pilnu sarakstu dokumentācijā.

Lai iegūtu papildu informāciju par citām slodzes līdzsvarošanas politikām, apmeklējiet Envoy dokumentāciju.

5. solis — Proxija un upstream konfigurācija

NGINX upstream konfigurācija nosaka mērķa serveru grupu, kas apstrādās trafiku. Šajā gadījumā tika norādīti divi klasteri.

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

To Envoy pārvalda klasteri.

Envoy Clusters

Upstream ekvivalents tiek noteikts kā klasteri. Šajā gadījumā tika definēti hosti, kas apkalpos satiksmi. Piekļuves metode hostiem, piemēram, gaidīšanas laiks, tiek definēta kā klastera konfigurācija. Tas ļauj precīzāk kontrolēt tādus aspektus kā gaidīšanas laiks un slodzes sadale.

Copy to Editor  klasteri:
  - 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 }}
    ]

Izmantojot pakalpojumu atklāšanu STRICT_DNS Envoy nepārtraukti un asinkroni izšķirs noteiktās DNS mērķus. Katrs atgrieztais IP adrese rezultātā DNS tiks uzskatīta par skaidru hostu augšupējā klasterī. Tas nozīmē, ka, ja pieprasījums atgriež divas IP adreses, Envoy pieņems, ka klasterī ir divi hosti, un abi jānodrošina ar slodzes sadali. Ja hosts tiek izņemts no rezultāta, Envoy pieņem, ka tas vairs nepastāv, un izvēlēsies satiksmi no jebkuriem esošajiem savienojumu baseiniem.

Papildu informācijai skatiet. Envoy proxy dokumentāciju..

Soliet 6 — Piekļuve žurnālam un kļūdām.

Galīgā konfigurācija — reģistrācija. Tā vietā, lai nodotu kļūdu žurnālus diskā, Envoy Proxy izmanto mākoņa pieeju. Visi lietojumprogrammu žurnāli tiek izvadīti stdout un stderr.

Kad lietotāji veic pieprasījumus, piekļuves žurnāli ir nepiespiesti un pēc noklusējuma ir atslēgti. Lai ieslēgtu piekļuves žurnālus HTTP pieprasījumiem, aktivizējiet konfigurāciju. access_log HTTP savienotāja vadītājam. Ceļš var būt vai nu ierīce, piemēram, stdout, vai fails diskā, atkarībā no jūsu prasībām.

Nākamā konfigurācija novirzīs visus piekļuves žurnālus uz stdout (piezīme tulkotājam — stdout ir nepieciešams, lai izmantotu envoy iekšā docker. Ja izmantot bez docker, tad aizstājiet \/dev\/stdout ar parastā žurnāla faila ceļu). Nokopējiet fragmentu uz savienotāju vadītāja konfigurācijas sadaļu:

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

Rezultātiem vajadzētu izskatīties šādi:

      - 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:

Pēc noklusējuma Envoy ir formāta rinda, kas ietver HTTP pieprasījuma detaļas:

[%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

Šīs rindas formāta rezultāts:

[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"

Izvadīšanas saturu var konfigurēt, iestādot formāta lauku. Piemēram:

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"

Žurnāla rindu var arī izvadīt JSON formātā, iestādot lauku json_format. Piemēram:

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

Lai iegūtu papildinformāciju par nosūtītāja žurnālfiksācijas metodēm, apmeklējiet

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

Žurnālfiksācija nav vienīgais veids, kā iegūt priekšstatu par Envoy Proxy darbību. Tajā ir iebūvētas uzlabotas izsekošanas un metrikas iespējas. Jūs varat uzzināt vairāk izsekošanas dokumentācijā vai caur Interaktīvā izsekošanas skripta.

7. solis — Palaišana

Tagad esat pārcēlis konfigurāciju no NGINX uz Envoy Proxy. Pēdējais solis ir palaist Envoy Proxy instanci, lai to pārbaudītu.

Palaist no lietotāja

NGINX konfigurācijas augšdaļā rinda user www www; norāda, ka NGINX tiek palaists kā zemu privilēģiju lietotājs, lai uzlabotu drošību.

Envoy Proxy izmanto mākoņus, lai pārvaldītu to, kurš ir procesa īpašnieks. Kad mēs palaistam Envoy Proxy caur tvertni, mēs varam norādīt zemu privilēģiju lietotāju.

Palaist Envoy Proxy

Apskatītā komanda palaidīs Envoy Proxy caur Docker tvertni uz hosta. Šī komanda ļauj Envoy klausīties ienākošās pieprasījumu caur 80. portu. Tomēr, kā norādīts klausītāja konfigurācijā, Envoy Proxy klausās ienākošo datu plūsmu caur 8080. portu. Tas ļauj procesam darboties kā zemu privilēģiju lietotājam.

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

Testēšana

Ar palaistu proxy tagad var veikt un apstrādāt testus. Nākamā cURL komanda nosūta pieprasījumu ar gala nosaukumu, kas norādīts proxy konfigurācijā.

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

HTTP pieprasījums radīs kļūdu 503Tas ir saistīts ar to, ka izejošie savienojumi nedarbojas un tie nav pieejami. Tādējādi Envoy Proxy nav pieejamu galamērķu, uz kuriem nosūtīt pieprasījumu. Nākamā komanda uzsāks sēriju HTTP pakalpojumu, kas atbilst konfigurācijai, kas noteikta Envoy.

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

Ar pieejamajām pakalpojumiem Envoy var veiksmīgi nosūtīt trafiku uz galamērķi.

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

Jums vajadzētu redzēt atbildi, kas norāda, kurš Docker konteiners apstrādāja pieprasījumu. Envoy Proxy žurnālos jums arī vajadzētu redzēt izdrukošanas piekļuves rindu.

Papildu HTTP atbildes virsraksti (HTTP Response)

Jūs redzēsiet papildu HTTP virsrakstus derīgā pieprasījuma atbildē. Virsrakstā ir norādīts laiks, kas pārstāvošajam hostam tika pavadīts pieprasījuma apstrādei. Tas tiek izteikts milisekundēs. Tas ir noderīgi, ja klients vēlas noteikt apkalpošanas laiku salīdzinājumā ar tīkla kavējumu.

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

Kopsavilkuma konfigurācija

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 }

Papildu informācija no tulkotāja

Instrukcijas par Envoy Proxy uzstādīšanu var atrast mājaslapā https://www.getenvoy.io/

Noklusējuma rpm nav iekļauts systemd pakalpojuma konfigurācija.

Pievienojiet systemd pakalpojuma konfigurāciju \/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

Jums jāizveido direktorija \/etc\/envoy\/ un jāievieto tajā konfigurācija config.yaml.

Par envoy proxy ir Telegram čats: https://t.me/envoyproxy_ru

Envoy Proxy nav atbalsta statisko saturu piegādē. Tāpēc, lūdzu, balsot par funkciju: https://github.com/envoyproxy/envoy/issues/378

Tikai reģistrētie lietotāji var piedalīties aptaujā. Pieteikties, lūdzu.

Vai šis ziņojums jūs mudināja instalēt un izmēģināt envoy proxy?

Balsojuši 75 lietotāji. Atturējušies 18 lietotāji.

Avots: habr.com