🥇Migráció az Nginx-ről az Envoy Proxy-ra

Helló, Habr! Örömmel mutatom be a cikk fordítását: Migráció Nginx-ről Envoy Proxy-ra.

Az Envoy egy nagy teljesítményű elosztott proxy szerver (C++ nyelven íródott), amelyet független szolgáltatások és alkalmazások számára terveztek, valamint kommunikációs buszként és "univerzális adat síkként" funkcionál, amelyet nagy mikroservices architektúrákhoz, "service mesh"-ekhez fejlesztettek ki. Fejlesztésekor figyelembe vették azon problémákat, amelyek a NGINX, HAProxy, hardveres terheléselosztók és felhő terheléselosztók fejlesztése során merültek fel. Az Envoy minden alkalmazással együttműködik, és absztrahálja a hálózatot, közös funkciókat kínálva a platformtól függetlenül. Amikor a teljes szolgálati forgalom az infrastruktúrán belül az Envoy hálózatán keresztül halad, könnyű vizualizálni a problémás területeket, koherens megfigyelhetőséggel, a teljesítmény közös konfigurálásával és alapvető funkciók hozzáadásával egy adott ponton.

Lehetőségek

Eljárás-alapú architektúra: az envoy egy autonóm, nagy teljesítményű szerver, amely kis mennyiségű RAM-ot igényel. Bármely alkalmazási nyelvvel vagy keretrendszerrel együttműködik.
HTTP/2 és gRPC támogatás: az envoy elsőrangú támogatást nyújt a HTTP/2 és gRPC számára a bejövő és kimenő kapcsolatokhoz. Ez egy átlátszó proxy a HTTP/1.1-től a HTTP/2-ig.
Fejlett terheléskiegyenlítés: az envoy támogatja a fejlett terheléskiegyenlítési funkciókat, beleértve az automatikus újrapróbálkozásokat, a kapcsolatok megszakítását, globális sebességkorlátozásokat, lekérdezések elhomályosítását, helyi terheléskiegyenlítést zónák szerint stb.
API a konfiguráció kezelésére: az envoy megbízható API-t kínál a konfiguráció dinamikus kezelésére.
Megfigyelhetőség: mély megfigyelés az L7 forgalomban, beépített támogatás a megosztott nyomozáshoz, valamint a MongoDB, DynamoDB és sok más alkalmazás megfigyeléséhez.

1. lépés — NGINX konfiguráció példa

Ebben a forgatókönyvben egy speciálisan létrehozott fájlt használunk nginx.conf, amely a teljes példán alapul a NGINX Wiki. A konfigurációt szerkesztőben nézheti meg, ha megnyitja nginx.conf

az nginx alapkonfigurációt

felhasználó  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;
    }
  }
}

Az NGINX konfigurációknak általában három kulcsfontosságú eleme van:

Az NGINX szerver beállítása, a naplózási struktúra és a Gzip funkcionalitás. Ez globálisan van meghatározva minden esetben.
Az NGINX beállítása a kérdések fogadására a hoszton one.example.com a 8080-as porton.
A célhely beállítása, hogy hogyan kezeljük a forgalmat az URL különböző részeihez.

Nem minden konfiguráció lesz alkalmazva az Envoy Proxy-ra, és nem kell néhány paramétert beállítani. Az Envoy Proxy-nak van négy kulcsfontosságú típusa, amelyek támogatják az NGINX által kínált alapinfrastruktúrát. A mag az:

Hallgatók: Ezek határozzák meg, hogy az Envoy Proxy hogyan fogadja a bejövő kéréseket. Jelenleg az Envoy Proxy csak TCP-alapú hallgatókat támogat. Miután a kapcsolat létrejött, az átvitelre kerül egy szűrőhalmazon a feldolgozásra.
Szűrők: Ezek a csővezetéki architektúra részét képezik, amely képes kezelni a bejövő és kimenő adatokat. Ez a funkció szűrőket foglal magában, mint például a Gzip, amely tömöríti az adatokat, mielőtt elküldené azokat az ügyfélnek.
Irányítók: Ezek irányítják a forgalmat a szükséges célállomás felé, amelyet klaszterként határoznak meg.
Klaszterek: Ezek határozzák meg a forgalom végpontját és a konfigurációs paramétereket.

