Lesson 1.2: Docker Architecture Overview
Docker Architecture Overview
When you hear the term “Docker” or “Docker engine”, think of a client-server application. The server in this architecture is the Docker Host, which runs the Docker Daemon. The Docker Daemon does most of the heavy lifting and can be thought of as the brain of the Docker platform. The Docker Daemon is a long-running service that exposes an API. The API is used by the Docker Client, which as the name suggests, is the client side of the Docker engine. Some popular clients are the Docker CLI or Docker Desktop, but a client can also be an application that a developer might build to interact with Docker Daemon directly.
Let us define some more key components that form the basis of Docker’s architecture:
- Docker CLI: The command-line interface developers use to interact with the Docker Daemon. It allows users to issue commands like docker run, docker build, and docker pull to manage containers and images.
- Docker Objects:
- Docker Images: Read-only templates used to create containers. Images are built from Dockerfiles and can be stored in a Docker registry.
- Docker Containers: Instances of Docker images that are isolated and have their own file system, processes, and network.
- Volumes: Used to persist data generated by and used by Docker containers.
- Networks: Allow containers to communicate and interact with each other and external systems while being isolated.
- Docker Registry: A place to store Docker images where you can push and pull images. Docker Hub is the most commonly used public registry, but you can also have private registries.
- Dockerfile: A script containing instructions to build a Docker image.
The interaction between these components is very concise. When any docker command is executed, the Docker CLI uses the REST API to communicate with the Docker Daemon. Docker Daemon then processes this request, performing step-by-step actions such as pulling an image from a registry or starting a new container. The client-server model ensures efficient communication and management of the docker resources, whether the client and daemon are on the same host or different systems. The client and daemon communicate over a UNIX socket or a network interface, allowing Dockers diverse integration options.
Docker Daemon in Detail
The Docker Daemon is responsible for building, running, and distributing Docker containers. The Daemon listens for API requests and then processes certain commands to create or manage containers and images. This functionality allows developers to deploy applications in isolated environments, making it easier to manage dependencies and configurations. The Daemon can also communicate with other Daemons in a distributed system, facilitating orchestration tasks across multiple hosts.
Key Components Managed by Docker Daemon
Containers:
When you run commands in Docker, the Docker Daemon (dockerd) performs a series of internal operations to manage Docker objects such as containers, images, networks, and volumes.
But what exactly is happening internally?
- Command Reception: The Docker client sends a request to the Docker Daemon via the Docker API to run a new container.
- Image Check: The Daemon checks if the hello-world image is available locally. If not, it initiates a pull request to the configured Docker registry (default is Docker Hub).
- Image Pulling: If the image is not found locally, the Daemon communicates with the registry to download the image layers. Each layer is stored in the Docker storage directory (e.g., /var/lib/docker).
- Container Creation: The Daemon creates a new container instance from the image. It sets up the filesystem, environment variables, and configurations specified in the image.
- Network Setup: The Daemon assigns a network interface to the container, allowing it to communicate with other containers and the host.
- Process Initialization: The Daemon starts the container process in a new namespace, isolating it from other processes on the host. This includes setting up PID, network, and IPC namespaces.
- Detached Mode: Since d is specified, the container runs in detached mode, allowing it to operate in the background.
- State Management: The Daemon updates the container's state to "running" and monitors its health and resource usage.