4 ms·
I'm still not sure I follow. If you're not setting up a DB that will have such heavy usage that it needs bare metal access, what's wrong with setting it up such
by kstenerud 10y ago
I'm still not sure I follow. If you're not setting up a DB that will have such heavy usage that it needs bare metal access, what's wrong with setting it up such that it stores data on a NAS, or via mounted volumes? Then when it comes time to upgrade due to a security issue, you can create a new container, spin it up, and if it barfs, relaunch the old one.
- toomuchtodo 10y agoUnnecssesary complexity. A VM would've sufficed for what you described.
- cs02rm0 10y agoI find VMs are super slow for development purposes (I mean setup, starting up and shutting down rather than actual processing), where docker's made a massive difference. YMMV especially if you're not spinning up new projects frequently. They might be a better solution in production, but I have a strong preference for production mimicking development.
- ascendantlogic 10y agoPrecisely the point. It's fine in dev but once you are running in prod and need rock solid stability the generally accepted dogma is that containerizing your DB is playing with fire. As you said, YMMV.
- deleted 10y ago[deleted]
- distracted_boy 10y agoWhat is the "Unnecssesary complexity" in this scenario? You literally just run a command and you can spin up a new container with your data.