Reading Time: 3 minutes
In my previous blog, we had a little glimpse of what Docker is. It’s time to take one step ahead of that. Let’s understand more about Docker through its architecture.
A Quick recall
Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and ship it all out as one package.
Suppose, I have made a Java application and set up an environment with tomcat server installed in it. Now I want QA team to test it thoroughly so that I can deploy this application. So, QA team needs the same environment to run this application so they’ll have to install tomcat server. Then, wherever I have to deploy it, I’ll need to have the same environment in order to successfully run my application.
So, the same thing is done thrice which is a practical time and effort wastage.
With the help of Docker container, I can simply create a tomcat docker image that would be used by all.
The basic architecture of Docker consists of 3 major parts:
1. Docker Host
2. Docker Client
Docker uses a client-server architecture. The Docker client talks to the Docker daemon, which does the heavy lifting of the building, running, and distributing your Docker containers.
The Docker client and daemon can run on the same system, or you can connect a Docker client to a remote Docker daemon. The Docker client and daemon communicate using a REST API, over UNIX sockets or a network interface.
The Docker Host
Docker Host runs the Docker Daemon. Docker Daemon listens for Docker requests.
Docker requests could be ‘docker run’, ‘docker build’, anything.
It manages docker objects such as images, containers, networks, and volumes.
The Docker Client
Docker Client is used to trigger Docker commands. When we send any command (docker build, docker run, etc) the docker client ends these commands to Docker daemon which further will deal with them.
Note: The Docker client can communicate with more than one daemon.
The Registry is a stateless, highly scalable server-side application that stores and lets you distribute Docker images. You can create your own image or you can use public registries namely, Docker Hub and Docker Cloud. Docker is configured to look for images on Docker Hub by default.
We can create our own registry in fact.
So, when we run the command docker pull or docker run, the required images are pulled from your configured registry. When you use the docker push command, your image is pushed to your configured registry.
We will look deep into docker commands in the next blog.
Docker images, containers, networks, volumes, plugins etc are the Docker objects.
In Dockerland, there are images and there are containers. The two are closely related, but distinct. But it all starts with a Dockerfile.
A Dockerfile is a file that you create which in turn produces a Docker image when you build it. It contains a bunch of instructions which informs Docker HOW the Docker image should get built.
You can relate it to cooking. In cooking you have recipes. A recipe lets you know all of the steps you must take in order to produce whatever you’re trying to cook.
The act of cooking is building the recipe.
A Dockerfile is a recipe or a blueprint for building Docker images and the act of running a separate build command produces the Docker image from the recipe.
– Docker Images
An image is an inert, immutable, file that’s essentially a snapshot of a container. It is simply a template with instructions for creating a Docker container.
Images are stored in a Docker registry such as registry.hub.docker.com. Because they can become quite large, images are designed to be composed of layers of other images, allowing a minimal amount of data to be sent when transferring images over the network.
– Docker Containers
To use a programming metaphor, if an image is a class, then a container is an instance of a class—a runtime object. They are lightweight and portable encapsulations of an environment in which to run applications.
You can create, start, stop, move, or delete a container using the Docker API or CLI. You can connect a container to one or more networks, attach storage to it, or even create a new image based on its current state.
That was all about the architecture of Docker. Hope it helped.