🥇Nginx-dən Envoy Proxy-ə miqrasiya

Hey Habr! Yazının tərcüməsini təqdim edirik: Nginx-dən Envoy Proxy-ə köçür.

Elçi fərdi xidmətlər və proqramlar üçün nəzərdə tutulmuş yüksək performanslı paylanmış proksi serverdir (C++ dilində yazılmışdır), o, həmçinin böyük “xidmət şəbəkəsi” mikroservis arxitekturaları üçün nəzərdə tutulmuş kommunikasiya avtobusu və “universal məlumat müstəvisidir”. Yaradıldığı zaman NGINX, HAProxy, hardware yük balanslaşdırıcıları və bulud yükü balanslaşdırıcıları kimi serverlərin inkişafı zamanı yaranan problemlərin həlli yolları nəzərə alınmışdır. Elçi hər bir proqramla birlikdə işləyir və platformadan asılı olmayaraq ümumi funksionallığı təmin etmək üçün şəbəkəni mücərrədləşdirir. İnfrastrukturdakı bütün xidmət trafiki Envoy şəbəkəsindən keçəndə ardıcıl müşahidə, ümumi performansı tənzimləmək və xüsusi məkanda əsas funksionallıq əlavə etməklə problem sahələrini vizuallaşdırmaq asan olur.

İmkanları

Prosesdən kənar arxitektura: envoy az RAM tutan, müstəqil, yüksək performanslı serverdir. İstənilən proqram dili və ya çərçivə ilə birlikdə işləyir.
http/2 və grpc dəstəyi: elçi həm daxil olan, həm də gedən bağlantılar üçün yüksək səviyyəli http/2 və grpc dəstəyinə malikdir. Bu http/1.1-dən http/2-yə qədər şəffaf bir proxydir.
Qabaqcıl yük balansı: elçi avtomatik təkrar cəhdlər, zəncirvari xitam, qlobal sürətin məhdudlaşdırılması, sorğu kölgəsi, zonanın yerli yük balansı və s. daxil olmaqla qabaqcıl yük balanslaşdırma xüsusiyyətlərini dəstəkləyir.
Konfiqurasiya İdarəetmə API: elçi konfiqurasiyasını dinamik şəkildə idarə etmək üçün güclü API təmin edir.
Müşahidə oluna bilənlik: L7 trafikinin dərin müşahidəsi, paylanmış izləmə üçün yerli dəstək və mongodb, dynamodb və bir çox digər tətbiqlərin müşahidə oluna bilməsi.

Addım 1 — NGINX konfiqurasiya nümunəsi

Bu skript xüsusi hazırlanmış fayldan istifadə edir nginx.confdan tam nümunə əsasında Viki. Açaraq redaktorda konfiqurasiyaya baxa bilərsiniz nginx.conf

İlkin nginx konfiqurasiyası

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 konfiqurasiyaları adətən üç əsas elementə malikdir:

NGINX serverinin, giriş strukturunun və Gzip funksionallığının qurulması. Bu, bütün hallarda qlobal olaraq müəyyən edilir.
NGINX hosta sorğuları qəbul etmək üçün konfiqurasiya edilir one.example.com 8080 portunda.
Hədəf yerinin qurulması, URL-nin müxtəlif hissələri üçün trafikin idarə edilməsi.

Bütün konfiqurasiyalar Envoy Proxy-ə tətbiq edilməyəcək və bəzi parametrləri konfiqurasiya etmək lazım deyil. Elçi Proxy var dörd əsas növNGINX tərəfindən təklif olunan əsas infrastrukturu dəstəkləyən. Kernel belədir:

Dinləyicilər: Onlar Envoy Proxy-nin daxil olan sorğuları necə qəbul etdiyini müəyyənləşdirirlər. Envoy Proxy hazırda yalnız TCP əsaslı dinləyiciləri dəstəkləyir. Bağlantı qurulduqdan sonra emal üçün filtr dəstinə ötürülür.
Filtrlər: Onlar daxil olan və gedən məlumatları emal edə bilən boru kəməri arxitekturasının bir hissəsidir. Bu funksionallığa məlumatı müştəriyə göndərməzdən əvvəl sıxışdıran Gzip kimi filtrlər daxildir.
Routerlər: Onlar trafiki klaster kimi təyin olunan istənilən təyinat yerinə yönləndirirlər.
Klasterlər: Onlar trafik və konfiqurasiya seçimləri üçün son nöqtəni müəyyənləşdirirlər.

