Migrimi nga Nginx në Envoy Proxy

Përshëndetje, Habr! Po ju paraqes përkthimin e postit: Migrimi nga Nginx në Envoy Proxy.

Envoy është një proxy server i shpërndarë me performancë të lartë (i shkruar në C++), i destinuar për shërbime dhe aplikacione të veçanta; gjithashtu është një autobüs komunikimi dhe «universal data plane», i projektuar për arkitekturën e madhe të mikroshërbimeve të quajtur «service mesh». Kur u krijua, u morën parasysh zgjidhjet për problemet që ishin hasur gjatë zhvillimit të serverëve si NGINX, HAProxy, balancuesit e ngarkesës hardware dhe balancuesit e ngarkesës në cloud. Envoy punon së bashku me çdo aplikacion dhe abtron rrjetin, duke ofruar funksionalitete të përbashkëta pavarësisht nga platforma. Kur të gjithë trafiku shërbyes në infrastrukturë kalon përmes rrjetit Envoy, bëhet e lehtë të vizualizosh fushat problematike me anë të vëzhgueshmërisë së konsoliduar, rregullimit të performancës së përbashkët dhe shtimit të funksionaliteteve bazë në një vend të caktuar.

Mundësitë

  • Arkitektura jashtë procesit: envoy është një server autonom me performancë të lartë që merr një sasi të vogël memorjeje. Ai punon në bashkëpunim me çdo gjuhë aplikacioni ose framework.
  • Mbështetje për http/2 dhe grpc: envoy ofron mbështetje të klasit të parë për http/2 dhe grpc për lidhjet hyrëse dhe dalëse. Ky është një proxy transparent nga http/1.1 në http/2.
  • Balancimi i avancuar i ngarkesës: envoy mbështet funksione të avancuara të balancimit të ngarkesës, përfshirë përpjekjet automatikë të riprovimit, ndërprerjen e zinxhirit, kufizimin global të shpejtësisë, errësimin e kërkesave, balancimin lokal të ngarkesës për zona etj.
  • API për menaxhimin e konfigurimit: envoy ofron një API të besueshëm për menaxhimin dinamik të konfigurimit të saj.
  • Vëzhgueshmëria: vëzhgueshmëri e thellë e trafikëve L7, mbështetje e integruar për gjurmin e shpërndarë dhe vëzhgueshmërinë e mongodb, dynamodb dhe shumë aplikacionesh të tjera.

Hapi 1 — Shembuj konfigurimi NGINX

Në këtë skenar përdoret një skedar i krijuar posaçërisht nginx.conf, i bazuar në një shembull të plotë nga Wiki NGINX. Mund ta shikoni konfigurimin në redaktor duke hapur nginx.conf

Konfigurimin burimor 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;
    }
  }
}

Konfigurimet e NGINX zakonisht përmbajnë tre elementë kyç:

  1. Konfigurimi i serverit NGINX, struktura e regjistrave dhe funksionaliteti Gzip. Kjo përcaktohet globalisht në të gjitha rastet.
  2. Konfigurimi i NGINX për të pranuar kërkesa në hostin one.example.com në portin 8080.
  3. Konfigurimi i vendndodhjes së targetit, si të trajtohet trafiku për pjesë të ndryshme të URL-së.

Jo të gjithë konfigurimi do të zbatohet në Envoy Proxy, dhe nuk ka nevojë të konfigurosh disa parametra. Envoy Proxy ka katër lloje kyçe, që mbështesin infrastrukturën bazë të ofruar nga NGINX. Nucleus është:

  • Dëgjuesit: Ata përcaktojnë se si Envoy Proxy pranon kërkesat e ardhshme. Aktualisht, Envoy Proxy mbështet vetëm dëgjuesit mbi TCP. Pasi që lidhja është krijuar, ajo kalon në një grup filtrash për përpunim.
  • Filtrat: Ata janë pjesë e arkitekturës së tubacionit, e cila mund të trajtojë të dhënat e ardhshme dhe dalëse. Kjo funksionalitet përfshin filtra si Gzip, i cili kompreson të dhënat para se t'i dërgojë ato klientit.
  • Ruterat: Ata ridrejtojnë trafikun në destinacionin e kërkuar, të kërkuar si grup.
  • Grupet: Ata përcaktojnë pikën e fundit për trafikun dhe parametrat e konfigurimit.

