Should Java (fat) JARs be published before containerization?

Question

There doesn't seem to be a lot of literature around the best practices when it comes to containerization of Java applications and I'm curious as to what the logical approaches are. It used to be that we needed to setup some sort of server, configure its runtime (libraries, etc.), and deploy packaged Java applications, whether its WAR, JAR, EAR, etc., on it. This is something that is still applicable in the age of containerization, but nowadays, with the growing popularity of tools like Spring Boot, most Java apps are built into all-in-one fat JARs that contain everything needed for (isolated) execution (including usually lightweight servers).

However, I'm confused as to how the containerization assembly is usually executed. Java archives can be built in just about any fairly capable machine. The resulting package, I understand, is what we build into our Docker image for deployment. Most of the time, development teams that adopt CI/CD will have remote systems that run tests and build JARs automatically. In this kind of setup, how does the deployment container look like? Should the CI/CD system be setup to publish the fat JAR in some sort of a remote repository (e.g. Artifactory), and then have the Docker image pull from there to run? Or, does the CI/CD system be expected to containerize the resulting JAR and publish the Docker image into the registry?

Answer 1

If you want to deploy via container images, then your build process should create the images directly. It is then completely irrelevant what kind of JAR and even what kind of runtime system you are using. Since you should test the same artefact you want to deploy, all tests should then use the container and not the un-containerized JAR.

That said, fat JARs already give many of the benefits you can get through containers. If you have a JVM-based IT landscape that's not inherently better or worse than a Linux-based, containerized setup. Containers are clearly better if you need to use some kind of orchestration (e.g. Kubernetes) or if you need to package non-JVM dependencies (e.g. native services). Staying with JARs is clearly better if you will run the software on non-Linux systems, e.g. Windows or Solaris.

Answer 2

Since each Java application has unique requirements. The user should be able to specify an environment variable that defines extra parameters for the JVM (e.g. the size of the JVM Heap.) Your deployment plan should have support for such features.

JVM is not optimized for executing inside a container, which is essentially a highly-constrained Linux. The best CI/CD pipeline is run tests and if successful, upload a FAT jar to docker image and push it to Git. Then this image is pulled by your server.