Миграция С Nginx На Envoy Proxy

Привет, Хабр! Предлагаю вашему вниманию перевод поста: Миграция с Nginx на Envoy Proxy .

Envoy — это высокопроизводительный распределенный прокси-сервер (написанный на C++), предназначенный для отдельных сервисов и приложений, а также коммуникационная шина и «универсальная плоскость данных», предназначенная для крупных микросервисных «сервисных» архитектур.

При его создании были учтены решения проблем, возникавших при разработке таких серверов, как NGINX, HAProxy, аппаратных балансировщиков нагрузки и облачных балансировщиков нагрузки.

Envoy работает вместе с каждым приложением и абстрагирует сеть для обеспечения общей функциональности независимо от платформы.

Когда весь сервисный трафик в инфраструктуре проходит через сетку Envoy, становится легко визуализировать проблемные области с постоянной наблюдаемостью, настраивать общую производительность и добавлять основные функции в определенном месте.

Возможности

• Внепроцессная архитектура: envoy — это автономный высокопроизводительный сервер, занимающий небольшой объем оперативной памяти.

  Он работает в сочетании с любым языком приложений или платформой.

• Поддержка http/2 и grpc: envoy имеет первоклассную поддержку http/2 и grpc для входящих и исходящих соединений.

  Это прозрачный прокси от http/1.1 до http/2.

• Расширенная балансировка нагрузки: envoy поддерживает расширенные функции балансировки нагрузки, включая автоматические повторные попытки, разрыв цепочки, глобальное ограничение скорости, теневое копирование запросов, балансировку нагрузки в локальной зоне и т. д.
• API управления конфигурациями: envoy предоставляет надежный API для динамического управления вашей конфигурацией.

• Наблюдаемость: глубокая наблюдаемость трафика L7, встроенная поддержка распределенной трассировки и наблюдаемость mongodb, dynamodb и многих других приложений.

Шаг 1 — Пример конфигурации 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;
     }
   }
 }

   

1. Настройка сервера NGINX, структуры журналов и функциональности Gzip. Во всех случаях это определяется глобально.

2. Настройка NGINX для приема запросов к хосту one.example.com на порту 8080.
3. Настройка целевого местоположения, обработка трафика для разных частей URL.

Прокси посланника имеет четыре типа ключей , которые поддерживают базовую инфраструктуру, предлагаемую NGINX. Ядро:

• Слушатели: Они определяют, как Envoy Proxy принимает входящие запросы.

  Envoy Proxy в настоящее время поддерживает только прослушиватели на основе TCP. Как только соединение установлено, оно передается набору фильтров для обработки.

• Фильтры: Они являются частью конвейерной архитектуры, которая может обрабатывать входящие и исходящие данные.

  Эта функциональность включает такие фильтры, как Gzip, который сжимает данные перед отправкой клиенту.

• Маршрутизаторы: Они перенаправляют трафик в необходимое место назначения, определенное как кластер.

• Кластеры: Они определяют конечную точку для параметров трафика и конфигурации.

В этом случае базовая конфигурация будет использовать статические, жестко закодированные настройки из NGINX.

Шаг 2. Настройка NGINX

Рабочие связи

Это показывает, как NGINX будет масштабироваться для удовлетворения спроса.

worker_processes 2; events { worker_connections 2000; }

Envoy Proxy управляет рабочими процессами и соединениями по-разному.

Envoy создает рабочий поток для каждого аппаратного потока в системе.

Каждый рабочий поток выполняет неблокирующий цикл событий, который отвечает за

1. Слушаем каждого слушателя
2. Принятие новых подключений
3. Создание набора фильтров для соединения
4. Обрабатывать все операции ввода-вывода в течение срока действия соединения.

Для каждого рабочего потока в Envoy существует пул соединений.

Таким образом, пулы соединений HTTP/2 одновременно устанавливают только одно соединение на каждый внешний хост. Если имеется четыре рабочих потока, на каждый внешний хост в стабильном состоянии будет четыре соединения HTTP/2. Если хранить все в одном рабочем потоке, почти весь код можно писать без блокировок, как если бы он был однопоточным.

