ProHoster > Blog > Stjórnsýsla > Flutningur frá Nginx til sendifulltrúa

Flutningur frá Nginx til sendifulltrúa

Halló, Habr! Ég vek athygli á þýðingu á færslunni: Flutningur frá Nginx til sendifulltrúa.

Envoy er afkastamikill dreifður proxy-þjónn (skrifaður í C++) hannaður fyrir einstakar þjónustur og forrit, hann er líka samskiptarúta og „alhliða gagnaplan“ hannað fyrir stóra „þjónustumöskva“ arkitektúr. Við gerð þess var tekið tillit til lausna á vandamálum sem komu upp við þróun netþjóna eins og NGINX, HAProxy, vélbúnaðarálagsjafnara og skýjahlaðajafnara. Sendiherra vinnur við hlið hvers forrits og dregur út netið til að veita sameiginlega virkni óháð vettvangi. Þegar öll þjónustuumferð í innviði rennur í gegnum Envoy-netið, verður auðvelt að sjá vandamálasvæði með samkvæmri athugun, stilla heildarframmistöðu og bæta við kjarnavirkni á tilteknum stað.

Hæfileiki

  • Arkitektúr sem er ekki í ferli: Envoy er sjálfstæður, afkastamikill netþjónn sem tekur lítið magn af vinnsluminni. Það virkar í tengslum við hvaða forritamál eða ramma sem er.
  • http/2 og grpc stuðningur: envoy er með fyrsta flokks http/2 og grpc stuðning fyrir komandi og útleiðandi tengingar. Þetta er gagnsætt umboð frá http/1.1 til http/2.
  • Háþróuð álagsjöfnun: sendifulltrúi styður háþróaða álagsjafnvægi, þar á meðal sjálfvirkar tilraunir aftur, keðjubrot, hnattræna takmörkun á gjaldskrá, skyggingu á beiðni, álagsjöfnun á staðbundnu svæði o.s.frv.
  • Stillingarstjórnunarforritaskil: sendiherra býður upp á öflugt API til að stjórna stillingunum þínum á virkan hátt.
  • Athugun: Djúpur athuganleiki L7 umferðar, innbyggður stuðningur við dreifða rekja og athuganleika mongodb, dynamodb og margra annarra forrita.

Skref 1 — Dæmi NGINX Config

Þetta handrit notar sérsmíðaða skrá nginx.conf, byggt á heildardæminu frá NGINX Wiki. Þú getur skoðað uppsetninguna í ritlinum með því að opna nginx.conf

nginx frumstillingar

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 stillingar hafa venjulega þrjá lykilþætti:

  1. Stilla NGINX miðlara, log uppbyggingu og Gzip virkni. Þetta er skilgreint á heimsvísu í öllum tilvikum.
  2. Stillir NGINX til að samþykkja beiðnir til gestgjafans one.example.com á port 8080.
  3. Setja upp markstaðsetningu, hvernig á að meðhöndla umferð fyrir mismunandi hluta vefslóðarinnar.

Ekki munu allar stillingar eiga við umboð sendifulltrúa og þú þarft ekki að stilla sumar stillingar. Sendifulltrúi hefur fjórar lykilgerðir, sem styðja kjarnainnviði sem NGINX býður upp á. Kjarninn er:

  • Hlustendur: Þeir ákvarða hvernig umboð sendifulltrúa tekur við beiðnum sem berast. Envoy Proxy styður sem stendur aðeins TCP-undirstaða hlustendur. Þegar tenging hefur verið komið á er hún send í sett af síum til vinnslu.
  • Síur: Þau eru hluti af leiðsluarkitektúr sem getur unnið úr gögnum sem koma og út. Þessi virkni inniheldur síur eins og Gzip, sem þjappar gögnunum saman áður en þau eru send til viðskiptavinarins.
  • Beinar: Þeir senda umferð á tilskilinn áfangastað, skilgreindan sem klasa.
  • Klasar: Þeir skilgreina endapunkt fyrir umferðar- og stillingarfæribreytur.

