Nginx에서 Envoy 프록시로 마이그레이션

안녕, 하브르! 게시물 번역을 알려드립니다. Nginx에서 Envoy 프록시로 마이그레이션.

Envoy는 개별 서비스 및 애플리케이션용으로 설계된 고성능 분산 프록시 서버(C++로 작성)이며, 대규모 마이크로서비스 "서비스 메시" 아키텍처용으로 설계된 통신 버스이자 "범용 데이터 플레인"이기도 합니다. 이를 만들 때 NGINX, HAProxy, 하드웨어 로드 밸런서, 클라우드 로드 밸런서 등 서버 개발 중에 발생한 문제에 대한 솔루션을 고려했습니다. Envoy는 각 애플리케이션과 함께 작동하고 네트워크를 추상화하여 플랫폼에 관계없이 공통 기능을 제공합니다. 인프라의 모든 서비스 트래픽이 Envoy 메시를 통해 흐르면 일관된 관찰 가능성으로 문제 영역을 시각화하고, 전반적인 성능을 조정하고, 특정 위치에 핵심 기능을 추가하는 것이 쉬워집니다.

기능

• 독립 프로세스 아키텍처: Envoy는 소량의 RAM을 차지하는 독립형 고성능 서버입니다. 이는 모든 애플리케이션 언어 또는 프레임워크와 함께 작동합니다.
• http/2 및 grpc 지원: envoy는 들어오고 나가는 연결에 대해 최고 수준의 http/2 및 grpc 지원을 제공합니다. 이는 http/1.1에서 http/2까지의 투명 프록시입니다.
• 고급 로드 밸런싱: Envoy는 자동 재시도, 체인 차단, 전역 속도 제한, 요청 섀도잉, 로컬 영역 로드 밸런싱 등을 포함한 고급 로드 밸런싱 기능을 지원합니다.
• 구성 관리 API: Envoy는 구성을 동적으로 관리하기 위한 강력한 API를 제공합니다.
• 관찰 가능성: L7 트래픽에 대한 심층적인 관찰 가능성, 분산 추적에 대한 기본 지원, mongodb, dynamodb 및 기타 여러 애플리케이션의 관찰 가능성.

1단계 - NGINX 구성 예

이 스크립트는 특별히 제작된 파일을 사용합니다. 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 프록시에 적용되는 것은 아니며 일부 설정을 구성할 필요가 없습니다. 특사 프록시는 네 가지 주요 유형NGINX가 제공하는 핵심 인프라를 지원합니다. 핵심은 다음과 같습니다.

• 청취자: Envoy 프록시가 들어오는 요청을 수락하는 방법을 결정합니다. Envoy 프록시는 현재 TCP 기반 리스너만 지원합니다. 연결이 설정되면 처리를 위해 필터 세트로 전달됩니다.
• 필터: 이는 들어오고 나가는 데이터를 처리할 수 있는 파이프라인 아키텍처의 일부입니다. 이 기능에는 데이터를 클라이언트에 보내기 전에 압축하는 Gzip과 같은 필터가 포함되어 있습니다.
• 라우터: 클러스터로 정의된 필수 대상으로 트래픽을 전달합니다.
• 클러스터: 트래픽 및 구성 매개변수에 대한 엔드포인트를 정의합니다.

이 네 가지 구성 요소를 사용하여 특정 NGINX 구성과 일치하는 Envoy 프록시 구성을 생성합니다. Envoy의 목표는 API 및 동적 구성을 사용하여 작업하는 것입니다. 이 경우 기본 구성은 NGINX의 정적, 하드 코딩된 설정을 사용합니다.

2단계 - NGINX 구성

첫 번째 부분 nginx.conf 구성해야 하는 일부 NGINX 내부를 정의합니다.

작업자 연결

아래 구성은 작업자 프로세스 및 연결 수를 결정합니다. 이는 NGINX가 수요를 충족하기 위해 어떻게 확장되는지를 나타냅니다.

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy 프록시는 다양한 방식으로 워크플로와 연결을 관리합니다.

Envoy는 시스템의 각 하드웨어 스레드에 대해 작업자 스레드를 생성합니다. 각 작업자 스레드는 다음을 담당하는 비차단 이벤트 루프를 실행합니다.

1. 청취자 한 분 한 분의 말씀을 듣고
2. 새로운 연결 수락
3. 연결을 위한 필터 세트 만들기
4. 연결 수명 동안 모든 I/O 작업을 처리합니다.

전달 동작을 포함하여 모든 추가 연결 처리는 전적으로 작업자 스레드에서 처리됩니다.

Envoy의 각 작업자 스레드에는 연결 풀이 있습니다. 따라서 HTTP/2 연결 풀은 외부 호스트당 한 번에 하나의 연결만 설정합니다. 작업자 스레드가 2개라면 안정적인 상태에서는 외부 호스트당 XNUMX개의 HTTP/XNUMX 연결이 있게 됩니다. 모든 것을 하나의 작업자 스레드에 유지함으로써 마치 단일 스레드인 것처럼 거의 모든 코드를 차단 없이 작성할 수 있습니다. 필요한 것보다 더 많은 작업자 스레드가 할당되면 이로 인해 메모리가 낭비되고 유휴 연결이 많이 생성되며 연결이 풀로 다시 반환되는 횟수가 줄어들 수 있습니다.

자세한 정보는 Envoy 프록시 블로그.

HTTP 구성

다음 NGINX 구성 블록은 다음과 같은 HTTP 설정을 정의합니다.

• 지원되는 MIME 유형
• 기본 시간 초과
• Gzip 구성

