🥇Migrimi nga Nginx në përfaqësuesin e të dërguarit

Përshëndetje, Habr! Unë sjell në vëmendjen tuaj një përkthim të postimit: Migrimi nga Nginx në përfaqësuesin e të dërguarit.

Envoy është një server proxy i shpërndarë me performancë të lartë (i shkruar në C++) i krijuar për shërbime dhe aplikacione individuale, ai është gjithashtu një autobus komunikimi dhe "avioni universal i të dhënave" i projektuar për arkitekturat e mëdha "mesh shërbimi" të mikroshërbimeve. Gjatë krijimit të tij, u morën parasysh zgjidhjet e problemeve që u shfaqën gjatë zhvillimit të serverëve si NGINX, HAProxy, balancuesit e ngarkesës së harduerit dhe balancuesit e ngarkesës në cloud. Envoy punon së bashku me çdo aplikacion dhe përmbledh rrjetin për të ofruar funksionalitet të përbashkët pavarësisht nga platforma. Kur i gjithë trafiku i shërbimit në një infrastrukturë rrjedh përmes rrjetës së Envoy, bëhet e lehtë të vizualizosh zonat problematike me vëzhgim të qëndrueshëm, të rregullosh performancën e përgjithshme dhe të shtosh funksionalitetin bazë në një vendndodhje specifike.

Aftësitë

Arkitektura jashtë procesit: i dërguari është një server i pavarur, me performancë të lartë që merr një sasi të vogël RAM. Ai funksionon në lidhje me çdo gjuhë ose kornizë aplikimi.
Mbështetja http/2 dhe grpc: i dërguari ka mbështetje të klasit të parë http/2 dhe grpc për lidhjet hyrëse dhe dalëse. Ky është një përfaqësues transparent nga http/1.1 në http/2.
Balancimi i avancuar i ngarkesës: i dërguari mbështet veçori të avancuara të balancimit të ngarkesës, duke përfshirë përsëritjet automatike, ndërprerjen e zinxhirit, kufizimin e normës globale, hijezimin e kërkesave, balancimin e ngarkesës së zonës lokale, etj.
API për Menaxhimin e Konfigurimit: i dërguari ofron një API të fuqishme për menaxhimin dinamik të konfigurimit tuaj.
Vëzhgueshmëria: Vëzhgueshmëri e thellë e trafikut L7, mbështetje vendase për gjurmimin e shpërndarë dhe vëzhgueshmërinë e mongodb, dynamodb dhe shumë aplikacione të tjera.

Hapi 1 - Shembull Konfigurimi NGINX

Ky skenar përdor një skedar të krijuar posaçërisht nginx.konf, bazuar në shembullin e plotë nga NGINX Wiki. Ju mund ta shikoni konfigurimin në redaktues duke hapur nginx.konf

konfigurimi i burimit 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 NGINX zakonisht kanë tre elementë kryesorë:

Konfigurimi i serverit NGINX, strukturës së regjistrit dhe funksionalitetit Gzip. Kjo është e përcaktuar globalisht në të gjitha rastet.
Konfigurimi i NGINX për të pranuar kërkesat për hostin one.example.com në portin 8080.
Vendosja e vendndodhjes së synuar, si të trajtohet trafiku për pjesë të ndryshme të URL-së.

Jo i gjithë konfigurimi do të zbatohet për Envoy Proxy dhe nuk keni nevojë të konfiguroni disa cilësime. I dërguari Proxy ka katër lloje kryesore, të cilat mbështesin infrastrukturën bazë të ofruar nga NGINX. Thelbi është:

Dëgjuesit: Ata përcaktojnë se si Envoy Proxy pranon kërkesat hyrëse. Envoy Proxy aktualisht mbështet vetëm dëgjuesit e bazuar në TCP. Pasi të krijohet një lidhje, ajo kalon në një grup filtrash për përpunim.
Filtrat: Ato janë pjesë e një arkitekture tubacioni që mund të përpunojë të dhënat hyrëse dhe dalëse. Ky funksion përfshin filtra të tillë si Gzip, i cili kompreson të dhënat përpara se t'i dërgojë ato te klienti.
Ruterat: Ata përcjellin trafikun në destinacionin e kërkuar, të përcaktuar si një grup.
Grupet: Ata përcaktojnë pikën përfundimtare për parametrat e trafikut dhe konfigurimit.

Ne do t'i përdorim këto katër komponentë për të krijuar një konfigurim të përfaqësuesit të Envoy për të përputhur një konfigurim specifik NGINX. Qëllimi i Envoy është të punojë me API dhe konfigurimin dinamik. Në këtë rast, konfigurimi bazë do të përdorë cilësime statike, të koduara nga NGINX.

Hapi 2 - Konfigurimi i NGINX

Pjesa e pare nginx.konf përcakton disa pjesë të brendshme NGINX që duhet të konfigurohen.

Lidhjet e punëtorëve

Konfigurimi i mëposhtëm përcakton numrin e proceseve dhe lidhjeve të punëtorëve. Kjo tregon se si NGINX do të shkallëzohet për të përmbushur kërkesën.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy menaxhon flukset e punës dhe lidhjet në mënyra të ndryshme.