Ne do të përdorim këta katër komponentë për të krijuar konfigurimin e Envoy Proxy në përputhje me një konfigurim të caktuar të NGINX. Qëllimi i Envoy është të punojë me API dhe konfigurim dinamik. Në këtë rast, konfigurimi bazë do të përdorë parametra statikë, të ngurtë të vendosur nga NGINX.

Hapi 2 — Konfigurimi NGINX

Pjesa e parë nginx.conf përkufizon disa komponentë të brendshëm të NGINX, të cilët duhet të konfigurohen.

Lidhjet e punës

Konfigurimi më poshtë përcakton numrin e proceseve punuese dhe lidhjeve. Kjo tregon se si NGINX do të përmirësohet për të përmbushur kërkesën.

proceset_punues  2;

events {
  lidhjet_punues   2000;
}

Envoy Proxy menaxhon ndryshe proceset punuese dhe lidhjet.

Envoy krijon një rrjedhë punuese për çdo rrjedhë harduerike në sistem. Çdo rrjedhë punuese kryen një cikël ngjarjesh jo bllokuese, i cili është përgjegjës për

  1. Dëgjimin e çdo dëgjuesi (listener)
  2. Pranimin e lidhjeve të reja
  3. Krijimin e një seti filtrash për lidhjen
  4. Këshillimin e të gjitha operacioneve të input-output gjatë gjithë ekzistencës së lidhjes.

Të gjitha përpunimet e mëtejshme të lidhjes kryhen plotësisht në rrjedhën punuese, përfshirë çdo sjellje ridrejtimi.

Për çdo shkarnë pune në Envoy ekziston një lidhje në grup. Kështu, grupet e lidhjeve HTTP/2 vendosin vetëm një lidhje për çdo host të jashtëm në një kohë. Nëse ka katër shkrira pune, do të ketë katër lidhje HTTP/2 për çdo host të jashtëm në një qëndrim stabil. Duke mbajtur gjithçka në një shkrirë pune, pothuajse e gjithë kode mund të shkruhet pa bllokime, sikur të ishte në një njësit të vetme. Nëse është caktuar më shumë se sa është e nevojshme shkrirave pune, kjo mund të çojë në përdorim të paefektshëm të memories, krijimin e një numri të madh të lidhjeve të papërdorura dhe reduktimin e numrit të rikthimeve të lidhjeve në grup.

Për informacion shtesë vizitoni Blogu i Proxy-t Envoy.

Konfigurimi HTTP

Blloku i mëposhtëm i konfigurimit NGINX përcakton cilësimet e HTTP, të tilla si:

  • Cilat lloje mime mbështeten
  • Kohët e pritjes të paracaktuar
  • Konfigurimi Gzip

Ju mund të konfiguroni këto aspekte me anë të filtrave në Proxy-në Envoy, të cilat do t'i diskutojmë më vonë.

Hapi 3 — Konfigurimi i Serverit

Në bllokun e konfigurimit HTTP, konfigurimi NGINX tregon të dëgjojë portin 8080 dhe të përgjigjet ndaj kërkesave të ardhshme për domenet one.example.com dhe www.one.example.com.

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

Brenda në Envoy kontrollohet nga Dëgjuarësit.

Dëgjuarësit e Envoy

Aspekti më i rëndësishëm për të nisur me Envoy Proxy është përcaktimi i dëgjuarësve. Ju nevojitet të krijoni një skedë konfigurimi që përshkruan si dëshironi të ekzekutoni një instancë të Envoy.

Fragmenti më poshtë do të krijojë një dëgjues të ri dhe do ta lidhë atë me portin 8080. Konfigurimi tregon që Envoy Proxy duhet të lidhet me cilët porte për kërkesat hyrëse.

Envoy Proxy përdor notacionin YAML për konfigurimin e tij. Për një njohje me këtë notacion, shikoni këtu këtu.

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

Nuk ka nevojë të përcaktoni server_name, pasi filtrot e Envoy Proxy do t'i trajtojnë ato.

Hapi 4 — Konfigurimi i vendndodhjes

