OpenResty Edge gRPC Proxy: Distributed Reverse Proxy & Load Balancer with TLS Termination

To run a gRPC reverse proxy in OpenResty Edge, enable HTTP/2 on the application, create an upstream that points at your gRPC backend, then add a page rule with the gRPC proxy switch turned on. The gateway proxies gRPC calls to the upstream, terminates TLS for a plaintext-only origin, and pushes every change to all gateway servers with no reload or restart. Below we set this up end to end and verify it with grpcurl.

Prepare a sample gRPC server and test it with grpcurl

We’ve prepared a sample gRPC backend server. The IP address of the backend ends with .166. And it’s listening on port 8080.

Here is the protobuf definition file for the sample gRPC service.

cat hello_world.proto

This service returns a welcome message based on the name parameter.

We can use the grpcurl command-line utility to check this service output. This tool can send gRPC requests and then show any received responses in the JSON format. We use the “plaintext” option here since our gRPC server does not support SSL/TLS encryption. We pass “world” as the value of the name parameter. We then enter the address of the gRPC server mentioned above. And finally, enter the gRPC service name.

Send the request.

We can see that the message “hello world” is returned, as expected.

Add the gRPC server as an upstream in OpenResty Edge

Next, we will use this gRPC server behind OpenResty Edge as an upstream.

As always, let’s go to the OpenResty Edge’s Admin web console. This is our sample deployment of the console. Every user has their own local deployment.

We still use our continuing sample application, test-edge.com.

Enter the application.

Enable HTTP/2 for gRPC

gRPC uses HTTP/2 for transport. And HTTP/2 is usually enabled by default in OpenResty Edge.

Here I’ll show how to enable HTTP/2 in the Edge application settings.

Select the “Enabled” option.

Save our change.

Then we go to the SSL page to make sure that the SSL certificate is configured.

We can see the certificates we configured in a previous tutorial.

Create a gRPC upstream

Go to the Upstreams page.

Create a new upstream for our backend server.

We give this upstream a name, say, “grpc_backend”.

If the gRPC backend server has SSL/TLS encryption enabled, we can select HTTPS here.

Fill out the host field for the gRPC backend server with its IP address mentioned earlier.

Enter its port number, 8080.

Click to save this upstream.

We can see that this new “grpc_backend” upstream was created successfully.

Enable the gRPC proxy in a page rule

Now let’s create a new page rule to actually use this upstream.

Create a new page rule.

We add a URI prefix rule condition.

Enter these request URI prefixes used by the “grpcurl”.

Let’s add a proxy target here.

Turn on this switch to enable the gRPC proxy.

Select the gRPC upstream that we just created.

Insert this page rule before any existing normal rules.

Save this page rule.

We can see the proxy page rule is already listed here.

We need to make a new release to push out our new changes, as always.

Click on this button.

Ship it!

Our new release is now synchronized to all our gateway servers.

Now the new page rule has been pushed to all the gateway clusters and servers.

Our configuration changes do NOT require server reload, restart, or binary upgrade. So it’s very efficient and scalable.

Test the gRPC proxy through the gateway with grpcurl

Then we’ll test the gRPC service through the gateway.

We still use the grpcurl tool to access the gRPC service.

We use the domain test-edge.com and port 443. This will hit our OpenResty Edge gateway. This time we don’t specify the plaintext option since the Edge gateway supports SSL/TLS encryption.

Send the request.

We can see that the message “hello world” is returned as expected.

The gRPC service is now accessible with full SSL/TLS encryption even though the origin server doesn’t. In other words, OpenResty Edge terminates TLS at the gateway while talking to the plaintext gRPC origin over the internal network — you get encrypted gRPC on the public side without touching the backend. OpenResty Edge can front other protocols the same way; to route raw TLS/TCP traffic by domain name, see Configuring SNI proxies in OpenResty Edge.

FAQ

How do I set up a gRPC reverse proxy in OpenResty Edge?

Enable HTTP/2 on the application, create an upstream pointing at your gRPC backend (host and port), then add a page rule that matches the gRPC request URI prefixes and turn on the Enable gRPC Proxy switch for that upstream. Publish a release and the gateway starts proxying gRPC calls to the backend upstream.

Do I need to enable HTTP/2 for gRPC proxying?

Yes. gRPC uses HTTP/2 for transport, so HTTP/2 must be on for the proxy to work. In OpenResty Edge it is usually enabled by default, and you can confirm or toggle it in the application settings before creating the gRPC page rule.

Can OpenResty Edge terminate TLS for a plaintext gRPC backend?

Yes. In this tutorial the origin gRPC server has no SSL/TLS, yet clients reach the service over full TLS on domain test-edge.com port 443. The gateway terminates TLS on the public side and forwards to the plaintext origin internally, so the backend never has to handle certificates.

How do I test a gRPC proxy?

Use grpcurl. Send a plaintext request straight to the origin to confirm the backend works, then send the same request to the gateway on port 443 without the plaintext option to confirm the proxy path over TLS. Both should return the same response — here, “hello world”.

Does changing the gRPC proxy configuration require a server reload or restart?

No. Publishing a release synchronizes the new page rule to all gateway clusters and servers with no reload, restart, or binary upgrade, which keeps the change fast to roll out and scalable across a large fleet.

What is OpenResty Edge

OpenResty Edge is our all-in-one gateway software for microservices and distributed traffic architectures. It combines traffic management, private CDN construction, API gateway, security, and more to help you easily build, manage, and protect modern applications. OpenResty Edge delivers industry-leading performance and scalability to meet the demanding needs of high concurrency, high load scenarios. It supports scheduling containerized application traffic such as K8s and manages massive domains, making it easy to meet the needs of large websites and complex applications.

If you like this tutorial, please subscribe to this blog site and/or our YouTube channel. Thank you!

About The Author

Yichun Zhang (Github handle: agentzh), is the original creator of the OpenResty^® open-source project and the CEO of OpenResty Inc..

Yichun is one of the earliest advocates and leaders of “open-source technology”. He worked at many internationally renowned tech companies, such as Cloudflare, Yahoo!. He is a pioneer of “edge computing”, “dynamic tracing” and “machine coding”, with over 22 years of programming and 16 years of open source experience. Yichun is well-known in the open-source space as the project leader of OpenResty^®, adopted by more than 40 million global website domains.

OpenResty Inc., the enterprise software start-up founded by Yichun in 2017, has customers from some of the biggest companies in the world. Its flagship product, OpenResty XRay, is a non-invasive profiling and troubleshooting tool that significantly enhances and utilizes dynamic tracing technology. And its OpenResty Edge product is a powerful distributed traffic management and private CDN software product.

As an avid open-source contributor, Yichun has contributed more than a million lines of code to numerous open-source projects, including Linux kernel, Nginx, LuaJIT, GDB, SystemTap, LLVM, Perl, etc. He has also authored more than 60 open-source software libraries.