I really don't understand why you insist. You keep saying "best-practice" like it is a law, but the truth is there is no such thing is best. It fits our cases, worked well, continues to work well. Did I say it cannot be managed with traditional package managers? No. But I do not like upstart nor systemd, and I like the simplicty I get from Docker, and ability to replicate the almost same environment easily. I really don't care a guy on the internet that is upset because I don't follow their "best" practice. I gave you my use cases, said that Its workinng well for almost 2 years and list the advantages, you still focus on your "best" cases. It works just fine as long as you know what you are doing, and I expect to hear more justifiable and technical explanations why this should not be done, rather than your feelings and biased best practices that does not translate into any verifiable points.
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.
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
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.
Comments
I really don't understand why you insist. You keep saying "best-practice" like it is a law, but the truth is there is no such thing is best. It fits our cases, worked well, continues to work well. Did I say it cannot be managed with traditional package managers? No. But I do not like upstart nor systemd, and I like the simplicty I get from Docker, and ability to replicate the almost same environment easily. I really don't care a guy on the internet that is upset because I don't follow their "best" practice. I gave you my use cases, said that Its workinng well for almost 2 years and list the advantages, you still focus on your "best" cases. It works just fine as long as you know what you are doing, and I expect to hear more justifiable and technical explanations why this should not be done, rather than your feelings and biased best practices that does not translate into any verifiable points.
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.
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
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.