Если выделяется больше рабочих потоков, чем необходимо, это может привести к пустой трате памяти, созданию большого количества простаивающих соединений и уменьшению количества соединений, возвращаемых обратно в пул.

Для получения дополнительной информации посетите Блог Envoy Proxy .

Конфигурация HTTP

• Какие типы MIME поддерживаются
• Таймауты по умолчанию
• Конфигурация Gzip

Шаг 3 — Настройка сервера

one.example.com И www.one.example.com .

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

Внутри Envoy им управляют Слушатели.

Слушатели посланника

Вам необходимо создать файл конфигурации, описывающий, как вы хотите запустить экземпляр 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 }

Нет необходимости определять имя сервера , поскольку фильтры Envoy Proxy справятся с этим.

Шаг 4 — Настройка местоположения

В следующем фрагменте весь трафик сайта передается в вышестоящий (примечание переводчика: вышестоящим обычно является сервер приложений) кластер с именем целевой кластер .

Восходящий кластер определяет узлы, которые должны обрабатывать запрос.

Мы обсудим это на следующем этапе.

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

Имя envoy.http_connection_manager — это встроенный фильтр в Envoy Proxy. Другие фильтры включают в себя Редис , Монго , TCP .

Полный список вы можете найти на документация .

Для получения дополнительной информации о других политиках балансировки нагрузки посетите Документация посланника .

Шаг 5. Настройка прокси и восходящего потока

В данном случае было выделено два кластера.

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 использует облачный подход. Все журналы приложений выводятся на стандартный вывод И stderr .

Когда пользователи делают запрос, журналы доступа не являются обязательными и по умолчанию отключены.

Чтобы включить журналы доступа для HTTP-запросов, включите конфигурацию доступ_журнал для менеджера HTTP-соединений.

Путь может быть либо устройством, например стандартный вывод или файл на диске, в зависимости от ваших требований.

Следующая конфигурация перенаправит все журналы доступа на стандартный вывод (примечание переводчика — для использования 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 — Запуск

Запуск от имени пользователя

Envoy Proxy использует облачный подход к управлению владельцами процессов.

Когда мы запускаем Envoy Proxy через контейнер, мы можем указать пользователя с низким уровнем привилегий.

Запуск прокси-сервера Envoy

Эта команда дает 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-ответа

В заголовке отображается время, потраченное вышестоящим хостом на обработку запроса.

Выражается в миллисекундах.

Это полезно, если клиент хочет определить время обслуживания по сравнению с задержкой в сети.

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

Окончательная конфигурация

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

https://www.getenvoy.io/ По умолчанию у rpm нет конфигурации службы systemd. Добавьте конфигурацию службы systemd /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. Есть чат в Telegram с использованием прокси-сервера: https://t.me/envoyproxy_ru Envoy Proxy не поддерживает обслуживание статического контента.

Итак, кто может голосовать за эту функцию: https://github.com/envoyproxy/envoy/issues/378 В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Побудил ли вас этот пост установить и протестировать прокси-сервер посланника? 42,21% да 65 57,79% нет 89 154 пользователя проголосовали.

32 пользователя воздержались.

Теги: #Nginx #Системное администрирование #Администрирование серверов #DevOps #Envoy

• Как Выбрать Лучшие Игры Для Iphone

  19 Oct, 24

• Российский Филиал Apple Принес Компании За Год 48,5 Млрд Рублей

  19 Oct, 24

• «Возможно Пиратская» Windows

  19 Oct, 24

• Обзор Vowney Verne V5. Процессор Мтк С Поддержкой Otg.

  19 Oct, 24

• Цифровые Мероприятия В Москве Со 2 По 8 Ноября

  19 Oct, 24

• Сделай Сам: Кап (Аэрофотосъемка С Воздушного Змея)

  19 Oct, 24

• Тамбов, Конференция. Часть Вторая

  19 Oct, 24

• Как Передать Полиморфный Объект Алгоритму Stl

  19 Oct, 24

• Один Из Крупнейших В Мире Биткойн-Процессоров Bitpay Разочаровался В Биткойнах

  19 Oct, 24

• Некоторые Музыканты Сопротивляются Цифровой Революции

  19 Oct, 24