Nginx-etik Envoy Proxyrako migrazioa

Kaixo, Habr! Zure arreta jartzen dizut mezuaren itzulpena: Nginx-etik Envoy Proxyrako migrazioa.

Envoy banakako zerbitzu eta aplikazioetarako diseinatutako errendimendu handiko proxy zerbitzari banatua da (C++-n idatzia), komunikazio-busa eta "datu plano unibertsala" mikrozerbitzuen "zerbitzu sare" arkitektura handietarako diseinatutakoa ere bada. Sortzerakoan, NGINX, HAProxy, hardware-karga-orekatzaileak eta hodeiko karga-orekatzaileak bezalako zerbitzarien garapenean sortutako arazoen konponbideak hartu dira kontuan. Envoy-ek aplikazio bakoitzarekin batera lan egiten du eta sarearen abstrakzioa egiten du plataforma edozein dela ere funtzionalitate komunak eskaintzeko. Azpiegitura bateko zerbitzu-trafiko guztia Envoy saretik igarotzen denean, erraza da arazo-eremuak behagarritasun koherentearekin bistaratzea, errendimendu orokorra doitzea eta oinarrizko funtzionalitateak gehitzea kokapen zehatz batean.

Capabilities

  • Prozesutik kanpoko arkitektura: envoy RAM kopuru txiki bat hartzen duen errendimendu handiko zerbitzari autonomoa da. Edozein aplikazio hizkuntza edo esparrurekin batera funtzionatzen du.
  • http/2 eta grpc laguntza: envoy-ek lehen mailako http/2 eta grpc laguntza ditu sarrerako eta irteerako konexioetarako. Hau http/1.1-tik http/2-ra proxy gardena da.
  • Karga-orekatze aurreratua: envoy-ek karga orekatzeko funtzio aurreratuak onartzen ditu, besteak beste, berriro saiakera automatikoak, kate-haustura, tasa-muga globala, eskaera itzaltzea, tokiko tokiko karga orekatzea, etab.
  • Konfigurazioa kudeatzeko APIa: envoy-ek API sendo bat eskaintzen du zure konfigurazioa modu dinamikoan kudeatzeko.
  • Behagarritasuna: L7 trafikoaren behagarritasun sakona, trazadura banaturako jatorrizko euskarria eta mongodb, dynamodb eta beste hainbat aplikazioren behagarritasuna.

1. urratsa - Adibidea NGINX Config

Script honek bereziki landutako fitxategi bat erabiltzen du nginx.conf, adibide osoa oinarri hartuta NGINX Wikia. Konfigurazioa editorean ikus dezakezu irekita nginx.conf

nginx iturburu-konfigurazioa

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 konfigurazioek hiru elementu gako izan ohi dituzte:

  1. NGINX zerbitzaria, log-egitura eta Gzip funtzionaltasuna konfiguratzen. Hau globalki definitzen da kasu guztietan.
  2. NGINX ostalariaren eskaerak onartzeko konfiguratzen bat.adibidea.com 8080 portuan.
  3. Xede-kokapena konfiguratzea, URLaren atal ezberdinetarako trafikoa nola kudeatu.

Konfigurazio guztiak ez dira aplikatuko Envoy Proxy-ri, eta ez dituzu ezarpen batzuk konfiguratu beharrik. Envoy Proxy du lau gako mota, NGINX-ek eskaintzen duen oinarrizko azpiegitura onartzen dutenak. Muina hau da:

  • Entzuleak: Envoy Proxy-k sarrerako eskaerak nola onartzen dituen zehazten dute. Envoy Proxy-k TCPn oinarritutako entzuleak soilik onartzen ditu gaur egun. Konexio bat ezarri ondoren, iragazki multzo batera pasatzen da prozesatzeko.
  • Iragazkiak: Sarrerako eta irteerako datuak prozesatu ditzakeen kanalizazio-arkitektura baten parte dira. Funtzionalitate honek Gzip bezalako iragazkiak barne hartzen ditu, datuak bezeroari bidali aurretik konprimitzen dituena.
  • Bideratzaileak: Trafikoa behar den helmugara bideratzen dute, kluster gisa definituta.
  • Klusterrak: Trafikorako eta konfigurazio-parametroetarako amaiera-puntua definitzen dute.

