ProHoster > блог > Администрација > Миграција од Nginx до Envoy Proxy

Миграција од Nginx до Envoy Proxy

Здраво, Хабр! Ви пренесувам превод на објавата: Миграција од Nginx до Envoy Proxy.

Envoy е дистрибуиран прокси-сервер со високи перформанси (напишан во C++) дизајниран за поединечни услуги и апликации, тој е исто така комуникациски автобус и „универзална рамнина за податоци“ дизајнирана за големи архитектури за „сервисна мрежа“ на микросервис. При неговото креирање, беа земени предвид решенијата за проблемите што се појавија за време на развојот на серверите како што се NGINX, HAProxy, хардверски балансери на оптоварување и балансери на оптоварување во облак. Envoy работи заедно со секоја апликација и ја апстрахира мрежата за да обезбеди заедничка функционалност без оглед на платформата. Кога целиот услужен сообраќај во инфраструктурата тече низ мрежата Envoy, станува лесно да се визуелизираат проблематичните области со доследна набудливост, да се прилагодат севкупните перформанси и да се додаде основна функционалност на одредена локација.

Способности

  • Архитектура надвор од процесот: envoy е самостоен сервер со високи перформанси кој зафаќа мала количина RAM меморија. Работи во врска со кој било јазик или рамка за апликација.
  • http/2 и grpc поддршка: envoy има прва класа http/2 и grpc поддршка за дојдовни и појдовни врски. Ова е транспарентен прокси од http/1.1 до http/2.
  • Напредно балансирање на оптоварување: пратеникот поддржува напредни функции за балансирање на оптоварување, вклучувајќи автоматски повторни обиди, прекин на синџирот, глобално ограничување на стапката, засенчување на барањата, локално балансирање на оптоварувањето во зоната итн.
  • API за управување со конфигурација: envoy обезбедува робустен API за динамичко управување со вашата конфигурација.
  • Набљудливост: Длабока набудливост на сообраќајот L7, мајчин поддршка за дистрибуирано следење и набљудување на mongodb, dynamodb и многу други апликации.

Чекор 1 - Пример NGINX Config

Оваа скрипта користи специјално изработена датотека nginx.conf, врз основа на целосниот пример од NGINX Вики. Можете да ја видите конфигурацијата во уредникот со отворање nginx.conf

nginx извор конфигурација

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 обично имаат три клучни елементи:

  1. Конфигурирање на NGINX сервер, структура на дневник и функционалност на Gzip. Ова е глобално дефинирано во сите случаи.
  2. Конфигурирање на NGINX да прифаќа барања до домаќинот one.example.com на порта 8080.
  3. Поставување на целната локација, како да се справи со сообраќајот за различни делови од URL-то.

Не целата конфигурација ќе важи за Envoy Proxy и не треба да конфигурирате некои поставки. Пратеникот прокси има четири клучни типови, кои ја поддржуваат основната инфраструктура понудена од NGINX. Јадрото е:

  • Слушатели: Тие одредуваат како Envoy Proxy прифаќа дојдовни барања. Envoy Proxy моментално поддржува само слушатели базирани на TCP. Откако ќе се воспостави врска, таа се пренесува на сет на филтри за обработка.
  • Филтри: Тие се дел од архитектурата на гасоводот што може да ги обработува влезните и излезните податоци. Оваа функционалност вклучува филтри како што е Gzip, кој ги компресира податоците пред да ги испрати до клиентот.
  • Рутери: Тие го проследуваат сообраќајот до бараната дестинација, дефинирана како кластер.
  • Кластери: Тие ја дефинираат крајната точка за сообраќајот и параметрите за конфигурација.

Ќе ги користиме овие четири компоненти за да создадеме конфигурација на Envoy Proxy за да одговара на специфична NGINX конфигурација. Целта на Envoy е да работи со API и динамична конфигурација. Во овој случај, основната конфигурација ќе користи статични, тврдокодирани поставки од NGINX.

Чекор 2 - Конфигурација на NGINX

Во првиот дел nginx.conf дефинира некои внатрешни NGINX што треба да се конфигурираат.

Работнички врски

Конфигурацијата подолу го одредува бројот на работни процеси и врски. Ова покажува како NGINX ќе скалира за да ја задоволи побарувачката.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy управува со работните текови и врските на различни начини.

Envoy создава работничка нишка за секоја хардверска нишка на системот. Секоја работничка нишка извршува неблокирачка циклус на настани за која е одговорна

  1. Слушање на секој слушател
  2. Прифаќање нови врски
  3. Создавање сет на филтри за поврзување
  4. Обработете ги сите I/O операции за време на траењето на врската.

