How to Direct Traffic to Compute or Cloud Run Based on URL

google-cloud-platform

We currently have a web app running on a Compute VM, and are working on gradually migrating it to Cloud Run. (We are doing it gradually because the current backend is in PHP and we are rewriting it in Go, one endpoint at a time)

Our site is current accessed at for example:
https://www.myapp.com
and API at:
https://www.myapp.com/books

Our plan is to have the new Cloud Run/Go API be accessible either in a 'v2' path:
https://www.myapp.com/v2/books
or on a subdomain
https://v2.myapp.com/books
and then decide which API to use in the client based on what's finished being migrated.

I was wondering what a good way to go about this would be.

Things I've considered (as a GCP beginner)

We already have nginx running on the Compute VM, so setting up a reverse proxy for https://www.myapp.com/v2 seemed like a good idea at first, but it seems that currently there is no way to access Cloud Run from Compute via private IP so the request would have to go out over the internet slowing things down (also not sure if reverse proxying to an external URL would cause issues with authentication etc?)
With the https://v2.myapp.com/books option, it seems that mapping custom domains for Cloud Run is still in preview release so I'm hesitant about using it in a production system, also ideally we'd like to use our own SSL certificate which doesn't seem to be supported.
The Firebase hosting option seems like it would be a bit complicated and also has a request timeout of 60s which is too short for some of the video uploads etc. we get.
Load balancer to a NEG would add a bit more complexity/cost but that seems to be the other option. It looks like serverless NEGs can't connect to Compute and managed VM NEGs can't connect to Cloud Run so would I need one of each in that case?

Best Answer

Commenting below on all the 4 options you mentioned

We already have nginx running on the Compute VM, so setting up a reverse proxy for https://www.myapp.com/v2 seemed like a good idea at first, but it seems that currently there is no way to access Cloud Run from Compute via private IP so the request would have to go out over the internet slowing things down (also not sure if reverse proxying to an external URL would cause issues with authentication etc?)

This is technically correct, you are able to setup a Cloud Run service to only accept traffic from the VPC (this is called Ingress options, you can read about it in the doc here [1]). And when you do, your Cloud Run Service will continue serving on what appears to be a public URL (the one generated when you deploy the service). But that URL is only accessible from the VPC, and even if it appears that the client will be making a call to an internet service, that traffic remains in our network and never leaves our backbone, so technically this should not add latency.

With the https://v2.myapp.com/books option, it seems that mapping custom domains for Cloud Run is still in preview release so I'm hesitant about using it in a production system, also ideally we'd like to use our own SSL certificate which doesn't seem to be supported.

I would not recommand using a preview feature in production, there is a risk that feature will change in a backward incompatible way. On the topic of using your own SSL certificates, you can deploy an HTTP LoadBalancer in front of your Cloud Run service (which is set to be private) and customize the LoadBalancer to fit your needs.

The Firebase hosting option seems like it would be a bit complicated and also has a request timeout of 60s which is too short for some of the video uploads etc. we get.

I'm not very familiar with Firebase.

Load balancer to a NEG would add a bit more complexity/cost but that seems to be the other option. It looks like serverless NEGs can't connect to Compute and managed VM NEGs can't connect to Cloud Run so would I need one of each in that case?

The LoadBalancer option looks complicated, but it's really not, you can use something like Terraform to provision the LoadBalancer, you only have to do it once

Hope this helps shade a light on your options [1] https://cloud.google.com/run/docs/securing/ingress

Related Solutions

Best practices for load balancing node.js app on google cloud

If you follow the instructions mentioned in this Help Center article, the traffic is being forwarded on the backend using a proxy after hitting the LB IP address. So the public IP address for your application will be the forwarding rule IP.

Google Cloud Function: Could not load the default credentials

As mentioned in the github issue

creating a client in the global scope outside of your function will solve this issue see: function execution lifetime.

If your code looks like this:

const {CloudTasksClient} = require('@google-cloud/task');
// CloudTasksClient, could be Storage, or Vision, or Speech.
const task = new CloudTasksClient();
export.helloWorld = (req, res) => {
  res.send('hello world');
}

Instead write:

const {CloudTasksClient} = require('@google-cloud/task');
// CloudTasksClient, could be Storage, or Vision, or Speech.
let task;
export.helloWorld = async (req, res) => {
  if (!task) {
    task = new CloudTasksClient();
  }
  await task.doSomething(); // or storage.doSomething(), etc.
  res.send('hello world');
}

There is work in motion to shield folks from this issue. But, as described in the execution timeline, the core of the problem is that asynchronous work cannot happen outside of the request cycle of your function.

This may also fix the problem

You can set an environment variable on a cloud function when deployed using the firebase-tools CL

Set the env variable DEBUG_AUTH to true
Run

npm install --save @google-cloud/firestore@latest gcp-metadata@latest

There are two ways to do this:

1.The official (old) way is to set the variable using gcloud or pantheon. The CLI will respect the variable on future deploys.

2.You can opt into the not-yet-public support for managing env variables with dot-env files. This can be done by calling:

firebase --open-sesame dotenv
#From their functions directory    
echo "DEBUG_AUTH=true" > .env  
firebase deploy --only functions

Best Answer

Related Solutions

Best practices for load balancing node.js app on google cloud

Google Cloud Function: Could not load the default credentials

Related Topic