Lau osagai hauek erabiliko ditugu Envoy Proxy konfigurazio bat sortzeko, NGINX konfigurazio zehatz batekin bat etortzeko. Envoy-en helburua APIekin eta konfigurazio dinamikoekin lan egitea da. Kasu honetan, oinarrizko konfigurazioak NGINX-en ezarpen estatikoak erabiliko ditu.

2. urratsa - NGINX konfigurazioa

Lehenengo zatian nginx.conf konfiguratu behar diren NGINX barneko batzuk definitzen ditu.

Langileen konexioak

Beheko konfigurazioak langileen prozesu eta konexio kopurua zehazten du. Honek NGINX eskaria asetzeko nola eskalatuko den adierazten du.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy-k modu ezberdinetan kudeatzen ditu lan-fluxuak eta konexioak.

Envoy-ek langile-hari bat sortzen du sistemako hardware-hari bakoitzeko. Langile-hari bakoitzak blokeorik gabeko gertaeren begizta bat exekutatzen du, eta horrek arduratzen du

  1. Entzule bakoitzari entzutea
  2. Konexio berriak onartzea
  3. Konexio baterako iragazki multzo bat sortzea
  4. Prozesatu I/O eragiketa guztiak konexioaren bizitzan zehar.

Konexioen prozesamendu gehiago langilearen harian kudeatzen da guztiz, birbidaltze-jokabide oro barne.

Envoy-eko langile-hari bakoitzeko, konexio-talde bat dago. Beraz, HTTP/2 konexio multzoek kanpoko ostalari bakoitzeko konexio bakarra ezartzen dute aldi berean, lau langile-hari badaude, kanpoko ostalari bakoitzeko lau HTTP/2 konexio egongo dira egoera egonkorrean. Dena langile-hari batean gordeta, ia kode guztia blokeatu gabe idatz daiteke, hari bakarrekoa balitz bezala. Behar baino langile hari gehiago esleitzen badira, horrek memoria alferrik galtzea ekar dezake, konexio inaktibo ugari sortuz eta konexioak igerilekura itzultzen diren aldi kopurua murriztuz.

Informazio gehiago nahi izanez gero, bisitatu Envoy Proxy bloga.

HTTP konfigurazioa

NGINX konfigurazio bloke honek HTTP ezarpenak definitzen ditu, hala nola:

  • Zein mimo mota onartzen diren
  • Denbora-muga lehenetsiak
  • Gzip konfigurazioa

Alderdi horiek pertsonaliza ditzakezu Envoy Proxy-ko iragazkiak erabiliz, geroago aztertuko ditugunak.

3. urratsa - Zerbitzariaren konfigurazioa

HTTP konfigurazio blokean, NGINX konfigurazioak 8080 atakan entzutea eta domeinuen sarrerako eskaerei erantzutea zehazten du. bat.adibidea.com ΠΈ www.one.adibidea.com.

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

Envoy-en barruan, Entzuleek kontrolatzen dute.

Entzule mandatariak

Envoy Proxy-rekin hasteko alderdirik garrantzitsuena zure entzuleak zehaztea da. Envoy instantzia nola exekutatu nahi duzun deskribatzen duen konfigurazio-fitxategi bat sortu behar duzu.

Beheko zatiak entzule berri bat sortuko du eta 8080 atakara lotuko du. Konfigurazioak Envoy Proxy-ri esaten dio zein portutara lotu behar duen sarrerako eskaeretarako.

Envoy Proxy-k YAML idazkera erabiltzen du bere konfiguraziorako. Notazio honi buruzko sarrera bat lortzeko, begiratu hemen link.

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

Ez dago definitu beharrik server_name, Envoy Proxy iragazkiak hau kudeatuko baitute.

4. urratsa - Kokapenaren konfigurazioa

NGINX-en eskaera bat sartzen denean, kokapen-blokeak trafikoa nola prozesatu eta non bideratu zehazten du. Hurrengo zatian, gunerako trafiko guztia upstream (itzultzailearen oharra: upstream aplikazio-zerbitzari bat izan ohi da) izeneko kluster batera transferitzen da. targetCluster. Upstream klusterrak eskaera prozesatu behar duten nodoak definitzen ditu. Hurrengo urratsean eztabaidatuko dugu.

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

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

