I have 2 versions x & y for A/B testing in an appengine module. I want 95%-5% ratio for traffic which I am able to configure from the panel. The problem is - Whenever I make a deployment to the module, appengine automatically routes all traffic to x or y. And its totally random, sometimes 100% of traffic goes to x and sometimes y. It is something that I am missing from docs, or it is supposed to happen this way?
mvn gcloud:deploy -Dapp.id=test-project -Dapp.module=alpha -Dapp.version=x
mvn gcloud:deploy -Dapp.id=test-project -Dapp.module=alpha -Dapp.version=y
You can use the --no-promote flag when deploying your apps:
mvn gcloud:deploy -Dapp.id=test-project -Dapp.module=alpha -Dapp.version=x --no-promote
mvn gcloud:deploy -Dapp.id=test-project -Dapp.module=alpha -Dapp.version=y --no-promote
For more info, check out this doc: Testing and Deploying Your Application.
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 have an app that uses the following command to deploy a static app generated by create-react-app:
gcloud app deploy --project MY_PROJECT -v dev
After that, my app is available on myproject.appstop.com.
But I don't figure out how to deploy this app using a diff URL for each environment. Like.: dev.myproject.appspot.com, stg.myproject.com and so on.
If you know or have other ideas about how to solve this please share your thoughts.
It depends on what you understand by environment. I would definitely recommend you to create different projects for the different environments (my-project-dev, my-project-staging, my-project-test, my-project-prod...)
If you just want to have a different url for your deployment, you are doing ok by using the -v (version parameter).
Once you've deployed again:
gcloud app deploy --project MY_PROJECT -v test
you'll have both versions accessible at:
dev.myproject.appspot.com
test.myproject.appspot.com
Also, check Dan's answer below as it contains very relevant info.
To complement #MarCialR's answer, you can use SSL as well, but with *-dot-* URLs like https://test-dot-myproject.appspot.com, see Targeted routing.
But personally I'm not a big fan of a version-based environment, it brings trouble, see Continuous integration/deployment/delivery on Google App Engine, too risky?
I chose to implement environments at app level - each environment as a different app, each with its own URL. See Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
Since I'm using a wildcard custom-domain SSL certificate I'm simply mapping the different apps (environments) to different hosts/subdomains in my custom domain - thus ensuring everything works as expected with a custom domain at every point in the CI/CD pipeline, no surprises in production.
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>
My problem is that I want to create dev, stage, prod environments by using different GCP projects.
Basically they are running the same code, just running them in different isolated environments.
I'm using gcloud app deploy in command line to deploy app right now.
How can I efficiently deploy an app to different project?
Do I have to do gcloud init to change my configuration of default project every time?
There must be some better practices.
Or, is there a better way for me to set up dev... environments in the context of app engine?
Thanks.
Instead of using gcloud init to change your configuration each time, use this code to deploy to multiple projects faster:
gcloud app deploy -q --project [YOUR_PROJECT_ID]
If your projects have similar IDs, let's say: test1, test2, test3, test4, You can deploy to the four projects with one command. Use this code:
for i in {1..4}; do gcloud app deploy -q --project test${i}; done
The "standard" approach is to use versions, e.g.
qa.myApp.appspot.com
Once a version is ready for next step, you deploy it with a different version id.
One problem with using multiple projects is that you have to maintain a different data set for each project.
My preference is to have the different environments managed via the same version control as the code - one branch for each environment, keeping the deployments perfectly aligned with the natural flow of code changes, promoted via branch merges: dev -> stage -> production.
To minimize the risk of human error I try as much as possible to keep the deployment configs in the code itself (i.e. - have the app IDs, versions, etc. picked up from the .yaml files, not passed to the deploy cmd as args). The deployment cmds themselves are kept in a cheat-sheet file (too simple to warrant a full-blown script at this time), also git-controlled. Illustrated in this answer: https://stackoverflow.com/a/34111170/4495081
Deployments are done from separate, dedicated workspaces - one for each environment, based on the corresponding git branch (I never switch the branches in these workspaces). I just update the workspace corresponding to the desired environment to the version needed and copy-paste the deployment cmd from the workspace's cheat-sheet.
This model is IMHO CI/CD-ready and can easily be entirely automated.
For Python applications, you can set application in the app.yaml file. This allows you to use different data for each project. This is when you deploy using the appcfg.py command.
application: myproject
version: alpha-001
runtime: python27
api_version: 1
threadsafe: true
handlers:
- url: /
script: home.app
If you don't want to change the application value in this file for each project, you can run the following:
appcfg.py -A <YOUR_PROJECT_ID> -V v1 update myapp/
https://cloud.google.com/appengine/docs/python/config/appref
If you do not specify the application in the file, use the --application option in the appcfg command when you deploy. This element is ignored when you deploy using the gcloud app deploy command.