2

When using Google Endpoints with Cloud Run to provide the container service, one creates a YAML file (stagger 2.0 format) to specify the paths with all configurations. For EVERY CHANGE the following is what I do (based on the documentation (https://cloud.google.com/endpoints/docs/openapi/get-started-cloud-functions)

Step 1: Deploying the Endpoints configuration

gcloud endpoints services deploy openapi-functions.yaml \
    --project ESP_PROJECT_ID

This gives me the following output:

Service Configuration [CONFIG_ID] uploaded for service [CLOUD_RUN_HOSTNAME]

Then,

Step 2: Download the script to local machine

chmod +x gcloud_build_image
./gcloud_build_image -s CLOUD_RUN_HOSTNAME \
    -c CONFIG_ID -p ESP_PROJECT_ID

Then,

Step 3: Re deploy the Cloud Run service

gcloud run deploy CLOUD_RUN_SERVICE_NAME \
  --image="gcr.io/ESP_PROJECT_ID/endpoints-runtime-serverless:CLOUD_RUN_HOSTNAME-CONFIG_ID" \
  --allow-unauthenticated \
  --platform managed \
  --project=ESP_PROJECT_ID

Is this the process for every API path change? Or is there a simpler direct method of updating the YAML file and uploading it somewhere?

Thanks.

RmR
  • 1,099
  • 10
  • 22
  • Do you perform the step 2 and 3 everytime that you change the CLoud Endpoint YAML? – guillaume blaquiere Jan 21 '20 at 16:21
  • Yes. Is there a way I can avoid it? When I do not it takes the old config-id in the Cloud Run service – RmR Jan 22 '20 at 03:00
  • It's actually a best practice to re-deploy a Cloud Run application when there's a new configuration for your app. This allows you to separate code from config and do stuff like rollbacks cleanly. – AhmetB - Google Jan 23 '20 at 18:46

2 Answers2

1

Based on the documentation, yes, this would be the process for every API path change. However, this may change in the future as this feature is currently on beta as stated on the documentation you shared.

You may want to look over here in order to create a feature request to GCP so they can improve this feature in the future.

In the meantime, I could advise to create a script for this process as it is always the same steps and doing something in bash that runs these commands would help you automatize the task.

Hope you find this useful.

rsalinas
  • 1,247
  • 3
  • 7
  • Thanks @rsalinas for your reply. I wanted to confirm that I was not missing out on something simpler – RmR Jan 22 '20 at 02:59
0

When you use the default Cloud Endpoint image as described in the documentation the parameter --rollout_strategy=managed is automatically set.

You have to wait up to 1 minutes to use the new configuration. Personally it's what I observe in my deployments. Have a try on it!

guillaume blaquiere
  • 33,758
  • 2
  • 11
  • 37
  • oh! is it? Let me give it a shot. Once I confirm I will mark this as the answer. Thanks @guilaume blaquiere – RmR Jan 22 '20 at 11:27
  • I wrote [an article](https://medium.com/google-cloud/secure-cloud-run-cloud-functions-and-app-engine-with-api-key-73c57bededd1) on Cloud Endpoint and I never had to redeploy Cloud Run during the tests. – guillaume blaquiere Jan 22 '20 at 12:19
  • it has not worked for me. As suggested I updated the `open-api-functions.yaml` file and deployed it as above using Step 1. The endpoints configuration shows the latest one as the current. However, when I check the **Google Cloud Run** service and check the YAML file there it points to the old configuration. This is the section in the YAML file under: 'spec > template > annotations` and within it the entry: `client.knative.dev/user-image: gcr.io/PROJECT-ID/endpoints-runtime-serverless:xxxx-yyyy--uc.a.run.app-CONFIG-ID`. This config-id is the earlier one. – RmR Jan 23 '20 at 04:37
  • And after running Step 2 and Step 3, the above `client.knative.dev/user-image` value changes to the latest config-Id – RmR Jan 23 '20 at 04:41
  • Why do you need to build your own esp image? Why you don't use the standard ones? What do you add in it? Anyway, I agree with you, when you update the endpoint configuration, Cloud Run is not redeployed. But Cloud Run is only a proxy here. It read the Cloud Endpoint configuration (that you deploy in step 1 and which is rolled out into Cloud Run dynamically, without new revision) and route the the request to the defined endpoint. – guillaume blaquiere Jan 23 '20 at 09:25
  • I do not understand by: "build your own esp image". I have no special case. I was just following the documentation given in the Endpoints site. https://cloud.google.com/endpoints/docs/openapi/get-started-cloud-functions. What would you recommend given my use-case – RmR Jan 23 '20 at 10:08
  • Ok!!!!!!!!!! You use the betaV2 version! Understood, you never mention this before!! – guillaume blaquiere Jan 23 '20 at 10:49
  • I always user [this](https://cloud.google.com/endpoints/docs/openapi/get-started-cloud-run) without the espBetaV2 section and it works well. I can't figure what is the difference because I use the same base image. – guillaume blaquiere Jan 23 '20 at 10:54
  • By comparing what I usually do (and I [wrote in my article](https://medium.com/google-cloud/secure-cloud-run-cloud-functions-and-app-engine-with-api-key-73c57bededd1)), this section "Deploy Cloud Endpoint Service" of my article is no longer available in GCP documentation. I don't know why... Anyway, I tested again this monday for configuring quotas, and it works well without rebuilding as described now. You can have a try on my article paragraph and update your service like this. Maybe it will solve the issue. – guillaume blaquiere Jan 23 '20 at 10:56
  • My bad on not specifying the version. Let me follow what you have suggested in your article and give it a shot. Thanks @guillaume blaquiere – RmR Jan 23 '20 at 11:14