Migraasje fan Nginx nei Envoy Proxy

Hallo, Habr! Ik bring jo oandacht in oersetting fan it berjocht: Migraasje fan Nginx nei Envoy Proxy.

Envoy is in hege-optreden ferspraat proxy tsjinner (skreaun yn C ++) ûntwurpen foar yndividuele tsjinsten en applikaasjes, it is ek in kommunikaasje bus en "universele gegevens fleanmasine" ûntwurpen foar grutte microservice "service mesh" arsjitektuer. By it oanmeitsjen fan it, waarden oplossingen foar problemen dy't ûntstienen by de ûntwikkeling fan servers lykas NGINX, HAProxy, hardware load balancers en cloud load balancers yn rekken brocht. Envoy wurket neist elke applikaasje en abstraheret it netwurk om mienskiplike funksjonaliteit te leverjen, nettsjinsteande platfoarm. As alle tsjinstferkear yn in ynfrastruktuer troch it Envoy-mesh streamt, wurdt it maklik om probleemgebieten te visualisearjen mei konsekwinte waarnimmberens, algemiene prestaasjes ôfstimme en kearnfunksjonaliteit ta te foegjen op in spesifike lokaasje.

Eigenskippen

  • Out-of-proses arsjitektuer: envoy is in selsstannige, hege prestaasjes tsjinner dy't nimt in lyts bedrach fan RAM. It wurket yn gearhing mei elke tapassingstaal of ramt.
  • http/2 en grpc-stipe: envoy hat earste-klasse http/2- en grpc-stipe foar ynkommende en útgeande ferbiningen. Dit is in transparante proxy fan http/1.1 nei http/2.
  • Avansearre load balancing: envoy stipet avansearre load balancing funksjes ynklusyf automatyske opnij besykjen, keatling brekken, globale taryf beheinen, fersyk shadowing, lokale sône load balancing, ensfh.
  • Configuration Management API: envoy leveret in robúste API foar dynamysk behear fan jo konfiguraasje.
  • Observabiliteit: Djippe waarnimmberens fan L7-ferkear, native stipe foar ferspraat tracing en observabiliteit fan mongodb, dynamodb en in protte oare applikaasjes.

Stap 1 - Foarbyld NGINX Config

Dit skript brûkt in spesjaal makke bestân nginx.conf, basearre op it folsleine foarbyld fan NGINX Wiki. Jo kinne de konfiguraasje yn 'e bewurker besjen troch te iepenjen nginx.conf

nginx boarne konfiguraasje

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-konfiguraasjes hawwe typysk trije wichtige eleminten:

  1. Konfigurearje NGINX-tsjinner, logstruktuer en Gzip-funksjonaliteit. Dit is yn alle gefallen wrâldwiid definiearre.
  2. NGINX konfigurearje om fersiken nei de host te akseptearjen one.example.com op haven 8080.
  3. It ynstellen fan de doellokaasje, hoe omgean mei ferkear foar ferskate dielen fan 'e URL.

Net alle konfiguraasje sil jilde foar Envoy Proxy, en jo hoege net te konfigurearjen guon ynstellings. Envoy Proxy hat fjouwer kaai types, dy't de kearnynfrastruktuer stypje oanbean troch NGINX. De kearn is:

  • Harkers: Se bepale hoe't Envoy Proxy ynkommende oanfragen akseptearret. Envoy Proxy stipet op it stuit allinnich TCP-basearre harkers. Sadree't in ferbining is oprjochte, wurdt trochjûn oan in set fan filters foar ferwurking.
  • Filters: Se meitsje diel út fan in pipeline-arsjitektuer dy't ynkommende en útgeande gegevens kin ferwurkje. Dizze funksjonaliteit omfettet filters lykas Gzip, dy't de gegevens komprimearret foardat se nei de kliïnt ferstjoere.
  • Routers: Se stjoere ferkear nei de fereaske bestimming, definiearre as in kluster.
  • Klusters: Se definiearje it einpunt foar ferkear- en konfiguraasjeparameters.