Envoy krijon një fill pune për çdo fije harduerike në sistem. Çdo thread punëtor ekzekuton një lak ngjarje jo-bllokuese që është përgjegjëse për të

Duke dëgjuar çdo dëgjues
Pranimi i lidhjeve të reja
Krijimi i një grupi filtrash për një lidhje
Përpunoni të gjitha operacionet I/O gjatë gjithë jetës së lidhjes.

I gjithë përpunimi i mëtejshëm i lidhjes trajtohet tërësisht në fillin e punës, duke përfshirë çdo sjellje përcjellëse.

Për çdo fije punëtore në Envoy, ekziston një grup lidhjesh. Pra, grupet e lidhjeve HTTP/2 krijojnë vetëm një lidhje për host të jashtëm në të njëjtën kohë, nëse ka katër thread-e punëtore, do të ketë katër lidhje HTTP/2 për host të jashtëm në një gjendje të qëndrueshme. Duke mbajtur gjithçka në një fill punëtor, pothuajse i gjithë kodi mund të shkruhet pa bllokuar, sikur të ishte një fije e vetme. Nëse ndahen më shumë fije punëtore se sa duhet, kjo mund të çojë në humbje të memories, duke krijuar një numër të madh lidhjesh boshe dhe duke reduktuar numrin e herëve që lidhjet kthehen përsëri në pishinë.

Për më shumë informacion vizitoni Blogu i përfaqësuesit të të dërguarit.

Konfigurimi HTTP

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

Cilat lloje të mimave mbështeten
Afatet e parazgjedhura
Konfigurimi Gzip

Ju mund t'i personalizoni këto aspekte duke përdorur filtra në Envoy Proxy, të cilat do t'i diskutojmë më vonë.

Hapi 3 - Konfigurimi i serverit

Në bllokun e konfigurimit HTTP, konfigurimi NGINX specifikon të dëgjojë në portin 8080 dhe t'u përgjigjet kërkesave hyrëse për domenet one.example.com и www.one.example.com.

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

Brenda të Dërguarit, ai kontrollohet nga Dëgjuesit.

Dëgjues të dërguar

Aspekti më i rëndësishëm i fillimit me Envoy Proxy është përcaktimi i dëgjuesve tuaj. Ju duhet të krijoni një skedar konfigurimi që përshkruan se si dëshironi të ekzekutoni shembullin e Envoy.

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

Envoy Proxy përdor shënimin YAML për konfigurimin e tij. Për një hyrje në këtë shënim, shikoni këtu lidhje.

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

Nuk ka nevojë për të përcaktuar Emri i serverit, pasi filtrat e përfaqësuesit të Envoy do ta trajtojnë këtë.

Hapi 4 - Konfigurimi i vendndodhjes

Kur një kërkesë vjen në NGINX, blloku i vendndodhjes përcakton se si të përpunohet dhe ku të drejtohet trafiku. Në fragmentin e mëposhtëm, i gjithë trafiku drejt sajtit transferohet në një grupim në rrjedhën e sipërme (shënimi i përkthyesit: në rrjedhën e sipërme është zakonisht një server aplikacioni) i quajtur targetCluster. Grupi në rrjedhën e sipërme përcakton nyjet që duhet të përpunojnë kërkesën. Ne do ta diskutojmë këtë në hapin tjetër.

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

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

Në Envoy, Filters e bën këtë.

Filtrat e të dërguarit

Për një konfigurim statik, filtrat përcaktojnë se si të përpunohen kërkesat hyrëse. Në këtë rast ne vendosim filtra që përputhen emrat e_serverit në hapin e mëparshëm. Kur mbërrijnë kërkesat hyrëse që përputhen me domene dhe rrugë të caktuara, trafiku drejtohet në grup. Ky është ekuivalenti i një konfigurimi NGINX nga poshtë-lart.

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

emër i dërguari.http_connection_manager është një filtër i integruar në Envoy Proxy. Filtra të tjerë përfshijnë Redis, Mongo, TCP. Listën e plotë mund ta gjeni në dokumentacionin.

Për më shumë informacion rreth politikave të tjera të balancimit të ngarkesës, vizitoni Dokumentacioni i të dërguarit.

Hapi 5 - Konfigurimi i përfaqësuesit dhe rrjedhës së sipërme

Në NGINX, konfigurimi në rrjedhën e sipërme përcakton një grup serverësh të synuar që do të përpunojnë trafikun. Në këtë rast, u caktuan dy grupime.

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

Në Envoy, kjo menaxhohet nga grupe.

Grupimet e të dërguarve

Ekuivalenti i rrjedhës së sipërme përkufizohet si grupime. Në këtë rast janë identifikuar pritësit që do t'i shërbejnë trafikut. Mënyra se si aksesohen hostet, si p.sh. afatet, përkufizohet si një konfigurim grupi. Kjo lejon një kontroll më të grimcuar mbi aspekte të tilla si vonesa dhe balancimi i ngarkesës.

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

