As a developer, you are familiar with Docker. You push your images to the Hub, use Compose locally and know a thing or two about Kubernetes. Or…​ Well…​ To be honest…​ You don’t. And you are ashamed you don’t know anything about it. You browse the internet and it’s so overwhelming. So you stop looking and continue what you’ve been doing all the time. Deep inside, you still wonder. Can’t anyone not just explain Docker in simple terms? Is it really this hard? Or am I just missing something really obvious?

Kill the fear

Well my friend, I know the feeling. I have been there for some time. Most of the time the introductions are verbose or even bloody complicated. I mean, let’s quote some official documentation:

Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same ways you manage your applications.
— Docker overview

Okay, that sounds both awesome and rather difficult. You already feel like giving up, but you persevere and read the rest of that page. Sadly, it goes on rambling about the platform, the engine, the architecture, deamons, objects and a lot more. And you think:

my brain will explode

The secret to getting ahead is getting started

For me, when I picked up the Docker Mastery course[1] with Bret Fisher, I learned the basics quick enough. So I will share some thoughts about the subject. This is not a real introduction to Docker. My explanation only covers a few topics, enough to make you comfortable to get out there!

Most of the time, when you learn something new, you start with definitions or examples. So let’s do something unconventional. Let’s start with examining the logo. For once, a company does have a logo that actually describes its business. For Docker, the oldest logo does the job the best[2].

docker old logo

As you can see, there is a whale half underwater. The whale is quite big, but smiling all confidence. On it’s back above the water some containers are safely stacked. There seems no struggle, just a safe journey to bring the containers home. Now this analogy is really powerful. You want your apps safe and sound. No trouble when building them, no trouble when deploying them and no trouble when they do run. When some app depend on others, they should easily be linked to each other. And most of all, you don’t want to know how all of this is done. It should just work.

Well, as you should have guessed by now, Docker does all that. Docker is a platform to both package your apps and run those packages as well[3]. As the logo gives away, most things it does are hidden from you, so it’s not hard to start either. You actually need to know just a few things before you dive into it yourself. So stay tuned!

We learn by example

Best to show this with a little example. Let’s say you work for company 'Green energy' and you created following Java app:

class TreeMessage {

    public static void main(String[] args) {
        System.out.println("Hello World: Let's cover the world with trees!");
    }

}

Even if you don’t have Java experience, don’t worry. The app does nothing more than just printing the text "Hello World: Let’s cover the world with trees!". How cool would it be if your neighbour next door could run your app without installing Java? Or PHP, Python, Node.js, Apache, etc for all your apps written in another language? We can build the app with Java tooling. When you normally would do this a Java archive (jar) is created. The problem is you neighbour needs a Java Runtime Enviroment (JRE) to run your app. If you could wrap your executable as a standalone process with the JRE included, your neighbour should be able to run your app without installing the JRE. It would be even more awesome if this proces was kind of a 'server' itself, where your program runs on natively.

This is where Docker comes into play. Docker gives you the possibility to do just that. You can create a Docker image, what acts like a blueprint of this 'server'. The image is nothing more than all of your needed resources bundled together. After creation, you could run this image with Docker. Once the run command is given, Docker copies the data of the image, places this is a new empty container, boots up your 'server' and then starts your app. Theoretically, you could be running thousands of containers of the same image, because every time you run the image a copy is made. For those with an OOP background, think of the image as a class and the containers as instances.

Who is ready to build it step by step?

Back to our example. We define we want to use Ubuntu as operating system of our 'server'. Let’s pick one where the JRE is already installed. In this OS we should place our compiled java file. At last it would be nice if this 'server' would just boot your Java application when it starts. As it turns out, that’s just a few lines of code:

FROM sharadprsn/ubuntu-openjre11:latest

COPY /some-local-path/tree-message.jar /tree-message.jar

CMD ["java", "-jar", "tree-message.jar"]

With this file we could instruct Docker to build an image, tagged with [company-name]/[name-of-image]:

docker build -t greenenergy/tree-message

After image creation, your neighbour should be able to run this. It’s just that the image is build on your machine, where your neighbour has not access to. There is a simple solution to this problem by publishing your images online. By default, the Docker Hub is the place to be. You push your image to the Hub, so everyone can download them easily:

docker push greenenergy/tree-message

Once your image is online, all is set. Your neighbour has only to install Docker itself and run:

docker container run greenenergy/tree-message

Wooh, that last step was strange right? How is that even possible? Should your neighbour not download the image first? Well, actually if you don’t have the image locally, Docker will automatically pull the image from the Docker Hub. Once the image is available locally, it will create a container from the image, start it and run the program. After running, the program would print Hello World: Let’s cover the world with trees!.

There is always an adventure waiting in the woods

Awesome, you just learned the very basics of Docker. Although next time, I would advice you to go to your neighbours house, ring the bell and tell them vocally :D. Now you are familiar with the basics, it’s time to go out there. Doing the JCore Docker 101 Workshop would be a fine way to start.

1. Excellent course if you want to learn Docker, Compose or Swarm. The Kubernetes lessons on the other hand are rather short; if you want to learn Kubernetes, I advise you to pick another course.
2. As Docker became more mature and business like, their design became less cartoony and frivolous as well. You can read all about that right here.
3. To be honest, this is not entirely true. For a production ready solution you probably want your apps running in a Kubernetes cluster. Kubernetes works with a range of container tools, Docker just being the one commonly used.
shadow-left