🥇 Perėjimas iš Nginx į Envoy Proxy

Sveiki, Habr! Atkreipiu jūsų dėmesį į įrašo vertimą: Perėjimas iš Nginx į Envoy Proxy.

„Envoy“ yra didelio našumo paskirstytasis tarpinis serveris (parašytas C++ kalba), sukurtas individualioms paslaugoms ir programoms, taip pat yra ryšio magistralė ir „universali duomenų plokštuma“, skirta didelėms mikroservisų „service mesh“ architektūroms. Kuriant jį buvo atsižvelgta į problemų sprendimus, iškilusius kuriant serverius, tokius kaip NGINX, HAProxy, aparatinės įrangos apkrovos balansavimo ir debesies apkrovos balansavimo priemones. „Envoy“ veikia kartu su kiekviena programa ir abstrahuoja tinklą, kad užtikrintų bendras funkcijas, nepaisant platformos. Kai visas paslaugų srautas infrastruktūroje teka per Envoy tinklelį, tampa lengva vizualizuoti problemines sritis su nuosekliu stebėjimu, suderinti bendrą našumą ir pridėti pagrindines funkcijas konkrečioje vietoje.

galimybės

Neapdorota architektūra: pasiuntinys yra savarankiškas, didelio našumo serveris, užimantis nedidelį kiekį RAM. Jis veikia kartu su bet kuria programos kalba ar sistema.
http/2 ir grpc palaikymas: pasiuntinys turi pirmos klasės http/2 ir grpc palaikymą įeinantiems ir išeinantiems ryšiams. Tai skaidrus tarpinis serveris nuo http/1.1 iki http/2.
Išplėstinis apkrovos balansavimas: pasiuntinys palaiko pažangias apkrovos balansavimo funkcijas, įskaitant automatinius pakartotinius bandymus, grandinės nutraukimą, visuotinį greičio ribojimą, užklausų šešėliavimą, vietinės zonos apkrovos balansavimą ir kt.
Konfigūracijos valdymo API: pasiuntinys teikia patikimą API, skirtą dinamiškai valdyti jūsų konfigūraciją.
Stebimumas: gilus L7 srauto stebėjimas, vietinis paskirstyto sekimo palaikymas ir mongodb, dynamodb ir daugelio kitų programų stebėjimas.

1 veiksmas – NGINX konfigūracijos pavyzdys

Šis scenarijus naudoja specialiai sukurtą failą nginx.conf, remiantis visu pavyzdžiu iš NGINX Wiki. Konfigūraciją galite peržiūrėti redaktoriuje atidarę nginx.conf

nginx šaltinio konfigūracija

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 konfigūracijos paprastai turi tris pagrindinius elementus:

NGINX serverio, žurnalo struktūros ir Gzip funkcijų konfigūravimas. Visais atvejais tai apibrėžiama globaliai.
NGINX konfigūravimas priimti užklausas pagrindiniam kompiuteriui one.example.com prie 8080 prievado.
Tikslinės vietos nustatymas, kaip tvarkyti srautą skirtingose URL dalyse.

Ne visa konfigūracija bus taikoma „Envoy Proxy“ ir jums nereikia konfigūruoti kai kurių nustatymų. „Envoy Proxy“ turi keturi pagrindiniai tipai, kurie palaiko pagrindinę NGINX siūlomą infrastruktūrą. Šerdis yra:

Klausytojai: Jie nustato, kaip „Envoy Proxy“ priima gaunamas užklausas. „Envoy Proxy“ šiuo metu palaiko tik TCP pagrįstus klausytojus. Užmezgus ryšį, jis perduodamas apdoroti filtrų rinkiniui.
Filtrai: Jie yra dujotiekio architektūros, galinčios apdoroti gaunamus ir išeinančius duomenis, dalis. Ši funkcija apima filtrus, tokius kaip Gzip, kuris suglaudina duomenis prieš siųsdamas juos klientui.
Maršrutizatoriai: Jie nukreipia srautą į reikiamą tikslą, apibrėžtą kaip klasterį.
Klasteriai: Jie apibrėžia srauto ir konfigūracijos parametrų galutinį tašką.

