4 ms·

Unfortunately I haven't read enough 12fa, but I know I can address most of your questions with one factoid: Volumes. You are absolutely right that Docker conta

by yebyen 12y ago

Unfortunately I haven't read enough 12fa, but I know I can address most of your questions with one factoid: Volumes. You are absolutely right that Docker containers are meant to be disposable, and should not contain backing data. That is what Volumes are for. I haven't done enough with volumes to give you a real primer on the use of them, but volumes can run on whatever backing store you want and they are not so intertwined with the container that they would be deleted along with it. It looks like volumes have evolved significantly since the feature was introduced, you might want these links, sorry I haven't reviewed them myself: https://docs.docker.com/userguide/dockervolumes/ https://docs.docker.com/userguide/dockervolumes/ http://crosbymichael.com/advanced-docker-volumes.html http://crosbymichael.com/advanced-docker-volumes.html (I actually do keep my backing data in the containers, we have institutionalized backups where all of the important data is already kept in git anyway, so instance clones are in fact disposable for me even though they have all of the important backing data in them.)

pas 12y ago
I'm familiar with volumes, and here's how I see the problem: On a docker host you have the docker daemon, and whatever auxiliary stuff you need to orchestrate either the containers or the host (update docker itself, and so on), you have space for /var/lib/docker, and that's it. Volumes are always somewhere on /host/data. That means you have to make up a scheme and convention, and cook up scripts and add it to your already quite dynamic mental model. If you go and want to manage volumes, you need something for that. And currently everyone and their cats have their own solutions (because there is one they claim to use and one they use, and one they hack on to use later). I'm not claiming it's a hard problem, just that it's not taken care of yet. Maybe Flocker will deliver, I haven't checked it since it was posted 5 minutes ago :)
- nl 12y ago
  Yeah, the problem isn't that you can't do it. The problem is there are too many ways that mostly do what you need.

by yebyen 12y ago

pas 12y ago

I'm familiar with volumes, and here's how I see the problem: On a docker host you have the docker daemon, and whatever auxiliary stuff you need to orchestrate either the containers or the host (update docker itself, and so on), you have space for /var/lib/docker, and that's it. Volumes are always somewhere on /host/data. That means you have to make up a scheme and convention, and cook up scripts and add it to your already quite dynamic mental model. If you go and want to manage volumes, you need something for that. And currently everyone and their cats have their own solutions (because there is one they claim to use and one they use, and one they hack on to use later). I'm not claiming it's a hard problem, just that it's not taken care of yet. Maybe Flocker will deliver, I haven't checked it since it was posted 5 minutes ago :)

nl 12y ago
Yeah, the problem isn't that you can't do it. The problem is there are too many ways that mostly do what you need.