Biz bu dörd komponentdən xüsusi NGINX konfiqurasiyasına uyğun gələn Envoy Proxy konfiqurasiyasını yaratmaq üçün istifadə edəcəyik. Elçinin məqsədi API işi və dinamik konfiqurasiyadır. Bu halda, əsas konfiqurasiya NGINX-dən statik, sərt kodlu seçimlərdən istifadə edəcək.

Addım 2 — NGINX Konfiqurasiyası

Birinci hissə nginx.conf konfiqurasiya edilməli olan bəzi NGINX daxili elementlərini müəyyən edir.

İşçi Əlaqələri

Aşağıdakı konfiqurasiya işçi prosesləri və əlaqələrin sayını müəyyən edir. Bu, NGINX-in tələbatı ödəmək üçün necə genişlənəcəyini göstərir.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy iş axınlarını və əlaqələri müxtəlif yollarla idarə edir.

Elçi sistemdəki hər bir aparat teli üçün işçi mövzu yaradır. Hər bir işçi ipi cavabdeh olan bloklanmayan bir hadisə dövrəsini yerinə yetirir

Hər bir dinləyiciyə qulaq asmaq (dinləyici)
Yeni əlaqələri qəbul etmək
Bağlantı üçün filtr dəsti yaradın
Bağlantının müddəti ərzində bütün I/O əməliyyatlarının işlənməsi.

Əlaqənin bütün sonrakı emalları hər hansı ötürmə davranışı da daxil olmaqla, tamamilə işçi ipdə idarə olunur.

Elçidəki hər bir işçi ipi üçün hovuzda bir əlaqə var. Beləliklə, HTTP/2 əlaqə hovuzları hər bir xarici host üçün eyni anda yalnız bir əlaqə qurur, dörd işçi iplə, sabit vəziyyətdə hər bir xarici host üçün dörd HTTP/2 bağlantısı olacaq. Hər şeyi bir işçi ipdə saxlamaqla, demək olar ki, bütün kodlar bloksuz yazıla bilər, sanki tək yivli kimi. Lazım olduğundan daha çox işçi telləri ayrılırsa, bu, yaddaşın boşaldılmasına, çoxlu sayda boş bağlantıların yaranmasına və hovuza qayıdan qoşulmaların sayının azalmasına səbəb ola bilər.

Daha çox məlumat üçün ziyarət edin Envoy Proxy bloqu.

HTTP konfiqurasiyası

Aşağıdakı NGINX konfiqurasiya bloku HTTP parametrlərini müəyyən edir, məsələn:

Hansı mime növləri dəstəklənir
Defolt fasilələr
Gzip konfiqurasiyası

Bu aspektləri daha sonra müzakirə edəcəyimiz Envoy Proxy-də filtrlərlə fərdiləşdirə bilərsiniz.

Addım 3 - Server Konfiqurasiyası

HTTP konfiqurasiya blokunda NGINX konfiqurasiyası 8080 portuna qulaq asmağı və domenlər üçün daxil olan sorğulara cavab verməyi təyin edir. one.example.com и www.one.example.com.

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

Inside Envoy, Dinləyicilər bunu idarə edir.

Elçi dinləyicilər

Envoy Proxy ilə işə başlamağın ən vacib aspekti dinləyiciləri müəyyən etməkdir. Siz Envoy instansiyasını necə işə salmaq istədiyinizi təsvir edən konfiqurasiya faylı yaratmalısınız.

Aşağıdakı fraqment yeni dinləyici yaradacaq və onu 8080 portuna bağlayacaq. Konfiqurasiya Envoy Proxy-ə onun gələn sorğular üçün hansı portlara bağlanmalı olduğunu bildirir.

Envoy Proxy konfiqurasiyası üçün YAML notasiyasından istifadə edir. Bu notasiyaya giriş üçün buraya baxın link.

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

Müəyyənləşdirməyə ehtiyac yoxdur server_name, çünki Envoy Proxy filtrləri bunu idarə edəcək.

Addım 4 - Məkan Konfiqurasiyası

NGINX-ə sorğu daxil olduqda, yer bloku trafikin necə idarə olunacağını və hara yönəldiləcəyini müəyyən edir. Aşağıdakı fraqmentdə sayta gedən bütün trafik yuxarı axın (tərcüməçinin qeydi: yuxarı axın adətən proqram serveridir) adlı klasterə ötürülür. targetCluster. Yuxarı klaster sorğunu emal etməli olan qovşaqları müəyyən edir. Bunu növbəti addımda müzakirə edəcəyik.

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

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

