Recommendation on muli region setup with ESPv2 via Cloud Run

67 views
Skip to first unread message

Alexandru Gogan

unread,
Jan 4, 2022, 3:56:45 PM1/4/22
to Google Cloud Endpoints
Hi everyone, 

What is the recommended way to achieve a multi region setup for Cloud Endpoints ESPv2 via Cloud Run? 

Would you need to deploy a different openapi spec for each regional ESPv2 that is structurally the same, but has a different X-Google-Backend url that is pointing to a regional deployed cloud run service? 

Wayne Zhang

unread,
Jan 4, 2022, 5:02:26 PM1/4/22
to Alexandru Gogan, Google Cloud Endpoints
Yes,  it is recommended to deploy different OpenAPI spec. with different x-google-backend in each region.  Thanks.  Regards  -Wayne

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/545d28f6-1f4d-4116-9e08-9f0dbc39dd11n%40googlegroups.com.

Alexandru Gogan

unread,
Jan 7, 2022, 11:36:04 AM1/7/22
to Google Cloud Endpoints
Thank you for confirming, it does make sense but I wasn't sure if each ESPv2 needs the exact/identical same version/openapi spec in place. 

Alexandru Gogan

unread,
Jan 7, 2022, 11:36:12 AM1/7/22
to Google Cloud Endpoints
Thank you for confirming the intended use. 

On Tuesday, January 4, 2022 at 5:02:26 PM UTC-5 qiwz...@google.com wrote:

Alexandru Gogan

unread,
Jan 31, 2022, 7:55:41 AM1/31/22
to Google Cloud Endpoints
To follow up on this for clarification. 

To support multiple regions let's say us-central1 and europe-west3 I'd have to:

- Create & deploy a new OpenAPI spec with the x-google-backend pointing to my backend service for us-central1
- Create & deploy a new OpenAPI spec with the x-google-backend pointing to my backend service for europe-west3

This means I'd end up with 2 revisions in Cloud endpoints, let's say 2022-01-30r0 and 2022-01-30r1. 
I'd then have to build the ESPv2 image containing the OpenAPI spec, one for each region/configId.

Deploy for each region a new Cloud Run Revision referencing the newly build images.

My follow-up question on this is, when I deploy out a new update to my OpenAPI spec, will the already deployed ESPv2 instances pick up the new configuration? Do I have to specify some specific params to make sure that a new spec change is not being picked up?


On Tuesday, January 4, 2022 at 5:02:26 PM UTC-5 qiwz...@google.com wrote:

Wayne Zhang

unread,
Jan 31, 2022, 12:16:06 PM1/31/22
to Alexandru Gogan, Google Cloud Endpoints
Your described approach is: same endpoint service config (OpenAPI spec), but with two revisions,  one for each region. In this case, `host` field is the same, `x-google-backend` is different.   It may work, just be careful. 
 I was proposing, two difference service names,  both `host` field and `x-google-backend` are different.  

When building ESP docker image with the script, `gloud_build_image`, you can specify revision name by the flag `-c`,  the service config will be downloaded and build into the docker image.  if you update the config after that,   the update will not impact the image. 

Alexandru Gogan

unread,
Jan 31, 2022, 10:43:15 PM1/31/22
to Google Cloud Endpoints
Thank you for the clarification. This helps to understand the services better. Keeping track of the configIds and matching them to the regions is something doable even though a bit cumbersome. 
Reply all
Reply to author
Forward
0 new messages