Cannot implement healthcheck as described in docs

[mikelambert]

The docs say:

You can write your own custom health-checking code. It should reply to /_ah/health requests with a HTTP status code 200.

However, this code and this handler appear to override the /_ah/health handler after the app is configured, such that the app cannot override the health handler in any way that I can see...

Is there some way I should be implementing my own health handler?

The only thing I can think of is to implement my own Dockerfile ENTRYPOINT that uses my own app, that tries to import vmruntime.wsgi.meta_app and override it after the fact...are there any other options?

(Note: I checked this awhile ago and noticed this behavior...finally getting around to writing up a bug report. Haven't checked it specifically on the latest code, but the issue looks to be the same.)

[duggelz]

Hi Mike,

I'm sorry that you're having this problem. Looking at the code, it's really unfortunate the way wsgi.py is implemented. I don't see an easy solution other than some aggressive monkey-patching. It might work to define your own gunicorn.conf.py, where you from vmruntime import middleware and then set middleware.health_check_middleware = your own health check function name.

Second, I need to mention that the python-compat runtime is deprecated, and will not advance to General Availability with the rest of AppEngine Flex. If at all possible, I would recommend migrating to the python runtime and using a supported third-party Python web framework such as Flask. More information is available here: https://cloud.google.com/appengine/docs/flexible/python/runtime#application_startup . This allows you to set the ENTRYPOINT via an entrypoint directive your app.yaml.

[mikelambert]

Thanks for the detailed response. Hadn't considered the gunicorn.conf.py angle, but that makes sense, and I may go with that, since it seems a bit cleaner than my proposal (which might be operating on the wsgi app too late). I'm on a custom docker VM that subclasses python-compat, so changing the ENTRYPOINT isn't the end of the world for me.

As far as the deprecation....I'm aware, but I'm in a tricky spot (like many python-compat users). I am a very-long-time GAE user, and migrated to Managed VMs (then Flex VMs), which means Google is pulling the rug out from me on a bunch of services I now depend on:

• memcache: waiting on the yet-to-be-released "App Engine Flexible Memcache" service (just applied for the "alpha")
• push queues: which may or may not be supported in the yet-to-be-released "Cloud Tasks" (just applied for the alpha)
• NDB: the "supported/recommended" python Datastore library, which is not "supported" outside of Standard VM as described in https://github.com/GoogleCloudPlatform/google-cloud-python/issues/557. I'm waiting on https://github.com/GoogleCloudPlatform/datastore-ndb-python/issues/272
• search: I need to migrate to a third-party platform (possibly ElasticSearch, though I'll be paying a lot more...)
• mail sending: I need to migrate to a third-party platform
• login: admin functionality: I need to migrate to a third-party platform
• mapreduce and pipeline libraries, which are built on top of push queues. If there are no push queues in Cloud Tasks, I'll need to rewrite these all for Cloud Dataflow...

And of course, since I jumped on the Managed VM / Flex VM bandwagon, I've also added enough features that make it difficult to migrate back to stock GAE:

• Python native C modules
• a co-resident JS server for rendering React pages

I assumed "deprecated" just meant an undetermined end date, though poking around now I see it has a date of October 27th, 2017. Ugh, let's hope Google staffs the above "alpha" projects and open bug requests appropriately, so I have time to rewrite my code to use them (or work around them). :)