Kur një kërkesë mb arrives në NGINX, blloku i vendndodhjes përcakton si të përpunoni dhe ku të drejtoni trafik. Në fragmentin më poshtë, e gjithë trafiku në faqen e internetit kalon në një grup upstream (shënimi i përkthyesit: upstream zakonisht janë servera aplikacionesh) me emrin targetCluster. Grupi upstream përcakton nyjet që duhet të përpunojnë kërkesën. Ne do ta diskutojmë këtë në hapin tjetër.

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

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

Në Envoy, kjo bëhet nga Filters.

Filtrat Envoy

Për konfigurimin statik, filtrat përcaktojnë se si të trajtohen kërkesat e ardhshme. Në këtë rast, ne vendosim filtrat që përputhen server_names në hapin e mëparshëm. Kur vijnë kërkesa të ardhshme që përputhen me domenet dhe rrugët e caktuara, trafiku drejtohet në klaster. Kjo është ekuivalente me konfigurimin ngritës në NGINX.

Kopjo në Redaktor    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

Emri envoy.http_connection_manager është një filtr i integruar në Envoy Proxy. Filtra të tjerë përfshijnë Redis, Mongo, TCP. Mund ta gjeni listën e plotë në dokumentacion.

Për më shumë informacion mbi politikat e tjera të balancimit të ngarkesës, vizitoni Dokumentacionin e Envoy.

Hapi 5 — Konfigurimi i Proxy dhe Upstream

Në konfigurimin e NGINX, upstream përcakton një grup serverash të shënjestruar që do të përpunojnë trafikun. Në këtë rast, ishin caktuar dy klastera.

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

Në Envoy, kjo menaxhohet nga klasterat.

Klasterat e Envoy

Ekuivalenti upstream përcaktohet si klastera. Në këtë rast, ishin përcaktuar hostet që do të shërbenin trafikun. Mënyra e aksesit në hoste, siç është koha e pritjes, përcaktohet si konfigurimi i klasterit. Kjo lejon një kontroll më të saktë ndaj aspektëve të tilla si koha e pritjes dhe balancimi i ngarkesës.

Kopjo te Editori  klasterat:
  - 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 }}
    ]

Në përdorimin e zbulimit të shërbimit STRICT_DNS Envoy do t'ju përgjigjet vazhdimisht dhe asinkronisht objektivave të caktuara DNS. Çdo IP adresë e kthyer si rezultat i DNS do të konsiderohet një host i qartë në klasterin ngritës. Kjo do të thotë se nëse kërkesa kthen dy IP adresa, Envoy do të supozojë se në klaster ka dy hoste dhe të dy duhet të balancohen në ngarkesën. Nëse një host hiqet nga rezultati, Envoy do të supozojë se ai nuk ekziston më dhe do të fillojë të seleksionojë trafik nga çdo grup ekzistues lidhjesh.

Për informacion të mëtejshëm shihni. Dokumentacionin e proxy-serverit Envoy.

Hapi 6 — Qasja në regjistrin dhe gabimet

Konfigurimi përfundimtar — regjistrimi. Në vend që të kalojë regjistrat e gabimeve në disk, Envoy Proxy përdor një qasje në re. Të gjitha regjistrat e aplikacioneve dalin në stdout dhe stderr.

Kur përdoruesit bëjnë kërkesë, regjistrat e aksesit janë të opsioneve dhe për parazgjedhje janë të çaktivizuar. Për të aktivizuar regjistrat e aksesit për kërkesat HTTP, aktivizoni konfigurimin access_log për menaxherin e lidhjeve HTTP. Rruga mund të jetë ose një pajisje, siç është stdout, ose një skedar në disk, në varësi të kërkesave tuaja.

Konfigurimi i mëposhtëm do të redirektojë të gjitha log-et e aksesit në stdout (shënim përkthyesi — stdout është i nevojshëm për përdorimin e envoy brenda docker. Nëse përdoret pa docker, zëvendësoni /dev/stdout me rrugën e skedarit të zakonshëm të log-ut). Kopjoni këtë fragment në seksionin e konfigurimit për menaxherin e lidhjeve:

Kopj për në Clipboardaccess_log:
- name: envoy.file_access_log
  config:
    path: "/dev/stdout"

Rezultatet duhet të duken si:

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

Sipas rregullit, Envoy ka një varg formati që përfshin detajet e kërkesës 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

Rezultati i kësaj string forme:

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

Përmbajtja e daljes mund të personalizohet duke vendosur fushën e formatit. Për shembull:

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"

