Re:Docker 1.12: Now with Built-In Orchestration
by btgeekboy on Monday June 20, 2016 @10:10PM
(#11943044)
> 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.
Re:Docker 1.12: Now with Built-In Orchestration
by cpuguy83 on Tuesday June 21, 2016 @05:38AM
(#11944584)
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
Re:Docker 1.12: Now with Built-In Orchestration
by Annatar on Tuesday June 21, 2016 @02:26AM
(#11943865)
> 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).
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.