Naudosime šiuos keturis komponentus, kad sukurtume „Envoy Proxy“ konfigūraciją, kuri atitiktų konkrečią NGINX konfigūraciją. Pasiuntinio tikslas – dirbti su API ir dinamine konfigūracija. Tokiu atveju pagrindinė konfigūracija naudos statinius, užkoduotus NGINX nustatymus.

2 veiksmas – NGINX konfigūracija

Pirmoji dalis nginx.conf apibrėžia kai kuriuos NGINX vidinius elementus, kuriuos reikia sukonfigūruoti.

Darbuotojų ryšiai

Toliau pateikta konfigūracija nustato darbuotojo procesų ir ryšių skaičių. Tai rodo, kaip NGINX mastelis, kad atitiktų paklausą.

worker_processes  2;

events {
  worker_connections   2000;
}

„Envoy Proxy“ įvairiais būdais valdo darbo eigas ir ryšius.

Pasiuntinys sukuria darbuotojo giją kiekvienai sistemos aparatinės įrangos gijai. Kiekviena darbuotojo gija vykdo neblokuojančią įvykio kilpą, kuri yra atsakinga už

Klausytis kiekvieno klausytojo
Naujų ryšių priėmimas
Filtrų rinkinio kūrimas ryšiui
Apdorokite visas įvesties / išvesties operacijas per ryšio veikimo laiką.

Visas tolesnis ryšio apdorojimas yra visiškai tvarkomas darbuotojo gijoje, įskaitant bet kokią persiuntimo veiklą.

Kiekvienai darbuotojo gijai programoje Envoy yra jungčių telkinys. Taigi HTTP/2 ryšio telkiniai vienu metu sukuria tik vieną ryšį vienam išoriniam pagrindiniam kompiuteriui, jei yra keturios darbuotojo gijos, kiekviename išoriniame pagrindiniame kompiuteryje bus keturios stabilios būsenos HTTP/2 jungtys. Viską laikant vienoje darbo gijoje, beveik visas kodas gali būti parašytas neužblokuojant, tarsi jis būtų viena gija. Jei paskirstoma daugiau darbininkų gijų, nei reikia, gali būti švaistoma atmintis, sukuriama daug neaktyvių jungčių ir sumažės jungčių grąžinimo į telkinį skaičius.

Norėdami gauti daugiau informacijos, apsilankykite „Envoy Proxy“ tinklaraštis.

HTTP konfigūracija

Šis NGINX konfigūracijos blokas apibrėžia HTTP nustatymus, tokius kaip:

Kokie mime tipai palaikomi
Numatytasis skirtasis laikas
Gzip konfigūracija

Šiuos aspektus galite tinkinti naudodami Envoy Proxy filtrus, kuriuos aptarsime vėliau.

3 veiksmas – serverio konfigūracija

HTTP konfigūracijos bloke NGINX konfigūracija nurodo klausytis prievado 8080 ir atsakyti į gaunamas užklausas dėl domenų one.example.com и www.one.example.com.

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

„Envoy“ viduje jį valdo klausytojai.

Pasiuntiniai klausytojai

Svarbiausias aspektas pradedant naudotis Envoy Proxy yra klausytojų apibūdinimas. Turite sukurti konfigūracijos failą, kuriame aprašoma, kaip norite paleisti Envoy egzempliorių.

Toliau pateiktas fragmentas sukurs naują klausytoją ir susies jį su 8080 prievadu. Konfigūracija nurodo įgaliotiniam pasiuntiniui, su kuriais prievadais jis turi susieti gaunamas užklausas.

„Envoy Proxy“ konfigūravimui naudoja YAML žymėjimą. Įvadą į šį žymėjimą rasite čia nuoroda.

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

Nereikia apibrėžti serverio pavadinimas, nes tai atliks Envoy Proxy filtrai.

4 veiksmas – vietos konfigūracija

Kai užklausa patenka į NGINX, vietos blokas nustato, kaip apdoroti ir kur nukreipti srautą. Šiame fragmente visas srautas į svetainę perkeliamas į aukštesnę (vertėjo pastaba: prieš srovę paprastai yra programų serveris) klasterį, pavadintą targetCluster. Prieš srovę esantis klasteris apibrėžia mazgus, kurie turėtų apdoroti užklausą. Tai aptarsime kitame žingsnyje.

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

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

