I used to deploy AppEngine apps with appcfg.py which, as far as I remember, was automatically deploying the index.yaml file as part of the app deployment.
Now that I'm using gcloud app deploy I've found out the hard way that I also have to run gcloud app deploy index.yaml to get the indices created.
Why was gcloud designed that way?
After indexes are uploaded, it can take a few minutes for them to actually build. While they build, any app that attempts to use those indexes will fail. The behavior in appcfg.py of uploading both at the same time can actually result in apps failing for a few minutes while the indexes build.
The behavior in gcloud app is more explicit to avoid these issues. If you are adding new indexes and new code that depends on it, you should use this procedure:
gcloud app deploy index.yaml
# wait for indexes to build
gcloud app deploy app.yaml
Related
There are many answers to this question already, but they no longer work here in January 2021. All those answers come in 3 flavors:
Set local machine timeout with something like gcloud config set app/cloud_build_timeout 1600 then deploy with gcloud app deploy ...
Use a cloudbuild.yaml file instead with timeout: 1600s bits in the gcloud app deploy buildstep and the global configuration, then deploy with gcloud builds submit ...
Per google's own docs, don't set timeout: 1600s in the cloudbuild file, but rather do a mashup of the previous 2 flavors with a build step including args: ['-c', 'gcloud config set app/cloud_build_timeout 1600 && gcloud app deploy']
None of them have any impact on the app deploy build - it's stuck at 10mins. When using gcloud builds submit, it results in 2 Cloud Builds being kicked off: one for the cloudbuild.yaml, and one for the app engine deployment using buildpack. The above solutions can impact the first build, but once that first build kicks off the second build (gcloud app deploy, you can see at https://console.cloud.google.com/cloud-build in the Execution Details tab that the Timeout is still 10m.
IMO, solutions 2-3 are hacks since 1 doesn't work, but now that 2-3 don't work either, I'm looking for another hack. Does anyone have a solution which works in 2021? Since my app is using GAE Standard Environment, I can't prebuild an image - I'm stuck with Buildpack building my ruby app and pulling all the Gems every time, and this runs out the seemingly immutable 10m clock.
You cannot change the timeout property in App Engine standard and it's always 10min. The workaround is to use App Engine flex and this way you can use the gcloud config set app/cloud_build_timeout TIME_SECONDS.
There is a feature request to enable timeout edit for App Engine standard but seems still in progress.
We are deploying our Go app to Google app engine with the command: gcloud app deploy
This creates a cloud build, which normally works fine. However, sometimes there are some dependencies which are flaky (sometimes unavailable or down) or gone (revision no longer existing).
These issues break our complete deploy and build and we can only get rid of the dependency or wait until it is fixed on that side.
Solution for this is using a proxy for the go dependencies (like https://proxy.golang.org/), but I don't have any way of setting this setting for our app engine deployments.
Does anyone know how I can use a proxy for google app engine deploys to make our builds more stable?
I'm building a custom image for App Engine Flexible with gcloud app deploy currently. I've played with using Kaniko to get caching working with gcloud builds submit for other projects, but is it possible to enable Kaniko for a build submitted with gcloud app deploy?
I've tried running gcloud config set builds/use_kaniko True, which doesn't seem to change the build behavior.
It seems like one option would be to build an image first via gcloud builds submit, then use gcloud app deploy --image-url=..., but I wasn't sure if there was a more streamlined way.
As you already said in your question, a good approach would be to first use Google Cloud Build to create your own image using your Dockerfile to then use it when deploying your application to Google App Engine.
In Google Cloud Container Builder you can run Kaniko by adding it as a build step in the build config:
steps:
- name: gcr.io/kaniko-project/executor:latest
args: ["--dockerfile=<path to Dockerfile>",
"--context=<path to build context>",
"--destination=<gcr.io/[PROJECT]/[IMAGE]:[TAG]>"]
More information can be found in these two blog posts about Google Cloud and kaniko. Post 1 & 2.
After that you can deploy your application by specifying the --image-url flag in the gcloud command:
gcloud app deploy --image-url=gcr.io/[PROJECT]/[IMAGE]:[TAG]
I'm deploying an app in Google Cloud that has multiple microservices. For one of them, I wish to use a push queue. I configured my queue.yaml file as follows:
queue:
- name: equeue
rate: 10/s
retry_parameters:
task_retry_limit: 1
task_age_limit: 2d
I spin up the SDK and the queue is working fine, just as it should. But then I go to push it to my app on Google Cloud using:
gcloud app deploy --project=<projectname> --promote --stop-previous-version
The code all loads correctly, but the queue never gets created. I am getting errors from my code as follows:
API error 1 (taskqueue: UNKNOWN_QUEUE)
And when I look in the console, on https://console.cloud.google.com/appengine/taskqueues, the queue has not been created.
I've read the documentation and it seems to indicate that all I need to do is create the queue.yaml file and deploy the app (and that has worked for me in the past, albeit with an older version of the SDK.)
In case it helps, here are the components I'm running locally:
Google Cloud SDK 164.0.0
app-engine-go
app-engine-python 1.9.57
bq 2.0.24
core 2017.07.25
gcloud
gsutil 4.27
Thanks!
Dan
The queue.yaml is an app-level configuration file, not a service-specific one. See (marginally related) Why do I need to deploy a "default" app before I can deploy multiple services in GCP?
While in a single service app case deploying the default service might also update one or more of these app-level configs that is not guaranteed in a multi-service app case. Which is why each of these configs also comes with an individual dedicated method of deployment which can be performed independently of and/or without updating any of the app's services.
For queue.yaml in particular deployment can be done using gcloud app deploy:
gcloud app deploy [...] queues.yaml
or, if you're using the GAE SDK, using appcfg.py update_queues:
appcfg.py update_queues -A <app_id>
The documentation describes how to deploy endpoints application with gcloud tool but is it possible to deploy the app with appcfg.py?
What I'd like is to use this command:
appcfg.py update [YOUR_APP_DIR] -A [YOUR_PROJECT_ID] -V [YOUR_VERSION_ID]
And don't have to edit the app.yaml file to set a new value for ENDPOINTS_SERVICE_VERSION variable every time I need to deploy a new version.
If I understand correctly YOUR_VERSION_ID application version is not the same as ENDPOINTS_SERVICE_VERSION but where this difference is important?