Við munum nota þessa fjóra íhluti til að búa til uppsetningu sendiboða til að passa við ákveðna NGINX uppsetningu. Markmið Envoy er að vinna með API og kraftmikla stillingar. Í þessu tilviki mun grunnstillingin nota kyrrstæðar, harðkóðaðar stillingar frá NGINX.

Skref 2 - NGINX stillingar

Í fyrsta hluta nginx.conf skilgreinir nokkur NGINX innri sem þarf að stilla.

Tengsl starfsmanna

Stillingin hér að neðan ákvarðar fjölda starfsmannaferla og tenginga. Þetta gefur til kynna hvernig NGINX mun stækka til að mæta eftirspurn.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy heldur utan um verkflæði og tengingar á mismunandi hátt.

Envoy býr til starfsþráð fyrir hvern vélbúnaðarþráð í kerfinu. Hver starfsþráður framkvæmir ólokandi atburðarlykkju sem ber ábyrgð á

  1. Að hlusta á hvern hlustanda
  2. Að samþykkja nýjar tengingar
  3. Að búa til sett af síum fyrir tengingu
  4. Vinnið úr öllum I/O-aðgerðum meðan á tengingunni stendur.

Öll frekari tengingarvinnsla er meðhöndluð alfarið í starfsþræðinum, þar með talið hvers kyns framsendingarhegðun.

Fyrir hvern starfsþráð í Envoy er tengilaug. Þannig að HTTP/2 tengingarhópar koma aðeins á einni tengingu á hvern ytri hýsil í einu, ef það eru fjórir vinnuþræðir verða fjórar HTTP/2 tengingar á hvern ytri hýsil í stöðugu ástandi. Með því að halda öllu í einum vinnuþræði er hægt að skrifa næstum allan kóða án þess að loka, eins og hann væri einn þráður. Ef fleiri starfsþráðum er úthlutað en nauðsynlegt er getur það leitt til sóunar á minni, búið til fjölda aðgerðalausra tenginga og fækkað þeim tengingum sem skila sér aftur í laugina.

Fyrir frekari upplýsingar heimsókn Sendiboði umboðsblogg.

HTTP stillingar

Eftirfarandi NGINX stillingarblokk skilgreinir HTTP stillingar eins og:

  • Hvaða mime tegundir eru studdar
  • Sjálfgefin tímamörk
  • Gzip stillingar

Þú getur sérsniðið þessa þætti með því að nota síur í Envoy Proxy, sem við munum ræða síðar.

Skref 3 - Stilling netþjóns

Í HTTP stillingarreitnum tilgreinir NGINX stillingar að hlusta á höfn 8080 og bregðast við komandi beiðnum um lén one.example.com и www.eitt.dæmi.is.

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

Inni í Envoy er því stjórnað af hlustendum.

Sendiherra hlustendur

Mikilvægasti þátturinn við að byrja með Envoy Proxy er að skilgreina hlustendur þína. Þú þarft að búa til stillingarskrá sem lýsir því hvernig þú vilt keyra Envoy tilvikið.

Bútinn hér að neðan mun búa til nýjan hlustanda og binda hann við port 8080. Uppsetningin segir Envoy Proxy hvaða tengi hann ætti að bindast við komandi beiðnir.

Envoy Proxy notar YAML merkingu fyrir uppsetningu sína. Til að fá kynningu á þessari merkingu, skoðaðu hér hlekkur.

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

Óþarfi að skilgreina netþjóni, þar sem Envoy Proxy síur munu sjá um þetta.

Skref 4 - Staðsetningarstillingar

