[cpuguy83]

I would not run a database on swarm. It simply does not have the right api's at the cluster level to properly express state requirements.

The original swarm design had some of this but it was pulled just before release for more design work... which was never completed.

I wrote the only storage support currently in swarm, which is the "mounts" api in your service spec...

So, technically you could use swarm to do it, but it will be painful and I don't think any amount of tooling will help until docker includes some support for cluster-aware storage.

I would be happy to hear if people have successfully done this, though!

[mosselman]

Thank you for your reply. Do I understand correctly that the biggest issue is the fact that containers won't run on the same node and you'd thus have storage issues? Would these issues be (partially) mitigated if you'd run postgres on a single node?

[keypusher]

If you are running multiple copies of postgres on a single node, then you have not significantly improved the resiliency of your database to failure, and it still does not solve the state transition problem. What happens when the primary database fails (or the node dies)? Whether it is on this node or another node, you need to have a replica (sync or async) that you can fail over to, preferably in an automated way. Docker swarm is not equipped to handle these transitions for you, at which point you are just running your database in Docker, with no real benefit over running it on actual hardware or a VM, and with significant added complexity.

[cpuguy83]

If you can express your storage requirements via the existing mounts api, then yeah it's all possible.

The thing to remember is mounts are implemented only at the node level, so there is no cluster-aware storage controller.