Wy sille dizze fjouwer komponinten brûke om in Envoy Proxy-konfiguraasje te meitsjen dy't oerienkomt mei in spesifike NGINX-konfiguraasje. It doel fan Envoy is om te wurkjen mei API's en dynamyske konfiguraasje. Yn dit gefal sil de basiskonfiguraasje statyske, hurdkodearre ynstellingen fan NGINX brûke.

Stap 2 - NGINX-konfiguraasje

Earste diel nginx.conf definiearret guon NGINX-ynternen dy't moatte wurde konfigureare.

Worker Connections

De konfiguraasje hjirûnder bepaalt it oantal arbeidersprosessen en ferbiningen. Dit jout oan hoe't NGINX sil skaalfergrutting om te foldwaan oan fraach.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy beheart workflows en ferbiningen op ferskate manieren.

Envoy makket in worker thread foar elke hardware thread op it systeem. Eltse worker thread fiert in net-blokkearjende evenemint loop dat is ferantwurdlik foar

  1. Harkje nei elke harker
  2. Akseptearje nije ferbinings
  3. It meitsjen fan in set fan filters foar in ferbining
  4. Ferwurkje alle I / O operaasjes yn it libben fan de ferbining.

Alle fierdere ferbining ferwurking wurdt ôfhannele hielendal yn 'e arbeider thread, ynklusyf alle trochstjoere gedrach.

Foar elke arbeider thread yn Envoy is der in ferbining yn it swimbad. Dat HTTP/2-ferbiningspools meitsje mar ien ferbining per eksterne host tagelyk, as d'r fjouwer arbeidersthreads binne, sille d'r fjouwer HTTP/2-ferbiningen per eksterne host yn in stabile steat wêze. Troch alles yn ien wurktried te hâlden, kin hast alle koade sûnder blokkearjen skreaun wurde, as wie it ien thread. As mear worker triedden wurde tawiisd as nedich, dit kin liede ta fergriemd ûnthâld, it meitsjen fan in grut oantal idle ferbinings, en it ferminderjen fan it oantal ferbinings werom nei it swimbad.

Foar mear ynformaasje besykje Envoy Proxy blog.

HTTP konfiguraasje

It folgjende NGINX-konfiguraasjeblok definiearret HTTP-ynstellingen lykas:

  • Hokker mime-typen wurde stipe
  • Standert Timeouts
  • Gzip-konfiguraasje

Jo kinne dizze aspekten oanpasse mei filters yn Envoy Proxy, dy't wy letter sille beprate.

Stap 3 - Server konfiguraasje

Yn it HTTP-konfiguraasjeblok spesifiseart de NGINX-konfiguraasje om te harkjen op poarte 8080 en te reagearjen op ynkommende oanfragen foar domeinen one.example.com и www.one.example.com.

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

Binnen Envoy wurdt it kontrolearre troch Listeners.

Envoy harkers

It wichtichste aspekt om te begjinnen mei Envoy Proxy is it definiearjen fan jo harkers. Jo moatte in konfiguraasjetriem oanmeitsje dy't beskriuwt hoe't jo de Envoy-eksimplaar útfiere wolle.

It snippet hjirûnder sil in nije harker meitsje en it bine oan poarte 8080. De konfiguraasje fertelt Envoy Proxy oan hokker havens it bine moat foar ynkommende fersiken.

Envoy Proxy brûkt YAML-notaasje foar syn konfiguraasje. Sjoch hjir foar in ynlieding op dizze notaasje link.

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

Gjin needsaak om te definiearjen Server Namme, sûnt Envoy Proxy filters sille omgean dit.

Stap 4 - Lokaasje konfiguraasje

