undefined | Better HN

0 pointskstenerud9y ago0 comments

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.

0 comments

4 comments · 1 top-level

toomuchtodo9y ago· 3 in thread

Unnecssesary complexity. A VM would've sufficed for what you described.

distracted_boy9y ago

What is the "Unnecssesary complexity" in this scenario? You literally just run a command and you can spin up a new container with your data.

cs02rm09y ago

I 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.

ascendantlogic9y ago

Precisely 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.

1 more reply

j / k navigate · click thread line to collapse