나중에 설명할 Envoy 프록시의 필터를 사용하여 이러한 측면을 사용자 정의할 수 있습니다.

3단계 - 서버 구성

HTTP 구성 블록에서 NGINX 구성은 포트 8080에서 수신 대기하고 도메인에 대한 수신 요청에 응답하도록 지정합니다. one.example.com и www.one.example.com.

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

Envoy 내부에서는 Listener에 의해 제어됩니다.

특사 청취자

Envoy Proxy를 시작할 때 가장 중요한 측면은 청취자를 정의하는 것입니다. Envoy 인스턴스 실행 방법을 설명하는 구성 파일을 생성해야 합니다.

아래 스니펫은 새 리스너를 생성하고 이를 포트 8080에 바인딩합니다. 구성은 수신 요청에 대해 바인딩해야 하는 포트를 Envoy 프록시에 알려줍니다.

Envoy 프록시는 구성에 YAML 표기법을 사용합니다. 이 표기법에 대한 소개는 여기를 참조하세요. 링크.

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

정의할 필요가 없습니다. 서버 이름, Envoy 프록시 필터가 이를 처리하기 때문입니다.

4단계 - 위치 구성

요청이 NGINX에 들어오면 위치 블록은 트래픽을 처리하는 방법과 라우팅할 위치를 결정합니다. 다음 조각에서는 사이트에 대한 모든 트래픽이 이름이 지정된 업스트림(번역자 참고 사항: 업스트림은 일반적으로 애플리케이션 서버임) 클러스터로 전송됩니다. 타겟클러스터. 업스트림 클러스터는 요청을 처리해야 하는 노드를 정의합니다. 이에 대해서는 다음 단계에서 논의하겠습니다.

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 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 대상을 지속적으로 비동기식으로 확인합니다. DNS 결과에서 반환된 각 IP 주소는 업스트림 클러스터의 명시적 호스트로 간주됩니다. 즉, 요청이 두 개의 IP 주소를 반환하는 경우 Envoy는 클러스터에 두 개의 호스트가 있고 둘 다 로드 밸런싱되어야 한다고 가정합니다. 결과에서 호스트가 제거되면 Envoy는 해당 호스트가 더 이상 존재하지 않는다고 가정하고 기존 연결 풀에서 트래픽을 가져옵니다.

자세한 내용은 특사 프록시 문서.

6단계 - 로그 액세스 및 오류

최종 구성은 등록입니다. Envoy Proxy는 오류 로그를 디스크에 푸시하는 대신 클라우드 기반 접근 방식을 취합니다. 모든 애플리케이션 로그는 다음으로 출력됩니다. 표준 출력 и 표준 오류.

사용자가 요청할 때 액세스 로그는 선택 사항이며 기본적으로 비활성화됩니다. HTTP 요청에 대한 액세스 로그를 활성화하려면 구성을 활성화하십시오. 액세스_로그 HTTP 연결 관리자의 경우. 경로는 다음과 같은 장치일 수 있습니다. 표준 출력, 또는 요구 사항에 따라 디스크의 파일.

다음 구성은 모든 액세스 로그를 다음으로 리디렉션합니다. 표준 출력 (번역자 참고 사항 - docker 내부에서 envoy를 사용하려면 stdout이 필요합니다. docker 없이 사용하는 경우 /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)%"}

Envoy 등록 방법에 대한 자세한 내용을 보려면 다음 사이트를 방문하세요.

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

로깅이 Envoy 프록시 작업에 대한 통찰력을 얻는 유일한 방법은 아닙니다. 여기에는 고급 추적 및 측정 기능이 내장되어 있습니다. 자세한 내용은 다음에서 확인할 수 있습니다. 추적 문서 또는를 통해 대화형 추적 스크립트.

7단계 - 실행

이제 구성을 NGINX에서 Envoy 프록시로 마이그레이션했습니다. 마지막 단계는 Envoy Proxy 인스턴스를 시작하여 테스트하는 것입니다.

사용자로 실행

NGINX 구성 줄 상단에 사용자 www www; 보안을 강화하기 위해 낮은 권한의 사용자로 NGINX를 실행하도록 지정합니다.

Envoy Proxy는 프로세스 소유자를 관리하기 위해 클라우드 기반 접근 방식을 사용합니다. 컨테이너를 통해 Envoy 프록시를 실행할 때 권한이 낮은 사용자를 지정할 수 있습니다.

Envoy 프록시 실행

아래 명령은 호스트의 Docker 컨테이너를 통해 Envoy 프록시를 실행합니다. 이 명령을 사용하면 Envoy는 포트 80에서 들어오는 요청을 수신할 수 있습니다. 그러나 리스너 구성에 지정된 대로 Envoy 프록시는 포트 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 프록시에는 요청에 사용할 수 있는 대상이 없습니다. 다음 명령은 Envoy에 정의된 구성과 일치하는 일련의 HTTP 서비스를 시작합니다.

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 프록시 로그에는 액세스 문자열 출력도 표시됩니다.

추가 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/

기본적으로 rpm에는 시스템 서비스 구성이 없습니다.

시스템 서비스 구성 /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 프록시는 정적 콘텐츠 제공을 지원하지 않습니다. 따라서 이 기능에 투표할 수 있는 사람은 다음과 같습니다. https://github.com/envoyproxy/envoy/issues/378

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

이 게시물이 특사 프록시를 설치하고 테스트하도록 권장했습니까?

• 예

• 아니

75명의 사용자가 투표했습니다. 18명의 사용자가 기권했습니다.

출처 : habr.com