Kubernetes solves this by mounting external volumes (say NFS or iSCSI) on the host and then exposing them to one or more docker containers. This seems like a pretty ideal solution for any Docker user.
Are you suggesting that a person with a total of 3 nodes use a system like Kubernetes which requires at a minimum (correct me if I'm wrong) 5 nodes just to function? If you really, really want to use Docker with a typical Nginx-App-DB setup just whip up the necessary shell commands to start/stop/log containers and throw that in Ansible or the like.
edit: I guess you can cram all of the various Kubernetes master/etcd servers on a single node but whoops there goes reliability.
Crap like that actually happens. I have a mathematician friend who does a bit of programming ask me about Docker, as someone had told her to use it. She works as a researcher in academia, so probably only needs to run her script a few times to get results. Why the hell would you recommend Docker?
> probably only needs to run her script a few times to get results.
Agreed that she doesn't need to use Docker. But if she is writing a paper on those results, she might want a way to reproduce her findings years down the road (even after she switched Distros), or to collaborate with others who want to reproduce/build on her research (and may not be running her distro).
It's easy to think "oh, this script just requires python 2.7", but most of the time you actually have many more dependencies than that (libxml, graphviz, latex, eggs, etc.) A Dockerfile requires some work to setup, but it tracks your requirements in an automated way.
So I'm not going to say "all researchers should use Docker". But I will say "Docker could be useful to some researchers". Just like Source Control, it's a tool that solves real problems. Source Control has gotten easy enough to use that it's recommended everywhere. Docker (or some other container standard) will get there eventually.
For research apps docker would be a godsend. Resea ch software is of the "install exactly this version of x,y,z,r,g and h" and then apply these patches....
Docker is really good for dev environments. I've had a relatively painless time dockerizing snapshots of old internal web apps so I can hack on them without installing things into my main desktop environment. It lets me have lots of server things side by side.
Sorry I was wrong. I assumed based on Kubernetes' use of etcd it would be 3+ nodes. It turns out Kubernetes master is a single node currently which means they haven't built high availability into the master at all... which is a pretty scary way to run a thing that manages your entire infrastructure. There's already a few topics on the mailing list about etcd losing its data and Kubernetes doesn't know how to recover. Yuck.
Is it really more likely to believe that someone who is not otherwise in the PaaS business is going to find it easier to run 5+ nodes of other services instead of, say, two nodes running their application directly for failover/HA?
This is not to say that Kubernetes is bad but … it's a commitment which isn't appropriate for everyone. If you aren't exercising its abilities heavily, that's probably going to be a distraction from more pressing work unless you're scaling up heavily right now.
edit: I guess you can cram all of the various Kubernetes master/etcd servers on a single node but whoops there goes reliability.