Þegar beiðni kemur inn í NGINX ákvarðar staðsetningarblokkin hvernig á að vinna úr og hvert á að beina umferðinni. Í eftirfarandi broti er öll umferð á síðuna flutt yfir í andstreymis (athugasemd þýðanda: andstreymis er venjulega forritaþjónn) sem heitir markþyrping. Andstreymisþyrpingin skilgreinir hnútana sem eiga að vinna úr beiðninni. Við munum ræða þetta í næsta skrefi.

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

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

Hjá Envoy gerir Filters þetta.

Sendiboðasíur

Fyrir fasta stillingu ákvarða síur hvernig á að vinna úr beiðnum sem berast. Í þessu tilviki setjum við síur sem passa server_nöfn í fyrra skrefi. Þegar innkomnar beiðnir berast sem passa við ákveðin lén og leiðir er umferð beint til þyrpingarinnar. Þetta jafngildir NGINX botnuppstillingu.

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

nafn sendimaður.http_tengingarstjóri er innbyggð sía í Envoy Proxy. Aðrar síur innihalda Redis, Mongó, TCP. Þú getur fundið heildarlistann á skjöl.

Fyrir frekari upplýsingar um aðrar reglur um álagsjöfnun, heimsækja Skjöl sendiherra.

Skref 5 - Stilling umboðs og andstreymis

Í NGINX skilgreinir uppstreymisstillingin mengi markþjóna sem munu vinna úr umferð. Í þessu tilviki var tveimur klösum úthlutað.

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

Í Envoy er þessu stjórnað af klösum.

Sendimannaklasar

Andstreymisjafngildið er skilgreint sem klasar. Í þessu tilviki hafa vélar sem munu þjóna umferðinni verið auðkenndar. Aðgangur að gestgjöfum, svo sem tímamörk, er skilgreind sem klasastilling. Þetta gerir ráð fyrir nákvæmari stjórn á þáttum eins og töf og álagsjafnvægi.

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

Þegar þú notar þjónustuuppgötvun STRICT_DNS Sendiherra mun stöðugt og ósamstillt leysa tilgreind DNS markmið. Hvert IP-tala sem skilað er úr DNS-niðurstöðunni verður talið vera skýr gestgjafi í andstreymisþyrpingunni. Þetta þýðir að ef beiðni skilar tveimur IP tölum mun Envoy gera ráð fyrir að það séu tveir vélar í þyrpingunni og báðir verða að vera í jafnvægi. Ef gestgjafi er fjarlægður úr niðurstöðunni mun Envoy gera ráð fyrir að hann sé ekki lengur til og mun draga umferð frá öllum núverandi tengingarhópum.

Nánari upplýsingar sjá Umboðsskjöl sendifulltrúa.

Skref 6 — Log aðgangur og villur

Endanleg uppsetning er skráning. Í stað þess að ýta villuskrám á diskinn, tekur Envoy Proxy skýtengda nálgun. Allar umsóknarskrár eru gefnar út til stdout и stderr.

Þegar notendur leggja fram beiðni eru aðgangsskrár valfrjálsar og sjálfgefið óvirkar. Til að virkja aðgangsskrár fyrir HTTP beiðnir skaltu virkja stillinguna aðgangsskrá fyrir HTTP tengingarstjórann. Leiðin getur verið annað hvort tæki eins og stdout, eða skrá á diski, allt eftir þörfum þínum.

Eftirfarandi uppsetning mun beina öllum aðgangsskrám til stdout (Athugasemd þýðanda - stdout er nauðsynlegt til að nota envoy inni í docker. Ef það er notað án docker skaltu skipta út /dev/stdout fyrir slóðina að venjulegri annálaskrá). Afritaðu bútinn í stillingarhlutann fyrir tengistjórann:

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

Niðurstöðurnar ættu að líta svona út:

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

Sjálfgefið er að Envoy er með sniðstreng sem inniheldur upplýsingar um HTTP beiðnina:

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

Niðurstaðan af þessum sniðstreng er:

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

