🥇Migration från Nginx till Envoy Proxy

Hej, Habr! Jag erbjuder er en översättning av inlägget: Migration från Nginx till Envoy Proxy.

Envoy är en högpresterande distribuerad proxyserver (skriven i C++), avsedd för individuella tjänster och applikationer. Det fungerar också som en kommunikationsbuss och "universal data plane", utvecklad för stora mikrotjänstarkitekturer "service mesh". Vid skapandet beaktades lösningar på problem som uppstått vid utvecklingen av servrar som NGINX, HAProxy, hårdvarubaserade belastningsbalanserare och molnbaserade belastningsbalanserare. Envoy arbetar tillsammans med varje applikation och abstraherar nätverket, vilket ger gemensamma funktioner oavsett plattform. När all tjänstetrafik i infrastrukturen går genom Envoy-målet blir det enkelt att visualisera problemområden med hjälp av sammanhängande övervakning, justera den gemensamma prestandan och lägga till centrala funktioner på specifika platser.

Funktioner

Arkitektur utanför processen: Envoy är en autonom, högpresterande server som tar upp en liten mängd minne. Den fungerar tillsammans med vilket programmeringsspråk eller ramverk som helst.
Stöd för HTTP/2 och gRPC: Envoy har förstklassigt stöd för HTTP/2 och gRPC för inkommande och utgående anslutningar. Det är en transparent proxy från HTTP/1.1 till HTTP/2.
Avancerad belastningsbalansering: Envoy stödjer avancerade funktioner för belastningsbalansering, inklusive automatiska omförsök, kedjeavbrott, global hastighetsbegränsning, begärningsskuggning, lokal zonbelastningsbalansering och så vidare.
API för konfigurationshantering: Envoy erbjuder ett pålitligt API för dynamisk hantering av sin konfiguration.
Övervakning: Djup övervakning av trafik L7, inbyggt stöd för distribuerad spårning och övervakning av MongoDB, DynamoDB och många andra applikationer.

Steg 1 - Exempel på NGINX-konfiguration

Detta scenario använder en specialdesignad fil nginx.conf, baserad på ett fullständigt exempel från NGINX Wiki. Du kan visa konfigurationen i redigeraren genom att öppna nginx.conf

Den ursprungliga nginx-konfigurationen

användare  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;
    }
  }
}

Konfigurationer för NGINX har vanligtvis tre centrala element:

Konfiguration av NGINX-servern, loggstrukturen och Gzip-funktionalitet. Detta definieras globalt i alla fall.
Konfiguration av NGINX för att ta emot förfrågningar på värden one.example.com på port 8080.
Konfiguration av målplats, hur man hanterar trafik för olika delar av URL:en.

Inte hela konfigurationen kommer att tillämpas på Envoy Proxy, och du behöver inte konfigurera vissa parametrar. Envoy Proxy har fyra centrala typer, som stöder den grundläggande infrastrukturen som erbjuds av NGINX. Kärnan är:

Lyssnare: De definierar hur Envoy Proxy tar emot inkommande förfrågningar. För närvarande stöder Envoy Proxy endast lyssnare baserade på TCP. Så snart anslutningen är etablerad, överförs den till en uppsättning filter för behandling.
Filter: De är en del av en rörledningsarkitektur som kan hantera inkommande och utgående data. Denna funktionalitet inkluderar filter som Gzip, som komprimerar data innan de skickas till klienten.
Router: De omdirigerar trafiken till den angivna destination som definieras som en kluster.
Kluster: De definierar slutpunkten för trafiken och konfigurationsparametrar.

Vi kommer att använda dessa fyra komponenter för att skapa en konfiguration för Envoy Proxy som motsvarar en viss konfiguration av NGINX. Målet med Envoy är att arbeta med API:er och dynamisk konfiguration. I det här fallet kommer den grundläggande konfigurationen att använda statiska, hårdkodade parametrar från NGINX.

Steg 2 – Konfiguration av NGINX

Den första delen nginx.conf definierar några interna komponenter av NGINX som måste konfigureras.

Arbetsanslutningar

Följande konfiguration definierar antalet arbetsprocesser och anslutningar. Detta indikerar hur NGINX kommer att skalas för att möta efterfrågan.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy hanterar arbetsprocesser och anslutningar på olika sätt.

Envoy skapar en arbetsström för varje hårdvarustress på systemet. Varje arbetsström kör en icke-blockerande händelsecykel, som ansvarar för

Att lyssna på varje lyssnare (listener)
Att ta emot nya anslutningar
Att skapa en uppsättning filter för anslutningen
Att hantera alla in- och utdataoperationer under anslutningens livslängd.

All vidare bearbetning av anslutningen hanteras helt i arbetsströmmen, inklusive eventuell omdirigeringsbeteende.

För varje arbetsström i Envoy finns det en anslutning i poolen. Därmed upprättar HTTP/2-anslutningspooler endast en anslutning per extern värd i taget; med fyra arbetsströmmar kommer det att finnas fyra HTTP/2-anslutningar för varje extern värd i stabilt tillstånd. Genom att behålla allt i en arbetsström kan nästan all kod skrivas utan blockering, som om den var entrådad. Om fler arbetsströmmar tilldelas än nödvändigt kan det leda till ineffektiv minnesanvändning, skapande av många passiva anslutningar och minskning av antalet återförda anslutningar till poolen.

För mer information, besök Envoy Proxy blogg.

HTTP-konfiguration

Följande konfigurationsblock för NGINX definierar HTTP-inställningar såsom:

Vilka mime-typer som stöds
Standardtimeoutar
Gzip-konfiguration

Du kan justera dessa aspekter med hjälp av filter i Envoy Proxy, vilket vi kommer att diskutera senare.

Steg 3 — Serverkonfiguration

I HTTP-konfigurationsblocket specificerar NGINX att lyssna på port 8080 och svara på inkommande förfrågningar för domänerna one.example.com och www.one.example.com.

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

Inom Envoy hanteras detta av lyssnare.

Envoy-lyssnare

Den viktigaste aspekten av att komma igång med Envoy Proxy är att definiera lyssnare. Du måste skapa en konfigurationsfil som beskriver hur du vill köra en instans av Envoy.

Nedanstående fragment skapar en ny lyssnare och kopplar den till port 8080. Konfigurationen anger för Envoy Proxy vilka portar den ska bindas till för inkommande förfrågningar.

Envoy Proxy använder YAML-notation för sin konfiguration. För att bekanta dig med denna notation, se här. länken.

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

Det finns ingen anledning att definiera server_name, eftersom Envoy Proxys filter hanterar detta.

Steg 4 – Konfiguration av plats

När en förfrågan kommer till NGINX, definierar platsblocket hur trafik ska hanteras och var den ska dirigeras. I följande fragment vidarebefordras all trafik till webbplatsen till en upstream (översättarens kommentar: upstream är vanligtvis applikationsservrar) kluster med namnet targetCluster. Upstream-klustret definierar de noder som ska hantera förfrågan. Vi kommer att diskutera detta i nästa steg.

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

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

I Envoy hanteras detta av Filters.

Envoy Filters

För statisk konfiguration definierar filter hur inkommande förfrågningar ska hanteras. I det här fallet ställer vi in filter som motsvarar server_names från föregående steg. När inkommande förfrågningar matchar specifika domäner och rutter, dirigeras trafiken till klustret. Detta är ekvivalent med en uppströmskonfiguration i 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

Namn envoy.http_connection_manager är ett inbyggt filter i Envoy Proxy. Andra filter inkluderar Redis, Mongo, TCP. Du kan hitta en fullständig lista i dokumentationen.

För mer information om andra belastningsfördelningsmetoder, besök Envoy-dokumentationen.

Steg 5 – Proxy- och upstreamkonfiguration

I NGINX definierar upstream-konfigurationen en uppsättning målservrar som ska hantera trafiken. I detta fall har två kluster tilldelats.

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

I Envoy hanteras detta av kluster.

Envoy Clusters

Uppströms ekvivalent definieras som kluster. I detta fall har värdaridentifierats som ska hantera trafiken. Åtkomstmetoden till värdarna, exempelvis tidsgräns, definieras som klusterkonfiguration. Detta möjliggör mer exakt kontroll över detaljer som tidsgräns och lastbalansering.

Kopiera till redigerare kluster:
  - namn: 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 }}
    ]

Vid användning av tjänstupptäckten STRICT_DNS Envoy kommer kontinuerligt och asynkront att lösa angivna DNS-mål. Varje IP-adress som returneras från DNS kommer att betraktas som en explicit värd i det uppåtgående klustret. Det innebär att om en förfrågan returnerar två IP-adresser kommer Envoy anta att det finns två värdar i klustret och båda ska lastbalanseras. Om en värd tas bort från resultatet, antar Envoy att den inte längre finns och kommer att dra trafik från alla existerande anslutningspooler.

För mer information, se. Dokumentationen för Envoy Proxy.

Steg 6 — Åtkomst till loggar och fel

