🥇Migrado de Nginx al Envoy Proxy

Saluton, Habr! Mi atentigas al vi tradukon de la afiŝo: Migrado de Nginx al Envoy Proxy.

Envoy estas alt-efikeca distribuita prokura servilo (skribita en C++) dizajnita por individuaj servoj kaj aplikoj, ĝi ankaŭ estas komunika buso kaj "universala datumaviadilo" desegnita por grandaj mikroservoj "servomaŝo" arkitekturoj. Kreante ĝin, solvoj al problemoj, kiuj ŝprucis dum la disvolvado de serviloj kiel NGINX, HAProxy, aparataj ŝarĝobalanciloj kaj nuba ŝarĝo-balanciloj estis konsiderataj. Envoy funkcias kune kun ĉiu aplikaĵo kaj abstraktas la reton por disponigi komunan funkciecon sendepende de platformo. Kiam la tuta serva trafiko en infrastrukturo fluas tra la Envoy-maŝo, fariĝas facile bildigi problemajn areojn kun konsekvenca observebleco, agordi ĝeneralan rendimenton kaj aldoni kernan funkcion en specifa loko.

Trajtoj

Eksterproceza arkitekturo: sendito estas memstara, alt-efikeca servilo, kiu okupas malgrandan kvanton da RAM. Ĝi funkcias kune kun iu ajn aplika lingvo aŭ kadro.
http/2 kaj grpc-subteno: sendito havas bonegan http/2 kaj grpc-subtenon por enirantaj kaj elirantaj konektoj. Ĉi tio estas travidebla prokurilo de http/1.1 al http/2.
Altnivela Ŝarĝbalancado: sendito subtenas altnivelajn ŝarĝbalancajn funkciojn inkluzive de aŭtomataj reprovoj, ĉenrompado, tutmonda tariflimigo, peto-ombrado, loka zono-ŝarĝbalancado ktp.
API-Administrado de Agordo: sendito provizas fortikan API por dinamike administri vian agordon.
Observeblo: Profunda observeblo de L7-trafiko, indiĝena subteno por distribuita spurado kaj observeblo de mongodb, dynamodb kaj multaj aliaj aplikoj.

Paŝo 1 - Ekzemplo NGINX-Agordo

Ĉi tiu skripto uzas speciale kreitan dosieron nginx.conf, surbaze de la plena ekzemplo de NGINX-Vikio. Vi povas vidi la agordon en la redaktilo malfermante nginx.conf

nginx fonta agordo

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-agordoj kutime havas tri ŝlosilajn elementojn:

Agordante NGINX-servilon, protokolan strukturon kaj Gzip-funkciecon. Ĉi tio estas difinita tutmonde en ĉiuj kazoj.
Agordante NGINX por akcepti petojn al la gastiganto unu.ekzemplo.com sur haveno 8080.
Agordo de la cela loko, kiel trakti trafikon por malsamaj partoj de la URL.

Ne ĉiu agordo aplikiĝos al Envoy Proxy, kaj vi ne bezonas agordi iujn agordojn. Envoy Proxy havas kvar ŝlosilaj tipoj, kiuj subtenas la kernan infrastrukturon ofertitan de NGINX. La kerno estas:

Aŭskultantoj: Ili determinas kiel Envoy Proxy akceptas alvenantajn petojn. Envoy Proxy nuntempe nur subtenas TCP-bazitajn aŭskultantojn. Post kiam konekto estas establita, ĝi estas pasita al aro de filtriloj por prilaborado.
Filtriloj: Ili estas parto de dukto-arkitekturo kiu povas prilabori envenantajn kaj elirantajn datumojn. Ĉi tiu funkcio inkluzivas filtrilojn kiel Gzip, kiu kunpremas la datumojn antaŭ ol sendi ĝin al la kliento.
Enkursigiloj: Ili plusendas trafikon al la postulata celloko, difinita kiel areto.
Aretoj: Ili difinas la finpunkton por trafiko kaj agordaj parametroj.

Ni uzos ĉi tiujn kvar komponantojn por krei Envoy Proxy-agordon por kongrui kun specifa NGINX-agordo. La celo de Envoy estas labori kun API-oj kaj dinamika agordo. En ĉi tiu kazo, la baza agordo uzos statikajn, malmolajn agordojn de NGINX.

Paŝo 2 - Agordo de NGINX

Unua parto nginx.conf difinas kelkajn NGINX-internaĵojn kiuj devas esti agordita.

Laboristaj Ligoj

La suba agordo determinas la nombron da laborprocezoj kaj konektoj. Ĉi tio indikas kiel NGINX skalos por plenumi postulon.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy administras laborfluojn kaj konektojn en malsamaj manieroj.

Envoy kreas laborfadenon por ĉiu aparatara fadeno sur la sistemo. Ĉiu laborfadeno ekzekutas ne-blokan okazaĵbuklon pri kiu respondecas

Aŭskultante ĉiun aŭskultanton
Akceptante novajn konektojn
Kreante aron da filtriloj por konekto
Prilaboru ĉiujn I/O-operaciojn dum la vivdaŭro de la konekto.

