I am trying to create a couple of resident instances on a google app engine app hosted on appspot.com. I moved the idle instances slider from Auto down to 2. My understanding is that this will then create two "resident" instances and I should see those marked as Resident instead of Dynamic in the instances screen. But it isn't working, I am still only seeing 1 dynamic instance (this is a test with no traffic).
When I made and saved the idle instances change, I noticed what to me was a new option underneath that section, as follow :
Performance Settings Migration for Modules
Before you can modify performance settings across Modules, your
settings must be migrated. After the migration, performance settings
will be managed at the Module level, and changes must be made through
your app.yaml (Python) or appengine-web.xml (Java). Copy the settings
clause below to the appropriate file to preserve your performance
settings during the next update.
There is a button under this new section called Migrate Settings. When I click this the main screen just blanks, with the admin console menu options still available on the side. All very peculiar!
It also gives some setting for python and java to do the idle instances down to 2 change at the module config level. I stuck this into my appengine-web.xml and re-deployed but I am still only getting one dynamic instance.
Has anyone any experience of this "migrate settings" option?
Related
How do I move instances from one project to the next?
Problem: I have frontend production instance and backend production instance in 2 separate project. I would like to have my production instances (both frontend and backend) in the same project.
How do I move instances from one project to the next within Google App Engine?
You could have the 2 apps run as 2 separate services inside the same project. To do that you'd have to deploy the app from the project that will disappear as another service in the project that will remain. Some code changes might be required, depending on how the app is coded. Typically they're small changes, though.
IMHO it would be simpler to keep the project currently hosting the frontend and move the backend over from the project to be retired. The reason is that the frontend is typically better fitted to play the default service role and it is already setup as such, changes should be smaller. Performing the move in the other direction would mean both services would need to changed.
You might need a dispatch.yaml file to route incoming packets, unless the URL mappings of the services are really well done. Not a big deal.
If you're using custom domains, with a bit of care it is possible to make the move (almost) transparent - by having the new service up and running before retiring the old project. DNS propagation time becomes rather irrelevant - both old and new services being simultaneously ready during the transition.
Note: technically you wouldn't be "moving" instances, you'd just stop the ones serving the project to be retired and start new ones for the service added to the project to be kept.
More or less related:
Change runtime from Python to Go in App Engine standard environment
Can a default service/module in a Google App Engine app be a sibling of a non-default one in terms of folder structure?
Is there a way to update selected files when using the App Engine Flexible env?
I'm facing an issue whenever I do a small change in the app.yaml file: to test it I would need to deploy the whole application which takes ~5mins.
Is there a way to update only the config file? OR is there a way to test these files locally.
Thanks!
The safe/blanket answer would be no as the flex env docker image would need to be updated regardless of how tiny the changes are, see How can I speed up Rails Docker deployments on Google Cloud Platform?
However, there might be something to try (YMMV).
From App Engine Flexible Environment:
You always have root access to Compute Engine VM instances. SSH access to VM instances in the flexible environment is disabled by
default. If you choose, you can enable root access to your app's VM
instances.
So you might be able to login as root on your GAE instance VM and try to manually modify a particular app artifact. Of course, you'd need to locate the artifact first.
Some artifacts might not even be present in the VM image itself (those used exclusively by the GAE infra, queue definitions, for example). But it should be possible to update these artifacts without updating the docker image, since they aren't part of the flex env service itself.
Other artifacts might be read-only and it might not be possible to change them to read-write.
Even if possible, such manual changes would be volatile, they would not survive an instance reload (which would be using the unmodified docker image), which might be required for some changes to take effect.
Lots of "might"s, lots of risks (manual fiddling with the app code could negatively impact its functionality), up to you to determine if a try is really worthy.
Update: it seems this is actually documented and supported, see Accessing Google App Engine Python App code in production
I am unable to permanently delete Google App Engine managed VMs I've created. I've deleted them multiple times both from the developer's console and by using the gcloud command. In every case the command completes successfully and the VM is deleted, but then almost immediately Google creates a brand new VM to take its place.
Does anyone know how to permanently delete managed VMs? Thanks.
We are working on improving this experience. For now, though, one workaround is to deploy a non-Managed VM instance as the default version and delete any other versions that are Managed VM-based. Again, this issue is on our radar to be fixed.
[Chris Ramsdale, Product Manager for App Engine]
I wanted to update this post with some of my solutions to deploying (with versions) and deleting instances on Google Compute Engine's managed VMs. Here's a solution I found for deleting the default GCE managed VM:
Make sure you have the up-to-date GCE components. Run gcloud components update in the Google Cloud SDK Shell.
In your app.yaml, remove the vm:true, resources: section, and manual scaling: section.
Navigate to Compute -> App Engine -> Versions and record the <default-version-number>. Mine looks like 20150722t1245032 with the words (default) indicating the default version.
Deploy the application, set the default, and specify the default version. gcloud preview app deploy "...\app.yaml" --set-default --version=<default-version-number>.
Navigate to Compute -> Compute Engine -> VM instances. Select the default instance and delete.
I was also taught how to stop deploying additional instances:
The key is to specify the version number gcloud preview app deploy "...\app.yaml" --set-default --version=<version-number>. #ZacharyNewman was able to help me with this problem.
And finally, this is how to delete the additional versions of an instance:
Navigate to Compute -> App Engine -> Versions and delete the versions you don't want.
Navigate to Compute -> Compute Engine -> VM instances. Select the instances you don't want and delete.
Hope this helps!
There might be a simpler way to explain this -- "basically, you cannot delete a version that's receiving 100% of the traffic."
Therefore, you just need to create a non managed VM, like a simple helloworld application. Then, you can move all of the traffic to this helloworld application (see graphic, I named mine version 0), then, delete version 20160... or whatever the name of your vm is.
At some point in time, you're probably going to experiment or spin up your managed VM again. When you do that, it will automatically start getting 100% of the traffic.
Or, if you happen to know version number receiving 100% of the traffic, you can always deploy a simple, non managed VM, with this version.
In Google Cloud Console under App Engine -> Versions , select the default version of your managed VM application and use STOP button to turn it off.
I ran into the same problem this is how i was able to stop the managed VM permanently. Just go to appengine -> settings -> disable application. This will automatically stop and delete your VM. In future if you want to run managed vm just enable application this will redeploy your application to the last known version.
We have an existing application using the legacy Master-Slave database with an alias to one of our subdomains. When we went to HRD, we re-engineered the application considerably and so we don't want to use the migration tool. In fact, we don't care about the data at all (see background below for why). I just want to change the alias so that the subdomain points to a new application, or in other words:
subdomain.example.com --> oldapplication.appspot.com
to
subdomain.example.com --> newapplication.appspot.com
Ordinarily (in a non-GAE environment) this would be a simple DNS change and once DNS propagates we could shut down the legacy application. In GAE, we can delete the old alias and set the alias up on the new application, but we don't know how long this is going to take to complete (other than the 10 seconds it takes for someone to click the buttons and post to the control panel). We're potentially willing to accept a very small window of downtime where subdomain.example.com won't be serving pages (because we know when peak loads are). But does anyone know how long this change-over should take?
We reported a production issue but have not had any feedback.
Background:
This application serves a bit of Javascript that can be embedded in parters' web sites. The data for this gets fed from our main site (not on GAE) via an API on a daily basis. So we don't care about migrating data and in fact we're already doing the daily feed to the new application and just need to change the alias.
I just did very similar thing for my domain. Moved example.com to point to my new app in GAE/google apps. I deleted my existing domain/appengine application mapping and in <10seconds added the new mapping.
There was no downtime. For about a minute my domain continued to point to old application and then it moved to the new application.
I've been thinking lately about the pros and cons of using AppEngine.
My concern would be, when we create application for GAE, the front-end code (the UI stuff) is served from the same application instance in the GAE cloud as with the Datastore codes.
The question would be when my applications grows:
For GAE:
Do I need to create multiple instance of my application?
If so, what do I need to manually update all instances?
For Appscale:
Do I also need to create multiple instance of my application?
If so, what do I need to manually update all instances?
GAE starts new frontend instances automatically, you even can't create or update frontend instances. You just need to configure min/max latency, min/max idle instances in Application Settings. See docs for performance settings
Btw, there are also Backend Instances that can be Resident and started manually from Admin Console. But it's useful only when you need something very specific
You seem to have missed the whole point of AppEngine, which is that Google takes care of scaling your app for you automatically. You seem to be confusing 'instance' with 'version' - you have control over which version of your app is serving, but Google dynamically creates and kills instances of that app depending on load. That's the main benefit of using AppEngine in the first place.