[kerr23]

hmm, your first complaint was that "Swarm offers no guarantees that containers will be rescheduled on the same host".

I'm saying that, if you want, you CAN make it guarantee that a container will be rescheduled to the same host. (or a controlled level of hosts).

I don't think it's docker's responsibility to solve database clustering.

And, as I said, I'm not advocating running a production DB in docker. But I can see a way that you may be able to.

[jdoliner]

I see how that was confusing. I meant that the fact that Swarm doesn't offer such a guarantee is the reason that storing the data on the host isn't a solution. My real complaint is that none of these give you a way to do persistence that doesn't destroy some other really nice properties of containers. There's lots of people trying to fix this problem the right way, Kubernetes has made a lot of progress on having volumes follow the containers around from host to host. Torus is a slightly different approach, Flocker is another one.

> I don't think it's docker's responsibility to solve database clustering.

I don't know if I'd call it a responsibility. But Docker is obviously trying to expand their platform into more and more aspects of containerization. If they figured out persistence that would really set them apart, something that this product doesn't really do. It mostly just keeps them even with Kubernetes at best. And an imitation of it at worst.

[cpuguy83]

Disagree... Also disclaimer, I work at Docker, and particularly spend a large amount of time working on storage for the docker engine.

Volumes are exactly what you should be using to have data that lives beyond the life of the container. Essentially, if you are writing to disk in your container, you should probably be writing it to a volume.

Volumes can be backed by any number of storage solutions, including from every cloud provider, various distributed block, gluster, ceph, etc...

Docker should _not_ be changing the way you run a database. If you need a highly available database, you don't use 1 database process and hope for the best, you use the built-in replication features available in just about every database product in existence today... database goes down, oh well you have a hot-standye ready.

[kerr23]

> My real complaint is that none of these give you a way to do persistence that doesn't destroy some other really nice properties of containers.

100% agree with you there.

> It mostly just keeps them even with Kubernetes at best. And an imitation of it at worst.

Personally, when I looked at kubernetes, mesos, etc and saw the xml hell that i'd be living in and said "no way".

If i have to run something as complex as those to have docker then it's not worth it to me.

When I look at the new docker swarm stuff. For the first time I think that docker is a viable thing (assuming it all works). because I'm not adding additional complexity to get my docker simplicity.

[Drdrdrq]

Not sure why you are being downvoted. My sentiment is similar... Docker's historical advantage over other solutions is easy-to-use interface ( including Dockerfile). Can't wait to try swarm out.