Целата понатамошна обработка на конекцијата е целосно обработена во работниот конец, вклучувајќи го секое однесување за препраќање.

За секоја работничка нишка во Envoy, постои базен за поврзување. Значи HTTP/2 поврзувачките базени воспоставуваат само една врска по надворешен хост во исто време, ако има четири работни нишки, ќе има четири HTTP/2 конекции по надворешен хост во стабилна состојба. Со задржување на сè во една работничка нишка, речиси целиот код може да се напише без блокирање, како да е со една нишка. Ако се распределат повеќе работни нишки отколку што е потребно, тоа може да доведе до залудно потрошена меморија, создавање голем број на неактивен врски и намалување на бројот на пати кога врските се враќаат назад во базенот.

За повеќе информации посетете ја Блог за полномошник на пратеник.

HTTP конфигурација

Следниот конфигурациски блок NGINX ги дефинира поставките за HTTP како што се:

  • Какви типови на мимика се поддржани
  • Стандарден тајмаут
  • Конфигурација на Gzip

Можете да ги приспособите овие аспекти користејќи филтри во Envoy Proxy, за што ќе разговараме подоцна.

Чекор 3 - Конфигурација на серверот

Во блокот за конфигурација HTTP, конфигурацијата NGINX одредува да слуша на портата 8080 и да одговара на дојдовните барања за домени one.example.com и www.one.example.com.

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

Внатре во Енвој, тој е контролиран од Слушатели.

Пратенички слушатели

Најважниот аспект за започнување со Envoy Proxy е дефинирањето на вашите слушатели. Треба да креирате конфигурациска датотека што опишува како сакате да ја извршите инстанцата Envoy.

Исечокот подолу ќе создаде нов слушател и ќе го поврзе со портата 8080. Конфигурацијата му кажува на Envoy Proxy за кои порти треба да се поврзе за дојдовните барања.

Envoy Proxy користи нотација YAML за својата конфигурација. За вовед во оваа нотација, погледнете овде врска.

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

Нема потреба да се дефинира име на сервер, бидејќи филтрите за прокси за пратеник ќе се справат со ова.

Чекор 4 - Конфигурација на локација

Кога барањето доаѓа во NGINX, блокот за локација одредува како да се обработи и каде да се насочува сообраќајот. Во следниот фрагмент, целиот сообраќај кон страницата е префрлен во горе (забелешка на преведувачот: горе е обично сервер за апликации) именуван targetCluster. Нагорниот кластер ги дефинира јазлите кои треба да го обработат барањето. За ова ќе разговараме во следниот чекор.

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

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

Во Envoy, Filters го прави ова.

Филтри за пратеник

За статична конфигурација, филтрите одредуваат како да ги обработуваат дојдовните барања. Во овој случај поставуваме филтри што се совпаѓаат имиња на сервери во претходниот чекор. Кога пристигнуваат дојдовни барања кои одговараат на одредени домени и маршрути, сообраќајот се пренасочува кон кластерот. Ова е еквивалент на 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

име пратеник.http_connection_manager е вграден филтер во Envoy Proxy. Други филтри вклучуваат Redis, Монго, TCP. Комплетната листа можете да ја најдете на документација.

За повеќе информации за другите политики за балансирање на оптоварување, посетете Пратеничка документација.

Чекор 5 - Конфигурација на прокси и нагоре

Во NGINX, upstream конфигурацијата дефинира сет на целни сервери кои ќе обработуваат сообраќај. Во овој случај, беа доделени два кластери.

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

Во Envoy, ова е управувано од кластери.

Кластери на пратеници

Нагорниот еквивалент се дефинира како кластери. Во овој случај, идентификувани се домаќините кои ќе го опслужуваат сообраќајот. Начинот на кој се пристапува до домаќините, како што се тајмаути, се дефинира како конфигурација на кластерот. Ова овозможува повеќе грануларна контрола врз аспекти како што се латентност и балансирање на оптоварување.

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

Кога користите откривање на услугата STRICT_DNS Envoy континуирано и асинхроно ќе ги решава наведените цели на DNS. Секоја вратена IP адреса од резултатот DNS ќе се смета за експлицитен хост во кластерот нагоре. Ова значи дека ако барањето врати две IP адреси, Envoy ќе претпостави дека има два хостови во кластерот и и двата мора да бидат избалансирани. Ако домаќинот е отстранет од резултатот, Envoy ќе претпостави дека повеќе не постои и ќе го повлече сообраќајот од сите постоечки базени за поврзување.

За повеќе информации видете Документација за полномошник на пратеник.

