- Serve traffic from multiple regions | Cloud Run Documentation | Google Cloud
- You can return faster responses to your users around the world by deploying services in multiple regions and routing your users to the nearest region. Deploying across multiple regions delivers low latency and higher availability in case of regional outages.
Last week, GCP released a feature for Cloud Run that allows for multi-region use with a single execution.
To briefly summarize multi-region services, let's say there are Seoul, London, and Las Vegas regions, for example.
Previously, you would have had to deploy to multiple regions individually using a script. The new feature allows you to deploy to multiple regions with a single script.
Actually, before its release, I had high expectations for this feature after reading the documentation, but I was a little disappointed.
Even before, using scripts for deployment allowed for deploying multiple services at once, one by one, but since they operate in parallel, there's no significant time difference, so I didn't have high expectations in that area. However, since this deploys everything at once, it's impossible to use different environment variables for each region.
Therefore, I frequently used the feature that allows individual Cloud Runs to connect to different databases or GCS using region-specific values, but I encountered a problem using that feature.
The second problem is that when you repeatedly deploy, you sometimes want to delete the existing content, but this cannot be controlled individually. It is held in read-only mode, preventing individual deletion of older versions.
There are several drawbacks, but the advantage is that multiple Cloud Runs can be "combined" into one.
In our service, we use Cloud Run extensively and utilize many regions. Currently, we have about 50, and this number will increase to around 100 once the current tasks are completed. Using the multi-region service will reduce this number to 10-20. (It just hides them.)
First, the script is as follows:
Executing the above script results in the following deployment.
Cloud Run
Cloud Runs with the same name are deployed in each region, and a folder (?) with the same name is created at the top level.
The combined view is as follows:
Cloud Run - Collapsed view
In fact, it's not very helpful when the number is small. However, if we assume it's deployed to 40 regions, it's extremely helpful. (Even if it's not that many...)
Marked as read-only.
For most functions, when you try to modify something, it's usually marked as read-only. The documentation mentions the feature, but it doesn't seem to work properly, possibly due to API issues.
The relevant documentation is located here.
The gcloud documentation is here. Only alpha/beta versions are currently supported; the official version is not. Furthermore, the --regions option mentioned in the above document is not present in the documentation. (It will be updated soon, right?)
What I'd like is simply this: Could you provide PORT as a default value in environment variables, similar to how it's currently done? I know that various information is provided through the metadata server, but it's inconvenient to fetch it directly using Fetch. (And it also consumes resources...)
Since it's still in preview, it will improve over time, right? (Complaining immediately after the release...)
Comments0