🥇Nginx'ten Envoy Proxy'ye Geçiş

Merhaba Habr! Yazının çevirisini dikkatlerinize sunuyorum: Nginx'ten Envoy Proxy'ye Geçiş.

Envoy, bireysel hizmetler ve uygulamalar için tasarlanmış yüksek performanslı bir dağıtılmış proxy sunucusudur (C++ ile yazılmıştır), aynı zamanda büyük mikro hizmet "hizmet ağı" mimarileri için tasarlanmış bir iletişim veri yolu ve "evrensel veri düzlemidir". Oluşturulurken NGINX, HAProxy, donanım yük dengeleyicileri ve bulut yük dengeleyicileri gibi sunucuların geliştirilmesi sırasında ortaya çıkan sorunların çözümleri dikkate alındı. Envoy, her uygulamayla birlikte çalışır ve platformdan bağımsız olarak ortak işlevsellik sağlamak için ağı soyutlar. Bir altyapıdaki tüm hizmet trafiği Envoy ağından geçtiğinde, sorunlu alanları tutarlı gözlemlenebilirlikle görselleştirmek, genel performansı ayarlamak ve belirli bir konuma temel işlevsellik eklemek kolaylaşır.

fırsatlar

Süreç dışı mimari: elçi, az miktarda RAM kaplayan, bağımsız, yüksek performanslı bir sunucudur. Herhangi bir uygulama dili veya çerçevesiyle birlikte çalışır.
http/2 ve grpc desteği: elçi, gelen ve giden bağlantılar için birinci sınıf http/2 ve grpc desteğine sahiptir. Bu, http/1.1'den http/2'ye kadar şeffaf bir proxy'dir.
Gelişmiş Yük Dengeleme: elçi, otomatik yeniden denemeler, zincir kırma, küresel hız sınırlama, istek gölgeleme, yerel bölge yük dengeleme vb. dahil olmak üzere gelişmiş yük dengeleme özelliklerini destekler.
Konfigürasyon Yönetimi API'si: envoy, konfigürasyonunuzu dinamik olarak yönetmek için güçlü bir API sağlar.
Gözlemlenebilirlik: L7 trafiğinin derinlemesine gözlemlenebilirliği, dağıtılmış izleme için yerel destek ve mongodb, dynamodb ve diğer birçok uygulamanın gözlemlenebilirliği.

Adım 1 – Örnek NGINX Yapılandırması

Bu komut dosyası özel hazırlanmış bir dosya kullanıyor nginx.conf, tam örneğe dayanarak NGINX Wiki. Düzenleyicide konfigürasyonu açarak görüntüleyebilirsiniz. nginx.conf

nginx kaynak yapılandırması

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 yapılandırmalarında genellikle üç temel öğe bulunur:

NGINX sunucusunu, günlük yapısını ve Gzip işlevselliğini yapılandırma. Bu, her durumda global olarak tanımlanır.
NGINX'i ana makineye gelen istekleri kabul edecek şekilde yapılandırma bir.example.com 8080 numaralı bağlantı noktasında.
Hedef konumu ayarlama, URL'nin farklı bölümlerine yönelik trafiğin nasıl yönetileceği.

Tüm yapılandırmalar Envoy Proxy'ye uygulanmaz ve bazı ayarları yapılandırmanız gerekmez. Elçi Vekili dört anahtar türüNGINX tarafından sunulan temel altyapıyı destekleyen. Çekirdek şudur:

Dinleyiciler: Elçi Vekilinin gelen talepleri nasıl kabul edeceğini belirlerler. Envoy Proxy şu anda yalnızca TCP tabanlı dinleyicileri desteklemektedir. Bağlantı kurulduğunda, işlenmek üzere bir dizi filtreye aktarılır.
Filtreler: Gelen ve giden verileri işleyebilen bir boru hattı mimarisinin parçasıdırlar. Bu işlevsellik, verileri istemciye göndermeden önce sıkıştıran Gzip gibi filtreleri içerir.
Yönlendiriciler: Trafiği küme olarak tanımlanan gerekli hedefe iletirler.
Kümeler: Trafik ve yapılandırma parametreleri için uç noktayı tanımlarlar.

