🥇Migrasie van Nginx na Gesant-volmag

Hallo, Habr! Ek bring 'n vertaling van die pos onder u aandag: Migrasie van Nginx na Envoy Proxy.

Envoy is 'n hoëprestasie verspreide instaanbediener (geskryf in C++) wat ontwerp is vir individuele dienste en toepassings, dit is ook 'n kommunikasiebus en "universele datavlak" wat ontwerp is vir groot mikrodiens "diensnetwerk"-argitekture. By die skep daarvan is oplossings vir probleme wat ontstaan het tydens die ontwikkeling van bedieners soos NGINX, HAProxy, hardeware-lasbalanseerders en wolklasbalanseerders in ag geneem. Envoy werk saam met elke toepassing en onttrek die netwerk om algemene funksionaliteit te verskaf, ongeag die platform. Wanneer alle diensverkeer in 'n infrastruktuur deur die Envoy-netwerk vloei, word dit maklik om probleemareas met konsekwente waarneembaarheid te visualiseer, algehele werkverrigting in te stel en kernfunksionaliteit op 'n spesifieke plek by te voeg.

Vermoëns

Buite-proses argitektuur: envoy is 'n selfstandige, hoëprestasie bediener wat 'n klein hoeveelheid RAM opneem. Dit werk saam met enige toepassingstaal of -raamwerk.
http/2- en grpc-ondersteuning: envoy het eersteklas http/2- en grpc-ondersteuning vir inkomende en uitgaande verbindings. Dit is 'n deursigtige instaanbediener van http/1.1 na http/2.
Gevorderde lasbalansering: gesant ondersteun gevorderde lasbalanseringskenmerke, insluitend outomatiese herprobasies, kettingbreek, globale tariefbeperking, versoekskadu, plaaslike sone-lasbalansering, ens.
Configuration Management API: gesant bied 'n robuuste API om jou konfigurasie dinamies te bestuur.
Waarneembaarheid: Diep waarneembaarheid van L7-verkeer, inheemse ondersteuning vir verspreide opsporing en waarneembaarheid van mongodb, dynamodb en baie ander toepassings.

Stap 1 — Voorbeeld NGINX Config

Hierdie skrif gebruik 'n spesiaal vervaardigde lêer nginx.conf, gebaseer op die volledige voorbeeld van NGINX Wiki. U kan die konfigurasie in die redigeerder sien deur oop te maak nginx.conf

nginx-bronkonfigurasie

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-konfigurasies het tipies drie sleutelelemente:

Konfigureer NGINX-bediener, logstruktuur en Gzip-funksionaliteit. Dit word in alle gevalle wêreldwyd gedefinieer.
Konfigureer NGINX om versoeke aan die gasheer te aanvaar een.voorbeeld.com op poort 8080.
Die opstel van die teikenligging, hoe om verkeer vir verskillende dele van die URL te hanteer.

Nie alle konfigurasie sal op Envoy Proxy van toepassing wees nie, en jy hoef nie sekere instellings op te stel nie. Gesant Proxy het vier sleuteltipes, wat die kerninfrastruktuur ondersteun wat deur NGINX aangebied word. Die kern is:

Luisteraars: Hulle bepaal hoe Envoy Proxy inkomende versoeke aanvaar. Envoy Proxy ondersteun tans net TCP-gebaseerde luisteraars. Sodra 'n verbinding tot stand gebring is, word dit na 'n stel filters oorgedra vir verwerking.
Filters: Hulle is deel van 'n pyplynargitektuur wat inkomende en uitgaande data kan verwerk. Hierdie funksionaliteit sluit filters soos Gzip in, wat die data saampers voordat dit na die kliënt gestuur word.
Roeteerders: Hulle stuur verkeer aan na die vereiste bestemming, gedefinieer as 'n groep.
Klusters: Hulle definieer die eindpunt vir verkeer en konfigurasie parameters.

Ons sal hierdie vier komponente gebruik om 'n Envoy Proxy-konfigurasie te skep om by 'n spesifieke NGINX-konfigurasie te pas. Envoy se doel is om met API's en dinamiese konfigurasie te werk. In hierdie geval sal die basiskonfigurasie statiese, hardgekodeerde instellings van NGINX gebruik.

Stap 2 - NGINX-konfigurasie

Eerste deel nginx.conf definieer sommige NGINX internals wat gekonfigureer moet word.

Werker verbindings

Die opstelling hieronder bepaal die aantal werkerprosesse en verbindings. Dit dui aan hoe NGINX sal skaal om aan die vraag te voldoen.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy bestuur werkvloeie en verbindings op verskillende maniere.

Envoy skep 'n werkersdraad vir elke hardewaredraad op die stelsel. Elke werker draad voer 'n nie-blokkerende gebeurtenis lus uit wat verantwoordelik is vir

Luister na elke luisteraar
Aanvaarding van nuwe verbindings
Skep 'n stel filters vir 'n verbinding
Verwerk alle I/O-bewerkings gedurende die leeftyd van die verbinding.

