🥇Migracija z Nginx na Envoy Proxy

Pozdravljeni, Habr! Predstavljam vam prevod objave: Migracija z Nginx na Envoy Proxy.

Envoy je visoko zmogljiv porazdeljen proxy strežnik (napisan v C++), zasnovan za posamezne storitve in aplikacije, je tudi komunikacijsko vodilo in "univerzalna podatkovna ravnina", zasnovana za velike mikrostoritvene "storitvene mreže" arhitekture. Pri izdelavi so bile upoštevane rešitve težav, ki so se pojavile med razvojem strežnikov, kot so NGINX, HAProxy, hardware load balancers in cloud load balancers. Envoy deluje skupaj z vsako aplikacijo in abstrahira omrežje, da zagotovi skupno funkcionalnost ne glede na platformo. Ko ves storitveni promet v infrastrukturi teče skozi mrežo Envoy, postane enostavno vizualizirati problematična področja z dosledno opazljivostjo, prilagoditi celotno zmogljivost in dodati osnovno funkcionalnost na določeni lokaciji.

možnosti

Zunajprocesna arhitektura: envoy je samostojen, visoko zmogljiv strežnik, ki zavzame majhno količino RAM-a. Deluje v povezavi s katerim koli aplikacijskim jezikom ali okvirom.
Podpora za http/2 in grpc: envoy ima prvovrstno podporo za http/2 in grpc za dohodne in odhodne povezave. To je pregleden proxy od http/1.1 do http/2.
Napredno uravnoteženje obremenitve: envoy podpira napredne funkcije za uravnoteženje obremenitve, vključno s samodejnimi ponovnimi poskusi, pretrganjem verige, omejevanjem globalne hitrosti, senčenjem zahtev, uravnoteženjem obremenitve lokalnega območja itd.
API za upravljanje konfiguracije: envoy ponuja robusten API za dinamično upravljanje vaše konfiguracije.
Opazljivost: globoka opazljivost prometa L7, izvorna podpora za porazdeljeno sledenje in opazljivost mongodb, dynamodb in številnih drugih aplikacij.

Korak 1 — Primer konfiguracije NGINX

Ta skript uporablja posebej oblikovano datoteko nginx.conftemelji na celotnem primeru iz NGINX Wiki. Konfiguracijo si lahko ogledate v urejevalniku tako, da odprete nginx.conf

izvorna konfiguracija 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;
    }
  }
}

Konfiguracije NGINX imajo običajno tri ključne elemente:

Konfiguracija strežnika NGINX, strukture dnevnika in funkcionalnosti Gzip. To je opredeljeno globalno v vseh primerih.
Konfiguriranje NGINX za sprejemanje zahtev gostitelju one.example.com na vratih 8080.
Nastavitev ciljne lokacije, kako obravnavati promet za različne dele URL-ja.

Vse konfiguracije ne bodo veljale za Envoy Proxy in nekaterih nastavitev vam ni treba konfigurirati. Envoy Proxy ima štiri ključne vrste, ki podpirajo osnovno infrastrukturo, ki jo ponuja NGINX. Jedro je:

Poslušalci: Določajo, kako Envoy Proxy sprejema dohodne zahteve. Envoy Proxy trenutno podpira samo poslušalce, ki temeljijo na TCP. Ko je povezava vzpostavljena, se posreduje naboru filtrov za obdelavo.
Filtri: So del arhitekture cevovoda, ki lahko obdeluje dohodne in odhodne podatke. Ta funkcionalnost vključuje filtre, kot je Gzip, ki stisne podatke, preden jih pošlje odjemalcu.
Usmerjevalniki: Posredujejo promet do želenega cilja, definiranega kot gruča.
Grozdi: Določajo končno točko za promet in konfiguracijske parametre.

Te štiri komponente bomo uporabili za ustvarjanje konfiguracije Envoy Proxy, ki bo ustrezala določeni konfiguraciji NGINX. Envoyjev cilj je delo z API-ji in dinamično konfiguracijo. V tem primeru bo osnovna konfiguracija uporabljala statične, trdo kodirane nastavitve iz NGINX.

2. korak – Konfiguracija NGINX

Prvi del nginx.conf definira nekatere notranje elemente NGINX, ki jih je treba konfigurirati.

Delavske povezave

Spodnja konfiguracija določa število delovnih procesov in povezav. To kaže, kako se bo NGINX prilagodil povpraševanju.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy upravlja poteke dela in povezave na različne načine.

Envoy ustvari delovno nit za vsako nit strojne opreme v sistemu. Vsaka delovna nit izvaja neblokirno zanko dogodkov, ki je odgovorna za

Poslušanje vsakega poslušalca
Sprejemanje novih povezav
Ustvarjanje niza filtrov za povezavo
Obdelajte vse V/I operacije med življenjsko dobo povezave.

