Docker Architecture – A Beginners Guide
Docker Architecture is based on the client-server model. Behind this fantastic tool, there has to be an amazing, well-thought architecture. Isn’t it?
In this post, I will explain what are the main components of Docker architecture and how they work together to deliver world-class deployment solution. It is important to have a rough understanding of how the Docker platform is put together under the hood.
The heart of the Docker ecosystem is Docker Engine which gets installed on the host machine when you run a Docker installation. This engine is based on the Client-Server architecture with the below components.
- Server: A server in Docker is called daemon which runs behind the secene (the dockerd command)/.
- REST API: It provides different interfaces that programs can use to talk to the daemon and make it functional.
- CLI: Docker CLI is a command line interface which acts as a Docker client.
When we run a docker command, the Docker CLI which takes commands and send them using the REST API to Docker daemon and tell the Docker to execute the action. These commands can be a script or direct commands which daemon receive and perform actions (such as creating images, containers or networks) under the hood.
Now, let’s see what each component of the Docker architecture is and what are their responsibilities.
Docker Architecture Components
Docker client talks to the Docker daemon, which perform different actions for building, running and distributing Docker container. The Docker client and daemon can be installed on the same host machine, or you can connect to remote Docker Daemon.
Docker daemon is the hub of the Docker Engine, which controls the access to Docker on your host machine, manage the state of your containers and images and interact with the outside world.
What is Daemon?
Generally, a daemon is a process that run in the background rather than under the direct control of the user.
Docker client is the simplest component of Docker architecture. It’s what we use and run, when we send the commands like
docker run or
docker pull on our host machine. Its job is to communicate with the daemon using the REST API.
Docker registries are the locations where we save the Docker images. It can be a public repository or a private repository. Docker Hub and Docker Cloud both are the public repositories, where developers publish their Docker images which can be downloaded and used by other developers (just like GitHub for code repositories).
When we run the
docker pull command, it will pull the image from the configured repository and when we run the
docker push, it will publish the image to the configured repository.
Docker does not ship with any images by default and it is also not configured by default to use which repository. If you don’t want to use a public repository like Docker Hub, then you can set up a private registry (will be covered in the coming posts) and configure docker to communicate with it.
When we are working in the Docker environment and we use the images, containers, volumes, and networks; all of them are Docker Objects.
An image is a read-only template with some instructions in it which Docker uses to create containers. Images can be created based on an existing image (from Docker’s public repository) or you can start from scratch.
Docker uses a smartly layered filesystem for the image, the base/bottom layer is read-only while the top layer is writable. In this case, if we try to write something on the base layer, a copy of the base layer will be created on the top layer and the base layer will remain unchanged.
For example, if you want a LAMP stack running on your server, you may build an image based on the Ubuntu (or any other one), but install the Apache, PHP, MySQL and your application including the configurations required for your applications.
To build an image, all you have to do is create a Dockerfile and define all steps needed to build this image and run it. Each instruction in the Dockerfile will create a layer in the image. When we will change something in the Dockerfile and rebuild the image, only those layers that have changed are built.
After you have created your Docker image, you run the image and it will create a Docker container. All applications and configurations will run inside this container. You can use the Docker CLI to start, stop or remove containers.
You can connect to the container, add storage to it, attach storage to it or even create a new image based on this image.
Data generated and used by the Docker containers are stored in the Volumes. Docker volumes are completely manageable using Docker CLI or Docker API. We can attach volumes to Docker containers on both Windows and Linux. It is always recommended to store the persisted data in the volumes than writing to the container’s writable layer. A volume’s content exists outside of the container, which does not increase the size of a container.
Docker volumes are simply directories that are not attached to a container’s filesystem. Docker volumes provide the following advantages:
- Docker volumes can be managed using the Docker CLI or Docker API.
- Docker volumes work on both Linux and Windows operating system.
- Volumes are easier to back up or migrate.
- Volume drivers let you save volume on remote hosts or cloud providers, to encrypt the volume content.
Docker networking allows multiple containers to communicate among themselves. There are mainly five network drivers which provide core-networking functionality.
By default Docker use the Bridge driver. If you don’t specify a network drive, Docker will create the bridge network. Bridge driver can be used when the application is running on the standalone containers, i.e. multiple containers communicate with the same Docker host.
This driver removes the network isolation between Docker containers and Docker host. It is used when you don’t need any network isolation between host and containers.
Using the overlay driver, Docker connects multiple Docker daemons and enable Swarm services to communicate with each other.
What is Docker Swarm?
Docker Swarm is a clustering and scheduling tool for Docker containers, using the Docker Swarm, administrators or developers can establish and manage a cluster of Docker nodes as a single virtual system.
Overlay driver is used when the containers are running on a different host.
This driver disables all networking for a container.
Macvlan driver allows assigning a MAC address to a container, which will make it look like a physical device on your network. When using this driver, Docker daemon will route all traffic to containers using this MAC address.
In this post, we have learned how different Docker’s component works together to provide flexibility and scalability. In the coming post, I will try to explain Docker’s every component like volumes, images, networks and of course containers in more detail.