Alle verdere verbindingsverwerking word geheel en al in die werkersdraad hanteer, insluitend enige aanstuurgedrag.

Vir elke werkersdraad in Envoy is daar 'n verbindingspoel. So HTTP/2-verbindingspoele vestig net een verbinding per eksterne gasheer op 'n slag, as daar vier werkersdrade is, sal daar vier HTTP/2-verbindings per eksterne gasheer in 'n stabiele toestand wees. Deur alles in een werkersdraad te hou, kan byna alle kode geskryf word sonder om te blokkeer, asof dit enkeldraad is. As meer werkersdrade toegewys word as wat nodig is, kan dit lei tot vermorsde geheue, die skep van 'n groot aantal ledige verbindings en die vermindering van die aantal kere wat verbindings na die swembad teruggestuur word.

Vir meer inligting besoek Gesant Proxy blog.

HTTP-konfigurasie

Die volgende NGINX-konfigurasieblok definieer HTTP-instellings soos:

Watter mimiektipes word ondersteun
Verstek Timeouts
Gzip-konfigurasie

U kan hierdie aspekte aanpas deur filters in Envoy Proxy te gebruik, wat ons later sal bespreek.

Stap 3 - Bedienerkonfigurasie

In die HTTP-konfigurasieblok spesifiseer die NGINX-konfigurasie om op poort 8080 te luister en te reageer op inkomende versoeke vir domeine een.voorbeeld.com и www.een.voorbeeld.com.

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

Binne Envoy word dit deur Luisteraars beheer.

Gesant luisteraars

Die belangrikste aspek om met Envoy Proxy te begin, is om jou luisteraars te definieer. Jy moet 'n konfigurasielêer skep wat beskryf hoe jy die Envoy-instansie wil laat loop.

Die brokkie hieronder sal 'n nuwe luisteraar skep en dit aan poort 8080 bind. Die konfigurasie vertel Envoy Proxy aan watter poorte dit moet bind vir inkomende versoeke.

Envoy Proxy gebruik YAML-notasie vir sy konfigurasie. Vir 'n inleiding tot hierdie notasie, kyk hier skakel.

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

Nie nodig om te definieer nie server, aangesien Envoy Proxy-filters dit sal hanteer.

Stap 4 - Liggingkonfigurasie