Vsa nadaljnja obdelava povezav se v celoti obravnava v delovni niti, vključno s kakršnim koli posredovanjem.

Za vsako delavsko nit v Envoy obstaja povezovalno področje. Področja povezav HTTP/2 torej vzpostavijo samo eno povezavo na zunanjega gostitelja naenkrat; če obstajajo štiri delovne niti, bodo štiri povezave HTTP/2 na zunanjega gostitelja v stabilnem stanju. Z ohranjanjem vsega v eni delovni niti je skoraj vso kodo mogoče napisati brez blokiranja, kot da bi bila enonitna. Če je dodeljenih več delovnih niti, kot je potrebno, lahko to privede do izgubljenega pomnilnika, ustvarjanja velikega števila nedejavnih povezav in zmanjšanja števila vrnitev povezav nazaj v področje.

Za več informacij obiščite Blog Envoy Proxy.

Konfiguracija HTTP

Naslednji konfiguracijski blok NGINX definira nastavitve HTTP, kot so:

Katere vrste mime so podprte
Privzete časovne omejitve
Konfiguracija Gzip

Te vidike lahko prilagodite s filtri v Envoy Proxy, o katerih bomo razpravljali pozneje.

3. korak – Konfiguracija strežnika

V konfiguracijskem bloku HTTP konfiguracija NGINX določa poslušanje na vratih 8080 in odgovarjanje na dohodne zahteve za domene one.example.com и www.one.example.com.

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

Znotraj Envoya ga nadzorujejo poslušalci.

Odposlanec poslušalcem

Najpomembnejši vidik začetka uporabe Envoy Proxy je definiranje vaših poslušalcev. Ustvariti morate konfiguracijsko datoteko, ki opisuje, kako želite zagnati primerek Envoy.

Spodnji delček bo ustvaril novega poslušalca in ga povezal z vrati 8080. Konfiguracija pove Envoy Proxy, na katera vrata naj se poveže za dohodne zahteve.

Envoy Proxy za svojo konfiguracijo uporablja zapis YAML. Za uvod v ta zapis si oglejte tukaj povezavo.

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

Ni treba definirati ime_strežnika, saj bodo to obravnavali filtri Envoy Proxy.

4. korak – Konfiguracija lokacije

Ko pride zahteva v NGINX, lokacijski blok določi, kako obdelati in kam usmeriti promet. V naslednjem fragmentu je ves promet do spletnega mesta prenesen v gorvodno (opomba prevajalca: zgoraj je običajno aplikacijski strežnik) gručo z imenom targetCluster. Gornja gruča definira vozlišča, ki naj obdelajo zahtevo. O tem bomo razpravljali v naslednjem koraku.

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

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

Pri Envoy to počne Filters.

Filtri Envoy

Za statično konfiguracijo filtri določajo, kako obdelati dohodne zahteve. V tem primeru nastavimo filtre, ki se ujemajo imena_strežnikov v prejšnjem koraku. Ko prispejo dohodne zahteve, ki se ujemajo z določenimi domenami in potmi, se promet usmeri v gručo. To je enakovredno konfiguraciji NGINX od spodaj navzgor.

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

ime odposlanec.http_connection_manager je vgrajen filter v Envoy Proxy. Drugi filtri vključujejo Redis, Mongo, TCP. Celoten seznam najdete na dokumentacijo.

Za več informacij o drugih pravilnikih o uravnoteženju obremenitve obiščite Odposlanska dokumentacija.

5. korak – Konfiguracija strežnika proxy in navzgor

V NGINX konfiguracija navzgor določa nabor ciljnih strežnikov, ki bodo obdelovali promet. V tem primeru sta bili dodeljeni dve skupini.

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

V Envoyu to upravljajo grozdi.

Odposlanski grozdi

Ekvivalent navzgor je opredeljen kot grozdi. V tem primeru so identificirani gostitelji, ki bodo služili prometu. Način dostopa do gostiteljev, kot so časovne omejitve, je definiran kot konfiguracija gruče. To omogoča bolj natančen nadzor nad vidiki, kot sta zakasnitev in uravnoteženje obremenitve.

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

Pri uporabi odkrivanja storitev STRICT_DNS Envoy bo nenehno in asinhrono razreševal navedene cilje DNS. Vsak naslov IP, vrnjen iz rezultata DNS, bo obravnavan kot eksplicitni gostitelj v gruči navzgor. To pomeni, da če zahteva vrne dva naslova IP, bo Envoy domneval, da sta v gruči dva gostitelja, oba pa morata biti uravnotežena. Če je gostitelj odstranjen iz rezultata, bo Envoy predvideval, da ne obstaja več, in bo črpal promet iz vseh obstoječih povezovalnih skupin.

Za več informacij glejte Dokumentacija pooblaščenca Envoy.

6. korak — Dostop do dnevnika in napake

