What is Docker?

What is Docker?

Docker is the platform that made containers usable. Linux containers existed before Docker - the kernel features they're built on had been around for years - but they were a kit of low-level primitives no one wanted to compose by hand. Docker wrapped them in a simple CLI, a portable image format, and a hosted registry of pre-built images, and put a friendly Mac and Windows app on top. Suddenly any developer could ship a container in an afternoon.

The word "Docker" gets used three different ways in conversation, and it helps to keep them apart. Docker is the company behind it all. Docker Engine is the open-source runtime that builds and runs containers. Docker (the CLI / Desktop / Hub) is the product most people interact with. Same brand, three layers - the company stewards the runtime, the runtime powers the product.

If you've never built one before, the article on containers is the right place to start. Docker is the tool you reach for to actually do something with them.

Docker is a platform designed to help developers build, share, and run container applications.- docs.docker.com

A bit of history

Docker was released as open source in March 2013, originally as an internal tool at a small platform-as-a-service company called dotCloud. The big idea wasn't to invent containers - Linux had cgroups, namespaces, and chroot for years. The big idea was to make them so easy to use that one command and a small text file could replace days of bespoke server setup.

It worked. Within two years, Docker went from a curiosity to a default. Every major cloud added container support. Kubernetes launched in 2014 with Docker images as its unit of deployment. The Open Container Initiative formed in 2015 to standardize the image and runtime specs Docker had popularized, so any tool could build and run Docker-compatible images. Today most images you'll ever touch - even ones run by Podman, containerd, or a serverless cloud platform - are built and tagged with Docker, then handed off to whatever runtime ends up executing them.

The shorthand is this: Docker won by being a developer experience, not just a runtime. The runtime got commoditized; the experience stuck around.

The pieces of Docker

"Docker" is six tools that ship together. They share one mental model, so once you learn the CLI the rest is mostly more of the same.

You don't have to learn all six at once. Most developers start with the CLI and Desktop, pick up Hub as soon as they pull an image, and get to Compose the first time they run an app that needs a database next to it.

The Dockerfile

A Dockerfile is a small text file that describes how to build an image. Each line is an instruction - start from this base image, copy these files in, run this command - and Docker turns those instructions into a stack of layers.

Three things to know about Dockerfiles before they bite:

• Each instruction is a layer. Docker caches layers, so the next build skips any layer whose inputs haven't changed. Copying dependency manifests first and source code last means a code change doesn't bust the dependency-install cache.
• The base image matters. Starting from node:22 gives you the full Debian-based Node image (~300 MB); node:22-alpine swaps Debian for Alpine Linux (~50 MB). Smaller bases mean smaller images and faster pulls.
• CMD is the default; the user can override it. docker run myimage runs the CMD as-is; docker run myimage bash runs bash instead. ENTRYPOINT is a stricter variant that's harder to override - useful when the container always wraps the same binary.

Build, ship, run

The whole Docker workflow is three verbs the CLI makes obvious - build the image, push it to a registry, pull and run it somewhere else. The same image moves through every stage unchanged.

That's the loop. Iterate on the Dockerfile, build, run locally to test, push when you're happy, pull on the server (or in CI, or in production). One image. Same bytes everywhere.

Docker Desktop

Containers are a Linux feature. On a Mac or Windows machine - which is most developer laptops - they need a small Linux VM underneath to host the kernel they share. Docker Desktop is the app that sets that up.

It bundles four things into one installer: a lightweight Linux VM, the Docker Engine running inside it, the CLI on the host so commands feel native, and a GUI that shows running containers, images, volumes, and logs. You install Docker Desktop and a minute later docker run hello-world works.

A few things worth knowing:

• Licensing. Docker Desktop is free for personal use, education, open source, and small businesses (fewer than 250 employees and $10M annual revenue). Larger organizations need a paid subscription.
• Alternatives exist. Rancher Desktop, OrbStack (Mac-only), and Podman Desktop all run Docker-format images and the same docker CLI commands. Different VM, same images.
• Linux is direct. On a Linux developer machine you skip the VM entirely - Docker Engine runs natively on the kernel. No Desktop needed.

Docker Compose

Most real apps are more than one container. A typical stack has a frontend, an API, and a database - three services that need to start together, talk to each other, and share some configuration. Docker Compose is the YAML file that describes that whole topology and the command that runs it.

Then docker compose up starts all three together, creates a shared network so they can find each other by service name (the API connects to db, not localhost), and stays attached so you see every service's logs in one terminal. docker compose down stops them all and cleans up.

Compose is the right tool for local development. It's not designed to run production traffic - in production those same services land on Kubernetes, a serverless container platform like Azure Container Apps, or a similar orchestrator. The Compose file maps cleanly to those targets, so the local description and the production description stay in sync.

Docker today

Docker is no longer the only way to run containers - it hasn't been for years - but it's still the way most developers first meet them, and the format every other tool agreed to speak.

• The image format is a standard. The OCI image spec is what Docker built and then donated. Any compliant tool produces and consumes the same artifact.
• The runtime is unbundled. Under Docker Engine sits containerd, the actual container runtime, and it's used directly by Kubernetes and many cloud platforms. Docker is one of several front ends for it.
• Alternatives are real. Podman runs containers daemonless and with rootless defaults; Buildah builds images without a daemon; CRI-O targets Kubernetes specifically. All of them run Docker-format images.
• Docker Inc. is profitable and active. Docker Desktop, Docker Scout (image security), Docker Hub paid tiers, and Docker Hardened Images keep the company shipping. The open-source pieces continue under the Moby Project.

The takeaway for a beginner is simple. Learn Docker. The skills transfer to every container tool. The image you build with docker build will run unchanged on Kubernetes, on Cloud Run, on Azure Container Apps, on a teammate's laptop running Podman. The CLI you learn here is the CLI you'll keep using.