Slutlig konfiguration — loggning. Istället för att skicka felrapporter till disk, använder Envoy Proxy en molnbaserad metod. Alla programloggar skickas till stdout och stderr.

När användare gör en förfrågan är åtkomstloggar valfria och som standard inaktiverade. För att aktivera åtkomstloggar för HTTP-förfrågningar, aktivera konfigurationen access_log för HTTP-anslutningshanteraren. Sökvägen kan antingen vara en enhet, såsom stdout, eller en fil på disken, beroende på dina krav.

Följande konfiguration kommer att vidarebefordra alla åtkomstloggar till stdout (översättarens anteckning — stdout är nödvändigt för att använda envoy inuti docker. Om du använder utan docker, ersätt \/dev\/stdout med sökvägen till en vanlig loggfil). Kopiera fragmentet till konfigurationsavsnittet för anslutningshanteraren:

Kopiera till urklippaccess_log:
- namn: envoy.file_access_log
  config:
    path: "\/dev\/stdout"

Resultaten bör se ut så här:

      - namn: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          access_log:
          - namn: envoy.file_access_log
            config:
              path: "\/dev\/stdout"
          route_config:

Som standard har Envoy en formatsträng som inkluderar detaljer om HTTP-förfrågan:

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

Resultatet av denna formatsträng:

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

Innehållet i utdata kan anpassas genom att ange formatfältet. Till exempel:

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"

Loggsträngen kan också skrivas ut i JSON-format genom att ange fältet json_formatJuniper (MX/QFX/ACX)

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

För mer information om loggmetodiken för envoy, besök

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

Loggning är inte det enda sättet att få insyn i Envoy Proxy:s funktion. Den har inbyggda avancerade spårnings- och mätmöjligheter. Du kan läsa mer i dokumentationen för spårning eller via Interaktiv spårningsscenarie.

Steg 7 – Starta

Nu har du översatt konfigurationen från NGINX till Envoy Proxy. Det sista steget är att starta en instans av Envoy Proxy för att testa den.

Starta som användare

I toppen av NGINX-konfigurationen anger raden user www www; att NGINX körs som en användare med låg privilegium för att förbättra säkerheten.

Envoy Proxy använder en molnbaserad metod för att hantera vem som äger processen. När vi kör Envoy Proxy i en container kan vi specificera en användare med låg privilegium.

Starta Envoy Proxy

Kommandot nedan kommer att starta Envoy Proxy via en Docker-container på värden. Detta kommando ger Envoy möjlighet att lyssna på inkommande förfrågningar via port 80. Men som anges i lyssnarens konfiguration lyssnar Envoy Proxy på inkommande trafik via port 8080. Detta gör att processen kan köras som en användare med låga privilegier.

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

Testning

Med proxy igång kan tester nu göras och hanteras. Nästa cURL-kommando ger en begäran med värdhuvudet angivet i proxy-konfigurationen.

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

HTTP-förfrågan kommer att resultera i ett fel 503Det beror på att inkommande anslutningar inte fungerar och därmed är inte tillgängliga. På så sätt har Envoy Proxy inga tillgängliga måladresser för förfrågan. Följande kommando kommer att starta en serie HTTP-tjänster som motsvarar konfigurationen definierad för Envoy.

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

Med tillgängliga tjänster kan Envoy framgångsrikt proxy-trafik till destinationen.

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

Du bör se ett svar som anger vilken Docker-container som hanterade förfrågan. I loggarna för Envoy Proxy bör du också se den utprintade access-strängen.

Ytterligare HTTP-svars-rubriker (HTTP Response)

I rubrikerna för den giltiga förfrågan ser du ytterligare HTTP-rubriker. I rubriken visas tiden som den överordnade värden tog på sig för att behandla förfrågan. Detta anges i millisekunder. Det är användbart om klienten vill fastställa tid för service i förhållande till nätverksfördröjning.

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

Slutlig konfig

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 }

Ytterligare information från översättaren

Installationsinstruktioner för Envoy Proxy kan du hitta på webbplatsen https://www.getenvoy.io/

Som standard saknar rpm systemd service-konfiguration.

Lägg till systemd service-konfigurationen i \/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

Du behöver skapa en mapp \/etc\/envoy\/ och lägga konfigurationsfilen config.yaml där.

Det finns en Telegram-chat för envoy proxy: https://t.me/envoyproxy_ru

Envoy Proxy har ingen stöd för att leverera statiskt innehåll. Så vänligen rösta för funktionen: https://github.com/envoyproxy/envoy/issues/378

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Har detta inlägg inspirerat dig att installera och testa envoy proxy?

75 användare röstade för. 18 användare avstod.

Källa: habr.com