Ĉiu plia konektpretigo estas pritraktita tute en la laborfadeno, inkluzive de ajna plusendado-konduto.

Por ĉiu laborfadeno en Envoy, ekzistas konektogrupo. Do HTTP/2-konektoj nur establas unu konekton per ekstera gastiganto samtempe, se estas kvar laborfadenoj, estos kvar HTTP/2-konektoj per ekstera gastiganto en stabila stato. Tenante ĉion en unu laborfadeno, preskaŭ ĉio kodo povas esti skribita sen blokado, kvazaŭ ĝi estus ununura fadeno. Se pli da laborfadenoj estas asignitaj ol necese, tio povas konduki al malŝparita memoro, kreante grandan nombron da neaktivaj ligoj, kaj reduktante la nombron da fojoj kiam ligoj estas resenditaj al la naĝejo.

Por pliaj informoj vizitu Envoy Proxy-blogo.

HTTP-Agordo

La sekva NGINX-agorda bloko difinas HTTP-agordojn kiel ekzemple:

Kiaj mimspecoj estas subtenataj
Defaŭltaj Tempotempoj
Gzip-agordo

Vi povas personecigi ĉi tiujn aspektojn uzante filtrilojn en Envoy Proxy, pri kiuj ni diskutos poste.

Paŝo 3 - Servila Agordo

En la HTTP-agorda bloko, la NGINX-agordo specifas aŭskulti sur la haveno 8080 kaj respondi al envenantaj petoj por domajnoj. unu.ekzemplo.com и www.one.example.com.

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

Ene de Envoy, ĝi estas kontrolita fare de Aŭskultantoj.

Senditaj aŭskultantoj

La plej grava aspekto por komenci kun Envoy Proxy estas difini viajn aŭskultantojn. Vi devas krei agordan dosieron, kiu priskribas kiel vi volas ruli la ekzemplon Envoy.

La malsupra fragmento kreos novan aŭskultanton kaj ligos ĝin al haveno 8080. La agordo diras al Envoy Proxy al kiuj havenoj ĝi devas ligi por alvenantaj petoj.

Envoy Proxy uzas YAML-notacion por sia agordo. Por enkonduko al ĉi tiu notacio, rigardu ĉi tie ligilo.

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

Ne necesas difini servilo_nomo, ĉar Envoy Proxy-filtriloj pritraktos ĉi tion.

Paŝo 4 - Loka Agordo

Kiam peto venas en NGINX, la loka bloko determinas kiel prilabori kaj kien direkti la trafikon. En la sekva fragmento, la tuta trafiko al la retejo estas transdonita al kontraŭflua (noto de la tradukisto: kontraŭflue estas kutime aplikaĵoservilo) nomita areto. celCluster. La kontraŭflua areto difinas la nodojn kiuj devus prilabori la peton. Ni diskutos ĉi tion en la sekva paŝo.

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

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

Ĉe Envoy, Filtriloj faras tion.

Envoy Filtriloj

Por senmova agordo, filtriloj determinas kiel prilabori envenantajn petojn. En ĉi tiu kazo ni starigas filtrilojn kiuj kongruas servilo_nomoj en la antaŭa paŝo. Kiam alvenantaj petoj alvenas kiuj kongruas kun certaj domajnoj kaj itineroj, trafiko estas direktita al la areto. Ĉi tio estas la ekvivalento de malsupra agordo de NGINX.

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

nomo sendito.http_connection_manager estas enkonstruita filtrilo en Envoy Proxy. Aliaj filtriloj inkluzivas Redis, Mongo, TCP. Vi povas trovi la kompletan liston ĉe dokumentado.

Por pliaj informoj pri aliaj ŝarĝaj ekvilibraj politikoj, vizitu Envoy Dokumentado.

Paŝo 5 - Prokura kaj Kontraŭflua Agordo

En NGINX, la kontraŭflua agordo difinas aron da celserviloj, kiuj prilaboros trafikon. En ĉi tiu kazo, du aretoj estis asignitaj.

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

En Envoy, ĉi tio estas administrita de aretoj.

Senditaj Aretoj

La kontraŭflua ekvivalento estas difinita kiel aretoj. En ĉi tiu kazo, la gastigantoj, kiuj servos la trafikon, estis identigitaj. La maniero kiel gastigantoj estas aliritaj, kiel tempotempoj, estas difinita kiel cluster-agordo. Ĉi tio permesas pli granulan kontrolon de aspektoj kiel latencia kaj ŝarĝbalancado.

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

Kiam vi uzas servo-malkovron STRICT_DNS Envoy kontinue kaj nesinkrone solvos la specifitajn DNS-celojn. Ĉiu resendita IP-adreso de la DNS-rezulto estos konsiderata eksplicita gastiganto en la kontraŭflua areto. Ĉi tio signifas, ke se peto resendas du IP-adresojn, Envoy supozos, ke estas du gastigantoj en la areto, kaj ambaŭ devas esti ŝarĝitaj ekvilibraj. Se gastiganto estas forigita de la rezulto, Envoy supozos ke ĝi ne plu ekzistas kaj tiros trafikon de iuj ekzistantaj konektgrupoj.

