3 ms·

I'm still trying to wrap my head around what Docker really is, and how/when I should use it. Say, I have a JVM-based web application along with a database, lik

I'm still trying to wrap my head around what Docker really is, and how/when I should use it. Say, I have a JVM-based web application along with a database, like Play/Scala with some MySQL or H2. Is there any good reason to dockerize anything, or am I better off running them in bare form on a server? The applications themselves (or the JVM as platform) should already act as a good enough abstraction from then underlying platform, right?

dsign 8y ago
If you are going to be the only maintainer of your stack, in a single machine, and you are not going to pause your work for a few months, you don't need Docker. If you are planning to bring more developers, or there is a risk that you will have to leave the project for long enough to get some form of dependency rot, then Docker will eventually make your life much easier. Though Docker or any other container technology requires a non-trivial time investment.
crdoconnor 8y ago
It's occasionally useful when you have what I call "misbehaved" applications that have certain picky requirements regarding environment - system libraries (e.g. specific oracle version), absolute path locations, etc. and fulfilling those environmental requirements may conflict with other applications if you installed them both on the same box. Better behaved applications (statically compiled golang apps being one i guess) will not be so dependent upon a specially configured environment. I think it gained popularity originally because this is a big problem on development environments and docker was the first (possibly only) technology to really try to solve it. It doesn't solve the "works on my machine" problem and it doesn't do what it does particularly elegantly, but it gets part of the way there. I think the reason people then ported it on to production was because they liked consistency between environments, not because it is especially well suited to production environments. The creators obviously encouraged people to use it in prod (so now it's "best practice") because there's more money in your prod environment than there is in your dev environment. I still think the whole ecosystem is somewhat shoddily put together and the culture is cargo cultish, so I try to avoid it where possible.
mping 8y ago
I'll give an example: I maintain a personal clojure/angular app for my girlfriend's students. One in a blue moon she asks me to fix things. Last time I reinstalled node, and the app was written against node 0.x, now node LTS is 6 or whatever, guess what, I couldn't even build it locally. Besides, I moved the app from a couple of VPSs (linode, DO, downsized it to cut costs, etc). But because I have my build dockerized, and it's running on docker too, I was able to quickly have an environment to run it. Although docker images are not exactly reproducible ( you do apt-get update and you can get different results), its good enough. For me, it boils down to isolation and reproducible systems.

dsign 8y ago

If you are going to be the only maintainer of your stack, in a single machine, and you are not going to pause your work for a few months, you don't need Docker. If you are planning to bring more developers, or there is a risk that you will have to leave the project for long enough to get some form of dependency rot, then Docker will eventually make your life much easier. Though Docker or any other container technology requires a non-trivial time investment.

crdoconnor 8y ago

It's occasionally useful when you have what I call "misbehaved" applications that have certain picky requirements regarding environment - system libraries (e.g. specific oracle version), absolute path locations, etc. and fulfilling those environmental requirements may conflict with other applications if you installed them both on the same box. Better behaved applications (statically compiled golang apps being one i guess) will not be so dependent upon a specially configured environment. I think it gained popularity originally because this is a big problem on development environments and docker was the first (possibly only) technology to really try to solve it. It doesn't solve the "works on my machine" problem and it doesn't do what it does particularly elegantly, but it gets part of the way there. I think the reason people then ported it on to production was because they liked consistency between environments, not because it is especially well suited to production environments. The creators obviously encouraged people to use it in prod (so now it's "best practice") because there's more money in your prod environment than there is in your dev environment. I still think the whole ecosystem is somewhat shoddily put together and the culture is cargo cultish, so I try to avoid it where possible.

mping 8y ago

I'll give an example: I maintain a personal clojure/angular app for my girlfriend's students. One in a blue moon she asks me to fix things. Last time I reinstalled node, and the app was written against node 0.x, now node LTS is 6 or whatever, guess what, I couldn't even build it locally. Besides, I moved the app from a couple of VPSs (linode, DO, downsized it to cut costs, etc). But because I have my build dockerized, and it's running on docker too, I was able to quickly have an environment to run it. Although docker images are not exactly reproducible ( you do apt-get update and you can get different results), its good enough. For me, it boils down to isolation and reproducible systems.