So, Docker is like your magical kitchen where you make dishes (containers) using plans (Dockerfiles) and ingredients (images) with the assistance of your kitchen helpers (Docker Engine). You can even serve entire meals (Docker Compose) and use special storage areas (volumes) and communication paths (networks) to make your dishes even more amazing. Just like a chef gets better with practice, exploring Docker will help you become a master of DevOps in no time! Now, let’s dive deeper into Docker architecture to understand its nuances!
As we already know, Docker uses the build once, run anywhere concept. Docker packages applications into images. Docker images form the blueprint of containers, so a container is an instance of an image.
A container image packages applications and their dependencies, so they are a single immutable unit you can run on any machine that runs Docker. You can also visualize them as a snapshot of the container.
We can build and store Docker images in a Docker registry, such as Docker Hub, and then download and use those images in the system where we want to deploy them. Images comprise several layers, which helps break images into multiple parts. The layers tend to be reusable stages that other images can build upon. This also means we don’t have to transmit the entire image over a network when changing images. We only transmit the delta, which saves a lot of network I/O. We will talk about the layered filesystem in detail later in this chapter.
The following diagram shows the components Docker uses to orchestrate the following activities:
Figure 4.1 – Docker architecture
The components are:
- Docker daemon: Thisprocess runs on the servers that we want to run our containers on. They deploy and run containers on the Docker server.
- Docker registries: These store and distribute Docker images.
- Docker client: This isthe command-line utility that we’ve been using to issue docker commands to the Docker daemon.
Now that we understand Docker architecture’s key components and how Docker images play an essential role, let’s understand Docker images and their components, directives, and registries in detail.
Understanding Docker images
Docker images form the blueprint of Docker containers. Just like you need a blueprint for a shipping container to determine its size and what goods it will contain, a Docker image specifies what packages, source code, dependencies, and libraries it needs to use. It also determines what it needs to do for the source code to run effectively.
Technically, it consists of a series of steps you would perform on a base OS image to get your application up and running. This may include installing packages and dependencies, copying the source code to the correct folder, building your code to generate a binary, and so on.
You can store Docker images in a container registry, a centralized location from where your Docker machines can pull images to create containers.
Docker images use a layered filesystem. Instead of a huge monolithic block on the filesystem that comprises the template to run containers, we have many layers, one on top of the other. But what does this mean? What problem does this solve? Let’s have a look in the next section.