Ez a négy komponenst fogjuk használni az Envoy Proxy konfigurációjának létrehozására, hogy megfeleljen az NGINX által megadott konfigurációnak. Az Envoy célja az API-k kezelése és a dinamikus konfiguráció. Ebben az esetben az alap konfiguráció statikus, rögzített paramétereket fog használni az NGINX-ből.

2. lépés - Az NGINX konfigurálása

Első rész nginx.conf meghatározza az NGINX néhány belső komponensét, amelyet be kell állítani.

Worker Connections (Munkakapcsolatok)

Az alábbi konfiguráció meghatározza a munkafolyamatok és kapcsolatok számát. Ez azt jelzi, hogyan fog az NGINX skálázódni a kereslet kielégítésére.

worker_processes  2;

events {
  worker_connections   2000;
}

Az Envoy Proxy eltérően kezeli a munkafolyamatokat és kapcsolatok.

Az Envoy minden hardveres szálhoz létrehoz egy munkafolyamatot a rendszerben. Minden munkafolyamat egy nem blokkoló eseménycikluson fut, amely felelős a

Minden hallgató (listener) figyelésére
Új kapcsolatok elfogadására
Szűrőkészlet létrehozására a kapcsolathoz
Minden bemeneti-kimeneti művelet feldolgozására a kapcsolat élettartama alatt.

A kapcsolat további feldolgozása teljes mértékben a munkafolyamatban történik, beleértve bármilyen átirányítási viselkedést.

Az Envoy minden munkafolyamata rendelkezik egy kapcsolattal a medencében. Így a HTTP/2 kapcsolópulzusok csak egy kapcsolatot állítanak fel minden külső hoszthoz egyszerre; négy munkafolyamat esetén négy HTTP/2 kapcsolat lesz minden külső hoszthoz a stabil állapotban. Mivel mindent egy munkafolyamatban tartunk, a legtöbb kódot blokkolás nélkül írhajuk, mintha egyszálú lenne. Ha a szükségesnél több munkafolyamat van kijelölve, az memóriafelesleghez, sok inaktív kapcsolat létrejöttéhez és a kapcsolatok medencébe való visszatérésének csökkenéséhez vezethet.

További információért látogasson el a Envoy Proxy blogra.

HTTP konfiguráció

Az alábbi NGINX konfigurációs blokk határozza meg az HTTP beállításokat, mint például:

Milyen mime típusok támogatottak
Alapértelmezett időtúllépések
Gzip konfiguráció

Ezeket a szempontokat szűrőkkel testreszabhatja az Envoy Proxy-ben, amit később megvitatunk.

3. lépés — A Server konfigurációja

A HTTP konfigurációs blokkban az NGINX azt jelzi, hogy figyelje a 8080-as portot és válaszoljon a bejövő kérésekre a következő domainekhez: one.example.com és www.one.example.com.

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

Az Envoy esetében ezt hallgatók kezelik.

Az Envoy hallgatói

A legfontosabb tényező az Envoy Proxy használatának megkezdéséhez a hallgatók meghatározása. Létre kell hoznia egy konfigurációs fájlt, amely leírja, hogyan szeretné futtatni az Envoy példányt.

Az alábbi részlet létrehoz egy új hallgatót, és összekapcsolja azt a 8080-as porttal. A konfiguráció megadja, hogy az Envoy Proxy mely portokhoz kell csatlakoznia a bejövő kérésekhez.

Az Envoy Proxy YAML szintaxist használ a konfigurációjához. Ezen szintaxis megismeréséhez nézze meg ezt. linkre.

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

Nincs szükség meghatározni server_name, hiszen az Envoy Proxy szűrők ezt kezelni fogják.

4. lépés — Helymeghatározás konfigurációja

Amikor a kérés beérkezik az NGINX-be, a helymeghatározási blokk határozza meg, hogyan kell kezelni és hova kell irányítani a forgalmat. A következő részletben a weboldalra irányított forgalom az upstream (fordítási megjegyzés: az upstream általában az alkalmazásszervereket jelenti) klaszterhez kerül, amelynek neve targetCluster. Az upstream klaszter határozza meg azokat a csomópontokat, amelyeknek a kérés feldolgozása van. Erről a következő lépésben beszélünk.

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

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

