Re:Beta release of PHP 7.2 in the Google App Engine standard...
by derefr on Tuesday August 21, 2018 @12:59PM
(#17811409)
> The flexible environment also continues to confuse me - it talks about being a managed Docker container, but it doesn't seem like you actually get access to anything like a Dockerfile and that's more of an implementation detail on their end.
You're right that you don't get access to the Dockerfile. Docker isn't a 100%-isolated environment for multitenant use-cases, so Google needs to control the stack themselves, using specific trusted versions of base-image layers and app layers. There's maybe extra "Docker-image compile time" security restrictions made on top of that as well.
However, it's not just an implementation detail—it has pretty visible effects.
1. A Flexible Environment app slug gets baked into a regular Docker image and placed into your Google Container Registry alongside container-images you've built yourself with GCR. (And your GCR registry, in turn, is backed by a Google Cloud Storage bucket in your own account—meaning that you're paying for storing the resulting images just like any other uploaded objects. You should prune old App Engine Flexible Environment image versions if you don't want to pay!)
2. You can do whatever you want with the filesystem of your container, because it is just a Docker container. You can mount volumes to the container in the container spec (app.yaml), just like if you were writing a k8s container spec. (In fact, sharing IPC sockets through a Docker volume-mount is how the Google Cloud SQL proxy works.) You can internally auto-update your container by downloading new Python/Node/etc. code into the container and getting the interpreter to re-exec(2) itself. Pretty much anything that can run in a "Python Docker container environment" can run in Google's "Python Flexible Environment", because they're pretty much the same (save for those container-build-time security restrictions.)
You're right that you don't get access to the Dockerfile. Docker isn't a 100%-isolated environment for multitenant use-cases, so Google needs to control the stack themselves, using specific trusted versions of base-image layers and app layers. There's maybe extra "Docker-image compile time" security restrictions made on top of that as well.
However, it's not just an implementation detail—it has pretty visible effects.
1. A Flexible Environment app slug gets baked into a regular Docker image and placed into your Google Container Registry alongside container-images you've built yourself with GCR. (And your GCR registry, in turn, is backed by a Google Cloud Storage bucket in your own account—meaning that you're paying for storing the resulting images just like any other uploaded objects. You should prune old App Engine Flexible Environment image versions if you don't want to pay!)
2. You can do whatever you want with the filesystem of your container, because it is just a Docker container. You can mount volumes to the container in the container spec (app.yaml), just like if you were writing a k8s container spec. (In fact, sharing IPC sockets through a Docker volume-mount is how the Google Cloud SQL proxy works.) You can internally auto-update your container by downloading new Python/Node/etc. code into the container and getting the interpreter to re-exec(2) itself. Pretty much anything that can run in a "Python Docker container environment" can run in Google's "Python Flexible Environment", because they're pretty much the same (save for those container-build-time security restrictions.)