<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1063935717132479&amp;ev=PageView&amp;noscript=1 https://www.facebook.com/tr?id=1063935717132479&amp;ev=PageView&amp;noscript=1 "> Taxonomy of Docker

Taxonomy of Docker

This course covers the core concepts behind containerizing an app: taxonomy, writing a Dockerfile, volumes, Compose, and secrets. All exercises run in the browser — no local Docker install required.

Docker has four core building blocks — the Dockerfile, the image, the container, and the daemon — and they're easy to confuse. The rest of this course builds on telling them apart, so it's worth getting them straight first.

The Docker daemon

When you type a docker command, you're talking to the Docker daemon (dockerd), a background process that does the actual work: building images, running containers, pulling from registries , and managing volumes. The docker CLI is just a thin client that sends it instructions. It runs in the background on your laptop and on the server in production. Knowing it exists explains why Docker commands work from any directory, and why restarting Docker Desktop fixes mysterious build errors.

The host machine

The host (or host machine) is the computer Docker runs on: your laptop in development, a server in production. The daemon, your images, and your containers all live on it. A container is isolated from the host by default, with its own filesystem and network, but the two can be connected on purpose: publishing a port (-p 3000:3000) links a host port to a container port, and mounting a volume links a host folder to a container path. When a lesson says "the host machine," it means this underlying computer, as opposed to the isolated environment inside a container.

Image vs. Container vs. Dockerfile

  • Dockerfile: a text file of instructions for building an image.
  • Image: a packaged, runnable snapshot of an application and everything it needs to run — code, runtime, config. It could be something you built from a Dockerfile, or a pre-built image pulled from a registry like Docker Hub (a database, a web server, etc.).
  • Container: a running instance of an image. Multiple containers can run at the same time — from the same image or from different images — each isolated from the others.

The part that trips people up: a Dockerfile builds an image, and an image runs as a container. Editing the Dockerfile changes nothing until you rebuild, and a rebuild doesn't touch a running container until you start a new one.

Dockerfile build instructions docker build Image read-only package docker run Container running instance
A Dockerfile builds an image. That image runs as one or many containers.

Check your understanding

Question 1 of 2

Why didn't the running app change?

You edited your Dockerfile and re-ran your app, but the behavior stayed the same. Which option best explains where Dockerfile edits take effect in Docker's build and run flow?