NGINX를 API 게이트웨이로 배포하기, 3부: gRPC 서비스 게시

Liam Crilly제품 관리 부문 수석 이사

이 글은 NGINX Open Source 및 NGINX Plus를 API 게이트웨이로 배포하는 방법을 다루는 블로그 시리즈의 세 번째 글입니다.

• 1부에서는 RESTful HTTP 기반 API의 API 게이트웨이로 NGINX Open Source 및 NGINX Plus를 사용하는 여러 사용 사례에 대한 자세한 지침을 제공합니다.
• 2부에서는 이러한 사용 사례를 확장하고, 프로덕션 환경에서 백엔드 API 서비스를 보호하고 안전하게 유지하기 위해 적용할 수 있는 다양한 보호 조치를 살펴봅니다.
• 이 게시물에서는 NGINX Open Source와 NGINX Plus를 gRPC 서비스용 API 게이트웨이로 배포하는 방법을 설명합니다. 2018년에 처음 게시된 이 글은 NGINX Plus 릴리스 23에서 도입된 네이티브 gRPC 상태 확인 프로토콜 지원을 활용하도록 업데이트되었습니다. 자세한 내용은 상태 확인 구현을 참조하세요.

참고: 별도로 명시된 경우를 제외하면 이 게시물의 모든 내용은 NGINX Plus와 NGINX Open Source 모두에 적용됩니다. 읽기 쉽도록 이 블로그의 나머지 부분에서는 두 버전 모두에 해당하는 내용을 설명할 때 간단히 “NGINX”라고 지칭합니다.

최근 몇 년간 마이크로서비스 애플리케이션 아키텍처의 개념과 이점은 여러 곳에서 자세히 다뤄졌으며, 그중에서도 특히 NGINX 블로그에서 폭넓게 소개되었습니다. 마이크로서비스 애플리케이션의 핵심은 HTTP API이며, 이 시리즈의 첫 두 게시물에서는 가상의 REST API를 사용하여 NGINX가 이러한 유형의 애플리케이션을 어떻게 지원하는지 설명합니다.

JSON 메시지 형식을 사용하는 REST API는 최신 애플리케이션에서 널리 사용되고 있지만, 모든 상황이나 조직에 적합한 이상적인 접근 방식은 아닙니다. 가장 일반적인 과제는 다음과 같습니다.

• 문서화 표준 – 개발자가 철저한 원칙을 따르거나 문서화 요구 사항이 의무화되어 있지 않으면 정확한 정의가 없는 REST API가 다수 생기기 쉽습니다. Open API Specification은 REST API를 위한 범용 인터페이스 기술 언어로 자리 잡았지만, 사용이 선택 사항이며 개발 조직 내에서 강력한 거버넌스가 필요합니다.
• 이벤트 및 장기 연결 – REST API는 HTTP를 전송 프로토콜로 사용하므로 대부분의 API 호출이 요청-응답 패턴을 따르게 됩니다. 애플리케이션에 서버에서 생성되는 이벤트가 필요한 경우 HTTP 롱 폴링 및 WebSocket과 같은 솔루션을 활용할 수 있지만, 결국 이러한 솔루션을 사용하려면 별도의 연계 API를 구축해야 합니다.
• 복잡한 트랜잭션 – REST API는 각각 URI로 표현되는 고유한 리소스라는 개념을 기반으로 구축됩니다. 애플리케이션 이벤트로 인해 여러 리소스를 업데이트해야 하는 경우, 비효율적인 여러 번의 API 호출을 수행하거나 REST의 핵심 원칙에 어긋나는 복잡한 트랜잭션을 백엔드에 구현해야 합니다.

최근 몇 년 사이 gRPC는 분산 애플리케이션, 특히 마이크로서비스 애플리케이션을 구축하기 위한 대안으로 부상했습니다. Google에서 처음 개발된 gRPC는 2015년에 오픈 소스로 공개되었으며, 현재는 Cloud Native Computing Foundation의 프로젝트입니다. 특히 gRPC는 HTTP/2를 전송 메커니즘으로 사용하여 바이너리 데이터 형식과 다중화 스트리밍 기능을 활용합니다.

gRPC의 주요 이점은 다음과 같습니다:

