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

WHAT?

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.

WHY?

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.

Docker Architecture

The basic architecture of Docker consists of 3 major parts:
1. Docker Host
2. Docker Client
3. Registry

High-level-overview-of-Docker-architecture

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.

Docker Registries

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 Objects

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. 🙂

References:
Docker documentation
https://www.edureka.co/blog/what-is-docker-container
https://www.edureka.co/blog/docker-container/


knoldus-advt-sticker


 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s