Envoy-en, Filters-ek hau egiten du.

Envoy Iragazkiak

Konfigurazio estatiko baterako, iragazkiek zehazten dute nola prozesatu sarrerako eskaerak. Kasu honetan bat datozen iragazkiak ezarri ditugu zerbitzari_izenak aurreko urratsean. Domeinu eta ibilbide jakin batzuekin bat datozen eskaerak iristen direnean, trafikoa klusterera bideratzen da. Hau NGINX behetik gorako konfigurazio baten baliokidea da.

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

izen envoy.http_connection_manager Envoy Proxy-n integratutako iragazkia da. Beste iragazki batzuk daude Birbanaketa, Mongo, TCP. Hemen aurkituko duzu zerrenda osoa dokumentazioa.

Karga orekatzeko beste politika batzuei buruzko informazio gehiago lortzeko, bisitatu Envoy dokumentazioa.

5. urratsa - Proxy eta Upstream konfigurazioa

NGINX-en, gorako konfigurazioak trafikoa prozesatuko duen helburu-zerbitzari multzo bat definitzen du. Kasu honetan, bi kluster esleitu ziren.

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

Envoy-en, klusterrak kudeatzen dira.

Envoy Clusters

Upstream baliokidea kluster gisa definitzen da. Kasu honetan, trafikoa zerbitzatuko duten ostalariak identifikatu dira. Ostalariak sartzeko modua, esate baterako, denbora-muga, kluster konfigurazio gisa definitzen da. Horrek latentzia eta karga orekatzea bezalako alderdien kontrol zehatzagoa ahalbidetzen du.

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

Zerbitzuaren aurkikuntza erabiltzean STRICT_DNS Envoy-ek etengabe eta modu asinkronoan ebatziko ditu zehaztutako DNS helburuak. DNS emaitzatik itzultzen den IP helbide bakoitza ostalari esplizitutzat hartuko da gorako klusterrean. Horrek esan nahi du eskaera batek bi IP helbide itzultzen baditu, Envoy-ek klusterrean bi ostalari daudela suposatuko du, eta biak karga orekatu behar direla. Ostalari bat emaitzatik kentzen bada, Envoy-ek jada existitzen ez dela suposatuko du eta lehendik dauden konexio-taldeetatik aterako du trafikoa.

Informazio gehiagorako ikusi Envoy proxy dokumentazioa.

6. urratsa - Sarbidea eta akatsak erregistratzea

Azken konfigurazioa erregistroa da. Erroreen erregistroak diskora eraman beharrean, Envoy Proxy-k hodeian oinarritutako ikuspegia hartzen du. Aplikazioen erregistro guztiak hona ateratzen dira stdout ΠΈ stderr.

Erabiltzaileek eskaera bat egiten dutenean, sarbide-erregistroak aukerakoak dira eta desgaituta daude lehenespenez. HTTP eskaeretarako sarbide-erregistroak gaitzeko, gaitu konfigurazioa sarbide_erregistroa HTTP konexio-kudeatzailerako. Bidea gailu bat izan daiteke, hala nola stdout, edo diskoan fitxategi bat, zure eskakizunen arabera.

Honako konfigurazio honek sarbide-erregistro guztiak birbideratuko ditu stdout (Itzultzailearen oharra - stdout beharrezkoa da envoy docker barruan erabiltzeko. Docker gabe erabiltzen bada, ordezkatu /dev/stdout erregistro-fitxategi arrunt baterako bidearekin). Kopiatu zatia konexio-kudeatzailearen konfigurazio atalera:

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

Emaitzak honelakoak izan beharko lirateke:

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

Lehenespenez, Envoy-ek HTTP eskaeraren xehetasunak biltzen dituen formatu-katea du:

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

Formatu-kate honen emaitza hau da:

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

Irteerako edukia pertsonalizatu daiteke formatu eremua ezarriz. Adibidez:

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"

Erregistro-lerroa JSON formatuan ere atera daiteke eremua ezarriz json_format. Adibidez:

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