Belirli bir NGINX yapılandırmasıyla eşleşecek bir Envoy Proxy yapılandırması oluşturmak için bu dört bileşeni kullanacağız. Elçinin hedefi API'ler ve dinamik yapılandırmayla çalışmaktır. Bu durumda temel yapılandırma, NGINX'in statik, sabit kodlu ayarlarını kullanacaktır.

Adım 2 - NGINX Yapılandırması

Birinci bölüm nginx.conf yapılandırılması gereken bazı NGINX dahili bileşenlerini tanımlar.

Çalışan Bağlantıları

Aşağıdaki yapılandırma çalışan süreçlerin ve bağlantıların sayısını belirler. Bu, NGINX'in talebi karşılamak için nasıl ölçekleneceğini gösterir.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy, iş akışlarını ve bağlantıları farklı şekillerde yönetir.

Envoy, sistemdeki her donanım iş parçacığı için bir çalışan iş parçacığı oluşturur. Her çalışan iş parçacığı, aşağıdakilerden sorumlu olan, engellemeyen bir olay döngüsünü yürütür.

Her dinleyiciyi dinlemek
Yeni bağlantıları kabul etme
Bağlantı için bir dizi filtre oluşturma
Bağlantının ömrü boyunca tüm G/Ç işlemlerini işleyin.

Diğer tüm bağlantı işlemleri, herhangi bir yönlendirme davranışı da dahil olmak üzere tamamen çalışan iş parçacığında gerçekleştirilir.

Envoy'daki her çalışan iş parçacığı için bir bağlantı havuzu vardır. Dolayısıyla, HTTP/2 bağlantı havuzları aynı anda harici ana bilgisayar başına yalnızca bir bağlantı kurar; dört çalışan iş parçacığı varsa, kararlı bir durumda harici ana bilgisayar başına dört HTTP/2 bağlantısı olacaktır. Her şeyi tek bir çalışan iş parçacığında tutarak neredeyse tüm kodlar, sanki tek iş parçacığıymış gibi, engelleme olmadan yazılabilir. Gerekenden daha fazla çalışan iş parçacığı tahsis edilirse, bu durum belleğin boşa harcanmasına, çok sayıda boş bağlantının oluşmasına ve bağlantıların havuza geri döndürülme sayısının azalmasına neden olabilir.

Daha fazla bilgi için ziyaret edin Elçi Vekil blogu.

HTTP Yapılandırması

Aşağıdaki NGINX yapılandırma bloğu aşağıdaki gibi HTTP ayarlarını tanımlar:

Hangi mime türleri desteklenir
Varsayılan Zaman Aşımları
Gzip Yapılandırması

Daha sonra tartışacağımız Envoy Proxy'deki filtreleri kullanarak bu özellikleri özelleştirebilirsiniz.

Adım 3 - Sunucu Yapılandırması

HTTP yapılandırma bloğunda NGINX yapılandırması, 8080 numaralı bağlantı noktasını dinlemeyi ve etki alanları için gelen isteklere yanıt vermeyi belirtir. bir.example.com и www.one.example.com.

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

Envoy'un içinde Dinleyiciler tarafından kontrol edilir.

Elçi dinleyicileri

Envoy Proxy'yi kullanmaya başlamanın en önemli yönü dinleyicilerinizi tanımlamaktır. Envoy örneğini nasıl çalıştırmak istediğinizi açıklayan bir yapılandırma dosyası oluşturmanız gerekir.

Aşağıdaki kod parçası yeni bir dinleyici oluşturacak ve onu 8080 numaralı bağlantı noktasına bağlayacaktır. Yapılandırma, Envoy Proxy'ye gelen istekler için hangi bağlantı noktalarına bağlanması gerektiğini söyler.

Envoy Proxy, yapılandırması için YAML gösterimini kullanır. Bu gösterime giriş için buraya bakın bağlantı.

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

Tanımlamaya gerek yok sunucu adı, çünkü Envoy Proxy filtreleri bu işi halledecektir.

Adım 4 - Konum Yapılandırması

NGINX'e bir istek geldiğinde konum bloğu, trafiğin nasıl işleneceğini ve nereye yönlendirileceğini belirler. Aşağıdaki parçada, siteye gelen tüm trafik, adı verilen bir yukarı akış (çevirmenin notu: yukarı akış genellikle bir uygulama sunucusudur) kümesine aktarılır. hedefKüme. Yukarı akış kümesi, isteği işlemesi gereken düğümleri tanımlar. Bunu bir sonraki adımda tartışacağız.

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

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

Envoy'da Filters bunu yapıyor.

Elçi Filtreleri

Statik bir yapılandırma için filtreler, gelen isteklerin nasıl işleneceğini belirler. Bu durumda eşleşen filtreleri ayarlıyoruz sunucu_adları önceki adımda. Belirli etki alanları ve rotalarla eşleşen gelen istekler geldiğinde trafik kümeye yönlendirilir. Bu, NGINX'in aşağıdan yukarıya yapılandırmasına eşdeğerdir.

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

isim elçi.http_connection_manager Envoy Proxy'de yerleşik bir filtredir. Diğer filtreler şunları içerir: Redis, Mongo, TCP. Tam listeyi şu adreste bulabilirsiniz: belgeleme.

Diğer yük dengeleme politikaları hakkında daha fazla bilgi için şu adresi ziyaret edin: Elçi Belgeleri.

Adım 5 - Proxy ve Yukarı Akış Yapılandırması

NGINX'te yukarı akış yapılandırması, trafiği işleyecek bir dizi hedef sunucuyu tanımlar. Bu durumda iki küme atanmıştır.

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

Envoy'da bu, kümeler tarafından yönetilir.

Elçi Kümeleri

Yukarı akış eşdeğeri kümeler olarak tanımlanır. Bu durumda trafiğe hizmet verecek hostlar belirlenmiştir. Zaman aşımları gibi ana bilgisayarlara erişme şekli, küme yapılandırması olarak tanımlanır. Bu, gecikme ve yük dengeleme gibi hususlar üzerinde daha ayrıntılı kontrole olanak tanır.

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

Hizmet bulmayı kullanırken SRICT_DNS Elçi, belirtilen DNS hedeflerini sürekli ve eşzamansız olarak çözecektir. DNS sonucundan döndürülen her IP adresi, yukarı akış kümesindeki açık bir ana bilgisayar olarak kabul edilecektir. Bu, bir isteğin iki IP adresi döndürmesi durumunda Envoy'un kümede iki ana bilgisayar olduğunu ve her ikisinin de yük dengeli olması gerektiğini varsayacağı anlamına gelir. Bir ana bilgisayar sonuçtan çıkarılırsa, Envoy onun artık var olmadığını varsayacak ve mevcut bağlantı havuzlarından trafiği çekecektir.

Daha fazla bilgi için bakınız Elçi vekil belgeleri.

Adım 6 – Erişimi ve Hataları Günlüğe Kaydedin

Son yapılandırma kayıttır. Envoy Proxy, hata günlüklerini diske göndermek yerine bulut tabanlı bir yaklaşım benimser. Tüm uygulama günlükleri şu adrese gönderilir: stdout'u и Stderr.

Kullanıcılar bir istekte bulunduğunda erişim günlükleri isteğe bağlıdır ve varsayılan olarak devre dışıdır. HTTP isteklerine yönelik erişim günlüklerini etkinleştirmek için yapılandırmayı etkinleştirin erişim_ günlüğü HTTP bağlantı yöneticisi için. Yol aşağıdaki gibi bir cihaz olabilir: stdout'uGereksinimlerinize bağlı olarak .

Aşağıdaki yapılandırma tüm erişim günlüklerini şuraya yönlendirecektir: stdout'u (Çevirmenin notu - docker'ın içindeki elçiyi kullanmak için stdout gereklidir. Docker olmadan kullanılırsa, /dev/stdout'u normal bir günlük dosyasının yolu ile değiştirin). Parçacığı bağlantı yöneticisinin yapılandırma bölümüne kopyalayın:

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

Sonuçlar şöyle görünmelidir:

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

Varsayılan olarak Envoy'un HTTP isteğinin ayrıntılarını içeren bir biçim dizesi vardır:

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

Bu biçim dizesinin sonucu:

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

Çıkış içeriği, format alanı ayarlanarak özelleştirilebilir. Örneğin:

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"

Günlük satırı, alanı ayarlayarak JSON formatında da çıkarılabilir. json_format. Örneğin:

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

Elçi Kayıt Metodolojisi hakkında daha fazla bilgi için şu adresi ziyaret edin:

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

