Getting Started with URL Rewrite in GCP Global External Load Balancer

You wrote a PoC for your backend applications on Cloud Run, now you want to bring it to the next step:

• Having all your backend services accessed through a single domain name.
• Having an SSL certificate for your API endpoints.
• Making minimal changes to your existing backend service code base.

Consider doing so with a Global External LoadBalancer with URL Rewrite configured, in this example, we will use CloudRun for backend.

Prerequisite

Cloud Run Applications Deployed

In this tutorial, we will focus on configuring the URL rewrite and will provide references for completing other steps.

Getting a domain name

If you already have a domain name at hand, you may skip this section. Ensure you have access to configure DNS A Record for later steps.

Follow this tutorial to register a domain on Google Cloud

Setting up your Global External Application LoadBalancer

Follow the below sections in this document to:

• Reserve an external IP address
• Create an SSL certificate resource
• Create the load balancer and a serverless NEG
• Connect your domain to your load balancer
• Test the load balancer

Configure URL Rewrite

Now you have two or more services that needs to be proxied by a Global External Load Balancer (under example.com)

In order for LB to know which backend service the request should proxy to, a url path prefix may be used to distinguish different backend services.

In this example, we have the following setup:

• Requests start with example.com/service-a/ go to service-a.
• Requests start with example.com/service-b/ go to service-b.
• Any requests with URLs that’s not known will route to the catch-all service.

The above can be done simply by using URL Mask

However, there’s one catch: Requests are forwarded by load balancer as is, meaning the request paths that contain the prefixes, e.g. “service-a/”, “service-b/” directly passed to your backend. It’s possible that your application is being written without knowledge of prefixes and it will cause errors in your applications.

We can use URL Rewrite rules to rewrite request paths when it reaches the backend.

This brings two benefits, you no longer need to make code changes to your application, you decouple further prefix changes. e.g. adding regional tags as you scale up.

There are multiple ways to configure URL rewrite, in this tutorial we will go through how to configure URL Rewrite using YAML.

Go to your Load Balancer, click “edit”

Make sure in your backend configuration, each backend contains a serverless group, which consists of one of your CloudRun applications.

Go to Routing rules, select “Advanced host and path rule”

In the “Edit host and path rule” section, ensure the “Hosts” field contains the domain name for Load Balancer.

In a text editor, use the example below to configure your own prefix and service names and paste in the Path matcher editor.

Make sure to update the following fields:

1. Description — enter the description for each route rule.
2. “prefixMatch:”- enter the prefix string within a request path used to distinguish each service.
3. “service:” — reference the backend service id for each of your backends.
4. “pathPrefixRewrite” — the desired prefix to rewrite the request path to. Leave it as “/” if your application path start with “/”

defaultService: projects/example-project/global/backendServices/backend-a
name: matcher1
routeRules:
- description: service-a-rewrite
  matchRules:
  - prefixMatch: /service-a
  priority: 1
  service: projects/example-project/global/backendServices/backend-a
  routeAction:
    urlRewrite:
      pathPrefixRewrite: /
- description: service-b-rewrite
  matchRules:
  - prefixMatch: /service-b
  priority: 2
  service: projects/example-project/global/backendServices/backend-b
  routeAction:
    urlRewrite:
      pathPrefixRewrite: /

A breakdown of each section of the URL rewrite rule

Request path: /unkwnown-service/panda

Below rule takes effect:

defaultService: projects/example-project/global/backendServices/backend-a

defaultServiceblock specifies the service that is set to handle requests that does not match any routing rules.

Requests are routed to projects/example-project/global/backendServices/backend-a

Request is being forwarded as it as it does not match any rewrite rules.

Request path received on backend: /unknown-service/panda

Request path: /service-a/dog

Below rule takes effect:

- description: service-a-rewrite
  matchRules:
  - prefixMatch: /service-a
  priority: 1
  service: projects/example-project/global/backendServices/backend-a
  routeAction:
    urlRewrite:
      pathPrefixRewrite: /

Requests are routed to projects/example-project/global/backendServices/backend-a

The request prefix /service-a has been rewrote to /, preserving the method name /dog.

Request path received on backend: /dog

Request path: /service-b/cat

Below rule takes effect:

- description: service-b-rewrite
  matchRules:
  - prefixMatch: /service-b
  priority: 2
  service: projects/example-project/global/backendServices/backend-b
  routeAction:
    urlRewrite:
      pathPrefixRewrite: /

Requests are routed to projects/example-project/global/backendServices/backend-b

The request prefix /service-b has been rewrote to /, preserving the method name /cat.

Request path received on backend: /cat

How to verify URL Rewrite:

Deploy the http-https-echo test container (MIT Licensed) in Cloud Run temporarily in place of the actual backend service.

This container image is very handy for debugging load balancer, it returns the detailed information about a request including host, path, header, method, body in json format. It provides great observability overall.

Read More:

Serverless network endpoint groups

Terraform for configuring routing and url rewrite rules

API Reference for urlMaps

External Application Load Balancer overview