How Docker Works

Hello “👋”

Welcome to another week, another opportunity to become a Great Backend Engineer.

Today’s issue is brought to you by MasteringBackend, a great resource for backend engineers. We offer next-level backend engineering training and exclusive resources.

Before we get down to the business of today. How Docker Works.

I have a special announcement: You will love this one.

Masteringbackend is launching the beta version of its platform, which allows you to learn backend engineering in one place. The platform will help you grow your backend engineering career and turn you into a great backend engineer.

Here are some of the features:

1. Roadmaps => MB Roadmap enables a structured-based learning approach for Backend engineers.

2. Project Land => MB Projects enables backend engineers to use a learn-by-building model. Build real-world backend projects without coding the frontend.

3. Backend Portfolio => Create and manage your backend portfolio with many real-world backend projects.

4. BackLand => Learn backend engineering by solving challenges in a gamifying way.

Sound interesting?

The beta version is out for testing, reviews, and feedback.

JOIN THE PLATFORM

Reply to this email if you find anything worth reporting or if there is more feedback to help us improve.

Now, back to the business of today.

I discussed “JavaScript for Backend Engineering” in the previous edition. In this issue, I will focus on exploring How Docker Works. This will detail what Docker is; we will examine Containers and how everything comes together.

Before we explore how Docker works internally, let’s get the high-level part out. Almost everyone here has worked with Docker somehow, but only a few know how Docker works internally.

What is Docker?

Docker is an open-source platform to create, deploy, and manage virtualized application containers.

Docker is only an implementation of the concept of containerization—putting your applications inside a self-contained package while making them portable and reproducible across various environments.

Since Docker is built on top of the concept of Containerization, it would be awesome if we could elucidate Containerization a bit.

What is Containerization?

Containerization is packaging an application’s code with all the files and libraries it needs to run on any infrastructure.

You may have heard these popular words from your team members before:

“It was working on my system.”

Well, we are not shipping your system. Lol 😄 

These kinds of problems are what containerization is trying to solve: the ability to package your application with all the required dependencies to run the application on any infrastructure.

Now, your next question might be:

“If Docker is an implementation of Containerization, does it mean there are other implementations like Docker?”

Yes.

We have many different types of container implementations. Here are a few lists of Container Implementations.

• Podman

• Runc

• LXC

• Containerd

Below is a screenshot showing some of the alternatives and their differences.

Now, let’s go to the topic of today. How does Docker work behind the hood?

How Docker Works

Docker works by running and managing containers. The concept of containerization gave birth to containers, which are fundamental to the world of containerization.

A container is a runnable instance of a Docker Image. It can be created, started, stopped, moved, or deleted using the Docker CLI or other accepted clients.

You can also combine multiple containers to become one or attach one or more networks, store them, or create a new Docker Image based on the current state of the container.

Docker containers are completely isolated environments from the host machine and other containers. They are built to be lightweight, standalone, executable software packages that include everything needed to run an application, such as the codes, runtimes, system tools, system libraries, or settings.

Look at this diagram a little deeper to understand Docker containers from the ground up. Each “App” is a container that runs on Docker.

Many commands are available to manage and manipulate Docker and the containers that Docker manages.

What happens when you type in this command:

The diagram shows that Docker relies on your host operating system (Linux) and machine infrastructure.

Therefore, how does Docker handle and manage different containers efficiently?

Let’s look at the Docker Architecture:

Docker: The Architecture

Building a containerized application with Docker is easy, and that’s why it’s popular. However, an underlying architecture 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, does the heavy lifting of building, running, and distributing your Docker containers and many other Docker objects. It is a process that runs 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 bridges 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 complete the job.

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 docker pull <image> command, where <image> is the image you want to pull.

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

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

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

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.

The Docker daemon's default behavior is 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>

That’s all

The architecture that Docker builds upon makes it easy for developers to use and interact with the Docker and Docker Daemon, which do the job.

If you want to learn more about Docker and how to Dockerize applications with it, here are a few articles on our blog that you will definitely enjoy.

• The Definitive Guide to Docker → This will teach beginner-level concepts around Docker and show you how to Dockerize a JavaScript project.

• Getting Started with Docker for Python Developers → This is a beginner's guide on how Python Developers can approach and use Docker professionally.

I hope this guide gives you perspective on How Docker works behind the hood.

That will be all for this one. See you on Saturday.

Don’t forget to Sign UP for the Beta version of Masteringbackend. It comes with unmatched benefits.

DON’T LEARN ALONE. SHARE THIS NEWSLETTER WITH YOUR FRIENDS

Backend Engineering Resources

1. Backend Engineering Hub

2. All Backend Books

3. Visit our Backend Store

4. Join our Community

I moved my newsletter from Substack to Beehiiv, and it's been an amazing journey. Start yours here.