Чекор 6 - Пристап и грешки во дневникот

Конечната конфигурација е регистрација. Наместо да ги турка дневниците за грешки на дискот, Envoy Proxy презема пристап базиран на облак. Сите дневници на апликации се емитуваат во stdout и стдерр.

Кога корисниците поднесуваат барање, дневниците за пристап се опционални и стандардно оневозможени. За да овозможите дневници за пристап за барањата HTTP, овозможете ја конфигурацијата access_log за HTTP конекција менаџер. Патеката може да биде или уред како на пр stdout, или датотека на диск, во зависност од вашите барања.

Следната конфигурација ќе ги пренасочи сите дневници за пристап stdout (забелешка на преведувачот - stdout е потребен за да се користи envoy внатре докер. Ако се користи без докер, тогаш заменете го /dev/stdout со патеката до обична датотека за евиденција). Копирајте го фрагментот во делот за конфигурација за менаџерот за поврзување:

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

Резултатите треба да изгледаат вака:

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

Стандардно, Envoy има низа за формат што ги вклучува деталите за барањето HTTP:

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

Резултатот од оваа форматска низа е:

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

Излезната содржина може да се приспособи со поставување на полето за формат. На пример:

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"

Линијата за евиденција може да се емитува и во JSON формат со поставување на полето json_format. На пример:

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

За повеќе информации за Методологијата за регистрација на пратеник, посетете

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

Пријавувањето не е единствениот начин да се добие увид во работата со Envoy Proxy. Има вградени напредни можности за следење и метрика. Можете да дознаете повеќе на документација за следење или преку Интерактивна скрипта за следење.

Чекор 7 - Стартување

Сега ја префрливте вашата конфигурација од NGINX во Envoy Proxy. Последниот чекор е да започнете инстанца на Envoy Proxy за да ја тестирате.

Стартувај како корисник

На врвот на линијата за конфигурација NGINX корисник www www; одредува да работи NGINX како корисник со ниски привилегии за да се подобри безбедноста.

Envoy Proxy презема пристап базиран на облак за управување со кој поседува процес. Кога работиме Envoy Proxy преку контејнер, можеме да одредиме ниско привилегиран корисник.

Стартување на прокси за пратеник

Командата подолу ќе изврши Envoy Proxy преку контејнер Docker на домаќинот. Оваа команда му дава можност на Envoy да слуша дојдовни барања на портата 80. Сепак, како што е наведено во конфигурацијата на слушателот, Envoy Proxy го слуша дојдовниот сообраќај на портата 8080. Ова овозможува процесот да се извршува како корисник со ниска привилегија.

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

Тестирање

Кога работи проксито, сега може да се направат и обработуваат тестови. Следната команда cURL издава барање со заглавието на домаќинот дефинирано во конфигурацијата на прокси.

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

Барањето HTTP ќе резултира со грешка 503. Ова е затоа што врските нагоре не работат и не се достапни. Затоа, Envoy Proxy нема достапни дестинации за барањето. Следната команда ќе започне серија HTTP услуги кои одговараат на конфигурацијата дефинирана за Envoy.

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

Со достапните услуги, Envoy може успешно да го пренасочи сообраќајот до неговата дестинација.

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

Треба да видите одговор кој покажува кој контејнер на Docker го обработил барањето. Во дневниците на Envoy Proxy треба да видите и излез од низата за пристап.

Дополнителни заглавија за одговор на HTTP

Ќе видите дополнителни HTTP заглавија во заглавијата на одговорот на вистинското барање. Заглавието го прикажува времето што домаќинот нагоре го поминал за обработка на барањето. Изразено во милисекунди. Ова е корисно ако клиентот сака да го одреди времето на услугата во споредба со мрежната латентност.

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

Конечна конфигурација

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 }

Дополнителни информации од преведувачот

Инструкции за инсталирање на Envoy Proxy може да се најдат на веб-страницата https://www.getenvoy.io/

Стандардно, вртежи во минута нема конфигурација на системска услуга.

Додадете системска конфигурација на услугата /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

Треба да креирате директориум /etc/envoy/ и таму да ја ставите конфигурацијата config.yaml.

Постои телеграмски разговор со помош на прокси за пратеник: https://t.me/envoyproxy_ru

Envoy Proxy не поддржува сервирање статична содржина. Затоа, кој може да гласа за функцијата: https://github.com/envoyproxy/envoy/issues/378

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Дали оваа објава ве поттикна да инсталирате и тестирате прокси за пратеник?

  • Да

  • Нема

Гласаа 75 корисници. 18 корисници беа воздржани.

Извор: www.habr.com

Додадете коментар