[cpuguy83]

This is very much the wrong way to approach storage (and sorry, for being so blunt, not sure how else to say it!).

Docker has support for a wide-array of storage solutions, everything from the various providers solutions (ebs, s3, gce storage, azure storage), to vsphere, netapp, scaleio, various distributed block solutions, nfs etc...

You should _not_ be changing the way you handle storage just because you are in a container. Use the tools you already have. If you need HA on a database, use the built-in replication service available on just about every database product in existence. If you really want distributed/shared storage, see the list above.

Containers are not black boxes.

[btgeekboy]

> If you need HA on a database, use the built-in replication service available on just about every database product in existence.

There are often valid reasons to not do this. For example, MySQL does not guarantee consistency between a source and its destination. mysqlrplsync can do this as a bandage, but it's something extra you need to set up and configure.

[cpuguy83]

I do not think this is a reason to not use replication. In this sense, no distributed system guarantees consistency. If a node goes down (particularly a leader!) while trying to distribute a new update, you are very likely to run into issues.

Replication != backup

[Annatar]

> You should _not_ be changing the way you handle storage just because you are in a container.

You mean exactly like zones handle it inside of SmartOS (;-))

The ZFS storage pool is abstracted away from the zone the virtual server runs on, and since it is persistent, it's completely out of the way, JustWorks(SM).