Končna konfiguracija je registracija. Namesto potiskanja dnevnikov napak na disk ima Envoy Proxy pristop, ki temelji na oblaku. Vsi dnevniki aplikacij so izpisani v stdout и stderr.

Ko uporabniki podajo zahtevo, so dnevniki dostopa neobvezni in privzeto onemogočeni. Če želite omogočiti dnevnike dostopa za zahteve HTTP, omogočite konfiguracijo dostop_log za upravitelja povezav HTTP. Pot je lahko bodisi naprava kot npr stdoutali datoteko na disku, odvisno od vaših zahtev.

Naslednja konfiguracija bo vse dnevnike dostopa preusmerila na stdout (opomba prevajalca - stdout je potreben za uporabo envoy znotraj dockerja. Če ga uporabljate brez dockerja, zamenjajte /dev/stdout s potjo do običajne datoteke dnevnika). Kopirajte delček v konfiguracijski razdelek za upravitelja povezav:

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

Rezultati bi morali izgledati takole:

      - 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 ima privzeto oblikovni niz, ki vključuje podrobnosti zahteve 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

Rezultat tega formatnega niza je:

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

Izhodno vsebino je mogoče prilagoditi z nastavitvijo polja za obliko. Na primer:

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"

Vrstico dnevnika je mogoče izpisati tudi v formatu JSON, tako da nastavite polje json_format. Na primer:

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

Za več informacij o metodologiji registracije Envoy obiščite

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

Beleženje ni edini način za vpogled v delo z Envoy Proxy. Vgrajeno ima napredne zmogljivosti sledenja in metrike. Več lahko izveste na sledilna dokumentacija ali preko Interaktivni skript za sledenje.

Korak 7 - Zagon

Zdaj ste preselili svojo konfiguracijo iz NGINX v Envoy Proxy. Zadnji korak je zagon primerka Envoy Proxy, da ga preizkusite.

Zaženi kot uporabnik

Na vrhu konfiguracijske vrstice NGINX uporabnik www www; določa zagon NGINX kot uporabnik z nizkimi pravicami za izboljšanje varnosti.

Envoy Proxy uporablja pristop v oblaku za upravljanje, kdo je lastnik procesa. Ko zaženemo Envoy Proxy prek vsebnika, lahko določimo uporabnika z nizkimi privilegiji.

Zagon Envoy Proxy

Spodnji ukaz bo zagnal Envoy Proxy prek vsebnika Docker na gostitelju. Ta ukaz Envoyju omogoča, da posluša dohodne zahteve na vratih 80. Vendar, kot je določeno v konfiguraciji poslušalca, Envoy Proxy posluša dohodni promet na vratih 8080. To omogoča, da se postopek izvaja kot uporabnik z nizkimi pravicami.

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

Testiranje

Ko proxy deluje, je zdaj mogoče narediti in obdelati teste. Naslednji ukaz cURL izda zahtevo z glavo gostitelja, definirano v konfiguraciji proxyja.

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

Zahteva HTTP bo povzročila napako 503. To je zato, ker povezave navzgor ne delujejo in niso na voljo. Zato Envoy Proxy nima razpoložljivih ciljev za zahtevo. Naslednji ukaz bo zagnal niz storitev HTTP, ki se ujemajo s konfiguracijo, definirano za Envoy.

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

S storitvami, ki so na voljo, lahko Envoy uspešno posreduje promet do cilja.

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

Morali bi videti odgovor, ki navaja, kateri vsebnik Docker je obdelal zahtevo. V dnevnikih Envoy Proxy bi morali videti tudi izpis niza za dostop.

Dodatne glave odziva HTTP

V glavah odgovora dejanske zahteve boste videli dodatne glave HTTP. V glavi je prikazan čas, ki ga je zgornji gostitelj porabil za obdelavo zahteve. Izraženo v milisekundah. To je uporabno, če želi odjemalec določiti čas storitve v primerjavi z zakasnitvijo omrežja.

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

Končna konfiguracija

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 }

Dodatne informacije od prevajalca

Navodila za namestitev Envoy Proxy najdete na spletni strani https://www.getenvoy.io/

Privzeto rpm nima konfiguracije storitve systemd.

Dodajte konfiguracijo storitve 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

Ustvariti morate imenik /etc/envoy/ in tja postaviti konfiguracijo config.yaml.

Obstaja telegramski klepet z uporabo proxyja odposlanca: https://t.me/envoyproxy_ru

Envoy Proxy ne podpira serviranja statične vsebine. Torej, kdo lahko glasuje za funkcijo: https://github.com/envoyproxy/envoy/issues/378

V anketi lahko sodelujejo samo registrirani uporabniki. Prijaviti se, prosim.

Ali vas je ta objava spodbudila k namestitvi in testiranju proxyja envoy?

Glasovalo je 75 uporabnikov. 18 uporabnikov se je vzdržalo.

Vir: www.habr.com

Migracija z Nginx na Envoy Proxy