Demystifying Docker Architecture: Images, Containers, and Docker‑Machine

In the previous article we introduced Docker concepts and possible front‑end use cases; here we outline Docker's architecture.

After a teammate Xiao Ming successfully ran a "Hello world" container, he wanted to understand terms like image, container, registry, and machine.

Q1: Why does Docker on macOS require VirtualBox? Docker builds on Linux kernel features such as cgroups and namespace. It is essentially an enhanced LXC implementation that adds portability, version control, and Docker Hub sharing. Because Docker relies on these Linux kernel features, it can run natively only on Linux; on macOS or Windows it needs a Linux VM, typically provided by VirtualBox.

Thus Docker runs only on Linux, and on other operating systems an additional Linux environment is required.

Q2: What does docker‑machine do? Since Docker runs only on Linux, the original "run anywhere" promise would be broken. The boot2docker tool was created, consisting of a tiny Core Linux ISO image and a management utility, allowing Docker to run on macOS and Windows. However, boot2docker only supports VirtualBox and cannot be used in cloud environments like AWS, Azure, or VMware.

The docker‑machine tool extends boot2docker, enabling Docker installation in many more places by automating VM creation and configuration. Officially, the Docker engine itself is referred to as docker‑engine.

Q3: What happens when you run docker run hello‑world ? The process is:

Create a VM with docker‑machine create -d virtualbox default.

Start the VM with docker‑machine start default.

Set environment variables (required for docker‑machine) using eval "$(docker‑machine env default)".

Execute docker run hello‑world.

The command tells Docker to start a container from the hello‑world image. Docker follows a client‑server model: the Docker client contacts the Docker daemon, which pulls the image from Docker Hub if not present locally, creates a container, runs the executable, and streams the output back to the client.

Images are read‑only templates (similar to classes) that can contain a full OS and applications; containers are instances of these images. Docker first checks for the image locally, then pulls it from Docker Hub if missing.

For more details on image operations see the official documentation https://docs.docker.com/engine/userguide/dockerimages/ . Images also have a layered filesystem, as illustrated below.

Further topics include building images with Dockerfile, managing images, and creating private registries.

In summary, Docker follows a client‑server architecture: the client sends commands to the daemon, which performs actions such as pulling images and running containers. When you execute docker run, Docker checks for the image locally, pulls it from Docker Hub if necessary, creates a container, and runs the specified program.