Envoy Erregistratzeko Metodologiari buruzko informazio gehiago lortzeko, bisitatu

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

Erregistratzea ez da Envoy Proxy-rekin lan egiteko modu bakarra. Trazamendu eta metrika gaitasun aurreratuak ditu barnean. Hemen informazio gehiago aurki dezakezu trazatzeko dokumentazioa edo bidez Trazadura-gidoia interaktiboa.

7. urratsa - Abiarazi

Orain zure konfigurazioa NGINXetik Envoy Proxyra migratu duzu. Azken urratsa Envoy Proxy instantzia bat abiaraztea da probatzeko.

Exekutatu erabiltzaile gisa

NGINX konfigurazio-lerroaren goialdean erabiltzailea www www; NGINX pribilegio baxuko erabiltzaile gisa exekutatzea zehazten du segurtasuna hobetzeko.

Envoy Proxy-k hodeian oinarritutako ikuspegia hartzen du prozesu baten jabea den kudeatzeko. Envoy Proxy edukiontzi baten bidez exekutatzen dugunean, pribilegio baxuko erabiltzaile bat zehaztu dezakegu.

Envoy Proxy abiarazten

Beheko komandoak Envoy Proxy exekutatuko du ostalariaren Docker edukiontzi baten bidez. Komando honek Envoy-i sarrerako eskaerak 80 atakan entzuteko gaitasuna ematen dio. Hala ere, entzulearen konfigurazioan zehazten den moduan, Envoy Proxy-k sarrerako trafikoa entzuten du 8080 atakan. Honi esker, prozesua pribilegio baxuko erabiltzaile gisa exekutatzen da.

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

Testing

Proxya martxan dagoela, probak egin eta prozesatu daitezke orain. Ondoko cURL komandoak eskaera bat igortzen du proxy konfigurazioan zehaztutako ostalariaren goiburuarekin.

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

HTTP eskaerak errore bat eragingo du 503. Hau da, upstream konexioak ez direlako funtzionatzen eta ez daudelako erabilgarri. Beraz, Envoy Proxy-k ez du eskaerarako helmuga erabilgarririk. Hurrengo komandoak Envoy-erako definitutako konfigurazioarekin bat datozen HTTP zerbitzu sorta bat abiaraziko du.

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

Eskuragarri dauden zerbitzuekin, Envoy-ek trafikoa behar bezala bidal dezake bere helmugara.

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

Eskaera zein Docker edukiontzi prozesatu duen adierazten duen erantzun bat ikusi beharko zenuke. Envoy Proxy erregistroetan sarbide-katearen irteera ere ikusi beharko zenuke.

HTTP erantzunen goiburu osagarriak

HTTP goiburu osagarriak ikusiko dituzu benetako eskaeraren erantzunen goiburuetan. Goiburuak gorako ostalariak eskaera prozesatzen eman duen denbora erakusten du. Milisegundotan adierazita. Hau erabilgarria da bezeroak zerbitzuaren denbora zehaztu nahi badu sareko latentziarekin alderatuta.

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

Azken konfigurazioa

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 }

Itzultzailearen informazio gehigarria

Envoy Proxy instalatzeko jarraibideak webgunean aurki daitezke https://www.getenvoy.io/

Lehenespenez, rpm-k ez du systemd zerbitzuaren konfiguraziorik.

Gehitu systemd zerbitzuaren konfigurazioa /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

/etc/envoy/ direktorio bat sortu eta config.yaml konfigurazioa bertan jarri behar duzu.

Telegram txat bat dago envoy proxy erabiliz: https://t.me/envoyproxy_ru

Envoy Proxy-k ez du onartzen eduki estatikoa hornitzea. Beraz, nork bozkatu dezake funtzioaren alde: https://github.com/envoyproxy/envoy/issues/378

Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. Hasi saioa, mesedez.

Mezu honek envoy proxy instalatzera eta probatzera animatu zaitu?

  • Bai

  • Π½Π΅Ρ‚

75 erabiltzailek eman dute botoa. 18 erabiltzaile abstenitu ziren.

Iturria: www.habr.com

Gehitu iruzkin berria