Installing Docker & your first run

hello-world, and what just happened.

How you install Docker depends on your machine. On Linux you install Docker Engine directly — it runs containers natively because the kernel is right there. On macOS and Windows you install Docker Desktop, which runs a small Linux VM under the hood (containers need a Linux kernel) and gives you the same command-line experience. Either way you end up with two pieces: a background service called the daemon, and the docker command-line client you type into.

$ docker version          # confirms the client AND the daemon are talking
Client:  version 27.1.1
Server:  Engine 27.1.1     # if Server is missing, the daemon is not running
 
$ docker info | head -4   # a summary of the running engine
 Containers: 3
 Images: 12
 Server Version: 27.1.1

Your first container

The traditional first run is hello-world, and it is worth reading what it actually does. Docker looks for the image locally, does not find it, pulls it from Docker Hub, creates a container from it, runs its one program (which prints a message), and the program exits — so the container immediately stops. That whole sequence, pull then create then run, is what every docker run does.

$ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world ... done
 
Hello from Docker!
This message shows that your installation appears to be working correctly.

Client and daemon

The docker command is only a client. It sends your instructions to the Docker daemon over a local socket, and the daemon does the real work — pulling images, creating containers, managing storage and networking. You rarely think about this split at first, but it explains later behaviour: for example, the build context is sent from the client to the daemon, and securing that daemon socket becomes a real concern in production.