Some google-managed base images would be helpful. The last time I checked, some of the major public docker images were still shellshock-vulnerable. Pre-installed GCE tools would be helpful. Perhaps automated environment variables about region, etc.

If you have found an official Docker image that is still shellshock vulnerable, the library maintainers [1] would love to hear from you as they take that stuff quite seriously. As far as I know the entire library is fully patched.

[1] https://github.com/docker-library/official-images

As one of the maintainers in question, I'd absolutely mirror this whole statement: if any of the image upstreams have an important update available that isn't applied, we're very interested in rectifying that.

Which images are still shellshock vulnerable? Wasn't aware that was an issue if we stick to the docker-managed images.

Which?

See https://gist.github.com/voltagex/582473e3b86ee5ae4438 - I ran some tests on the three most popular (?) official base images.

Given that this is the alpha launch of Container Engine, and the Beta launch of Autoscaling and Managed VMs, what is the anticipated timeframe for this to be ready for production workloads?

I'm assuming that there'll be a beta of Container Engine in the near future, and then a stable 1.0 launch?

Stable production ready GKE will gate on Kubernetes. Our Kubernetes roadmap is here: https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...

We are driving aggressively here. I hate to put a date on it but things are converging.

Ok that's fair, but just a rough idea would be incredibly helpful.

Are we talking sometime within the next 6 months / 12 months / longer?

That roadmap document doesn't really explain how the current featureset makes Kubernetes ready for an 'alpha' release on GKE.

We use AWS Elastic Beanstalk for Docker deployment. Can you comment on how this is different? I see it supports multiple containers per VM - are there other significant distinguishing factors?

Elastic Beanstalk is a VM centric management framework.

Kubernetes and GKE operate at a different level. It is an API for being able to schedule and manage containers instead of VMs. At this point, k8s/GKE doesn't have an idea of an "app" any more than a VM IaaS service has an idea of an app.

Moving from a VM centric view to a container centric view improves a lot of things: * Easier to create and manage images * Portability -- images can be moved between providers. Develop on your laptop with docker/k8s and deploy the exact same container image. * More transparency into compute workload. The hosting VM or cloud can see more of what is going on in the container for monitoring and logging, etc. * More efficient/higher density -- you can run more on any piece of (virtual?) hardware * More flexible resource sharing/overcommit -- as you drive density up you can get more nuanced about what workloads take get priority.

Some of this stuff is still in its infancy -- complex resource models aren't fully supported in Docker yet -- but it is where things are going, at least based on Google's experience.

>>Because this new service is officially in alpha, you’ll need to apply for access and be whitelisted to use the service. It also means the service isn’t feature complete and the whole infrastructure could melt down at any minute.

Not sure what the take away here is other than, this may one day be a feature. No information about pricing, support, or sla. My attitude is wait and see. Should it be otherwise?

Edit: Can someone tell me why this isn't a valid question? Why the down votes?

The TechCrunch article is incorrect. While it is still an early service, there is no whitelist.

It's all open source (including kubernetes) - so worst case you move it to the cloud provider of your choice. Other than Docker / k8s being a little immature, I don't see a ton of risk.

My biggest question on Docker / k8s: How does one control where persistent data lives and the required performance characteristics? Example: I need SSD + a certain level of availability? Is there a good strategy for managing this?

Right now, it isn't plumbed in but it is on the roadmap.

Either (a) you have network based block device and the master/manager maps that to a machine dynamically as the container get scheduled or (b) you constrain the containers to machines that have the hardware/data you need.

(b) is less than ideal but sometimes necessary.

Some discussion: https://github.com/GoogleCloudPlatform/kubernetes/issues/598

This is THE open question for Docker right now. The first person to actually solve it is going to be in a pretty damn good place.

Docker could make most infrastructure-level "cloud" abstraction obsolete and let people run resilient, scalable clusters on hardware pretty easily. There's CoreOS, Kubernetes, and a few others in the app-instance-scheduling space, but right now, if you want persistent data storage of any kind (block, SQL, blob, whatever) then you still need to tie things down to an individual machine or use VM-level cloud technology to acheive some semblance of fault tolerance. The inability to do persistent storage in a reasonable way is, from where I sit, the main thing keeping Docker from eating the world.

When you can run Postgres in a stable/supported way in a container on my own hardware that gets scheduled around failure/crowding/etc, you no longer needs AWS, VMWare, etc. That could be huge.

This is also what's holding me back from delving into Docker more. Love the concept, and the workflow, but trying to get my head around how the persistent data storage will work is still troubling me.

Is it possible to run a KVM VM inside one of the containers? I have an application for launching and managing VMs and letting people spin up a Google container to try it out would be neat.

GCE doesn't support nested virtualization.

But if you are running Kubernetes on bare metal, there is no reason you couldn't map in /dev/kvm and have k8s run VMs for you. I haven't done it though :)

Ok, I've done VMs inside docker already which has been fine, was hoping GCE would let me do it on Google's systems.

As someone who doesn't know, why would you want to run VMs inside of a docker container? Wouldn't this have tremendous overhead relative to just running the hypervisor?

If you use the -privileged flag, docker containers can access /dev/kvm and start low-overhead KVM instances.

It's advantageous for me, because I can say "hey check out this software" and they just have to run a single docker command, compared to installing Go, apt-getting a bunch of packages, fetching our repo, compiling, etc.

Why do you need the VM (as opposed to just containers)?

Because the software I'm attempting to demonstrate/distribute is specifically designed for running VMs. That is its sole purpose--sorta like OpenStack.

Do you see this being useful for analytical workloads (ie i need a bunch of cores for a short time to run a parallel job) or more focused on scaling web apps and services?

It can be used as both. As we build out better resource isolation and QoS, you'll be able to run mixed workload on the same hardware/VMs and use "every part of the animal".

I'm kind of confused. I get that they run on the Google VMs (which need a base OS, yes?) so does this manage all of that? Can I:

pick my vm size/ pick my docker image/ and go?

AKA does this bring me one step closer to docker-oku-aaS?

Essentially that is the case.

If you just want to launch a static set of containers on a specific VM, you can use our Container VM image -- https://cloud.google.com/compute/docs/containers/container_v....

Kubernetes (and GKE) is a dynamic system to run across a cluster of machines.