Docker — First Steps with Containers for Java Developers

At the last Java User Group meetup in Prague, someone mentioned Docker. Apparently it’s the future of deployment, apparently it changes everything. I’ll admit I was skeptical — after fifteen years in IT, I’ve heard “this changes everything” many times. But after a weekend of experimenting, I have to say: Docker is interesting. Very interesting.

What Docker Is (and Isn’t)¶

Docker is essentially lightweight virtualization at the operating system level. Instead of a full virtual machine (with its own kernel, init system, and everything), Docker creates an isolated process that shares the kernel with the host system. The result: a container starts in seconds instead of minutes, takes megabytes instead of gigabytes, and runs with minimal overhead.

It’s not truly new — Linux containers (LXC) have existed for years. What Docker added is ease of use. Dockerfile, image registry (Docker Hub), layered filesystem — all of this makes containers something any developer can handle, not just a Linux guru.

Our First Dockerfile — Java EE on Tomcat¶

We started simply. We have an internal application on Apache Tomcat 7 — a simple WAR file, a REST API for mobile clients. The Dockerfile looks surprisingly simple:

FROM tomcat:7-jre7
COPY myapp.war /usr/local/tomcat/webapps/
EXPOSE 8080
CMD ["catalina.sh", "run"]

Four lines. Building the image takes a few seconds. Starting the container takes one second. And the application runs identically on my MacBook, on my colleague’s Linux, and on the test server. “Works on my machine” is dead.

Why Docker Excited Us¶

Reproducibility. An image is immutable. What you build is what you get. No “a library is missing on the server” or “there’s a different version of Java installed”.

Isolation. Each container has its own filesystem, networking, and processes. Two containers on the same server don’t interfere with each other.

Speed. A new developer joining the team? Pull the image, docker run, and in a minute they have a running development environment. Instead of two days of laptop setup.

Why Docker Worried Us¶

Production deployment? Docker is version 0.9. Yes, zero-nine. We’re not putting that on a banking system’s production yet. Stability, security, monitoring — all of this is still in the “early adopter” stage.

Persistence. A container is ephemeral — when you stop it, data is gone. Volume mounts solve persistence, but volume management is still rudimentary. For databases in containers, I see this as a problem.

Networking. Connecting containers is easy via –link. But what about load balancing, service discovery, SSL termination? Docker doesn’t have an answer for that (yet). There are rumors about orchestration and clustering, but that’s music of the future.

Windows. Docker runs on Linux. Half our team has Windows. Boot2Docker (a VM with Linux) is a workaround, not a solution. We hope Microsoft will eventually support Docker natively.

Where We Use Docker Now¶

Exclusively in development and testing for now:

• Local development environment — full stack in docker-compose
• CI build agents — clean build environment in a container
• Demo environments for clients — quick setup on any server
• Experimenting with new technologies (Elasticsearch, MongoDB)

In production? Not yet. But we’re watching developments closely. I have a feeling that in a year or two, the situation will be different.

Docker Is Worth Your Attention¶

I’m not saying you should rewrite everything into containers tomorrow. But Docker is a technology you should know. Install it, try containerizing one of your applications, play with docker-compose. I bet it’ll get you excited.