| > For that matter, you can even use ZFS for the container FS, which has been in use in production scenarios for quite some time... performance may not be great with ZFS here but integrity will be It's not a very good fit for a production database if "performance may not be great"? > (not that I'm advocating for writing directly to the container FS... not at all, really). > There is nothing about Docker and statelessness. You just recommended against storing state in the container FS on the previous line. What kind of state are you advocating a container should keep (that is different from what is captured the docker file and any separate data volumes)? > Storage is hard whether you are in a container or not. Process isolation does not affect this. But abstraction does. Normally for a database, you'd have a mirrored set of ssds, lots of ram, spread over a couple of physical nodes. Maybe with a loadbalancer thrown in. Or maybe you'd run your nodes as a vm, with iscsi or some other nas/das. I can't recall seeing reasonable advice on how to set up such a production system with docker (but I haven't looked all that hard!). Last time i checked, I couldn't find any suggestions for high-performance, well-tested container storage? |
Why would a container keep from using mirrored sets of SSDS, RAM, or an LB?
The absolute worst case you can set these up manually on your host and map the directories into the container.
A better scenario, the various storage systems (EMC, NetApp, Ceph, name it) out there have volume plugins integrating with Docker, Kub, etc.
How to handle storage in the container depends on your needs, just like as if it was VM or a physical machine... and ultimately the setup is in the worst of cases no different.