Understanding Docker and Containerization: An Overview

Over the last few years, I’m sure you’ve heard of Docker at some point. What is this? In this post, I aim to give you the 411, the 101, the fundamentals (or fun-for-mentals as I like to say it) on what Docker & this whole container thing.

While I’m not the first to explain this, sometimes hearing it from a different point of view gels more for you, so here’s my take. I encourage you to also read up one the great explanation by Docker: What is Docker?.

TL;DR

It’s become quite popular outside of the Windows space, but containers are rapidly coming to Windows and it’s something you simply won’t be able to avoid. Wait… that’s a bad way to look at it. I think as a developer, once you become hip to containers as a development model, you’ll come to embrace, enjoy and maybe even prefer it over the way you build applications today. But to ge there you need to understand how it works first.

What are Containers?

I think it’s fair to start with the assumption that you know what a virtual machine (VM) is. But let’s establish some stuff first:

A VM is a software implementation of an entire system… applications & operating system. A VM has no hardware… it shares that with the underlying computer it’s on. VMs usually take a few minutes to be provisioned (because they have big virtual hard drives that are tens to hundreds of GB in size) and a few minutes to spin up (because they are full blown operating systems).

You can also templatize a VM making it easy to copy it between machines or creating a new VM based on an existing template like we have in the Azure VM Gallery.

Let’s use this picture for reference. Here’s what we are used to with virtual machines (each VM is a vertical stacks of “guest OS”, “bin/libs” & “app#) image taken from the Docker site:

So what’s a container? Look at this modified diagram. Notice a few differences:

• Each container (the vertical stacks of “bin/libs” & “app #”) doesn’t have their own guest operating systems.
• The shared core is the Docker Engine which knows how to run & manage containers on the host server. This could be living on a physical server / virtual server.

Yes, the term container is borrowed from the shipping industry. By wrapping the application in a common format, anything that supports containers will be able to run it.

How is it different from a VM? Every single VM contains an OS to run the machine. However containers don’t have an OS… they rely on the host’s OS. Because they have no OS and instead rely on the underlying host’s OS, they can spin up so much faster… typically in the realm of milliseconds. The only thing the container has in it is the stuff for the process to run.

There is a bit of a lock-in here with containers. Because the container doesn’t have an OS in it and instead, it relies on the OS of the underlying hosting system, containers are only portable between environments that have the same underlying OS. Therefore you can’t build a container that’s based on Ubuntu and then try and run it on the upcoming support for Windows containers.

Docker is Containers

Docker is a technology and a business. The Docker technology is the technology that has become one of the leading container formats in the business & is backed by the company & community as its a collection of open source projects. The Docker company provides enterprise SaaS solutions around the technology such as hosting images in a repository (Docker Hub), externalized & managed orchestration (Docker Cloud) of your environments, security scanning, a brand new store (Docker Store) for getting Docker applications & their own data center product (Docker DataCenter).

Let’s compare it to the shipping business. The oceans are the physical servers & virtual machines. You can think of the oceans as one of the public clouds (Azure, AWS, GCP, Digital Ocean, etc) or your own data center. The giant ships moving containers around is Docker. It’s the engine that can move (or run) the shipping containers (or Docker containers). So as long as the oceans can support ships, we’re good.

All the public clouds have different offerings for running the Docker engine on their virtual machines, or you can get Docker and run it in your data center. You can even run it on your laptop as it’s supported on all platforms for free (Windows, MacOS, Linux… even RaspberryPi!).

What is the Experience Like?

Now that I’ve explained what it is, let’s look at a little example. Let’s say you want to build a website using containers. What’s the full story look like?

Let me explain it from a very high level. I’m not going to do a walk through of creating your first container here… there are plenty of examples around for that. Instead, I just want to give you an overview of the concepts.

Make Initial Decisions

The first step is to decide what you are based on. Will your application be hosted in Linux / Windows? There isn’t a lot of stuff out there about Windows, but it’s coming quickly once Windows Server 2016 makes it to RTM.

Once you’ve made that decision, you then decide what base image you want to start with. Will it just have be basics on it or will there be some pre-installed stuff? For instance, if you’re building a Node.js app, will you base it on the Node.js official image for v5, node:5? If Windows, what about an official one from Microsoft? Or maybe you just want to build your own? All valid choices.

Build the Application

Once you do that you then build your application. Be it a console app, be it a website or REST API or maybe it’s just a worker that spins up, does some work and goes to sleep. There isn’t really anything Docker-specific about the app… it’s just like you would do normal dev… just like you don’t do special stuff when building an app in the VM for the most part.

Create an Image

A single file, Dockerfile will tell the Docker client how to package your application up into an image. Think of this as the template for running instances.

(optional) Share the Image

While not required, you can publish your image to a trusted registry where other systems and people can easily grab your image.

Maybe it’s public for all to use or maybe it’s private for just your team. Maybe you use a trusted registry service… there are many out there, not just from Docker, but AWS, Google & many others have them… but you can also run your own if you like. It’s easy to get started because you can use the official registry container to spin your own up.

Create an Instance (Container) of your Image

Now you’re ready to run your app. Run the app from the command line by telling Docker to spin up a new instance of the container. If the image you reference isn’t already on the host, it will download it from the registry you specify (the default is the Docker Hub). It will also download the other images that your image is based on if the system hadn’t already pulled them down in the past for your image or for other images that use the same dependencies you use.

And that’s it! Cool huh? Yes, it really is that simple.

Conclusion

This post is a high-level explanation of what Docker & containers are. Hopefully, it helps some concepts gel with you if you had trouble understanding it from other people’s posts.

I plan to have a few more posts in this series on Docker so keep an eye out on this blog.