Kur përdorni zbulimin e shërbimit STRICT_DNS I dërguari do të zgjidhë vazhdimisht dhe në mënyrë asinkron objektivat e specifikuara të DNS. Çdo adresë IP e kthyer nga rezultati DNS do të konsiderohet një host i qartë në grupin e rrjedhës së sipërme. Kjo do të thotë që nëse një kërkesë kthen dy adresa IP, Envoy do të supozojë se ka dy host në grup dhe të dyja duhet të jenë të balancuara në ngarkesë. Nëse një host hiqet nga rezultati, Envoy do të supozojë se ai nuk ekziston më dhe do të tërheqë trafikun nga çdo grup lidhjesh ekzistuese.

Për më shumë informacion shih Dokumentacioni i përfaqësuesit të të dërguarit.

Hapi 6 - Qasja në regjistër dhe gabimet

Konfigurimi përfundimtar është regjistrimi. Në vend që të shtyjë regjistrat e gabimeve në disk, Envoy Proxy merr një qasje të bazuar në cloud. Të gjitha regjistrat e aplikacioneve dalin te stdout и stderr.

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

Konfigurimi i mëposhtëm do të ridrejtojë të gjitha regjistrat e aksesit te stdout (shënimi i përkthyesit - stdout kërkohet për të përdorur envoy brenda docker. Nëse përdoret pa docker, atëherë zëvendësoni /dev/stdout me shtegun drejt një skedari të rregullt log). Kopjojeni fragmentin në seksionin e konfigurimit për menaxherin e lidhjes:

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

Rezultatet duhet të duken kështu:

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

Si parazgjedhje, 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ëtij vargu të formatit është:

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

Linja e regjistrit mund të dalë gjithashtu në format 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 më shumë informacion mbi Metodologjinë e Regjistrimit të të Dërguarit, 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ë fituar njohuri për të punuar me Envoy Proxy. Ka aftësi të avancuara të gjurmimit dhe metrikës të integruara në të. Mund të mësoni më shumë në dokumentacioni gjurmues ose nëpërmjet Skript gjurmues interaktiv.

Hapi 7 - Nisja

Tani e keni migruar konfigurimin tuaj nga NGINX te Envoy Proxy. Hapi i fundit është të hapni një shembull të përfaqësuesit të të dërguarit për ta testuar atë.

Ekzekutoni si përdorues

Në krye të linjës së konfigurimit NGINX përdorues www www; specifikon të ekzekutojë NGINX si një përdorues me privilegj të ulët për të përmirësuar sigurinë.

Envoy Proxy merr një qasje të bazuar në cloud për të menaxhuar se kush zotëron një proces. Kur ekzekutojmë Envoy Proxy përmes një kontejneri, mund të specifikojmë një përdorues me privilegj të ulët.

Nisja e përfaqësuesit të të dërguarit

Komanda më poshtë do të ekzekutojë Envoy Proxy përmes një kontejneri Docker në host. Kjo komandë i jep Envoy mundësinë për të dëgjuar kërkesat hyrëse në portin 80. Megjithatë, siç specifikohet në konfigurimin e dëgjuesit, Envoy Proxy dëgjon për trafikun në hyrje në portin 8080. Kjo lejon që procesi të ekzekutohet si një përdorues me privilegj të ulët.

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

Testimi

Me funksionimin e përfaqësuesit, testet tani mund të bëhen dhe të përpunohen. Komanda cURL e mëposhtme lëshon një kërkesë me kokën e hostit të përcaktuar në konfigurimin e përfaqësuesit.

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

Kërkesa HTTP do të rezultojë në një gabim 503. Kjo për shkak se lidhjet në rrjedhën e sipërme nuk funksionojnë dhe nuk janë të disponueshme. Prandaj, Envoy Proxy nuk ka destinacione të 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ë përcaktojë me sukses trafikun për në destinacionin e tij.

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

Ju duhet të shihni një përgjigje që tregon se cili kontejner Docker e përpunoi kërkesën. Në regjistrat e përfaqësuesit të të dërguarit duhet të shihni gjithashtu një dalje të vargut të aksesit.

Titujt shtesë të përgjigjes HTTP

Do të shihni tituj shtesë HTTP në titujt e përgjigjeve të kërkesës aktuale. Kreu tregon kohën e kaluar nga hosti në rrjedhën e sipërme duke përpunuar kërkesën. 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 e rrjetit.

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 }

Informacion shtesë nga përkthyesi

Udhëzimet për instalimin e Envoy Proxy mund të gjenden në faqen e internetit https://www.getenvoy.io/

Si parazgjedhje, rpm nuk ka një konfigurim të shërbimit systemd.

Shto konfigurimin e shërbimit 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

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

Ekziston një bisedë telegrami duke përdorur përfaqësuesin e të dërguarit: https://t.me/envoyproxy_ru

Proxy i dërguar nuk e mbështet shërbimin 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, te lutem

A ju inkurajoi ky postim të instaloni dhe testoni përfaqësuesin e të dërguarit?

75 përdorues votuan. 18 përdorues abstenuan.

Burimi: www.habr.com

Migrimi nga Nginx në përfaqësuesin e të dërguarit