Ready to fully understand Docker? I just launched the Dive Into Docker course See What You'll Learn
Docker has a bunch of different tools and if you’re just getting into Docker it’s very easy to become overwhelmed. You don’t even know where to start.
The goal of this post is to identify and demystify some of Docker’s different tools so that you can at least figure out where to begin.
By the way, if you prefer learning by video, then check out the first 20 videos and 1.5 hours of my newest Dive Into Docker course for free. It covers everything in this blog post and much more.
When you hear people talk about “Docker” in general, it’s typically in reference to the Docker Engine. This is the tool that runs on Linux due to its dependence on various Linux kernel features. However, there are multiple ways to run it on OSX and Windows.
Without diving too deep, you can think of Docker Engine as the service that runs which allows you to create Docker images and run Docker containers. At its core it uses a technology called
containerd which is officially labeled as a “container runtime” by Docker but that’s an implementation detail of Docker Engine.
If you were to compare Docker to your body, Docker Engine is the brain.
If you’re running Linux, it’s quite simple. You can just use your distro’s package manager to install Docker Engine and you’re good to go. Then you’re free to install other supporting tools that we’ll go into later.
Both OSX and Windows users aren’t so lucky, but as time goes on, getting Docker to run on all major platforms is getting better and better. As of this post, there are 2 ways, both with their pros and cons.
The first method we’ll look at is called the Docker Toolbox. It is appropriately named because it’s an installation tool that pulls together a few different tools.
Those tools are:
Let’s talk about the bottom 3 tools because they are specific to the Docker Toolbox.
The gist of it is, when you install Docker Toolbox it will automatically install Virtual Box which is a tool that lets you run virtual machines. Technically Virtual Box is defined as a hypervisor if you want to get picky.
You see, when you run Docker on OSX or Windows through the Docker Toolbox, you end up running Docker inside of a Linux based virtual machine that’s managed by Virtual Box.
With the toolbox approach that is all set up and configured for you behind the scenes.
From your computer’s POV, your VM driven Docker host is another computer on your local network.
To interact with Docker from your OS, you launch a special terminal called “Docker Quickstart Terminal” which pre-configures a bunch of things for you so that you can connect to Docker running inside of a remote location (in this case, the Virtual Box driven VM).
It is considered a remote location because it’s not running directly on your OS. Even if it happens to be on your local network, from Docker’s point of view it’s still considered remote.
Kitematic is a graphical tool that lets you manage your Docker images and containers. Personally I don’t use it because I run Linux natively and I find the command line tools to be sufficient.
Kitematic is optional, but for some people it could be seen as a “nice to have” application.
The Docker team is slowly but surely improving Docker for Mac and Docker for Windows. Both are solutions that let you run Docker through OSX’ and Windows’ native hypervisors. On OSX that would be HyperKit and on Windows that’s Hyper-V.
Instead of having to lug around a clunky Virtual Box driven VM, you can just let your OS’ native hypervisor deal with things. In theory this will use less resources and be much faster.
Docker for Mac / Windows installs the following tools:
We already know what the Docker Engine is from earlier but it’s still not time to talk about Compose and Machine yet.
Instead, let’s talk about how you would interact with Docker. Instead of having to use a pre-configured terminal you can use your normal terminal.
From your Docker client’s point of view, Docker is running locally so there’s nothing special to configure.
Sounds awesome right? It is but both installation methods have their own set of pros and cons. So let’s go over that next.
Let’s talk about the elephant in the room: “What does my computer need to run either installation method?”.
You must not be running HyperKit or Hyper-V.
If you are, then you cannot use the Docker Toolbox because you cannot have Virtual Box running together with HyperKit or Hyper-V. There are hacks you can do to modify your system’s boot flags to switch between using both but that’s likely not worth the hassle.
To run HyperKit you need OSX Yosemite 10.10.3 or later with a Mac from 2010 or later due to its hardware requirements of memory management unit (MMU) virtualization, Extended Page Tables (EPT) and Unrestricted Mode.
It’s also worth noting that moving forward, Docker is only going to officially support El Capitan 10.11 and newer versions of OSX.
These stats are listed on Docker’s official Docker for Mac documentation.
To run Hyper-V you need Windows 10 Professional, Education or Enterprise. Virtualization also needs to be enabled (it probably is). These stats are listed on Docker’s official Docker for Windows documentation.
Also in case you’re wondering, no you cannot run Docker under WSL because it requires more Linux kernel features than what’s been ported to WSL so far. If you’re curious, I have a whole blog post dedicated to that among other things.
With the Docker Toolbox approach, your Docker host (the machine running Docker Engine) is ran through a VM which in turn is a computer on your local network.
This means when you read certain guides online, you may see people reference
localhost. For example, if you Dockerized a web application and the guide told you to goto
localhost:8000 you would not be able to access that if you used the Docker Toolbox approach.
Instead you would have to goto your Docker Machine’s IP address which is likely going to be
192.168.99.100:8000. We haven’t talked about what a Docker Machine is yet but we will soon.
If you used Docker for Mac / Windows you would be able to access
localhost:8000 because your Docker host is running locally.
Docker has this concept of mounting files and folders from your OS into a running container. That might not make sense to you now but it will when you start feeling the pain of your web server taking 9 seconds to reload when it should only take 1.
With Linux, it’s super fast and you can’t even notice you’re running your code inside of a Docker container but on OSX and Windows there are some performance issues.
Keep in mind, these issues are typically only in development mode where you want to mount in your source code so you can get real time feedback without having to re-build your Docker images.
Anyways, the Docker Toolbox approach seems to be a bit more polished when it comes to performance. At least that’s what I’ve heard through feedback from my students as well as reading GitHub performance related issues with Docker.
The Docker team are fully aware of this and improvements will certainly be made in due time.
I recommend going with the Docker for Mac / Windows method if your system is capable of running it. Then I would keep using it until (or if!) you run into performance related issues.
If you run into show stopping performance issues then go with the Docker Toolbox approach.
If you’re on Windows and you’re serious about Linux development you may also want to run your Linux development environment in a graphical seamless virtual machine. It’s what I’ve been doing for years and it gives you the best of both worlds because you can run Docker on Linux natively.
Now that you know how to install Docker, let’s talk about Docker Compose. It is an official Docker tool. Back in the day it used to be called “Fig”. It got so popular that the Docker team eventually took it over.
That’s a nice example of how you can build an open source tool and then end up being part of a huge project. Yay for open source.
Docker Compose lets you “compose” docker commands. This article isn’t meant to be a deep dive, but understand that at its core it lets you run more than 1 Docker container at a time.
You write a bunch of YAML to define your containers and then run a single command to run them all. I would consider it a must have tool to know and use.
Lastly (for this guide at least), there’s Docker Machine. Docker Machine is a tool that lets you create a server that’s capable of running Docker and then automatically install Docker on it.
In fact, Docker Machine is used to create the Virtual Box driven VM that runs Docker if you happen to use the Docker Toolbox.
Docker Machine was created with a lot of thought because it’s not just used to spawn Virtual Box VMs. You can use it to create hosts on cloud providers too.
That means you can run a single command to spin up a DigitalOcean or any other supported cloud provider instance and set up SSH along with installing Docker. That’s really handy.
That’s a good question. For that, I’ve prepared a free PDF guide that you can start reading right now which goes over 5 benefits of using Docker, grab it below: