8 ms·

What are the reasons for wanting to run java inside docker? The jvm is supported andavailable, and portable on every environment socket is, so what does it get

What are the reasons for wanting to run java inside docker? The jvm is supported andavailable, and portable on every environment socket is, so what does it get you?

twelve40 9y ago
if, say, zookeeper was a dependency for local development and you didn't want to go through the installation on every laptop... i guess?
- jvwilge 9y ago
  That's right and another possibility is to create a small cluster to do integration testing (on Jenkins for example). It's more easy to share containers with colleagues so you don't have to worry about about dependencies. It's also easier to limit cpu/memory in a container to check the cpu/memory requirements of your application.
codeN 9y ago
I have faced issues relating to requiring specific versions of JDK for each software. I don't work with Java so using a docker would have been a simpler solution, sadly this was before dockers became mainstream.
dagw 9y ago
Running multiple specific version of the JDK is kind of a pain. So if you are working on projects targeting specific versions of the JDK then isolating each on in its own container isn't the dumbest thing to do.
- currywurst 9y ago
  But initializing the JAVA_HOME and related env variables before launching your java process should help, right?
  - madeofpalk 9y ago
    Or, just use Docker to capture all of that :)
coldtea 9y ago
Developing/testing for multiple versions at the same time, having repeatable tests, versioning, using the same environment for development as your final deliverable (e.g. a Linux environment not OS X), being able to take your container and run it on production as is, and more things besides?
- manquer 9y ago
  wouldn't a build server be better for that sort of release testing? like travis CI / gitlab CI runner on DO / light sail etc @ $5/month
  - coldtea 9y ago
    Not all developers have access to a build server or want to bother setting up one.
  - barrkel 9y ago
    Yes; you use the build server to build the docker image, and run tests on the docker image in a test environment.
dkersten 9y ago
We run java + clojure in Docker and we do it so that we can connect all of the dependencies together with Docker-compose. We don't "develop" inside docker, but we do integration tests in docker. We also deploy (CI and prod) on docker for convenience. This setup also allows us test resiliency under bad network conditions using https://github.com/IG-Group/Havoc/ https://github.com/IG-Group/Havoc/
- rockostrich 9y ago
  This is how I like to use Docker. Especially if it's a project that I'm working on every day. Docker-compose makes running a single app and all of its dependencies locally really simple. The other use case for Docker, for me at least, is running specific versions of libraries. The other day we had a problem with npm and it was working for everyone locally. Turns out we were a few versions behind and it was much simpler to do `docker run -it node:0.12 bash` than to install the node version manager alongside my homebrew install of node.
cel1ne 9y ago
Also many common problems like targeting the correct Jdk, customize start parameters and classpath, shipping agents, selecting native libraries etc. are nowadays better solved by using capsule for packaging. It gets you a single jar without classloader interference or onejar-zipping madness It even supports automatic download of dependencies like the clojure runtime and sharing those between apps. http://www.capsule.io http://www.capsule.io
agibsonccc 9y ago
A significant amount of java apps (think finance/high frequency trading) run a ton of java native interface. A ton of microservices are built with the JVM. Turns out containers are pretty good at that as well.
- bschwindHN 9y ago
  I feel like I just read a bunch of "facts" that don't answer the question and have no real reasoning behind them.
  - agibsonccc 9y ago
    To clarify a bit - "platform dependent/hard to run code" exists in java land. Docker is good at managing native dependncies. I'm also assuming folks reading this have had some context around microservices and k8s. Microservices no matter what language are well suited to containers and container orchestration. It's a widely used pattern to have self contained services in containers with some sort of orchestration managing the containers those services are deployed in. Those "facts" were targeting an audience that have at least some familiarity with containers and the basics of the problems they solve but maybe less familiarity with the JVM (which from my experience is the typical reader on HN).
stevehiehn 9y ago
In the common and unfortunate situation where devops does not allow app developer access to prod environments containers are a dream. If the prod env is running docker your container is almost certain to work.
- coredog64 9y ago
  SOX 404 mandates segregation of duties. You literally cannot access prod if you also have access to dev. Granted, this is only for US public companies, and only for systems that are in scope for your 404 audits.
vkjv 9y ago
My primary reason is orchestration. By putting it inside Docker it runs like every other application in our Kubernetes cluster. If everything you run is Java, it might not make sense, but in a polyglot, the uniformity can be really beneficial.
tyingq 9y ago
One I've seen is less technical, and more organizational. Once it's in docker, the development team now owns things like the jvm version, command line parameters (thread pool settings, gc settings, etc). Lacking that, in some large companies, some other team has control of your environment. Silly, yes, but that is one of the bigger motivators I've seen for docker use at big companies...clawing back control.
- falcolas 9y ago
  This is both good and bad. Good for developers who can control more, bad for sysadmins who have to force JVM updates to address security vulnerabilities and inefficient settings (hello world pre-allocating 10 gigs of memory).
  - gutnor 9y ago
    Most likely, organisation that needs this kind of workaround do not have sysadmin that monitor or track JVM updates. They just have inflexible process guardian with a 2 week lead time and at least 1 man-week worth of effort on a specific budget code. Of course the only source of change request would be the developers themselves. I have seen organisation devolve like that on the database side. At one time you have a DBA team monitoring server, planning for capacity, upgrade, optimising script and owning datamodel. A few years of cost cutting and 3 guys own the datamodel of tens of application, over hundreds of servers, basically becoming a huge bottleneck for the 300+ developers. When adding a column is eating half of your project budgets and adding uncertainty on delivery date, developers become creative. The best of them sneak a way to get DBA access, the others multiplex value in existing columns (Hello, "PROPERTIES" xml column !)
  - tyingq 9y ago
    It'll come full circle soon enough. Some PHB will centralize the developers that deal with docker, and we'll start over. In the early days of Unix, there weren't sysadmins really...just one or two devs on each team that dealt with it. They were later centralized, and...seen this cycle before.

What are the reasons for wanting to run java inside docker? The jvm is supported andavailable, and portable on every environment socket is, so what does it get you?

twelve40 9y ago

if, say, zookeeper was a dependency for local development and you didn't want to go through the installation on every laptop... i guess?

jvwilge 9y ago
That's right and another possibility is to create a small cluster to do integration testing (on Jenkins for example). It's more easy to share containers with colleagues so you don't have to worry about about dependencies. It's also easier to limit cpu/memory in a container to check the cpu/memory requirements of your application.

codeN 9y ago

I have faced issues relating to requiring specific versions of JDK for each software. I don't work with Java so using a docker would have been a simpler solution, sadly this was before dockers became mainstream.

dagw 9y ago

Running multiple specific version of the JDK is kind of a pain. So if you are working on projects targeting specific versions of the JDK then isolating each on in its own container isn't the dumbest thing to do.

currywurst 9y ago
But initializing the JAVA_HOME and related env variables before launching your java process should help, right?
- madeofpalk 9y ago
  Or, just use Docker to capture all of that :)

coldtea 9y ago

Developing/testing for multiple versions at the same time, having repeatable tests, versioning, using the same environment for development as your final deliverable (e.g. a Linux environment not OS X), being able to take your container and run it on production as is, and more things besides?

manquer 9y ago
wouldn't a build server be better for that sort of release testing? like travis CI / gitlab CI runner on DO / light sail etc @ $5/month
- coldtea 9y ago
  Not all developers have access to a build server or want to bother setting up one.
- barrkel 9y ago
  Yes; you use the build server to build the docker image, and run tests on the docker image in a test environment.

dkersten 9y ago

We run java + clojure in Docker and we do it so that we can connect all of the dependencies together with Docker-compose. We don't "develop" inside docker, but we do integration tests in docker. We also deploy (CI and prod) on docker for convenience. This setup also allows us test resiliency under bad network conditions using https://github.com/IG-Group/Havoc/ https://github.com/IG-Group/Havoc/

rockostrich 9y ago
This is how I like to use Docker. Especially if it's a project that I'm working on every day. Docker-compose makes running a single app and all of its dependencies locally really simple. The other use case for Docker, for me at least, is running specific versions of libraries. The other day we had a problem with npm and it was working for everyone locally. Turns out we were a few versions behind and it was much simpler to do `docker run -it node:0.12 bash` than to install the node version manager alongside my homebrew install of node.

cel1ne 9y ago

Also many common problems like targeting the correct Jdk, customize start parameters and classpath, shipping agents, selecting native libraries etc. are nowadays better solved by using capsule for packaging. It gets you a single jar without classloader interference or onejar-zipping madness It even supports automatic download of dependencies like the clojure runtime and sharing those between apps. http://www.capsule.io http://www.capsule.io

agibsonccc 9y ago

A significant amount of java apps (think finance/high frequency trading) run a ton of java native interface. A ton of microservices are built with the JVM. Turns out containers are pretty good at that as well.

bschwindHN 9y ago
I feel like I just read a bunch of "facts" that don't answer the question and have no real reasoning behind them.
- agibsonccc 9y ago
  To clarify a bit - "platform dependent/hard to run code" exists in java land. Docker is good at managing native dependncies. I'm also assuming folks reading this have had some context around microservices and k8s. Microservices no matter what language are well suited to containers and container orchestration. It's a widely used pattern to have self contained services in containers with some sort of orchestration managing the containers those services are deployed in. Those "facts" were targeting an audience that have at least some familiarity with containers and the basics of the problems they solve but maybe less familiarity with the JVM (which from my experience is the typical reader on HN).

stevehiehn 9y ago

In the common and unfortunate situation where devops does not allow app developer access to prod environments containers are a dream. If the prod env is running docker your container is almost certain to work.

coredog64 9y ago
SOX 404 mandates segregation of duties. You literally cannot access prod if you also have access to dev. Granted, this is only for US public companies, and only for systems that are in scope for your 404 audits.

vkjv 9y ago

My primary reason is orchestration. By putting it inside Docker it runs like every other application in our Kubernetes cluster. If everything you run is Java, it might not make sense, but in a polyglot, the uniformity can be really beneficial.

tyingq 9y ago

One I've seen is less technical, and more organizational. Once it's in docker, the development team now owns things like the jvm version, command line parameters (thread pool settings, gc settings, etc). Lacking that, in some large companies, some other team has control of your environment. Silly, yes, but that is one of the bigger motivators I've seen for docker use at big companies...clawing back control.

falcolas 9y ago
This is both good and bad. Good for developers who can control more, bad for sysadmins who have to force JVM updates to address security vulnerabilities and inefficient settings (hello world pre-allocating 10 gigs of memory).
- gutnor 9y ago
  Most likely, organisation that needs this kind of workaround do not have sysadmin that monitor or track JVM updates. They just have inflexible process guardian with a 2 week lead time and at least 1 man-week worth of effort on a specific budget code. Of course the only source of change request would be the developers themselves. I have seen organisation devolve like that on the database side. At one time you have a DBA team monitoring server, planning for capacity, upgrade, optimising script and owning datamodel. A few years of cost cutting and 3 guys own the datamodel of tens of application, over hundreds of servers, basically becoming a huge bottleneck for the 300+ developers. When adding a column is eating half of your project budgets and adding uncertainty on delivery date, developers become creative. The best of them sneak a way to get DBA access, the others multiplex value in existing columns (Hello, "PROPERTIES" xml column !)
- tyingq 9y ago
  It'll come full circle soon enough. Some PHB will centralize the developers that deal with docker, and we'll start over. In the early days of Unix, there weren't sysadmins really...just one or two devs on each team that dealt with it. They were later centralized, and...seen this cycle before.