3 ms·
The vision of http://sandstorm.io http://sandstorm.io ties well into this strategy (not affiliated, I just like the idea).
by jonasvp 10y ago
The vision of http://sandstorm.io http://sandstorm.io ties well into this strategy (not affiliated, I just like the idea).
- Zelmor 10y agoThey put databases and store data in containers. What a bad idea.
- TeMPOraL 10y agoWhy?
- vetinari 10y agoContainers are supposed to be throwaway; if you need to change something inside, you rebuild it from scratch and redeploy. Hopefully, your data should not be throwaway. The common architecture is to have an application server inside container that connects to database or other persistent storage running outside containers.
- TeMPOraL 10y agoUhm. I'm not using containers much so I'm not up-to-date with best practices, but I recall a solution involving a "shared volume" for containerazed database to store data in. Is this approach wrong?
- Zelmor 10y agoYes, because when (not if) your container crashes, your data is gone.
- superuser2 10y agoNope, that is the problem that mounts and shared volumes solve. At that point you can argue there is no point in using a container, but your statement is false.
- vetinari 10y agoMounts and shared volumes are fine, if you can guarantee that the container is going to be scheduled on this specific machine, where the given filesystem lives. If you can't guarantee that, you are going into the world of NFS (which databases do not like much) or iSCSI, or, if you have distributed storage, into the world of glusterfs, ceph or something similar. It's much simpler to just set up a database server (or cluster) and live with that.