Pasiuntinyje tai daro filtrai.

Pasiuntinių filtrai

Statinės konfigūracijos filtrai nustato, kaip apdoroti gaunamas užklausas. Šiuo atveju nustatome atitinkančius filtrus serverio_pavadinimai ankstesniame žingsnyje. Kai gaunamos užklausos, atitinkančios tam tikrus domenus ir maršrutus, srautas nukreipiamas į klasterį. Tai prilygsta NGINX konfigūracijai iš apačios į viršų.

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

pavadinimas pasiuntinys.http_ryšio_vadybininkas yra „Envoy Proxy“ įtaisytas filtras. Kiti filtrai apima Redis, mongo, TCP. Visą sąrašą galite rasti adresu dokumentacija.

Norėdami gauti daugiau informacijos apie kitas apkrovos balansavimo taisykles, apsilankykite Pasiuntinio dokumentacija.

5 veiksmas – tarpinio serverio ir prieš srovę konfigūravimas

NGINX konfigūracija apibrėžia tikslinių serverių rinkinį, kuris apdoros srautą. Šiuo atveju buvo priskirti du klasteriai.

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

„Envoy“ tai valdo klasteriai.

Pasiuntinių klasteriai

Prieš srovę esantis ekvivalentas apibrėžiamas kaip klasteriai. Šiuo atveju buvo nustatyti prieglobos, kurios aptarnaus srautą. Prieigos prieglobos būdas, pvz., skirtasis laikas, yra apibrėžiamas kaip klasterio konfigūracija. Tai leidžia detaliau valdyti tokius aspektus kaip delsa ir apkrovos balansavimas.

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

Kai naudojate paslaugų aptikimą STRICT_DNS Pasiuntinys nuolat ir asinchroniškai išspręs nurodytus DNS tikslus. Kiekvienas grąžintas IP adresas iš DNS rezultato bus laikomas aiškiu pagrindiniu kompiuteriu priešsrautiniame klasteryje. Tai reiškia, kad jei užklausoje pateikiami du IP adresai, pasiuntinys manys, kad klasteryje yra du pagrindiniai kompiuteriai ir abu turi būti subalansuoti. Jei priegloba pašalinama iš rezultato, pasiuntinys manys, kad jo nebėra, ir ištrauks srautą iš bet kokių esamų ryšių telkinių.

Daugiau informacijos žr Pasiuntinio įgaliotinio dokumentai.

6 veiksmas – prieiga prie žurnalo ir klaidos

Galutinė konfigūracija yra registracija. Užuot siuntęs klaidų žurnalus į diską, „Envoy Proxy“ imasi debesies metodo. Visi programų žurnalai išvedami į stdout и stderr.

Kai vartotojai pateikia užklausą, prieigos žurnalai yra neprivalomi ir pagal numatytuosius nustatymus išjungti. Norėdami įjungti HTTP užklausų prieigos žurnalus, įgalinkite konfigūraciją prieigos_žurnalas skirtas HTTP ryšio tvarkyklei. Kelias gali būti arba įrenginys, pvz stdout, arba failą diske, atsižvelgiant į jūsų poreikius.

Ši konfigūracija nukreips visus prieigos žurnalus į stdout (vertėjo pastaba – stdout reikalingas norint naudoti envoy inside docker. Jei naudojamas be dockerio, pakeiskite /dev/stdout keliu į įprastą žurnalo failą). Nukopijuokite fragmentą į ryšio tvarkyklės konfigūracijos skyrių:

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

Rezultatai turėtų atrodyti taip:

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

Pagal numatytuosius nustatymus pasiuntinys turi formato eilutę, į kurią įtraukta HTTP užklausos informacija:

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

Šios formato eilutės rezultatas:

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

Išvesties turinį galima tinkinti nustatant formato lauką. Pavyzdžiui:

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"

Žurnalo eilutė taip pat gali būti išvesta JSON formatu, nustatant lauką json_format. Pavyzdžiui:

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

