Learn

Docker: run a service without owning its mess

Docker is a tool that packages a service together with its dependencies into a single image, then runs that image as an isolated container. The container shares the host's kernel but keeps its own files, libraries and processes, so the service behaves the same wherever the image runs.

At a glance

What it is
A tool that packages a service into an image and runs it as a container
Why it matters
The same image runs the same way on any host, no dependency hunting
Image vs container
An image is the frozen recipe; a container is one running copy of it
Typical role here
Starts the web server, proxy and supporting services in clean boxes
Stack

From image to running service

An image is a frozen, layered package. Docker starts a container from it, an isolated process that shares the host kernel but keeps its own files. The green band is the running service you actually use.

3
Container (one running copy) isolated files and processes, started from the image
2
Image (the frozen recipe) service plus its libraries, built once
1
Host kernel shared by every container, not duplicated

What does Docker actually do?

Docker takes a service and everything it depends on, the libraries, the runtime, the config, and freezes them into one package called an image. From that image it starts a container: a running copy of the service, isolated from the rest of the machine. The container has its own files and its own processes, but it shares the host’s kernel rather than booting a whole second operating system. That is the trade that makes it light. A virtual machine carries its own kernel; a container borrows the host’s.

The payoff is repeatability. The image you built on your laptop is the same image that runs on the server, so “it works on my machine” stops being an argument. You pull an image, you run it, and the service starts with the dependencies it was built against, not whatever happens to be installed on the host.

Image, container, what is the difference?

An image is the frozen recipe; a container is one running copy of it. You can start ten containers from the same image, throw them all away, and start ten more. The image does not change. This is why a container feels disposable: its job is to run the service, and anything you want to keep, a database, uploaded files, has to live in a volume that outlives the container. Forget that and the data goes when the container does. Docker rewards treating the running thing as replaceable and the data as the part you guard.

Check it yourself

docker ps

Lists the containers running right now, with the image each one came from. Add -a to include stopped ones.

Docker is good for

  • Shipping a service with its dependencies so it runs the same anywhere
  • Keeping unrelated services from clashing over libraries or ports
  • Tearing a service down and rebuilding it from the image cleanly
  • Pinning a known-good version so an upgrade elsewhere cannot break it

Docker will not

  • Fully isolate like a virtual machine; containers share the host kernel
  • Survive a reboot on its own; you still need a supervisor to restart it
  • Make a heavy model light; it packages the work, it does not shrink it
  • Forgive sloppy storage; data outside a volume vanishes with the container

Related terms

← All terms Reviewed: June 2026