Az Envoy-ban ezt a feladatot a szűrők végzik.

Envoy Szűrők

A statikus konfigurációban a szűrők határozzák meg, hogyan kell kezelni a bejövő kéréseket. Ebben az esetben azokat a szűrőket állítjuk be, amelyek megfelelnek server_names a korábbi lépésben. Amikor bejövő kérések érkeznek, amelyek bizonyos domainekhez és útvonalakhoz kapcsolódnak, a forgalom a klaszterbe irányul. Ez is megfelel az NGINX felfelé irányuló konfigurációjának.

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

Név envoy.http_connection_manager beépített szűrő az Envoy Proxy-ban. Más szűrők közé tartozik Redis, Mongo, TCP. A teljes listát megtalálja itt dokumentáció.

További információkért más terheléselosztási politikákról látogasson el a Envoy Dokumentációba.

5. lépés — Proxy és upstream konfiguráció

Az NGINX-ben az upstream konfiguráció meghatározza a forgalmat kezelő célserversorozatot. Ebben az esetben két klasztert rendeltek hozzá.

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

Az Envoy-ban ezt a klaszterek kezelik.

Envoy Klaszterek

Az upstream ekvivalens klasztereként van meghatározva. Ebben az esetben olyan hosztok kerültek meghatározásra, amelyek a forgalmat kezelni fogják. A hosztokhoz való hozzáférés módját, például a várakozási időt, a klaszter konfigurációjaként határozzák meg. Ez lehetővé teszi a finomabb ellenőrzést az olyan szempontok, mint a várakozási idő és a terheléselosztás vonatkozásában.

Másolás az editorhoz  klaszterek:
  - név: targetCluster
    csatlakozási_idő: 0.25s
    típus: STRICT_DNS
    dns_keresési_család: V4_ONLY
    lb_politika: ROUND_ROBIN
    hosztok: [
      { socket_address: { address: 172.18.0.3, port_value: 80 }},
      { socket_address: { address: 172.18.0.4, port_value: 80 }}
    ]

Szolgáltatás felfedezésekor STRICT_DNS Az Envoy folyamatosan és aszinkron módon fogja feloldani a megadott DNS célokat. Minden visszaadott IP-cím, amely a DNS-ből származik, egy explicit hosztnak minősül a felfelé irányuló klaszterben. Ez azt jelenti, hogy ha a kérés két IP-címet ad vissza, az Envoy fel fogja tételezni, hogy két hoszt van a klaszterben, és mindkettőt terheléselosztás alá kell vonni. Ha egy hoszt eltávolításra kerül az eredményből, az Envoy feltételezi, hogy az már nem létezik, és a forgalmat az összes létező kapcsolati poolból fogja választani.

További információért lásd. Az Envoy proxy szerver dokumentációját.

6. lépés - Hozzáférés a naplóhoz és hibák

A végső konfiguráció - naplózás. Ahelyett, hogy a hibanaplókat lemezre küldené, az Envoy Proxy felhőalapú megközelítést alkalmaz. Minden alkalmazásnapló a következő helyre kerül: stdout és stderr.

Amikor a felhasználók lekérdezést indítanak, a hozzáférési naplók opcionálisak és alapértelmezés szerint ki vannak kapcsolva. A HTTP lekérdezések hozzáférési naplóinak engedélyezéséhez aktiválja a konfigurációt: access_log a HTTP kapcsolatkezelő számára. Az útválasztás lehet egy eszköz, mint például stdout, vagy egy fájl a lemezen, az Ön igényeitől függően.

A következő konfiguráció minden hozzáférési naplót átirányít stdout (fordító megjegyzése - a stdout használata szükséges az envoy használatához docker alatt. Ha docker nélkül használja, cserélje ki a /dev/stdout-ot egy szokásos naplófájl elérési útjára). Másolja a részt a kapcsolatkezelő konfigurációs részébe:

Másolás a vágólapra access_log:
- név: envoy.file_access_log
  konfiguráció:
    elérési_út: "\/dev\/stdout"

