ProHoster > Blog > Beheer > Migratie van Nginx naar Envoy Proxy

Migratie van Nginx naar Envoy Proxy

Hallo, Habr! Ik bied je de vertaling van een bericht aan: Migratie van Nginx naar Envoy Proxy.

Envoy is een hoogwaardige, gedistribueerde proxyserver (geschreven in C++) die is ontworpen voor afzonderlijke diensten en toepassingen. Het is ook een communicatiesysteem en een 'universele dataplatform' dat is ontwikkeld voor grote microservicesarchitecturen 'service mesh'. Bij de ontwikkeling zijn oplossingen overwogen voor problemen die zich voordeden bij de ontwikkeling van servers zoals NGINX, HAProxy, hardware load balancers en cloud load balancers. Envoy werkt samen met elke applicatie en abstraheert het netwerk, waardoor gemeenschappelijke functies ongeacht het platform worden geboden. Wanneer al het servicetrafiek in de infrastructuur via het Envoy-netwerk loopt, wordt het eenvoudig om probleemgebieden te visualiseren met behulp van consistente observatie, het afstemmen van algemene prestaties en het toevoegen van essentiƫle functies op een specifieke plaats.

Functionaliteiten

  • Architectuur buiten het proces: envoy is een autonome, hoogwaardige server die een klein geheugenfootprint heeft. Het werkt samen met elke programmeertaal of framework.
  • Ondersteuning voor http/2 en grpc: envoy heeft eersteklas ondersteuning voor http/2 en grpc voor inkomende en uitgaande verbindingen. Het is een transparante proxy van http/1.1 naar http/2.
  • Geavanceerde load balancing: envoy ondersteunt geavanceerde load balancing-functies, inclusief automatische herhaalpogingen, circuit breaking, globale snelheidbeperkingen, request shadowing, lokale zone load balancing, enzovoort.
  • API voor configuratiemanagement: envoy biedt een robuuste API voor dynamisch beheer van zijn configuratie.
  • Observatie: diepe observatie van L7-verkeer, ingebouwde ondersteuning voor gedistribueerde traceerbaarheid en observatie van mongodb, dynamodb en vele andere applicaties.

Stap 1 - Voorbeeldconfiguratie NGINX

In dit scenario wordt een speciaal gemaakte bestand gebruikt nginx.conf, gebaseerd op een volledig voorbeeld van NGINX Wiki. Je kunt de configuratie bekijken in de editor door nginx.conf

De oorspronkelijke nginx-config

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

De configuraties van NGINX bevatten doorgaans drie belangrijke elementen:

  1. De NGINX-serverconfiguratie, de logstructuur en de functionaliteit van Gzip. Dit wordt globaal in alle gevallen vastgesteld.
  2. NGINX configureren om verzoeken voor de host one.example.com op poort 8080.
  3. Het instellen van de doellocatie, hoe verkeer voor verschillende delen van de URL te verwerken.

Niet alle configuraties zijn van toepassing op Envoy Proxy, en je hoeft bepaalde parameters niet in te stellen. Envoy Proxy heeft vier belangrijke soorten, die de basisinfrastructuur ondersteunen die door NGINX wordt aangeboden. De kern is:

  • Listeners: Ze bepalen hoe Envoy Proxy binnenkomende verzoeken accepteert. Momenteel ondersteunt Envoy Proxy alleen TCP-gebaseerde listeners. Zodra de verbinding is gemaakt, wordt deze doorgestuurd naar een set filters voor verwerking.
  • Filter: Ze maken deel uit van de pijplijnarchitectuur die inkomende en uitgaande gegevens kan verwerken. Deze functionaliteit omvat filters zoals Gzip, dat gegevens comprimeert voordat ze naar de client worden verzonden.
  • Routers: Ze sturen verkeer door naar de vereiste bestemming, gedefinieerd als een cluster.
  • Clusters: Ze definiĆ«ren het eindpunt voor verkeer en de configuratieparameters.

We zullen deze vier componenten gebruiken om een Envoy Proxy-configuratie te maken die overeenkomt met de specifieke NGINX-configuratie. Het doel van Envoy is om met API's en dynamische configuratie te werken. In dit geval zal de basisconfiguratie statische, hardcoded parameters uit NGINX gebruiken.

Stap 2 ā€” NGINX-configuratie

Eerste deel nginx.conf definieert enkele interne componenten van NGINX die moeten worden ingesteld.

Worker Connections

De onderstaande configuratie definieert het aantal werkprocessen en verbindingen. Dit geeft aan hoe NGINX zal schalen om aan de vraag te voldoen.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy beheert op verschillende manieren de werkprocessen en verbindingen.

Envoy creƫert een werkthread voor elke hardwarethread in het systeem. Elke werkthread voert een niet-blokkerende gebeurtenislus uit, die verantwoordelijk is voor

  1. Het luisteren naar elke listener
  2. Nieuwe verbindingen accepteren
  3. Een set filters voor de verbinding aanmaken
  4. Alle invoer- en uitvoerbewerkingen afhandelen gedurende de levensduur van de verbinding.

Alle verdere verwerking van de verbinding wordt volledig afgehandeld in de werkthread, inclusief elk omleidingsgedrag.

Voor elke werkthread in Envoy is er een verbinding in de pool. Hierdoor stellen HTTP/2-verbindingen slechts ƩƩn verbinding per externe host tegelijkertijd in, bij vier werkthreads zijn er vier HTTP/2-verbindingen voor elke externe host in een stabiele toestand. Door alles in ƩƩn werkthread te behouden, kan vrijwel alle code zonder blokkeringen worden geschreven, alsof het enkelvoudig is. Als er meer werkthreads zijn toegewezen dan nodig, kan dit leiden tot ondoelmatig geheugen gebruik, het creƫren van een groot aantal inactieve verbindingen en het verminderen van het aantal verbindingen dat terug de pool in gaat.

Voor meer informatie, bezoek Envoy Proxy blog.

HTTP-configuratie

De volgende configuratieblok van NGINX definieert HTTP-instellingen, zoals:

  • Welke mime-typen worden ondersteund
  • Standaard time-outs
  • Gzip-configuratie

U kunt deze aspecten configureren met behulp van filters in Envoy Proxy, wat we later zullen bespreken.

Stap 3 ā€” Serverconfiguratie

In het HTTP-configuratieblok geeft de NGINX-configuratie aan om poort 8080 te beluisteren en in te gaan op inkomende verzoeken voor domeinen one.example.com en www.one.example.com.

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

Binnen Envoy wordt dit beheerd door listeners.

Envoy listeners

Het belangrijkste aspect van het werken met Envoy Proxy is het definiƫren van listeners. U moet een configuratiebestand aanmaken dat beschrijft hoe u een instantie van Envoy wilt uitvoeren.

De onderstaande snippet creƫert een nieuwe listener en koppelt deze aan poort 8080. De configuratie geeft aan aan welke poorten Envoy Proxy moet worden gekoppeld voor inkomende verzoeken.

Envoy Proxy gebruikt YAML-notatie voor zijn configuratie. Voor een kennismaking met deze notatie, kijk hier link.

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

Er is geen noodzaak om te definiƫren server_name, omdat de filters van Envoy Proxy dit zullen afhandelen.

Stap 4 ā€” Configuratie van locatie

Wanneer een aanvraag in NGINX binnenkomt, bepaalt het locatieblok hoe het verkeer moet worden verwerkt en waar het naartoe moet worden geleid. In de volgende snippet wordt al het verkeer naar de site doorgegeven aan de upstream (vertaler opmerking: upstream is meestal een cluster van applicatieservers) cluster met de naam targetCluster. Het upstream-cluster definieert de knooppunten die de aanvraag moeten verwerken. We bespreken dit in de volgende stap.

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

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

In Envoy wordt dit afgehandeld door Filters.

Envoy Filters

Voor statische configuratie bepalen de filters hoe inkomende aanvragen moeten worden verwerkt. In dit geval stellen we filters in die overeenkomen met server_names uit de vorige stap. Wanneer inkomende verzoeken binnenkomen die overeenkomen met bepaalde domeinen en paden, wordt het verkeer naar het cluster geleid. Dit is gelijk aan de upstream-configuratie van 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

Naam envoy.http_connection_manager is een ingebouwde filter in Envoy Proxy. Andere filters omvatten Redis, Mongo, TCP. Je kunt een volledige lijst vinden in de documentatie.

Voor meer informatie over andere load balancing strategieƫn, bezoek de Documentatie van Envoy.

Stap 5 ā€” Proxy en Upstream Configuratie

In NGINX definieert de upstream-configuratie een set doelservers die het verkeer zullen verwerken. In dit geval zijn er twee clusters toegewezen.

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

In Envoy wordt dit beheerd door clusters.

Envoy Clusters

De equivalent upstream wordt gedefinieerd als clusters. In dit geval zijn er hosts gedefinieerd die de traffic gaan verwerken. De toegangsmethode tot de hosts, zoals de time-out, wordt gedefinieerd als de clusterconfiguratie. Dit biedt een betere controle over de fijnmazigheid van aspecten zoals time-out en load balancing.

Kopieer naar editor clusters:
  - naam: 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 }}
    ]

Bij het gebruik van service discovery STRICT_DNS Envoy zal continu en asynchroon de opgegeven DNS-doelen resolveren. Elk IP-adres dat als resultaat van de DNS wordt geretourneerd, wordt beschouwd als een expliciete host in het upstream-cluster. Dit betekent dat als het verzoek twee IP-adressen retourneert, Envoy aanneemt dat er twee hosts in het cluster zijn, en beide moeten worden gebalanceerd. Als een host uit het resultaat wordt verwijderd, gaat Envoy ervan uit dat deze niet meer bestaat en zal het verkeer uit bestaande verbindingenpoolen selecteren.

Voor meer informatie, zie De documentatie van de Envoy-proxy.

Stap 6 - Toegang tot logs en fouten