As in fersyk yn NGINX komt, bepaalt it lokaasjeblok hoe't it ferwurke wurdt en wêr't it ferkear moat wurde rout. Yn it folgjende fragmint wurdt al it ferkear nei de side oerbrocht nei in streamop (oersetternotysje: streamop is normaal in applikaasjetsjinner) kluster neamd targetCluster. De streamopkluster definiearret de knopen dy't it fersyk moatte ferwurkje. Wy sille dit besprekke yn 'e folgjende stap.

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

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

By Envoy docht Filters dit.

Envoy Filters

Foar in statyske konfiguraasje bepale filters hoe't te ferwurkjen ynkommende fersiken. Yn dit gefal sette wy filters yn dy't oerienkomme server_names yn 'e foarige stap. As ynkommende oanfragen oankomme dy't oerienkomme mei bepaalde domeinen en rûtes, wurdt ferkear trochstjoerd nei it kluster. Dit is it ekwivalint fan in NGINX bottom-up konfiguraasje.

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

namme envoy.http_connection_manager is in ynboude filter yn Envoy Proxy. Oare filters omfetsje Redis, Mongo, TCP. Jo kinne de folsleine list fine op dokumintaasje.

Foar mear ynformaasje oer oare belesting balancing belied, besykje Envoy dokumintaasje.

Stap 5 - Proxy en Upstream konfiguraasje

Yn NGINX definieart de streamopkonfiguraasje in set fan doeltsjinners dy't ferkear ferwurkje. Yn dit gefal waarden twa klusters tawiisd.

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

Yn Envoy wurdt dit beheard troch klusters.

Envoy Klusters

It upstream ekwivalint wurdt definiearre as klusters. Yn dit gefal binne de hosts identifisearre dy't it ferkear sille tsjinje. De manier wêrop tagong wurdt ta hosts, lykas timeouts, wurdt definiearre as in klusterkonfiguraasje. Dit soarget foar mear korrelige kontrôle oer aspekten lykas latency en load balancing.

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

By it brûken fan tsjinst ûntdekking STRICT_DNS Envoy sil de oantsjutte DNS-doelen kontinu en asynchronysk oplosse. Elk weromjûn IP-adres fan it DNS-resultaat sil wurde beskôge as in eksplisite host yn it streamop-kluster. Dit betsjut dat as in fersyk twa IP-adressen werombringt, sil Envoy der fanút gean dat d'r twa hosts binne yn it kluster, en beide moatte loadbalansearre wêze. As in host wurdt fuorthelle út it resultaat, Envoy sil oannimme dat it net mear bestiet en sil lûke ferkear út alle besteande ferbining pools.

Foar mear ynformaasje sjoch Envoy proxy dokumintaasje.

Stap 6 - Log tagong en flaters

De definitive konfiguraasje is registraasje. Ynstee fan flaterlogs nei skiif te drukken, nimt Envoy Proxy in wolkbasearre oanpak. Alle applikaasje logs wurde útfierd nei stdout и stderr.

As brûkers in fersyk meitsje, binne tagongslogboeken opsjoneel en standert útskeakele. Om tagongslogboeken foar HTTP-oanfragen yn te skeakeljen, skeakelje de konfiguraasje yn tagong_log foar de HTTP-ferbiningbehearder. It paad kin wêze of in apparaat lykas stdout, of in triem op skiif, ôfhinklik fan jo easken.

De folgjende konfiguraasje sil alle tagongslogboeken omliede nei stdout (Opmerking fan 'e oersetter - stdout is nedich om envoy binnen docker te brûken. As brûkt sûnder docker, ferfange dan /dev/stdout mei it paad nei in gewoane lochbestân). Kopiearje it snippet nei de konfiguraasjediel foar de ferbiningbehearder:

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

De resultaten moatte der sa útsjen:

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

Standert hat Envoy in opmaakstring dy't de details fan it HTTP-fersyk omfettet:

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

It resultaat fan dizze opmaakstring is:

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

De útfierynhâld kin oanpast wurde troch it opmaakfjild yn te stellen. Bygelyks:

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"

De logline kin ek wurde útfierd yn JSON-formaat troch it fjild yn te stellen json_format. Bygelyks:

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

Foar mear ynformaasje oer de metoade foar registraasje fan gesant, besykje

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

Logging is net de ienige manier om ynsjoch te krijen yn it wurkjen mei Envoy Proxy. It hat avansearre tracing- en metrikemooglikheden ynboud. Jo kinne mear útfine op tracing dokumintaasje as troch Ynteraktyf tracing skript.

Stap 7 - Launch

Jo hawwe jo konfiguraasje no migrearre fan NGINX nei Envoy Proxy. De lêste stap is om in Envoy Proxy-eksimplaar te starten om it te testen.

Run as brûker

Oan 'e boppekant fan' e NGINX-konfiguraasjeline brûker www www; spesifisearret om NGINX út te fieren as in leech-privilegearre brûker om feiligens te ferbetterjen.

Envoy Proxy nimt in wolkbasearre oanpak foar it behearen fan wa't in proses hat. As wy Envoy Proxy troch in kontener útfiere, kinne wy ​​in brûker mei leech befoarrjochte spesifisearje.

Launching Envoy Proxy

It kommando hjirûnder sil Envoy Proxy útfiere fia in Docker-kontener op 'e host. Dit kommando jout Envoy de mooglikheid om te harkjen nei ynkommende fersiken op haven 80. Lykwols, lykas oantsjutte yn de harker konfiguraasje, Envoy Proxy harket nei ynkommende ferkear op haven 8080. Dit makket it mooglik dat it proses te rinnen as in lege-privilegearre brûker.

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

Testing

Mei't de proxy rint, kinne no testen wurde makke en ferwurke. It folgjende cURL-kommando jout in fersyk út mei de host-header definieare yn de proxy-konfiguraasje.

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

It HTTP-fersyk sil resultearje yn in flater 503. Dit komt om't streamopferbiningen net wurkje en net beskikber binne. Dêrom hat Envoy Proxy gjin beskikbere bestimmingen foar it fersyk. It folgjende kommando sil in searje HTTP-tsjinsten begjinne dy't oerienkomme mei de konfiguraasje definieare foar Envoy.

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

Mei de beskikbere tsjinsten kin Envoy ferkear ferkear mei súkses proxy nei syn bestimming.

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

Jo moatte in antwurd sjen dat oanjout hokker Docker-container it fersyk ferwurke. Yn 'e Envoy Proxy-logs moatte jo ek in tagongsstringútfier sjen.

Oanfoljende HTTP-antwurdkoppen

Jo sille ekstra HTTP-koppen sjen yn 'e antwurdkoppen fan it eigentlike fersyk. De koptekst toant de tiid dat de streamop-host bestege oan it ferwurkjen fan it fersyk. Utdrukt yn millisekonden. Dit is handich as de kliïnt de tsjinsttiid bepale wol yn ferliking mei netwurklatinsje.

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

Finale konfiguraasje

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 }

Oanfoljende ynformaasje fan de oersetter

Ynstruksjes foar it ynstallearjen fan Envoy Proxy kinne fûn wurde op 'e webside https://www.getenvoy.io/

Standert hat rpm gjin systemd tsjinst konfiguraasje.

Foegje systemd service config /etc/systemd/system/envoy.service ta:

[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

Jo moatte in map meitsje /etc/envoy/ en dêr de config.yaml config pleatse.

D'r is in telegrampetear mei help fan envoy proxy: https://t.me/envoyproxy_ru

Envoy Proxy stipet gjin tsjinjen fan statyske ynhâld. Dêrom, wa kin stimme foar de funksje: https://github.com/envoyproxy/envoy/issues/378

Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. Ynlogge, asjebleaft.

Hat dizze post jo oanmoedige om envoy-proxy te ynstallearjen en te testen?

  • ja

  • gjin

75 brûkers stimden. 18 brûkers ûntholden har.

Boarne: www.habr.com

Add a comment