Az eredményeknek így kell kinézniük:

      - név: envoy.http_connection_manager
        konfiguráció:
          codec_típus: auto
          stat_prefix: ingress_http
          access_log:
          - név: envoy.file_access_log
            konfiguráció:
              elérési_út: "\/dev\/stdout"
          route_config:

Alapértelmezés szerint az Envoy egy formátumstringet használ, amely tartalmazza a HTTP kérés részleteit:

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

A kimenet formátumának eredménye:

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

A kimenet tartalma a formátum mező beállításával testreszabható. Például:

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"

A naplóbejegyzés JSON formátumban is kiadható a mező beállításával json_format. Például:

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

További információt a proxy naplózási módszeréről a következő linken talál:

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

A naplózás nem az egyetlen módja annak, hogy betekintést nyerjünk az Envoy Proxy működésébe. Beépített nyomkövetési és metrikai funkciói vannak. További információért látogasson el a nyomkövetési dokumentációra vagy a Interaktív nyomkövetési szkript.

7. lépés – Indítás

Most átültette a konfigurációt NGINX-ről Envoy Proxy-ra. Az utolsó lépés az Envoy Proxy példányának elindítása a teszteléshez.

Indítás felhasználóként

A NGINX konfigurációjának tetején lévő sor user www www; megadja, hogy az NGINX alacsonyabb szintű jogosultságokkal rendelkező felhasználóként induljon a biztonság növelése érdekében.

Az Envoy Proxy felhőalapú megközelítést alkalmaz a folyamat tulajdonosának kezelésére. Amikor az Envoy Proxy-t konténeren keresztül indítjuk, meg tudjuk adni egy alacsonyabb jogkörű felhasználót.

Envoy Proxy indítása

Az alábbi parancs elindítja az Envoy Proxy-t Docker konténeren keresztül a gazdagépen. Ez a parancs lehetővé teszi az Envoy számára, hogy a 80-as porton figyelje a bejövő kéréseket. Azonban, ahogy a hallgató konfigurációjában meg van adva, az Envoy Proxy a 8080-as porton figyel a bejövő forgalomra. Ez lehetővé teszi a folyamat számára, hogy alacsony jogkörű felhasználóként fusson.

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

Tesztelés

A proxy indítása után a tesztek most elvégezhetők és feldolgozhatók. A következő cURL parancs egy kérést generál, amelynek a gazda címe a proxy beállításainak megfelelően van definiálva.

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

A HTTP kérés hibát eredményez 503Ez annak köszönhető, hogy a felfelé irányuló kapcsolatok nem működnek, és nem elérhetők. Így az Envoy Proxy-nek nincsenek elérhető célpontjai a kéréshez. A következő parancs egy sor HTTP-szolgáltatást indít el, amelyek megfelelnek az Envoy által meghatározott konfigurációnak.

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

A rendelkezésre álló szolgáltatásokkal az Envoy sikeresen tudja proxizni a forgalmat a rendeltetési helyhez.

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

Látnia kell egy választ, ami megmondja, hogy melyik Docker konténer kezelte a kérdést. Az Envoy Proxy naplójában szintén látnia kell a hozzáférési sort.

További HTTP válaszfejlécek (HTTP Response)

A valódisággal ellátott kérés válaszfejléceiben további HTTP-fejléceket fog látni. A fejlécben megjelenik az idő, amelyet a felülről érkező hoszt a kérés feldolgozására fordított. Millisekundumban kifejezve. Ez hasznos, ha az ügyfél szeretné meghatározni a kiszolgálási időt a hálózati késleltetéshez képest.

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

Végső konfiguráció

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 }

További információ a fordítótól

Az Envoy Proxy telepítési utasításait a honlapon találhatja. https://www.getenvoy.io/

Alapértelmezetten az rpm-ből hiányzik a systemd szolgáltatás konfiguráció.

Adjon hozzá systemd szolgáltatás konfigurációt a következőhöz: /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

Létre kell hoznia egy könyvtárat a /etc/envoy/ útvonalon, és oda elhelyezni a config.yaml fájlt.

Az envoy proxy-hoz van Telegram csoport: https://t.me/envoyproxy_ru

Az Envoy Proxy nem támogatja a statikus tartalom kiszolgálását. Ezért kérjük, szavazzanak a funkcióra: https://github.com/envoyproxy/envoy/issues/378

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.