Por pliaj informoj vidu Envoy prokura dokumentaro.

Paŝo 6 — Ensalutu Aliro kaj Eraroj

La fina agordo estas registriĝo. Anstataŭ puŝi erarprogramojn al disko, Envoy Proxy prenas nub-bazitan aliron. Ĉiuj aplikaj protokoloj estas eligitaj al stdout и stderr.

Kiam uzantoj faras peton, alirprotokoloj estas laŭvolaj kaj malŝaltitaj defaŭlte. Por ebligi alirprotokolojn por HTTP-petoj, ebligu la agordon aliro_log por la HTTP-konektadministranto. La vojo povas esti aŭ aparato kiel ekzemple stdout, aŭ dosieron sur disko, depende de viaj postuloj.

La sekva agordo redirektos ĉiujn alirprogramojn al stdout (Noto de la tradukinto - stdout estas postulata por uzi envoy ene de docker. Se uzata sen docker, tiam anstataŭigu /dev/stdout per la vojo al regula protokolo-dosiero). Kopiu la fragmenton al la agorda sekcio por la koneksa administranto:

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

La rezultoj devus aspekti jene:

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

Defaŭlte, Envoy havas formaton, kiu inkluzivas la detalojn de la HTTP-peto:

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

La rezulto de ĉi tiu formata ĉeno estas:

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

La eligo enhavo povas esti personecigita fiksante la formato kampo. Ekzemple:

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"

La protokollinio ankaŭ povas esti eligita en JSON-formato fiksante la kampon json_format. Ekzemple:

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

Por pliaj informoj pri la Envoy-Registrado-Metodologio, vizitu

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

Registrado ne estas la sola maniero akiri sciojn pri laboro kun Envoy Proxy. Ĝi havas progresintajn spurajn kaj metrikajn kapablojn enkonstruitajn en ĝi. Vi povas ekscii pli ĉe spura dokumentado aŭ tra Interaga spura skripto.

Paŝo 7 - Lanĉo

Vi nun migris vian agordon de NGINX al Envoy Proxy. La lasta paŝo estas lanĉi Envoy Proxy-instancon por testi ĝin.

Kuru kiel uzanto

Ĉe la supro de la agorda linio NGINX uzanto www www; specifas ruli NGINX kiel malalt-privilegia uzanto por plibonigi sekurecon.

Envoy Proxy prenas nub-bazitan aliron por administri kiu posedas procezon. Kiam ni rulas Envoy Proxy tra ujo, ni povas specifi malaltan privilegiitan uzanton.

Lanĉante Envoy Proxy

La suba komando funkcios Envoy Proxy per Docker-ujo sur la gastiganto. Ĉi tiu komando donas al Envoy la kapablon aŭskulti por envenantaj petoj sur haveno 80. Tamen, kiel specifite en la aŭskultanto-agordo, Envoy Proxy aŭskultas por envenanta trafiko sur haveno 8080. Ĉi tio permesas al la procezo funkcii kiel malalt-privilegia uzanto.

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

Testado

Kun la prokurilo funkcias, provoj nun povas esti faritaj kaj prilaboritaj. La sekva cURL-komando eldonas peton kun la gastiga kaplinio difinita en la prokura agordo.

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

La HTTP-peto rezultigos eraron 503. Ĉi tio estas ĉar kontraŭfluaj konektoj ne funkcias kaj ne disponeblas. Tial Envoy Proxy ne havas disponeblajn cellokojn por la peto. La sekva komando komencos serion de HTTP-servoj, kiuj kongruas kun la agordo difinita por Envoy.

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

Kun la disponeblaj servoj, Envoy povas sukcese prokura trafiko al sia celloko.

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

Vi devus vidi respondon indikantan kiu Docker-ujo prilaboris la peton. En la prokuroroj de Envoy Proxy vi ankaŭ devus vidi eliron de aliro ĉeno.

Pliaj HTTP-Respondaj Kapoj

Vi vidos pliajn HTTP-kapojn en la respondaj kaplinioj de la reala peto. La kaplinio montras la tempon, kiun la kontraŭflua gastiganto pasigis por prilabori la peton. Esprimite en milisekundoj. Ĉi tio estas utila se la kliento volas determini servotempon kompare kun reta latenco.

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

Fina agordo

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 }

Pliaj informoj de la tradukinto

Instrukcioj por instali Envoy Proxy troveblas en la retejo https://www.getenvoy.io/

Defaŭlte, rpm ne havas systemd-servan agordon.

Aldonu agordon de systemd servo /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

Vi devas krei dosierujon /etc/envoy/ kaj meti la agordon config.yaml tie.

Estas telegrama babilejo uzante senditan prokurilon: https://t.me/envoyproxy_ru

Envoy Proxy ne subtenas servadon de senmova enhavo. Tial, kiu povas voĉdoni por la funkcio: https://github.com/envoyproxy/envoy/issues/378

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Ĉu ĉi tiu afiŝo instigis vin instali kaj testi senditan prokurilon?

jes
neniu

75 uzantoj voĉdonis. 18 uzantoj sindetenis.

fonto: www.habr.com

Migrado de Nginx al Envoy Proxy