Një hyrje e regjistrit gjithashtu mund të shfaqet në formatin JSON duke vendosur fushën json_format. Për shembull:

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

Për informacion të mëtejshëm rreth metodologjisë së regjistrimit të Envoy, vizitoni

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

Regjistrimi nuk është mënyra e vetme për të marrë një pasqyrë të funksionimit të Envoy Proxy. Ai përmban funksionalitete të avancuara të gjurmimit dhe metrike. Mund të mësoni më shumë në dokumentacionin e gjurmimit ose përmes Skenari i gjurmimit interaktiv.

Hapi 7 - Nisi

Tani keni përkthyer konfigurimin nga NGINX në Envoy Proxy. Hapi i fundit është të nisni një shembull të Envoy Proxy për ta testuar.

Nisja nga përdoruesi

Në pjesën e sipërme të konfigurimit të NGINX, rreshti user www www; tregon se NGINX do të niset si një përdorues me privilegje të ulëta për të rritur sigurinë.

Envoy Proxy ndjek një qasje cloud për të menaxhuar se kush është pronar i procesit. Kur nisim Envoy Proxy përmes enëve, mund të përcaktojmë një përdorues me privilegje të ulta.

Nisja e Envoy Proxy

Ekipa më poshtë do të niste Envoy Proxy përmes një kontejneri Docker në host. Kjo komandë i jep mundësinë Envoy të dëgjojë kërkesat e ardhshme përmes portit 80. Megjithatë, siç tregohet në konfigurimin e dëgjuesit, Envoy Proxy dëgjon trafikun e ardhshëm përmes portit 8080. Kjo lejon që procesi të nisë si përdorues me privilegje të ulta.

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

Testimi

Me proxy-në e nisur, testet tani mund të kryhen dhe të përpunohen. Komanda e mëposhtme cURL jep një kërkesë me headerin e hostit të përcaktuar në konfigurimin e proxy-së.

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

Kërkesa HTTP do të rezultojë me një gabim 503. Kjo për shkak se lidhjet e ngjitura nuk funksionojnë dhe ato nuk janë të disponueshme. Kështu, Envoy Proxy nuk ka adresat e disponueshme për kërkesën. Komanda e mëposhtme do të nisë një seri shërbimesh HTTP që përputhen me konfigurimin e përcaktuar për Envoy.

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

Me shërbimet e disponueshme, Envoy mund të proksojë me sukses trafikun drejt destinacionit.

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

Duhet të shihni një përgjigje që tregon se cili kontejner Docker përpunoi kërkesën. Në logjet e Envoy Proxy gjithashtu duhet të shihni rreshtin e aksesit të treguar.

Kryesit e tjerë të përgjigjes HTTP (HTTP Response)

Në kryesit e përgjigjes së kërkesës valide do të shihni kryesia të tjera HTTP. Në kryesë tregohet koha që hosti i sipërm kaloi për të përpunuar kërkesën. Kjo është e shprehur në milisekonda. Kjo është e dobishme nëse klienti dëshiron të përcaktojë kohën e shërbimit në krahasim me vonesën në rrjet.

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

Konfigurimi përfundimtar

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 }

Informacione shtesë nga përkthyesi

Udhëzimet për instalimin e Envoy Proxy mund t'i gjeni në faqe https://www.getenvoy.io/

Normalisht, në rpm mungon konfigurimi i shërbimit systemd.

Shtoni konfigurimin e shërbimit systemd në /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

Duhet të krijoni direktorinë /etc/envoy/ dhe të vendosni aty konfigurimin config.yaml.

Për envoy proxy ka një bisedë në Telegram: https://t.me/envoyproxy_ru

Envoy Proxy nuk ka mbështetje për shpërndarjen e përmbajtjes statike. Prandaj, kush mund të votojë për veçorinë: https://github.com/envoyproxy/envoy/issues/378

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutemi.

A ka nxitur ky post të instaloni dhe testoni envoy proxy?

  • po

  • jo

75 përdorues kanë votuar. 18 përdorues kanë abstenuar.

Burimi: habr.com

Bleni hostim të besueshëm për faqe me mbrojtje nga DDoS, serverë VPS VDS 🔥 Bleni hostim të besueshëm për faqe me mbrojtje nga DDoS, serverë VPS VDS | ProHoster