De uiteindelijke configuratie is registratie. In plaats van foutlogs naar de schijf te schrijven, gebruikt Envoy Proxy een cloudbenadering. Alle applicatielogs worden verzonden naar stdout en stderr.

Wanneer gebruikers een verzoek doen, zijn toegangslogs optioneel en standaard uitgeschakeld. Om toegangslogs voor HTTP-verzoeken in te schakelen, activeer de configuratie access_log voor de HTTP-verbinder. Het pad kan een apparaat zijn, zoals stdout, of een bestand op schijf, afhankelijk van uw vereisten.

De volgende configuratie zal alle toegangslogs omleiden naar stdout (opmerking van de vertaler - stdout is nodig voor het gebruik van envoy binnen docker. Als het zonder docker wordt gebruikt, vervang dan \/dev\/stdout door het pad naar een normaal logbestand). Kopieer het fragment naar het configuratiegedeelte voor de verbindingsmanager:

Kopieer naar klembord access_log:
- naam: envoy.file_access_log
  config:
    path: "\/dev\/stdout"

De resultaten moeten er als volgt uitzien:

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

Standaard heeft Envoy een opmaakregel die de details van het HTTP-verzoek bevat:

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

De uitkomst van deze formatregel:

[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 inhoud van de uitvoer kan worden ingesteld door het formatveld in te stellen. Bijvoorbeeld:

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 logregel kan ook in JSON-formaat worden uitgevoerd door het veld json_format. Bijvoorbeeld:

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

Voor meer informatie over de loggingmethodologie van de envoy, bezoek

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

Logging is niet de enige manier om inzicht te krijgen in het functioneren van de Envoy Proxy. Het bevat ingebouwde mogelijkheden voor tracing en metrics. U kunt er meer over lezen in de documentatie over tracing of via Het interactieve tracing script.

Stap 7 ā€” Starten

U heeft nu de configuratie van NGINX naar Envoy Proxy vertaald. De laatste stap is het starten van een instantie van Envoy Proxy voor testen.

Starten als gebruiker

Aan de bovenkant van de NGINX-configuratie geeft de regel user www www; aan dat NGINX als een gebruiker met lage privileges draait voor een betere beveiliging.

Envoy Proxy gebruikt een cloudbenadering voor het beheren van wie de proces eigenaar is. Wanneer we Envoy Proxy via een container starten, kunnen we een gebruiker met lage privileges opgeven.

Envoy Proxy starten

De onderstaande opdracht start Envoy Proxy via een Docker-container op de host. Deze opdracht biedt Envoy de mogelijkheid om inkomende verzoeken te beluisteren via poort 80. Zoals aangegeven in de listener-configuratie, beluistert Envoy Proxy echter inkomend verkeer via poort 8080. Dit stelt het proces in staat om als een gebruiker met lage privileges te draaien.

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

Testen

Met de draaiende proxy kunnen nu tests worden uitgevoerd en verwerkt. De volgende cURL-opdracht geeft een verzoek met de hostheader die in de proxyconfiguratie is gedefinieerd.

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

Het HTTP-verzoek zal leiden tot een fout 503Dit komt doordat de upstream-verbindingen niet werken en niet beschikbaar zijn. Hierdoor heeft Envoy Proxy geen beschikbare doeladressen voor het verzoek. Het volgende commando start een reeks HTTP-services die overeenkomen met de configuratie die voor Envoy is gedefinieerd.

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

Met de beschikbare services kan Envoy succesvol verkeer naar de bestemming proxy'en.

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

Je zou een antwoord moeten zien dat aangeeft welke Docker-container het verzoek heeft verwerkt. In de logs van Envoy Proxy zou je ook de uitvoer van de toegangstekst moeten zien.

Extra HTTP-responsheaders

In de headers van een geldig verzoek zie je extra HTTP-headers. De header toont de tijd die de upstream-host heeft besteed aan het verwerken van het verzoek. Dit wordt uitgedrukt in milliseconden. Dit is nuttig als de client de verwerkingstijd wil vergelijken met de netwerkvertraging.

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

Eindconfiguratie

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 }

Extra informatie van de vertaler

Instructies voor het installeren van Envoy Proxy vind je op de website https://www.getenvoy.io/

Standaard ontbreekt de systemd-serviceconfig in de rpm.

Voeg de systemd-serviceconfig toe aan \/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

Je moet de directory \/etc\/envoy\/ aanmaken en daarin de config.yaml plaatsen.

Er is een Telegram-chat over Envoy Proxy: https://t.me/envoyproxy_ru

Envoy Proxy ondersteunt geen statische inhoudsdistributie. Daarom, wie kan stemmen op deze functionaliteit: https://github.com/envoyproxy/envoy/issues/378

Alleen geregistreerde gebruikers kunnen deelnemen aan de enquĆŖte. Log in, alstublieft.

Heeft deze post je aangespoord om Envoy Proxy te installeren en te testen?

  • ja

  • nee

75 gebruikers stemden. 18 gebruikers onthielden zich.

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster