Hacker News Reader

Comment by sgt | Hacker News Reader

I get Docker and I use it, but it does bother me that one bundles the JDK along with the docker image. Such a waste of space. I like this idea, I hope it gets more traction.

In terms of deployment of Java apps, we've found that Nomad works really well as it doesn't need a full Docker image (or equivalent) like Docker, Kubernetes etc. In Nomad you just make sure the worker node has the JDK, and then you specify the .jar file in the job.

View on HN

I'm not sure this is the issue you are referencing, but you can use multi-stage Docker image builds to avoid bundling the JDK in the final Docker image:

  FROM openjdk:jdk AS build
  
  COPY . .
  RUN mvn package

  FROM openjdk:jre

  COPY --from=build ./somepath/app.jar .

  CMD java app.jar

The first stage (defined by the first FROM) is only used to build the ".jar", the second stage will only contain the JRE and the ".jar" copied from the first stage.

Anything after Java 9 would have to use the jlink method, as with the new modules system, there is no longer a distinction between the JDK and JRE.

The problem is most 3rd party libraries aren't ready for the modules switchover, so for anyone using those libraries, you are stuck with having either a 3-400mb docker image or using jlink

There are “jre” images for java 10 plus that exclude the java compiler and other unnecessary JDK components, you don’t need to use modules to use this.

Sorry, I didn't intend to write "image", but rather container. I can no longer edit my comment.

I don't see what the issue is with space/size having the JDK in a docker issue layer vs installing through ansible/chef later (or whenever it is you're doing). Docker images are layered, and by including a pinned version of the JVM that's baked into a core Docker stack for your org that's been security hardened, tested, etc, seems like it's better than taking the time to install a JVM every time during deployment of the worker node.

EDIT: checking out Nomad now, since we have used other Hashicorp prods in the past...

The underlying file system might be able to dedupe the data. I remember playing around with linux containers and ZFS, where the base image was a snapshot, so only the changes to the base image take up hdd space. With modern solid state disks able to read several GB per second and with 1TB capacity, and Gbit Internet, i do not worry much if the app itself is 300MB big. If you skip the GUI the app should be fairly small - even when statically linked, then I use Linux namespaces for isolation, so no need to ship the entire OS with the app (which is a bit absurd imho. I wonder how many containers run old OS and risk container escape that would end up with root on the host, or the unnecessary extra virtualization layer killing the performance)

Docker images are layered, so this isn't a problem in most cases.

Cloud Native Buildpacks take advantage of this to isolate a JRE or JDK to its own layer for fast rebasing and high reuse[0].

[0] https://github.com/cloudfoundry/java-cnb

Yeah I meant the container i.e. the end result, not the actual image. I'm aware of layered images.

That's not the whole truth, though. If you don't tweak chroot_env in the client settings you get a whole copy of /lib, /lib64, /sbin, /usr and some other things in each allocation. So less network traffic, but uses more real estate.

> bundles the JDK

Not being pedantic, honestly - do you mean the JDK (which includes the compiler) or the JRE (just the VM)?

Reply on news.ycombinator.com