undefined | Better HN

0 pointsotterley9y ago0 comments

Well, for one, because many database vendors won't provide support unless you're using the bits they've precompiled for you. If you think you'll never need outside help for the lifetime of your organization, then more power to you.

Another reason is that you're introducing an unnecessary dependency/component that can introduce potential instability. Common sense (since you seem to be offended by the term "best practice") and experience suggests that you should eliminate as many sources of potential instability as possible to increase the overall availability of a service or component.

0 comments

2 comments · 1 top-level

ageofwant9y ago· 1 in thread

And this is exactly why you should containerise your db's run environment with docker. Dependency management. You cannot control your host environment to the same degree you can control the docker environment, given the same amount of effort. If Oracle only supports RH6 and you use Ubuntu LTS on your host, you run it in a RH6 based container. Oh look, maybe even use the official one https://github.com/oracle/docker-images

otterleyOP9y ago

If the DB vendor is supplying and supporting the images, then that's a different story, of course. The devil is in the details, and the presence of Docker support shouldn't be interpreted to suggest that other aspects of database administration shouldn't be followed.

At any rate, at least MySQL and its Percona variant have native packages for modern mainstream Linux distributions , so as a practical matter you shouldn't need to run them in a container: they've already worked out the dependencies for you. This means you don't need to bother with the overhead of Docker.

j / k navigate · click thread line to collapse