How is patching done for flexible instances?

64 views
Skip to first unread message

Attila-Mihaly Balazs

unread,
Nov 17, 2017, 12:18:02 PM11/17/17
to Google App Engine
Hello all,

Flexible instances sound great in theory - use runtime you wish as long as you can create a docker image for it and listen for HTTP on 8080.

However, one of the reasons I prefer AppEngine (standard) is the fact that I don't want to be Ops - don't want to be concerned about updating the kernel at 3AM in the morning when the latest exploit comes out. I love that G just handles that for me with AppEngine standard.

How does this work with flexible? There is a throw-away line in the documentation about "flex instances will be restarted at least once per month to apply critical security updates", however I fail to see how this could work when - from what I can see - the base image can be anything (ie. RedHat, Ubuntu, Arch or even Linux From Scratch, OpenWRT, etc :-)).

To what extent does Google patch the flexible instances? Do I still need to recreate the docker image weekly for example to ensure that all the latest packages are installed? Or rather - do I need to deploy weekly in this case? (since deploying rebuilds the docker image - which is nice but still annoying that I need to deploy at least once a week to have my instances be up to date).

Jun (Cloud Platform Support)

unread,
Nov 17, 2017, 6:57:07 PM11/17/17
to Google App Engine
Hi Attila,

Basically Google's management services will apply in-place security patches (excludes container image runtime) and any operating system and security updates during the restarts on a weekly basis per the doc at "Choosing an App Engine Environment". 

Attila-Mihaly Balazs

unread,
Nov 18, 2017, 1:46:35 AM11/18/17
to Google App Engine
Hello,

Thank you for the reply. Just making sure that I understand correctly: when you say "excludes container image runtime", it means that none of the following scenarios are covered:

Lets say that I'm running a CentOS based docker image on AppEngine Flex.

1) A security bug is discovered in nginx. There is an update available in the repositories. However my instances are not patched until I rebuild/redeploy my images (and I have to be careful to rebuild them in such a away that Docker doesn't re-use a cached intermediary image which would result in the package update step being skipped)

2) Let's say that I'm running Java 9 inside my flex instance, using the OpenJDK build. A new version of the build is released fixing a security bug. I won't get it, until I manually update my Dockerfile presumably and redeploy

3) My webservice is written in Haskell, which gets compiled down to a native executable statically linking zlib. Zlib has a vulnerability and there is a new version. My webservice won't have that update until I rebuild / redeploy it.

Is my understanding correct that in all of the above scenarios the onerous task of keeping the different libraries / runtimes updated falls on me? I do realize that supporting (2) and (3) is somewhat of a pipedream (since there are an almost infinite amount of possible configurations) and even (1) can be very complicated since there are a lot of linux distributions out there, but please do realize that one important reason for choosing Google Appengine is that I don't have time to be ops!

Thank you.

Jun (Cloud Platform Support)

unread,
Nov 20, 2017, 11:54:03 PM11/20/17
to Google App Engine
Hi Attila,

You're correct about the uncovered scenarios mentioned if your app runtime is container image runtime. However, we are very aware of all of the above mentioned scenrios, and our product teams are working hard to improve App Engine to a state where more needed solutions will be provided to meet different users' demand.
Reply all
Reply to author
Forward
0 new messages