Norėdami gauti daugiau informacijos apie pasiuntinio registracijos metodiką, apsilankykite

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

Registravimas nėra vienintelis būdas sužinoti apie darbą su „Envoy Proxy“. Jame įdiegtos pažangios sekimo ir metrikos funkcijos. Daugiau sužinoti galite adresu sekimo dokumentus arba per Interaktyvus sekimo scenarijus.

7 veiksmas – paleiskite

Dabar perkėlėte savo konfigūraciją iš NGINX į „Envoy Proxy“. Paskutinis veiksmas yra paleisti „Envoy Proxy“ egzempliorių, kad jį išbandytumėte.

Paleisti kaip vartotojas

NGINX konfigūracijos eilutės viršuje vartotojas www www; nurodo paleisti NGINX kaip mažas privilegijas turinčiam vartotojui, siekiant pagerinti saugumą.

„Envoy Proxy“ valdo procesą, kuriam priklauso debesys. Kai paleidžiame „Envoy Proxy“ per konteinerį, galime nurodyti žemų privilegijų vartotoją.

„Envoy Proxy“ paleidimas

Toliau pateikta komanda paleis „Envoy Proxy“ per pagrindinio kompiuterio „Docker“ konteinerį. Ši komanda suteikia pasiuntiniui galimybę klausytis įeinančių užklausų per 80 prievadą. Tačiau, kaip nurodyta klausytojo konfigūracijoje, „Envoy Proxy“ klauso įeinančio srauto per 8080 prievadą. Tai leidžia procesui vykdyti kaip žemų privilegijų vartotojui.

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

Bandymai

Kai tarpinis serveris veikia, dabar galima atlikti ir apdoroti testus. Ši cURL komanda pateikia užklausą su pagrindinio kompiuterio antrašte, apibrėžta tarpinio serverio konfigūracijoje.

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

HTTP užklausa sukels klaidą 503. Taip yra todėl, kad jungtys prieš srovę neveikia ir nepasiekiamos. Todėl pasiuntinio įgaliotasis serveris neturi galimų užklausos paskirties vietų. Ši komanda pradės HTTP paslaugų, atitinkančių konfigūraciją, nustatytą pasiuntiniui, seriją.

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

Su turimomis paslaugomis Envoy gali sėkmingai perduoti srautą į paskirties vietą.

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

Turėtumėte pamatyti atsakymą, nurodantį, kuris „Docker“ konteineris apdorojo užklausą. „Envoy Proxy“ žurnaluose taip pat turėtumėte matyti prieigos eilutės išvestį.

Papildomos HTTP atsako antraštės

Faktinės užklausos atsakymo antraštėse matysite papildomas HTTP antraštes. Antraštėje rodomas laikas, kurį aukštesnė priegloba praleido apdorodama užklausą. Išreiškiama milisekundėmis. Tai naudinga, jei klientas nori nustatyti aptarnavimo laiką, palyginti su tinklo delsa.

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

Galutinė konfigūracija

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 }

Papildoma informacija iš vertėjo

Instrukcijas, kaip įdiegti „Envoy Proxy“, galite rasti svetainėje https://www.getenvoy.io/

Pagal numatytuosius nustatymus rpm neturi sistemos paslaugos konfigūracijos.

Pridėti systemd paslaugos konfigūraciją /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

Turite sukurti katalogą /etc/envoy/ ir įdėti config.yaml config.

Yra telegramos pokalbis naudojant pasiuntinio tarpinį serverį: https://t.me/envoyproxy_ru

„Envoy Proxy“ nepalaiko statinio turinio pateikimo. Taigi, kas gali balsuoti už funkciją: https://github.com/envoyproxy/envoy/issues/378

Apklausoje gali dalyvauti tik registruoti vartotojai. Prisijungti, Prašau.

Ar šis įrašas paskatino jus įdiegti ir išbandyti pasiuntinio įgaliotąjį serverį?

taip
ne

Balsavo 75 vartotojų. 18 vartotojai susilaikė.

Šaltinis: www.habr.com

Perėjimas iš Nginx į Envoy Proxy