About #docker

The JVM has spoiled us with its cleverness. It makes so many decisions behind the scenes, that lots of us gave up on looking at what’s inside. Memory-related discussions are probably more likely to appear at a conference or during a job interview than at “real” work. Of course, depending on what you work on.

Java apps are often run in containers these days. Built-in container awareness makes the JVM respect various container-specific limits (e.g. CPU, memory). This means, that even when running an app with a dummy java -jar app.jar (which is usually not the best idea), everything should just work. That’s probably why the only memory-related option provided is often the -Xmx flag (or any of its equivalents). In other words, we tend to only limit the maximum heap size, like this:

At the end of 2018, I had a pleasure to give a talk at Testwarez - the oldest testing-oriented conference organized in Poland. The recording recently appeared on YouTube, so I decided to take this opportunity to figure out what has changed through the past few months in terms of tools that I presented.

The goal of my talk was to present some practices and open source tools for improving the overall security of Java-based projects. Including them as a part of the delivery pipeline (static code analysis, build process, Docker images creation, etc.) sets up a regular and automated “security audits” routine even without a dedicated security team. Please don’t get me wrong - it doesn’t mean that we don’t need pentesters (“security magicians” in general) or external audits anymore. I believe that if some of their work could be done in an automated manner every day then it should make our apps noticeably more secure and reduce the number of vulnerabilities that could be found later on.

Building docker images within the CI pipeline isn’t something new or unusual these days. Normally it’s super easy - you just have to install Docker in your Jenkins CI environment and add jenkins user to the docker group. Problems appear when your Jenkins instance is a docker container itself.

Inception begins

How to make docker available inside your container? Here is a three steps solution:

1. Install docker in your container.
2. Expose docker socket (/var/run/docker.sock) to the Jenkins container.
3. Expose host’s docker executable (/usr/bin/docker) to the container.

At this point, you should already be able to use docker inside Jenkins’ container. Nevertheless, all docker commands executing by Jenkins must start with sudo docker. That requirement has been greatly explained in Post-installation steps for Linux chapter of docker’s docs. If it fits your needs & security restriction you can stop here - but please know, that there is a better solution ;)

Two days ago I’ve participated in a JUG meeting in Poznań which special guest was famous Java rock star Adam Bien with his presentation called Microservices in 2016 — What Worked Well. The session was focused on the typical Bien’s stack: JEE microservices & Docker and overlapped with his presentation on Devoxx Poland 2016. But don’t get me wrong - it was totally worth it!

The Bien’s way

One of the most controversial topics during the session was the preffered size and the granularity of microservices. Bien’s approach is to start with a monolith app (single WAR) and split it only when you have a good reason for it (like security requirements). He typically ends up with just a few microservices (eg. about 5), that not always have to encapsulate just one feature. At the same time they should be ‘micro’ in terms of the WAR size and a minimalistic dependecy set - ideally limited only to JEE libs provided by the application server. Probably the most powerful feature of his development model is the speed - he packages and deploys WAR into dockerized application server blazingly fast (seconds!). But are his microservices really ‘micro’?

Case

Imagine the following scenario: your world-famous web application is hosted with two Docker containers (eg. with application server). Both containers have access to same host’s directories (passed with Docker’s -v parameter) mounted as:

• /configuration - containing few configuration files,
• /logs - storing log files outside containers.

Arguably, there are lots of better solutions (including databases, log indexing systems etc.) but that’s the issue we need to face now.

The following user accounts are involved:

When docker kicked in to the enterprise market many things started changing. Along with microservice-based architectures it became a must-have technology for any “modern” project (the containers idea itself isn’t new - docker has just made things much simplier). In analogy to Java related slogan from 1995 “Write once, run anywhere” almost 20 years later docker enthusiasts say: “Build once, run everywhere”. In fact both ideas can coexist easily and that’s probably one of the reason they really do in practice nowadays. However, there ain’t no such thing as a free lunch…