Recently, I had a reader reach out to me wanting to understand the difference between docker build and docker-compose. In that instance, it dawned on me how confusing the whole world of containers is to new users. I remember, back when I first started working with the technology, how profoundly challenging I found it to be. With so many moving parts, it’s easy to get lost within the minutia. When you do get lost, it can be difficult to find your way back.
All you wanted to do was learn how to deploy a container to your data center. Is anything ever that simple? No. No, it’s not.
I cannot tell you how many times I’ve leaped down a rabbit hole, managed to mess up everything and had to start from scratch–only to find out it was one simple mistake I made along the way.
Or I used the wrong tool from the very beginning.
That’s just it: these tools have very specific purposes. Some of the tools have different iterations, forks, flavors or brands. You could use kubectl, minikube, or k8s.
I thought I’d do a bit of demystification for you, by way of explaining the difference between docker, docker-compose, docker swarm and Kubernetes.
SEE: Kubernetes security guide (free PDF) (TechRepublic)
A bit of a preface
You all may be asking, “Aren’t docker and docker-compose irrelevant at this point?” Given the staggering popularity of Kubernetes, you might be inclined to think that, but Docker is still around and still relevant. Even though Kubernetes might have deprecated support for Docker, there are companies and systems that still use and depend on Docker.
Even though the vast majority of enterprise businesses use Kubernetes.
With that out of the way, let’s talk about the key difference between these tools. It shouldn’t take too much of your time, so be prepared to dive in and dive out.
What is the difference between these three?
I can sum it up in a single sentence:
Docker (or specifically, the docker command) is used to manage individual containers, docker-compose is used to manage multi-container applications and Kubernetes is a container orchestration tool.
Of course, nothing is quite that simple. Docker has the built-in capability to manage a cluster of containers, by way of docker swarm. Let’s get a bit more nuanced here:
- Docker is (in many cases) the core technology used for containers and can deploy single, containerized applications
- Docker Compose is used for configuring and starting multiple Docker containers on the same host–so you don’t have to start each container separately
- Docker swarm is a container orchestration tool that allows you to run and connect containers on multiple hosts
- Kubernetes is a container orchestration tool that is similar to Docker swarm, but has a wider appeal due to its ease of automation and ability to handle higher demand
It must also be said that the biggest difference between Docker swarm and Kubernetes is the ease of use. Nothing better illustrates this than how each handles networking. When you deploy a cluster of containers with Docker swarm, those containers are typically available to your network because you’ve directed an external to an internal port from the docker command itself. In other words, you don’t have to configure a separate network layer within your YAML files.
However, with Kubernetes, you must configure a networking layer (using declarations like hostNetwork: true within a manifest). Without adding a LAN-accessible network layer within your YAML files, you won’t be able to access your containers from anywhere but the Kubernetes cluster itself.
In the end, Docker (or even Docker swarm) is far simpler than Kubernetes, but Kubernetes is far more scalable than Docker. So, let’s answer the question: When should you use docker, docker-compose or Kubernetes?
- Docker – when you want to deploy a single (network accessible) container
- Docker Compose – when you want to deploy multiple containers to a single host from within a single YAML file
- Docker swarm – when you want to deploy a cluster of docker nodes (multiple hosts) for a simple, scalable application
- Kubernetes – when you need to manage a large deployment of scalable, automated containers
And that (at least from my perspective) should help you understand the differences, similarities and use cases between these technologies.
Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.