Envoy Proxy ile çalışmaya ilişkin bilgi edinmenin tek yolu günlük tutmak değildir. Dahili olarak gelişmiş izleme ve ölçüm yeteneklerine sahiptir. Daha fazlasını şu adreste bulabilirsiniz: belgeleri izleme aracılığıyla veya Etkileşimli izleme komut dosyası.

Adım 7 - Başlatma

Artık yapılandırmanızı NGINX'ten Envoy Proxy'ye taşıdınız. Son adım, test etmek için bir Envoy Proxy örneğini başlatmaktır.

Kullanıcı olarak çalıştır

NGINX konfigürasyon satırının en üstünde kullanıcı www www; güvenliği artırmak için NGINX'in düşük ayrıcalıklı bir kullanıcı olarak çalıştırılacağını belirtir.

Envoy Proxy, bir sürecin kime ait olduğunu yönetmek için bulut tabanlı bir yaklaşım benimsiyor. Envoy Proxy'yi bir konteyner üzerinden çalıştırdığımızda düşük ayrıcalıklı bir kullanıcı belirleyebiliriz.

Envoy Proxy'yi Başlatma

Aşağıdaki komut, Envoy Proxy'yi ana bilgisayardaki bir Docker kapsayıcısı aracılığıyla çalıştıracaktır. Bu komut, Envoy'a 80 numaralı bağlantı noktasından gelen istekleri dinleme yeteneği verir. Ancak, dinleyici yapılandırmasında belirtildiği gibi Envoy Proxy, 8080 numaralı bağlantı noktasından gelen trafiği dinler. Bu, işlemin düşük ayrıcalıklı bir kullanıcı olarak çalışmasına olanak tanır.

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

Test

Proxy çalışırken artık testler yapılabilir ve işlenebilir. Aşağıdaki cURL komutu, proxy yapılandırmasında tanımlanan ana bilgisayar başlığıyla bir istek yayınlar.

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

HTTP isteği bir hatayla sonuçlanacak 503. Bunun nedeni, yukarı akış bağlantılarının çalışmaması ve kullanılamamasıdır. Bu nedenle Elçi Proxy'sinin istek için kullanılabilir hedefi yok. Aşağıdaki komut, Envoy için tanımlanan yapılandırmayla eşleşen bir dizi HTTP hizmetini başlatacaktır.

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

Mevcut hizmetler sayesinde Envoy, trafiği hedefine başarıyla yönlendirebilir.

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

İsteği hangi Docker kapsayıcısının işlediğini belirten bir yanıt görmelisiniz. Envoy Proxy günlüklerinde ayrıca bir erişim dizesi çıktısı görmelisiniz.

Ek HTTP Yanıt Başlıkları

Gerçek isteğin yanıt başlıklarında ek HTTP başlıkları göreceksiniz. Başlık, yukarı akış ana bilgisayarının isteği işlemek için harcadığı süreyi görüntüler. Milisaniye cinsinden ifade edilir. İstemci ağ gecikmesine kıyasla hizmet süresini belirlemek isterse bu kullanışlıdır.

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

Son yapılandırma

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 }

Çevirmenden ek bilgi

Envoy Proxy'yi yükleme talimatlarını web sitesinde bulabilirsiniz https://www.getenvoy.io/

Varsayılan olarak rpm'nin bir sistemd hizmet yapılandırması yoktur.

Systemd hizmet yapılandırması /etc/systemd/system/envoy.service ekleyin:

[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

Bir /etc/envoy/ dizini oluşturmanız ve config.yaml yapılandırmasını buraya koymanız gerekir.

Elçi proxy'sini kullanan bir telgraf sohbeti var: https://t.me/envoyproxy_ru

Elçi Proxy'si statik içerik sunulmasını desteklemez. Bu nedenle kimler özelliğe oy verebilir: https://github.com/envoyproxy/envoy/issues/378

Ankete sadece kayıtlı kullanıcılar katılabilir. Giriş yapLütfen.

Bu gönderi sizi elçi proxy'sini kurup test etmeye teşvik etti mi?

evet
hayır

75 kullanıcı oy kullandı. 18 kişi çekimser kaldı.

Kaynak: habr.com

Nginx'ten Envoy Proxy'ye Geçiş