I have a test app on app engine.
I incremented its version and deployed again
now If I modify some data in one version, it is written on datastore that 2nd version uses (because version point to same store)
how can I disable the version, without deleting it?
There's only one datastore that's common to all versions. It's not like each version has its own datastore.
You can set a default version, but you can't prevent anyone from directly forcing a version by going to http://version.appid.appspot.com
you could use namespaces to separate the data between versions.
https://developers.google.com/appengine/docs/python/multitenancy/overview
Related
I have a website on AppEngine that is 99% static. It is running on Python 2.7 runtime. Now the time has come to evolve this webapp, and since I have almost none Python code in it, I'd prefer to write it in Go instead.
Can I change runtime from Python 2.7 to Go, while keeping the project intact? Specifically, I want to keep the same app-ID, the same custom domain attached to it, the same SSL certificate, and so on.
What do I have to do in order to do that? I surely have to change runtime in the app.yaml. Is there anything else?
Bonus question: will such change happen without a downtime?
I'd be grateful for any links to documentation on exactly that (swapping runtime on a live app). I can't find any.
Specify a runtime as well as a new value for version. When deployed you'll have an older version that is Python and a newer version that is Go. There won't be any downtime (same as when deploying a newer version of Python).
Rather than trusting links/docs (that may be out of date or not 100% exactly what you're trying to do), why not create a new GAE-Std project for testing purposes and try it yourself. Having a GAE-Std test project is good for testing new function (especially by other testers who won't have access to the dev environ on your laptop).
The GAE services offer complete code isolation. So it should be possible to simply deploy a new version of the service, which can be written in a different language or even use a different GAE (standard/flex) environment. Personally I didn't go through a language change, but I did go through a split of a single-service app into a multi-service one, I see no reason for which the same principles wouldn't apply.
Maybe develop the new version as a separate app first, to be able to test it properly without risking an accidental impact on the old version and only after that bring the code as a new version in the old app. That'd be using the GAE project isolation. You can, in fact, test the entire version migration as a separate app if you so desire without even touching the existing app. I am using this technique - a separate app ID - to implement a staging environment for my app, completely isolated from my production app, see How to copy / clone entire Google App Engine Project
Make sure to not switch traffic to the new version at deployment time. This keeps the app working with the old version. Test first that the new version works as expected using Targeted routing. Then maybe use Splitting traffic across multiple versions to perform A/B testing with just a small percentage of the traffic going to the new version. Finally, when happy with the results, switch all traffic to the new version.
You need to pay special attention to the app-level configs (dispatch, cron, queue, datastore indexes), shared by all services/versions. They need to be functionally equivalent in the 2 versions. The service isolation doesn't apply to them, only project isolation can ensure no impact to the old version.
There should be no need to make any change to the app ID, custom domain mapping or SSL config. The above mentioned tests should confirm that.
A few potentially interesting posts related to re-working services/modules:
Converting App Engine frontend versions to modules
Google App Engine upgrading part by part
Migrating to app engine modules, test versions first?
Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
I have GAE application with 3 versions. Only default version has active instance, other two versions do not have active instances. Usually after deploy of any version, instance is created. But now that is not the case. Instances of non default versions wont to start after deploy, and I need those versions up.
I saw this question:
Google App Engine instances not starting
but there is no concrete answer.
Any idea how to start version instance?
The version will start after you send it the first request (unless you use Managed VM - https://cloud.google.com/appengine/docs/managed-vms).
It's unclear what you are trying to accomplish by having multiple versions running at the same time, having a little more info would really help providing a specific solution.
As #Vlad stated App Engine won't start (or keep) any app until it gets some traffic. you can start them by hitting ..appspot.com
If this "versions" are actually doing different things you should be implementing them as Modules .This way you can set up different rules for each module and setup the interactions between them.
1) Let say I have an application which has to be upgraded to a newer version.
In the newer version data form a table has to be moved to an another table before the application goes live.
How could this be achieved in a Google App Engine?
2) How could I switch over my application from one version to another. I know that GAE supports up to ten version of the same application. But how could I switch over between these versions?
why do you need to move data?
just deploy, give a name to the new version and change the default version to pointing to new one / split the traffic. Why do you need to maintain the old one?
I want to test my thick client against my RESTful appengine application. I regularly increment the appengine version number so I need to keep updating my test config. Is there the equivalent of http://latest.application.appspot.com that I could point my config too?
Thanks
Skirting around your question, but in my head, I've stopped thinking of the "version" in the typical software release version (which like you, I started out thinking), but rather, it's "a different application using the same datastore".
I found out the software release version (1.0, 1.1, 1.2 etc) doesn't make much sense because 1) I don't tend to use older versions 2) my main usage would be to regression test, but this doesn't work well, because it's quite possible for a change in your model in v1.1 to break the code in v1.0.
The versions feature comes in hand to have different functional versions. For example, maybe the default application.appspot.com runs production level code, but debug.application.appspot.com has more logging enabled. Perhaps a third version has administrator functionality enabled, etc.
No, there's no way to do this. Versions aren't sequenced - they're all entirely distinct deploys, only one of which is set as the default.
What you are likely looking for is the CURRENT_VERSION_ID environment variable. It stores the deployment revision as dot-separated string: version_name.deployment_revision, e.g. staging.12345678910111213141516. You could just use it directly in your config:
import os
API_VERSION = os.environ['CURRENT_VERSION_ID'].split('.')[1]
Can you test an uploaded version of an app, other than the "default" version?
I'm told it can be: WoLpH Google App Engine version numbers?
But I can't find it in the dashboard or the doco.
If the version of app is 2 and your app URL is appname.appspot.com then URL 2.appname.appspot.com will give you access to version 2 of your app.
As Vishal already said correctly (+1), you can prepend the version identifier to your url, so if your version is "version", the URL will be version.appname.appspot.com (app versions are strings, not numbers, although the string "2", is perfectly ok too).
To select another version from the Dashboard, just select the main application first, then use the second dropdown at the top of the page to select the version. This will show you the dashboard of another version, without changing the default (active) version.
Important considerations to keep in mind:
However, the main gotcha that I would like to mention, is that you're using the same Datastore of the live version. This can be a good thing, if you want to browse your application, but is not very recommendable if you want to insert test data that could potentially mess the public view.
You're also using the same task queues and cron, so you've to be careful of unintended consequences, should your application version update them.
If the problems mentioned above are important to you, you may consider to deploy another application to use for testing instead. In this way you'll be completely separated by the live environment.
Note that double wildcards for appspot.com are no longer supported (*.*.appspot.com). To test different version than default use version-dot- prefix.
appname.appspot.com // default
2-dot-appname.appspot.com // version 2
In the menu there is section Main > Versions and there you can choose the version then "Make default". Of course to have more than one version available there you have to change the version before deploying(as far as I remember you can do this in one of xml files).
Or you mean to have default version, but test another one?