Docker: The Architecture

Docker: The Architecture

Building a containerized application with Docker is easy and that’s why it’s popular. However, there underlining architecture that makes Docker super easy, and understanding these architectures can accelerate the way you build containerized applications.

Docker is designed using the client-server architecture where a client sends a request to the server and the server sends back a response to the client. The Docker client talks to the Docker daemon (server) using a REST API, over UNIX sockets or a network interface.

The engine consists of these three components:

1. Docker Daemon: The Docker Daemon (dockerd) which is the server that does the heavy lifting of building, running, and distributing your Docker containers and many other Docker objects. It is a process that keeps running in the background and waits for commands from the client.

2. Docker Client: The client (docker) is a command-line interface and the primary way users interact with Docker. When you type a Docker command like docker pull the docker client sends the command to the Docker Daemon using the Docker API for the command to be carried out.

3. Docker API (REST API): The REST API acts as a bridge between the daemon and the client. When you enter any command, the Docker Client calls out to the appropriate endpoint to communicate with the Daemon to fulfill your request.

The user executes commands using the Docker client command line and the client uses the Docker Rest API to communicate with the Docker Daemon to get the job done.

Next, let me work you through what happens when you type a Docker command in your terminal let’s say the docker run <image> command. This will help us understand the full picture of Docker.

1. When you type the command docker pull <image> command where <image> the image you want to pull.

2. The Docker client reaches out to the Docker Daemon for the image using Docker REST API.

3. The Docker Daemon reaches out for the image in your local machine repository and if not found, it will display an error like Unable to find image <image> locally.

4. Next, the Docker Daemon will look for the image in Docker Hub either a private or public repository depending on your configuration.

5. Next, the Docker Daemon will save the image in your local machine repository for subsequent requests.

6. Lastly, It will return a response containing the image while outputting the wall of text on your terminal.

It's the default behavior of the Docker daemon to look for images in the hub that are not present locally. But once an image has been fetched, it'll stay in the local cache. So if you execute the command again, you won't see the following lines in the output:

Unable to find image '<image>' locally
latest: Pulling from <image>
0e03bdcc26d7: Pull complete
Digest: sha256:d58e752213a51785838f9eed2b7a498ffa1cb3aa7f946dda11af39286c3db9a9
Status: Downloaded newer image for <image>

Docker Objects

When working with Docker, you will surely create different objects such as images, containers, networks, volumes, etc in fact, you have already seen how to pull Docker images from the Docker repository from the illustration above using the command docker pull <image>.

The Image that you pulled, created, or deleted is part of Docker Objects and in this lesson, we will learn 2 of the most used Docker objects viz:

1. Docker Images

2. Docker Containers

To learn more about other Docker Objects, explore our Docker Hub content here.