• 긴밀하게 결합된 인터페이스 정의 언어(프로토콜 버퍼)
• 스트리밍 데이터 기본 지원(양방향)
• 효율적인 바이너리 데이터 형식
• 다양한 프로그래밍 언어를 위한 자동 코드 생성을 통해 상호 운용성 문제 없이 진정한 다중 언어 개발 환경을 구현

gRPC 게이트웨이 정의

이 시리즈의 첫 두 게시물에서는 여러 API를 단일 진입점(예: https://api.example.com)을 통해 제공하는 방법을 설명했습니다. gRPC 트래픽의 기본 동작과 특성을 고려하면 NGINX를 gRPC 게이트웨이로 배포할 때도 동일한 접근 방식을 취하게 됩니다. 동일한 호스트 이름과 포트에서 HTTP와 gRPC 트래픽을 모두 처리할 수도 있지만, 다음과 같은 여러 이유로 두 트래픽을 분리하는 것이 더 바람직합니다:

• REST 및 gRPC 애플리케이션의 API 클라이언트는 서로 다른 형식의 오류 응답을 기대합니다
• 액세스 로그의 관련 필드는 REST와 gRPC에 따라 다릅니다
• gRPC는 레거시 웹 브라우저를 처리할 일이 없으므로 더 엄격한 TLS 정책을 적용할 수 있습니다.

이러한 분리를 구현하기 위해 gRPC 게이트웨이 구성을 기본 gRPC 구성 파일의 별도 server{} 블록에 배치합니다. 기본 gRPC 구성 파일은 grpc_gateway.conf이며, /etc/nginx/conf.d 디렉터리에 있습니다.

코드 예제를 로드하는 중…

먼저 gRPC 트래픽의 액세스 로그 항목 형식부터 정의합니다(1~4행). 이 예제에서는 JSON 형식을 사용하여 각 요청에서 가장 중요한 데이터를 수집합니다. 예를 들어 모든 gRPC 요청은 POST를 사용하므로 HTTP 메서드는 포함하지 않습니다. 또한 HTTP 상태 코드와 함께 gRPC 상태 코드도 기록합니다. 하지만 gRPC 상태 코드는 여러 방식으로 생성될 수 있습니다. 일반적인 상황에서는 grpc-status가 백엔드에서 HTTP/2 트레일러로 반환되지만, 일부 오류 상황에서는 백엔드 또는 NGINX 자체에서 HTTP/2 헤더로 반환될 수 있습니다. 액세스 로그를 간소화하기 위해 map 블록(6~9행)을 사용하여 새 변수 $grpc_status를 평가하고, 출처와 관계없이 gRPC 상태를 가져옵니다.

이 구성에는 평문(포트 50051) 트래픽과 TLS로 보호되는(포트 443) 트래픽을 모두 테스트할 수 있도록 두 개의 listen 지시문(12행과 13행)이 포함되어 있습니다. http2 매개변수는 NGINX가 HTTP/2 연결을 수락하도록 구성합니다. 이 매개변수는 ssl 매개변수와는 별개라는 점에 유의하세요. 또한 포트 50051은 gRPC에서 일반적으로 사용하는 평문 포트이지만 프로덕션 환경에서 사용하기에는 적합하지 않습니다.

TLS 구성은 일반적인 방식이지만, ssl_protocols 지시문(23행)은 허용되는 가장 낮은 프로토콜로 TLS 1.2를 지정한다는 점이 예외입니다. HTTP/2 사양에서는 TLS 1.2 이상을 사용하도록 규정하고 있으며, 이에 따라 모든 클라이언트가 TLS의 서버 이름 표시(SNI) 확장을 지원합니다. 즉, gRPC 게이트웨이는 다른 server{} 블록에 정의된 가상 서버와 포트 443을 공유할 수 있습니다.

샘플 gRPC 서비스 실행

NGINX의 gRPC 기능을 살펴보기 위해 여러 gRPC 서비스가 배포된 gRPC 게이트웨이의 주요 구성 요소를 나타내는 간단한 테스트 환경을 사용합니다. 공식 gRPC 가이드에서 제공하는 두 가지 샘플 애플리케이션인 helloworld(Go로 작성)와 RouteGuide(Python으로 작성)를 사용합니다. RouteGuide 애플리케이션은 다음과 같은 네 가지 gRPC 서비스 메서드를 모두 포함하므로 특히 유용합니다.

• 단순 RPC(단일 요청-응답)
• 응답 스트리밍 RPC
• 요청 스트리밍 RPC
• 양방향 스트리밍 RPC

두 gRPC 서비스는 모두 NGINX 호스트에 Docker 컨테이너로 설치됩니다. 테스트 환경을 구축하는 방법에 대한 전체 지침은 부록을 참조하세요.

NGINX가 RouteGuide 및 helloworld 서비스와 사용 가능한 컨테이너의 주소를 인식하도록 구성합니다.

코드 예제를 로드하는 중…

각 gRPC 서비스(40~45행 및 47~51행)에 대해 upstream 블록을 추가하고, gRPC 서버 코드를 실행하는 개별 컨테이너의 주소를 입력합니다.

gRPC 요청 라우팅

NGINX가 gRPC의 일반적인 평문 포트(50051)에서 수신 대기하도록 설정한 다음, 클라이언트 요청이 올바른 백엔드 서비스에 도달할 수 있도록 구성에 라우팅 정보를 추가합니다. 하지만 먼저 gRPC 메서드 호출이 HTTP/2 요청으로 어떻게 표현되는지 이해해야 합니다. 다음 다이어그램은 RouteGuide 서비스의 route_guide.proto 파일을 축약하여 보여 주며, NGINX에서 볼 때 패키지, 서비스 및 RPC 메서드가 URI를 구성하는 방식을 설명합니다.

따라서 HTTP/2 요청에 포함된 정보는 패키지 이름(여기서는 routeguide 또는 helloworld)만 일치시키면 라우팅에 사용할 수 있습니다.

코드 예제를 로드하는 중…

첫 번째 location 블록(26행)은 수정자 없이 접두사 일치를 정의하므로 /routeguide.는 해당 패키지의 관련 .proto 파일에 정의된 모든 서비스 및 RPC 메서드와 일치합니다. 따라서 grpc_pass 지시어(27행)는 RouteGuide 클라이언트의 모든 요청을 업스트림 그룹인 routeguide_service로 전달합니다. 이 구성(및 29행과 30행의 helloworld 서비스에 대한 유사한 구성)은 gRPC 패키지와 해당 백엔드 서비스를 간단하게 매핑합니다.

Notice that the argument to the grpc_pass 지시문의 인수는 grpc:// 스킴으로 시작하며, 이를 통해 암호화되지 않은 gRPC 연결을 사용하여 요청을 프록시한다는 점에 유의하세요. 백엔드에 TLS가 구성되어 있다면 grpcs:// 스킴을 사용하여 종단 간 암호화로 gRPC 연결을 보호할 수 있습니다.

RouteGuide 클라이언트를 실행한 후 로그 파일 항목을 검토하여 라우팅 동작을 확인할 수 있습니다. 여기서는 RouteChat RPC 메서드가 포트 10002에서 실행 중인 컨테이너로 라우팅된 것을 확인할 수 있습니다.

$ python route_guide_client.py...
$ tail -1 /var/log/nginx/grpc_log.json | jq
{
  "timestamp": "2021-01-20T12:17:56+01:00",
  "client": "127.0.0.1",
  "uri": "/routeguide.RouteGuide/RouteChat",
  "http-status": 200,
  "grpc-status": 0,
  "upstream": "127.0.0.1:10002",
  "rx-bytes": 161,
  "tx-bytes": 212
}

정밀한 라우팅

위에서 살펴본 것처럼 여러 gRPC 서비스를 서로 다른 백엔드로 라우팅하는 것은 간단하고 효율적이며, 몇 줄의 구성만으로 가능합니다. 하지만 프로덕션 환경에서는 라우팅 요구 사항이 더 복잡할 수 있으며, URI의 다른 요소(gRPC 서비스 또는 개별 RPC 메서드까지)를 기준으로 라우팅해야 할 수도 있습니다.

다음 구성 스니펫은 이전 예제를 확장하여 양방향 스트리밍 RPC 메서드인 RouteChat은 한 백엔드로 라우팅하고, 그 외 모든 RouteGuide 메서드는 다른 백엔드로 라우팅합니다.

코드 예제를 로드하는 중…

두 번째 location 지시문(7행)은 =(등호) 수정자를 사용하여 RouteChat RPC 메서드의 URI와 정확히 일치함을 나타냅니다. 정확한 일치는 접두사 일치보다 먼저 처리되므로 RouteChat URI에는 다른 location 블록이 고려되지 않습니다.

오류에 응답하기

gRPC 오류는 일반적인 HTTP 트래픽에서 발생하는 오류와 다소 다릅니다. 클라이언트는 오류 상태가 gRPC 응답으로 표현되기를 기대하므로, NGINX가 gRPC 게이트웨이로 구성된 경우 기본 NGINX 오류 페이지 세트(HTML 형식)는 적합하지 않습니다. 이를 해결하기 위해 gRPC 클라이언트용 사용자 지정 오류 응답 세트를 지정합니다.

코드 예제를 로드하는 중…

전체 gRPC 오류 응답 설정은 비교적 길고 대부분 변경되지 않으므로 별도의 파일인 errors.grpc_conf에 저장하고 include 지시어(34행)를 사용하여 참조합니다. HTTP/REST 클라이언트와 달리 gRPC 클라이언트 애플리케이션은 다양한 HTTP 상태 코드를 처리하도록 설계되지 않았습니다. gRPC 문서에서는 클라이언트가 항상 적절한 응답을 받을 수 있도록 NGINX와 같은 중간 프록시가 HTTP 오류 코드를 gRPC 상태 코드로 변환하는 방법을 명시합니다. 이 매핑을 수행하기 위해 error_page 지시어를 사용합니다.

코드 예제를 로드하는 중…

각 표준 HTTP 상태 코드는 gRPC 호환 응답을 생성할 수 있도록 @ 접두사를 사용해 명명된 location으로 전달됩니다. 예를 들어 HTTP 404 응답은 파일의 뒷부분에 정의된 @grpc_unimplemented location으로 내부 리디렉션됩니다:

코드 예제를 로드하는 중…

The @grpc_unimplemented 명명된 위치는 NGINX 내부 처리에만 사용할 수 있으며, 라우팅 가능한 URI가 없으므로 클라이언트가 직접 요청할 수 없습니다. 이 위치에서는 필수 gRPC 헤더를 채운 후 응답 본문 없이 HTTP 상태 코드 204(No Content)로 전송하여 gRPC 응답을 생성합니다.

존재하지 않는 gRPC 메서드를 요청하는 비정상적인 gRPC 클라이언트를 흉내 내기 위해 curl(1) 명령을 사용할 수 있습니다. 하지만 프로토콜 버퍼는 바이너리 데이터 형식을 사용하므로 curl은 일반적으로 gRPC 테스트 클라이언트로 적합하지 않습니다. 명령줄에서 gRPC를 테스트하려면 grpc_cli 사용을 고려해 보세요.

$ curl -i --http2 -H "Content-Type: application/grpc" -H "TE: trailers" -X POST https://grpc.example.com/does.Not/ExistHTTP/2 204 
server: nginx/1.19.5
date: Wed, 20 Jan 2021 15:03:41 GMT
grpc-status: 12
grpc-message: unimplemented

위에서 언급한 grpc_errors.conf 파일에는 시간 초과 및 클라이언트 인증서 오류와 같이 NGINX에서 생성될 수 있는 기타 오류 응답에 대한 HTTP‑gRPC 상태 코드 매핑도 포함되어 있습니다.

gRPC 메타데이터를 사용한 클라이언트 인증

gRPC 메타데이터를 사용하면 클라이언트가 해당 데이터를 프로토콜 버퍼 사양(.proto 파일)에 포함하지 않고도 RPC 메서드 호출과 함께 추가 정보를 전송할 수 있습니다. 메타데이터는 키-값 쌍으로 구성된 단순한 목록이며, 각 쌍은 별도의 HTTP/2 헤더로 전송됩니다. 따라서 NGINX에서 메타데이터에 쉽게 액세스할 수 있습니다.

메타데이터의 다양한 사용 사례 중에서 gRPC API 게이트웨이에 가장 일반적으로 사용되는 것은 클라이언트 인증입니다. 다음 구성 코드 조각은 NGINX Plus가 gRPC 메타데이터를 사용하여 JWT 인증을 수행하는 방법을 보여줍니다(JWT 인증은 NGINX Plus에서만 지원됨). 이 예에서는 JWT가 auth-token 메타데이터로 전송됩니다.

코드 예제를 로드하는 중…

모든 HTTP 요청 헤더는 NGINX Plus에서 $http_header라는 변수로 사용할 수 있습니다. 헤더 이름의 하이픈(-)은 변수 이름에서 밑줄( _ )로 변환되므로 JWT는 $http_auth_token로 사용할 수 있습니다(2행).

기존 HTTP/REST API 등에서 인증에 API 키를 사용하는 경우, 이 키를 gRPC 메타데이터에 포함하고 NGINX에서 검증할 수도 있습니다. API 키 인증<.htmla>을 위한 구성은 이 블로그 시리즈의 1부에서 제공합니다.

상태 확인 구현

여러 백엔드로 트래픽을 부하 분산할 때는 작동이 중단되었거나 그 밖의 이유로 사용할 수 없는 백엔드에 요청을 보내지 않는 것이 중요합니다. NGINX Plus에서는 능동 상태 확인을 사용하여 백엔드에 대역 외 요청을 선제적으로 보내고, 백엔드가 상태 확인에 예상대로 응답하지 않으면 부하 분산 대상에서 제외할 수 있습니다. 이를 통해 클라이언트 요청이 서비스 중단 상태인 백엔드에 전달되지 않도록 할 수 있습니다.

다음 구성 코드 조각은 RouteGuide 및 helloworld gRPC 서비스에 대한 능동 상태 확인을 활성화합니다. 관련 구성을 명확히 보여 주기 위해 이전 섹션에서 사용한 grpc_gateway.conf 파일에 포함된 일부 지시어는 생략했습니다.

코드 예제를 로드하는 중…

이제 각 경로에 health_check 지시문도 지정합니다(17행 및 21행). type=grpc 인수에 지정된 대로 NGINX Plus는 gRPC 상태 확인 프로토콜을 사용하여 업스트림 그룹의 모든 서버에 상태 확인 요청을 보냅니다. 하지만 이 예제의 간단한 gRPC 서비스는 gRPC 상태 확인 프로토콜을 구현하지 않으므로, “구현되지 않음”을 의미하는 상태 코드(grpc_status=12)로 응답할 것으로 예상합니다. 이 코드로 응답하면 활성 gRPC 서비스와 통신하고 있음을 확인하기에 충분합니다.

이 구성을 적용하면 gRPC 클라이언트에서 지연이나 시간 초과가 발생하지 않도록 하면서 백엔드 컨테이너를 중지할 수 있습니다. 능동 상태 확인은 NGINX Plus에서만 제공됩니다. 자세한 내용은 블로그의 gRPC 상태 확인을 참조하세요.

속도 제한 및 기타 API 게이트웨이 제어 적용

The sample configuration in grpc_gateway.conf의 샘플 구성은 TLS를 위해 약간만 수정하면 프로덕션 환경에서 사용하기에 적합합니다. 패키지, 서비스 또는 RPC 메서드를 기준으로 gRPC 요청을 라우팅할 수 있으므로, 기존 NGINX 기능을 HTTP/REST API나 일반 웹 트래픽에 적용하는 것과 똑같은 방식으로 gRPC 트래픽에도 적용할 수 있습니다. 각 경우에 해당하는 location 블록에 속도 제한이나 대역폭 제어 같은 구성을 추가할 수 있습니다.

요약

NGINX Open Source와 NGINX Plus를 API 게이트웨이로 배포하는 방법을 다룬 시리즈의 세 번째이자 마지막 블로그 게시물에서는 마이크로서비스 애플리케이션 구축을 위한 클라우드 네이티브 기술인 gRPC에 중점을 두었습니다. NGINX가 HTTP/REST API만큼 효과적으로 gRPC 애플리케이션을 제공할 수 있으며, 두 가지 유형의 API를 모두 다목적 API 게이트웨이인 NGINX를 통해 게시할 수 있음을 살펴보았습니다.

이 블로그 게시물에서 사용한 테스트 환경을 설정하는 방법은 아래 부록에 나와 있으며, 모든 파일은 GitHub Gist 저장소에서 다운로드할 수 있습니다.

이 시리즈의 다른 블로그 게시물도 확인해 보세요:

• 1부에서는 몇 가지 필수적인 HTTP 기반 API 게이트웨이 사용 사례에 맞게 NGINX를 구성하는 방법을 설명합니다.
• 2부에서는 악의적이거나 비정상적으로 동작하는 클라이언트로부터 백엔드 서비스를 보호하기 위한 고급 활용 사례를 살펴봅니다.

NGINX Plus를 API 게이트웨이로 사용해 보려면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요. 평가 기간에는 당사의 GitHub Gist 저장소에서 전체 구성 파일 세트를 사용하세요.

부록: 테스트 환경 설정

다음 지침에서는 테스트 환경을 격리되고 재현 가능한 형태로 구성하기 위해 가상 머신에 설치합니다. 하지만 물리적인 ‘베어 메탈’ 서버에 설치하지 못할 이유는 없습니다.

테스트 환경을 간소화하기 위해 Docker 컨테이너에서 gRPC 서비스를 실행합니다. 따라서 테스트 환경에 여러 호스트가 필요하지 않으면서도, 프로덕션 환경에서와 마찬가지로 NGINX가 네트워크 호출을 통해 프록시 연결을 수행하도록 할 수 있습니다.

또한 Docker를 사용하면 코드를 변경하지 않고도 각 gRPC 서비스의 여러 인스턴스를 서로 다른 포트에서 실행할 수 있습니다. 각 gRPC 서비스는 컨테이너 내부의 50051번 포트에서 수신 대기하며, 이 포트는 가상 머신의 고유한 localhost 포트에 매핑됩니다. 이에 따라 50051번 포트를 NGINX의 수신 포트로 사용할 수 있게 됩니다. 따라서 테스트 클라이언트가 미리 구성된 50051번 포트를 사용해 연결하면 NGINX에 도달합니다.

NGINX Open Source 또는 NGINX Plus 설치

1. Install NGINX Open Source 또는 NGINX Plus를 NGINX Plus 관리자 가이드의 지침에 따라 설치합니다.
2. 다음 파일을 GitHub Gist 저장소에서 /etc/nginx/conf.d로 복사합니다. 참고: TLS를 사용하지 않는 경우 ssl_* 지시문을 grpc_gateway.conf에서 주석 처리합니다.
   • grpc_gateway.conf
   • errors.grpc_conf
3. NGINX Open Source 또는 NGINX Plus를 시작합니다.

$ sudo nginx

Docker 설치

Debian 및 Ubuntu에서는 다음 명령어를 실행하세요:

$ sudo apt-get install docker.io

CentOS, RHEL 및 Oracle Linux에서는 다음을 실행합니다:

$ sudo yum install docker

RouteGuide 서비스 컨테이너 설치

1. 다음 Dockerfile을 사용하여 RouteGuide 컨테이너용 Docker 이미지를 빌드합니다.

   코드 예제를 로드하는 중…

   빌드하기 전에 Dockerfile을 로컬 하위 디렉터리에 복사하거나, Dockerfile이 있는 Gist의 URL을 docker build 명령의 인수로 지정할 수 있습니다:

$ sudo docker build -t routeguide https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/routeguide.Dockerfile

1. 이미지를 다운로드하고 빌드하는 데 몇 분 정도 걸릴 수 있습니다. Successfully built 메시지와 16진수 문자열(이미지 ID)이 표시되면 빌드가 완료된 것입니다.
2. 다음 명령을 실행하여 이미지가 빌드되었는지 확인합니다. docker images.

$ sudo docker imagesREPOSITORY     TAG          IMAGE ID          CREATED         SIZE
routeguide     latest       63058a1cf8ca      1 minute ago    1.31 GB
python         latest       825141134528      9 days ago      923 MB

1. RouteGuide 컨테이너를 시작합니다.

$ sudo docker run --name rg1 -p 10001:50051 -d routeguide$ sudo docker run --name rg2 -p 10002:50051 -d routeguide
$ sudo docker run --name rg3 -p 10003:50051 -d routeguide

1. 각 명령이 성공적으로 실행될 때마다 실행 중인 컨테이너를 나타내는 긴 16진수 문자열이 표시됩니다.
2. 다음 명령을 실행하여 세 컨테이너가 모두 실행 중인지 확인합니다. docker ps. (샘플 출력은 읽기 쉽도록 여러 줄로 나누어 표시했습니다.)

$ sudo docker psCONTAINER ID  IMAGE       COMMAND              STATUS        ...
d0cdaaeddf0f  routeguide  "python route_g..."  Up 2 seconds  ...
c04996ca3469  routeguide  "python route_g..."  Up 9 seconds  ...
2170ddb62898  routeguide  "python route_g..."  Up 1 minute   ...

      ... PORTS                     NAMES
      ... 0.0.0.0:10003->50051/tcp  rg3
      ... 0.0.0.0:10002->50051/tcp  rg2
      ... 0.0.0.0:10001->50051/tcp  rg1

1. 출력의 PORTS 열은 각 컨테이너가 서로 다른 로컬 포트를 컨테이너 내부의 50051번 포트에 어떻게 매핑했는지 보여줍니다.

helloworld 서비스 컨테이너 설치

1. 다음 Dockerfile을 사용하여 helloworld 컨테이너용 Docker 이미지를 빌드합니다.

   코드 예제를 로드하는 중…

   빌드하기 전에 Dockerfile을 로컬 하위 디렉터리에 복사하거나, Dockerfile이 포함된 Gist의 URL을 docker build 명령의 인수로 지정할 수 있습니다:

$ sudo docker build -t helloworld https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/helloworld.Dockerfile

1. 이미지를 다운로드하고 빌드하는 데 몇 분 정도 걸릴 수 있습니다. Successfully built 메시지와 16진수 문자열(이미지 ID)이 표시되면 빌드가 완료된 것입니다.
2. 다음 명령을 실행하여 이미지가 빌드되었는지 확인합니다. docker images.

$ sudo docker images
REPOSITORY     TAG          IMAGE ID          CREATED           SIZE
helloworld     latest       e5832dc0884a      10 seconds ago    926MB
routeguide     latest       170761fa3f03      4 minutes ago     1.31GB
python         latest       825141134528      9 days ago        923MB
golang         latest       d0e7a411e3da      3 weeks ago       794MB

1. helloworld 컨테이너를 시작합니다.

$ sudo docker run --name hw1 -p 20001:50051 -d helloworld$ sudo docker run --name hw2 -p 20002:50051 -d helloworld

1. 각 명령이 성공적으로 실행되면 실행 중인 컨테이너를 나타내는 긴 16진수 문자열이 표시됩니다.
2. 다음을 실행하여 두 helloworld 컨테이너가 실행 중인지 확인합니다. docker ps.

$ sudo docker psCONTAINER ID  IMAGE       COMMAND              STATUS        ... 
e0d204ae860a  helloworld  "go run greeter..."  Up 5 seconds  ... 
66f21d89be78  helloworld  "go run greeter..."  Up 9 seconds  ... 
d0cdaaeddf0f  routeguide  "python route_g..."  Up 4 minutes  ... 
c04996ca3469  routeguide  "python route_g..."  Up 4 minutes  ... 
2170ddb62898  routeguide  "python route_g..."  Up 5 minutes  ... 

      ... PORTS                     NAMES
      ... 0.0.0.0:20002->50051/tcp  hw2
      ... 0.0.0.0:20001->50051/tcp  hw1
      ... 0.0.0.0:10003->50051/tcp  rg3
      ... 0.0.0.0:10002->50051/tcp  rg2
      ... 0.0.0.0:10001->50051/tcp  rg1

gRPC 클라이언트 애플리케이션 설치

1. 프로그래밍 언어 필수 구성 요소를 설치합니다. 이 중 일부는 테스트 환경에 이미 설치되어 있을 수 있습니다. python-pip를 사용하려면 EPEL 리포지토리를 활성화해야 합니다(필요한 경우 먼저 sudo yum install epel-release를 실행합니다).
   • Ubuntu 및 Debian에서는 다음을 실행합니다:

$ sudo apt-get install golang-go python3 python-pip git

• CentOS, RHEL 및 Oracle Linux에서는 다음을 실행합니다:

$ sudo yum install golang python python-pip git

1. helloworld 애플리케이션을 다운로드합니다:

$ go get google.golang.org/grpc

1. RouteGuide 애플리케이션을 다운로드합니다:

$ git clone -b v1.14.1 https://github.com/grpc/grpc
$ pip install grpcio-tools

설정 테스트

1. helloworld 클라이언트를 실행합니다:

$ go run go/src/google.golang.org/grpc/examples/helloworld/greeter_client/main.go

1. RouteGuide 클라이언트를 실행합니다:

$ cd grpc/examples/python/route_guide
$ python route_guide_client.py

1. NGINX 로그를 확인하여 테스트 환경이 정상적으로 작동하는지 확인합니다:

$ tail /var/log/nginx/grpc_log.json

작성자 소개

Liam Crilly제품 관리 부문 수석 이사

Liam Crilly의 다른 블로그 게시물