Envoy-da Filtrlər bunu edir.

Elçi Filtrləri

Statik konfiqurasiya üçün filtrlər daxil olan sorğuların necə işləndiyini müəyyən edir. Bu halda uyğun gələn filtrləri təyin edirik server_adları əvvəlki addımda. Daxil olan sorğular müəyyən domenlərə və marşrutlara uyğun gələndə trafik klasterə yönləndirilir. Bu, NGINX yuxarı axını konfiqurasiyasının ekvivalentidir.

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

ad envoy.http_connection_manager Envoy Proxy-də quraşdırılmış filtrdir. Digər filtrlər daxildir Redis, Mongo, TCP. Tam siyahı ilə burada tanış ola bilərsiniz sənədləşdirmə.

Digər yük balanslaşdırma siyasətləri haqqında ətraflı məlumat üçün ziyarət edin Elçi Sənədləri.

Addım 5 - Proxy və Upstream Konfiqurasiyası

NGINX-də yuxarı axın konfiqurasiyası trafiki emal edəcək bir sıra hədəf serverləri müəyyən edir. Bu halda, iki klaster təyin edilmişdir.

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

Elçidə bu, klasterlər tərəfindən idarə olunur.

Elçi qrupları

Yuxarı axın ekvivalenti klasterlər kimi müəyyən edilir. Bu halda, trafikə xidmət edəcək hostlar müəyyən edilmişdir. Taymout kimi hostlara necə daxil olduğu klaster konfiqurasiyası kimi müəyyən edilir. Bu, gecikmə və yük balansı kimi aspektlərin detallılığına daha yaxşı nəzarət etməyə imkan verir.

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

Xidmət kəşfindən istifadə edərkən STRICT_DNS Elçi müəyyən edilmiş DNS hədəflərini davamlı və asinxron həll edəcək. DNS nəticəsindən qaytarılan hər bir IP ünvanı yuxarı klasterdə açıq host hesab ediləcək. Bu o deməkdir ki, sorğu iki IP ünvanını qaytararsa, Elçi klasterdə iki hostun olduğunu və hər ikisinin yük balanslı olması lazım olduğunu güman edəcək. Əgər host nəticədən silinərsə, Elçi onun artıq mövcud olmadığını güman edir və hər hansı mövcud əlaqə hovuzundan trafik çəkəcək.

Ətraflı məlumat üçün baxın Elçinin proxy sənədləri.

Addım 6 - Giriş və Səhvləri qeyd edin

Son konfiqurasiya qeydiyyatdır. Səhv qeydlərini diskə köçürmək əvəzinə, Envoy Proxy bulud əsaslı yanaşma tətbiq edir. Bütün proqram qeydləri buradan çıxarılır stdout и stderr.

İstifadəçilər sorğu etdikdə giriş qeydləri isteğe bağlıdır və defolt olaraq qeyri-aktivdir. HTTP sorğuları üçün giriş qeydlərini aktivləşdirmək üçün konfiqurasiyanı aktiv edin giriş_log HTTP əlaqə meneceri üçün. Yol ya kimi bir cihaz ola bilər stdout, və ya tələblərinizdən asılı olaraq diskdəki fayl.

Aşağıdakı konfiqurasiya bütün giriş qeydlərini yönləndirəcək stdout (tərcüməçinin qeydi - docker daxilində envoy istifadə etmək üçün stdout tələb olunur. Əgər docker olmadan istifadə olunursa, onda /dev/stdout-u adi log faylının yolu ilə əvəz edin). Parçanı əlaqə meneceri üçün konfiqurasiya bölməsinə kopyalayın:

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

Nəticələr belə görünməlidir:

      - 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 olaraq, Envoy HTTP sorğusunun təfərrüatlarını ehtiva edən format sətrinə malikdir:

[%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 format sətirinin nəticəsi belədir:

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

Çıxış məzmunu format sahəsini təyin etməklə fərdiləşdirilə bilər. Misal üçün:

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"

Jurnal xətti də sahəni təyin etməklə JSON formatında çıxarıla bilər json_format. Məsələn:

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

Elçi qeydiyyatı metodologiyası haqqında ətraflı məlumat üçün ziyarət edin

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

Logging Envoy Proxy ilə işləmək hissini əldə etməyin yeganə yolu deyil. O, inkişaf etmiş izləmə və ölçülərə malikdir. Ətraflı buradan öyrənə bilərsiniz iz sənədləri və ya vasitəsilə İnteraktiv marşrutlaşdırma skripti.

Addım 7 - işə salın

İndi konfiqurasiyanı NGINX-dən Envoy Proxy-ə köçürdünüz. Son addım onu sınaqdan keçirmək üçün Envoy Proxy instansiyasını işə salmaqdır.

İstifadəçi kimi işə salın

NGINX konfiqurasiya xəttinin yuxarı hissəsində istifadəçi www www; NGINX-in təhlükəsizliyi yaxşılaşdırmaq üçün aşağı imtiyazlı istifadəçi kimi işlədiyini göstərir.

Envoy Proxy prosesin kimə məxsus olduğunu idarə etmək üçün bulud əsaslı bir yanaşma tətbiq edir. Konteyner vasitəsilə Envoy Proxy-ni işə saldığımız zaman aşağı imtiyazlı istifadəçi təyin edə bilərik.

Envoy Proxy-ni işə salın

Aşağıdakı əmr hostda Docker konteyneri vasitəsilə Envoy Proxy-ni işə salacaq. Bu əmr Envoy-a 80-ci portda daxil olan sorğuları dinləmək imkanı verir. Bununla belə, dinləyici konfiqurasiyasında göstərildiyi kimi, Envoy Proxy 8080 portunda daxil olan trafiki dinləyir. Bu, prosesi aşağı imtiyazlara malik istifadəçi kimi işləməyə imkan verir.

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

Test

Proksi işə salındıqda, indi testlər edilə və emal edilə bilər. Aşağıdakı cURL əmri proksi konfiqurasiyasında müəyyən edilmiş host başlığı ilə sorğu verir.

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

HTTP sorğusu xəta ilə nəticələnəcək 503. Bunun səbəbi yuxarı axın bağlantılarının işləməməsi və mövcud olmamasıdır. Beləliklə, Envoy Proxy-nin sorğu üçün əlçatan hədəf istiqamətləri yoxdur. Aşağıdakı əmr Envoy üçün müəyyən edilmiş konfiqurasiyaya uyğun gələn bir sıra HTTP xidmətlərini işə salacaq.

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

Mövcud xidmətlərlə, Elçi trafiki təyinatına uğurla proksi edə bilər.

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

Hansı Docker konteynerinin sorğunu idarə etdiyini göstərən cavabı görməlisiniz. Envoy Proxy qeydlərində siz həmçinin çap edilmiş giriş sətirini görməlisiniz.

Əlavə HTTP Cavab Başlıqları (HTTP Response)

Etibarlı sorğunun cavab başlıqlarında əlavə HTTP başlıqlarını görəcəksiniz. Başlıq yuxarıdakı hostun sorğunu emal etməyə sərf etdiyi vaxtı göstərir. Millisaniyələrlə ifadə edilir. Müştəri şəbəkə gecikməsinə qarşı xidmət vaxtını müəyyən etmək istəsə, bu faydalıdır.

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

Son konfiqurasiya

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 }

Tərcüməçidən əlavə məlumat

Envoy Proxy-ni quraşdırmaq üçün təlimatları veb saytında tapa bilərsiniz https://www.getenvoy.io/

Defolt olaraq rpm-də sistem xidməti konfiqurasiyası yoxdur.

Systemd xidmət konfiqurasiyasını /etc/systemd/system/envoy.service-ə əlavə edin:

[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

Siz /etc/envoy/ kataloqunu yaratmalı və config.yaml konfiqurasiyasını ora qoymalısınız.

Elçi proxy üçün teleqram çatı var: https://t.me/envoyproxy_ru

Envoy Proxy statik məzmuna xidmət göstərməyi dəstəkləmir. Beləliklə, bir xüsusiyyətə kim səs verə bilər: https://github.com/envoyproxy/envoy/issues/378

Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. Daxil olunxahiş edirəm.

Bu yazı sizi elçi proksi quraşdırmağa və sınaqdan keçirməyə təşviq etdi?

bəli
нет

75 istifadəçi səs verib. 18 istifadəçi bitərəf qalıb.

Mənbə: www.habr.com

Nginx-dən Envoy Proxy-ə köçür