How to automatically delete old Google App Engine version instances?

I’m experimenting with more cost effective ways to deploy my Rails apps, and went through the Ruby Starter Projects to get a feel for Google Cloud Platform.

It’s almost perfect, and certainly competitive on price, but I can’t figure out how to automatically delete old deployed version instances after redeploying.

  • nginx timeout after https proxy to localhost
  • thrift + hbase exception (in docker containers)
  • How can I copy a directory or file to a docker image from localhost on ubuntu14.04?
  • Docker diff images
  • Can't connect to cassandra cluster, but can connect to single node?
  • connect .NET API running in linux container with SQL Server running in VM using windows auth
  • ie: let’s say I have one version of each instance running:

    Compute Engine -> VM Instances

    And then I make a change to my app and redeploy with:

    $ gcloud preview app deploy app.yaml worker.yaml --promote
    

    So now I have two versions of each instance deployed (as Google switches between them intelligently, I’d assume):

    Compute Engine -> VM Instances have doubled

    But now what? Will these instances ever turn off by themselves? The best way I’ve found of getting rid of them so far is from the tutorial’s Deleting the project page:

    Deleting app versions

    You can find the list of your app versions in the Versions page. To delete the non-default versions, select the check boxes and then click Delete.

    appengine/versions

    Is everyone on Google App Engine just manually deleting the old deployments of their apps?

  • Swagger express gives error inside docker container
  • Can't get Pod info in the kubernetes cluster
  • Vagrant docker provisioner command
  • Run OpenCv in jupyter with Docker
  • Build Meteor in Docker cannot pass proxy setting
  • kpm restore unable to find System.Net.Http
  • 2 Solutions collect form web for “How to automatically delete old Google App Engine version instances?”

    To stop all instances of all non-default versions of all modules (independently of what languages those modules are in), you could add a small control module, written in Python, using the modules API:

    from google.appengine.api.modules import modules
    
    # core logic (inside a cron or other handler)
    for m in modules.get_modules():
        dv = modules.get_default_version(m)
        for v in modules.get_versions(m):
            if v != dv: modules.stop_version(m, v)
    

    This doesn’t delete the non-default versions (the modules API does not appear to currently support deletion), but does ensure that none of their instances are running (so no charges would be incurred for them).

    This core logic is meant for you to wrap it inside a handler, so you can trigger it as required, for example in a cron job, or in a “regular” handler that you trigger from the outside (with appropriate auth) e.g. via wget or curl within your bash scripts.

    I don’t believe there’s a Ruby version of Python’s google.appengine.api.modules.modules , but, I could be wrong… I just couldn’t find one. However, a simple Python-coded module should let you control modules coded in whatever other App Engine language (since App Engine lets you mix and match modules coded in different languages).

    To turn off the instances associated with older versions you could try to use the teardown scripts (eventually customised) mentioned in the delete tutorial resources doc:

    If you tried the tutorial about how to run Ruby on Compute Engine, see
    the Deployment and teardown scripts section of that tutorial

    Careful with deleting the app, though, you can’t re-use the app id!

    Since the older versions are no longer the default ones at least no new instances will be automatically starting for them. You may still need to delete them manually, unless Google automatically deletes the older automatically assigned versions exceeding the max number of versions allowed for an app.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.