3 ms·
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 dynamical
by jbeda 12y ago
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 https://github.com/GoogleCloudPlatform/kubernetes/issues/598
- superuser2 12y agoThis 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.
- wastedhours 12y agoThis 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.