Nginx access gPRC

NGINX will include grpc related features in version 1.13.10

This version supports NGINX proxy gRPC TCP connection. Can be used to:

Published gRPC services, including unencrypted / encrypted gRPC service.
By publishing multiple gRPC single endpoint service, use NGINX routed to the back-end service. And even the same as other HTTP / 2 using the service endpoint, such as Web sites and REST API.
GRPC reverse proxy services, for gRPC service cluster load balancing.

What is gRPC?

gRPC rpc is a protocol for communication between the client and server. gRPC design is very compact and multi-language support good, while supporting the request / response mode and streaming interaction. Due to its extensive language support and a simple user-oriented design, the agreement more and more popular, which contains the mashup service (service mesh) to achieve.

Either expressly or TLS encryption, gRPC are HTTP / 2 transmission. gRPC request using an HTTP POST request. gRPC response is also used in a similar manner, and sends a status code using HTTP trailer at the end of the response.

Because the use of gRPC connection multiplexing and streaming functions HTTP / 2, you can not use HTTP 1.x. gRPC

Use NGINX service management gRPC

Here is a simple gRPC program as a DEMO.

Simple gRPC Service

First, we insert NGINX between the client and server applications. NGINX provides a stable and reliable gateway for server applications.

It should be noted that the use of NGINX with gRPC function. If you want to build from source NGINX, please keep in mind include http_ssl and http_v2 modules:

NGINX gRPC monitor traffic and use grpc_pass instruction proxy traffic. The following configuration is to forward port 80 traffic to the encrypted gRPC service on port 50051:

We need to ensure grpc_pass instruction address is correct. Recompile the client IP address and listening port of NGINX point.

When the client run the modified end, you will see the same response as before, but the request is forwarded via GINX. We can see the request recorded in the access log:

Note: NGINX support does not support HTTP / 1 and HTTP / 2 on a plaintext (non-TLS) port. If you want to process two protocol versions, you should create a listening port for each protocol version.

TLS encryption service release gRPC

The above example uses unencrypted HTTP / 2 (plain text) to communicate. This is very simple to deploy and test it, but the production environment needs to be encrypted. You can add this layer of encryption to use NGINX.

First create a self-signed certificate and modify your NGINX server configuration, as follows:

GRPC modify a client to use TLS, connect to port 1443, and disable certificate checking (using self-signed or not trusted certificates needed so). If you are using Go, you need to add crypto / tls and google.golang.org/grpc/credentials to import list, and grpc.Dial () call to modify the following:

This is the need to do all the work. In a production environment, you also need to replace the certificate authority is a trusted certificate authority (CA) self-signed certificate.

Reverse proxy encrypted gRPC service

If you want to call internally gRPC request encryption. First, we need to modify the server application to listen for TLS encryption (grpcs) connection:

In NGINX configuration, you will need to modify the flow gRPC proxy to upstream server protocols:

routing

Here we will explain how to use NGINX represent more gRPC back-end services.

Use NGINX, you can identify services and methods, and then use the location of instructions routing traffic. You might have guessed gRPC request URL is the package, service and method names from proto specification derived. Consider SayHello RPC Method:

SayHello RPC method call need to issue a POST request from /helloworld.Greeter/SayHello, as shown in the following log entries:

Use NGINX routing request is very simple:

You can try it yourself. Hello World example extends the package (in helloworld.proto) to add a new service called Dispatcher, and then create a new service to achieve a method of Dispatcher. The client using a HTTP / 2 connector and issuing an RPC request to Dispatcher Greeter service. NGINX routes the request to the appropriate server gRPC.

Note / location blocks. The block processing known gRPC invocation request do not match. You can use a location a block like this provide web content and other non-gRPC service.

Load Balancing

GRPC how to extend the service to increase capacity and provide high availability? NGINX is to do it in the upstream group:

Of course, if your upstream is listening TLS, you can use grpc_pass grpcs: // upstreams.

NGINX load balancing algorithm may be used to distribute a series of requests on gRPC gRPC backend server. NGINX built-in back-end service health check will detect whether or not a response if an error occurs, the back-end service if it detects a problem, NGINX will automatically remove the node. If there is no back-end nodes is available, the return / error502grpc.