Wanneer 'n versoek in NGINX kom, bepaal die liggingblok hoe om te verwerk en waarheen om die verkeer te stuur. In die volgende fragment word alle verkeer na die webwerf oorgedra na 'n stroomop (vertalersnota: stroomop is gewoonlik 'n toepassingsbediener) cluster met die naam doelgroep. Die stroomop-kluster definieer die nodusse wat die versoek moet verwerk. Ons sal dit in die volgende stap bespreek.

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

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

By Envoy doen Filters dit.

Gesant Filters

Vir 'n statiese opstelling bepaal filters hoe om inkomende versoeke te verwerk. In hierdie geval stel ons filters wat ooreenstem bedienername in die vorige stap. Wanneer inkomende versoeke aankom wat ooreenstem met sekere domeine en roetes, word verkeer na die groep gestuur. Dit is die ekwivalent van 'n NGINX bottom-up-konfigurasie.

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

naam gesant.http_verbindingsbestuurder is 'n ingeboude filter in Envoy Proxy. Ander filters sluit in Redis, Mongo, TCP. Jy kan die volledige lys vind by dokumentasie.

Vir meer inligting oor ander lasbalanseringsbeleide, besoek Gesant Dokumentasie.

Stap 5 - Volmag- en stroomopkonfigurasie

In NGINX definieer die stroomop-konfigurasie 'n stel teikenbedieners wat verkeer sal verwerk. In hierdie geval is twee groepe toegewys.

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

In Envoy word dit deur groepe bestuur.

Gesant Klusters

Die stroomop ekwivalent word gedefinieer as trosse. In hierdie geval is die gashere wat die verkeer sal bedien, geïdentifiseer. Die manier waarop toegang tot gashere verkry word, soos uitteltyd, word gedefinieer as 'n groepkonfigurasie. Dit maak voorsiening vir meer korrelige beheer oor aspekte soos latensie en lasbalansering.

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

Wanneer jy diensontdekking gebruik STRICT_DNS Gesant sal voortdurend en asynchronies die gespesifiseerde DNS-teikens oplos. Elke teruggekeerde IP-adres vanaf die DNS-resultaat sal as 'n eksplisiete gasheer in die stroomopgroep beskou word. Dit beteken dat as 'n versoek twee IP-adresse terugstuur, Envoy sal aanvaar dat daar twee gashere in die groep is, en albei moet lasgebalanseerd wees. As 'n gasheer uit die resultaat verwyder word, sal Envoy aanneem dat dit nie meer bestaan nie en sal verkeer van enige bestaande verbindingspoele trek.

Vir meer inligting sien Gesant volmag dokumentasie.

Stap 6 — Log toegang en foute

Die finale konfigurasie is registrasie. In plaas daarvan om foutlogboeke na skyf te druk, neem Envoy Proxy 'n wolkgebaseerde benadering. Alle toepassingslogboeke word uitgestuur na standout и stderr.

Wanneer gebruikers 'n versoek rig, is toegangslogboeke opsioneel en by verstek gedeaktiveer. Aktiveer die opstelling om toegangsloglêers vir HTTP-versoeke te aktiveer toegang_log vir die HTTP-verbindingsbestuurder. Die pad kan óf 'n toestel wees soos standout, of 'n lêer op skyf, afhangende van jou vereistes.

Die volgende konfigurasie sal alle toegangslogboeke na herlei standout (Vertaler se nota - stdout word vereis om envoy in docker te gebruik. As dit sonder docker gebruik word, vervang dan /dev/stdout met die pad na 'n gewone loglêer). Kopieer die brokkie na die konfigurasie-afdeling vir die verbindingsbestuurder:

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

Die resultate moet soos volg lyk:

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

By verstek het Envoy 'n formaatstring wat die besonderhede van die HTTP-versoek insluit:

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

Die resultaat van hierdie formaatstring 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"

Die uitvoerinhoud kan aangepas word deur die formaatveld in te stel. Byvoorbeeld:

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"

Die loglyn kan ook in JSON-formaat uitgevoer word deur die veld te stel json_formaat. Byvoorbeeld:

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

Vir meer inligting oor die Gesantregistrasiemetodologie, besoek

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

Logging is nie die enigste manier om insig te kry in die werk met Envoy Proxy nie. Dit het gevorderde dop- en statistiekvermoëns daarin ingebou. Jy kan meer uitvind by spoor dokumentasie of via Interaktiewe naspeurskrif.

Stap 7 - Begin

Jy het nou jou konfigurasie van NGINX na Envoy Proxy gemigreer. Die laaste stap is om 'n Envoy Proxy-instansie te begin om dit te toets.

Hardloop as gebruiker

Aan die bokant van die NGINX-konfigurasielyn gebruiker www www; spesifiseer om NGINX as 'n laebevoorregte gebruiker te laat loop om sekuriteit te verbeter.

Envoy Proxy volg 'n wolkgebaseerde benadering om te bestuur wie 'n proses besit. Wanneer ons Envoy Proxy deur 'n houer laat loop, kan ons 'n laebevoorregte gebruiker spesifiseer.

Begin tans Envoy Proxy

Die opdrag hieronder sal Envoy Proxy deur 'n Docker-houer op die gasheer laat loop. Hierdie opdrag gee Envoy die vermoë om te luister vir inkomende versoeke op poort 80. Soos gespesifiseer in die luisteraaropstelling, luister Envoy Proxy egter vir inkomende verkeer op poort 8080. Dit laat die proses toe om as 'n laebevoorregte gebruiker te loop.

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

toets

Met die instaanbediener aan die gang, kan toetse nou gemaak en verwerk word. Die volgende cURL-opdrag reik 'n versoek uit met die gasheeropskrif wat in die proxy-konfigurasie gedefinieer is.

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

Die HTTP-versoek sal 'n fout tot gevolg hê 503. Dit is omdat stroomopverbindings nie werk nie en nie beskikbaar is nie. Daarom het Envoy Proxy geen beskikbare bestemmings vir die versoek nie. Die volgende opdrag sal 'n reeks HTTP-dienste begin wat ooreenstem met die konfigurasie wat vir Envoy gedefinieer is.

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

Met die beskikbare dienste kan Envoy verkeer suksesvol na sy bestemming instaan.

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

U behoort 'n antwoord te sien wat aandui watter Docker-houer die versoek verwerk het. In die Envoy Proxy-logboeke behoort jy ook 'n toegangstring-uitvoer te sien.

Bykomende HTTP-reaksie-opskrifte

U sal addisionele HTTP-opskrifte in die antwoordopskrifte van die werklike versoek sien. Die opskrif wys die tyd wat die stroomopgasheer spandeer het om die versoek te verwerk. Uitgedruk in millisekondes. Dit is nuttig as die kliënt dienstyd wil bepaal in vergelyking met netwerkvertraging.

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

Finale konfigurasie

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 }

Bykomende inligting van die vertaler

Instruksies vir die installering van Envoy Proxy kan op die webwerf gevind word https://www.getenvoy.io/

By verstek het rpm nie 'n systemd-dienskonfigurasie nie.

Voeg systemd service config /etc/systemd/system/envoy.service by:

[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

Jy moet 'n gids /etc/envoy/ skep en die config.yaml config daar plaas.

Daar is 'n telegramklets met behulp van gesant-instaanbediener: https://t.me/envoyproxy_ru

Envoy Proxy ondersteun nie die bediening van statiese inhoud nie. Wie kan dus vir die kenmerk stem: https://github.com/envoyproxy/envoy/issues/378

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.

Het hierdie pos jou aangemoedig om gesant-instaanbediener te installeer en te toets?

Ja
geen

75 gebruikers het gestem. 18 gebruikers het buite stemming gebly.

Bron: will.com

Migrasie van Nginx na Envoy Proxy