Hægt er að aðlaga úttaksinnihaldið með því að stilla sniðreitinn. Til dæmis:

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"

Einnig er hægt að gefa út loglínuna á JSON sniði með því að stilla reitinn json_format. Til dæmis:

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

Nánari upplýsingar um aðferðafræði sendiboðaskráningar er að finna á

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

Skráning er ekki eina leiðin til að fá innsýn í að vinna með umboðsmanni sendiherra. Það hefur háþróaða rekja- og mælingargetu innbyggða í það. Þú getur fundið meira á rakningarskjöl eða í gegnum Gagnvirkt rekjaforrit.

Skref 7 - Ræsa

Þú hefur nú flutt stillingarnar þínar frá NGINX yfir í Envoy Proxy. Síðasta skrefið er að ræsa sendiboðatilvik til að prófa það.

Keyra sem notandi

Efst á NGINX stillingarlínunni notandi www www; tilgreinir að keyra NGINX sem notanda með litla forréttindi til að bæta öryggi.

Envoy Proxy notar skýjatengda nálgun til að stjórna hver á ferli. Þegar við keyrum Envoy Proxy í gegnum gám, getum við tilgreint lítinn réttindi notanda.

Ræsir envoy proxy

Skipunin hér að neðan mun keyra Envoy Proxy í gegnum Docker gám á gestgjafanum. Þessi skipun gefur Envoy getu til að hlusta eftir beiðnum sem berast á höfn 80. Hins vegar, eins og tilgreint er í hlustunarstillingunum, hlustar Envoy Proxy á komandi umferð á höfn 8080. Þetta gerir ferlið kleift að keyra sem notandi með litla forréttindi.

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

Prófun

Með proxy í gangi er nú hægt að gera og vinna úr prófunum. Eftirfarandi cURL skipun gefur út beiðni með hýsilhausnum sem er skilgreindur í proxy stillingunni.

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

HTTP beiðnin mun leiða til villu 503. Þetta er vegna þess að andstreymistengingar virka ekki og eru ekki tiltækar. Þess vegna hefur Envoy Proxy enga tiltæka áfangastaði fyrir beiðnina. Eftirfarandi skipun mun hefja röð af HTTP þjónustu sem passa við stillingarnar sem skilgreindar eru fyrir Envoy.

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

Með þeirri þjónustu sem er í boði getur Envoy tekist að koma umferð á áfangastað.

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

Þú ættir að sjá svar sem gefur til kynna hvaða Docker gámur afgreiddi beiðnina. Í umboðsskrám sendiboða ættirðu einnig að sjá aðgangsstrengsúttak.

Viðbótarhausar fyrir HTTP-svar

Þú munt sjá fleiri HTTP hausa í svarhausum raunverulegrar beiðni. Hausinn sýnir þann tíma sem andstreymisgestgjafinn eyddi í að vinna úr beiðninni. Gefið upp í millisekúndum. Þetta er gagnlegt ef viðskiptavinurinn vill ákvarða þjónustutíma miðað við netleynd.

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

Lokastilling

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 }

Viðbótarupplýsingar frá þýðanda

Leiðbeiningar um uppsetningu Envoy Proxy má finna á vefsíðunni https://www.getenvoy.io/

Sjálfgefið er að rpm er ekki með systemd þjónustustillingu.

Bæta við systemd þjónustu stillingum /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

Þú þarft að búa til möppu /etc/envoy/ og setja config.yaml config þar.

Það er símskeytispjall með umboði sendifulltrúa: https://t.me/envoyproxy_ru

Envoy Proxy styður ekki að þjóna kyrrstæðu efni. Því hver getur kosið um eiginleikann: https://github.com/envoyproxy/envoy/issues/378

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Hvatti þessi færsla þig til að setja upp og prófa umboð sendifulltrúa?

  • já

  • ekki

75 notendur kusu. 18 notendur sátu hjá.

Heimild: www.habr.com

Bæta við athugasemd