Background Process of "Docker Pull"

Overview

The docker pull command is used to download a Docker image from a Docker registry to your local machine. By default, it pulls images from Docker Hub, the official public repository, but it can also pull from other custom registries.When you run  the docker pull  command the Docker client itself acts as the command-line interface, which sends high-level requests (like docker pull) to the Docker daemon. The daemon does the heavy lifting, coordinating all the background processes to make images and containers available for use.

What happen in the background ?

1. Client-Registry Communication Initialization

• Docker establishes a connection to the registry (e.g., Docker Hub or a custom registry) specified in the image name. If no registry is specified, Docker defaults to Docker Hub.
  
• The Docker client prepares to interact with the registry’s API, which is responsible for handling image requests and supplying metadata.

2. Image Name Parsing

• Docker parses the image name to identify four main parts:
  • Registry: The server (e.g., docker.io for Docker Hub or a custom server).
  • Repository: The organization or user owning the image (e.g., library for official images).
  • Image Name: The actual image (e.g., nginx).
  • Tag: The version of the image (e.g., latest); if not specified, Docker assumes latest.

3. Image Authentication (Optional)

• If the image is private, Docker checks for credentials. This may involve:
  • Using cached login credentials.
  • Prompting the user for a username and password.
• If credentials are valid, Docker can proceed; otherwise, the user receives an authentication error.

4. Manifest Request and Retrieval

• Docker sends a request to the registry’s API to retrieve the manifest of the image.
• The manifest is a JSON file that includes details like:
  • Layer digests (unique hashes) that identify each layer of the image.
  • Metadata such as architecture and OS compatibility.
• Docker reads this manifest to understand the structure of the image.

5. Manifest Parsing and Layer Identification

• Docker parses the manifest file to extract a list of layers.
• Each layer is identified by a unique SHA256 digest which acts as its fingerprint, allowing Docker to recognize if any layer is already stored locally.

6. Layer Check (for Local Layers)

• Docker compares each layer’s digest in the manifest against its local storage to see if the layer is already available.
• If a layer with the matching digest exists, Docker skips downloading that layer to save bandwidth and time.

7. Layer Download (for Missing Layers)

• For layers not found locally, Docker downloads them from the registry.
• Each layer is fetched individually, starting with the base layers and moving up, allowing partial images to be used in other builds if they are incomplete.

 

8. Layer Decompression

• Downloaded layers are compressed, so Docker decompresses each one as it arrives.
• Decompression converts each layer back into its original filesystem format, preparing it for use.

9. Layer Storage in Local Cache

• Docker stores each decompressed layer in a local cache directory (usually /var/lib/docker on Linux).
  

• This cache allows Docker to reuse layers across different images and avoid repeated downloads.
•  Inside this directory, each layer has its own folder. However, these are not organized by image, so navigating manually can be complex.

10. Image Assembly by Layer Stacking

• Docker assembles the image by stacking the layers in the correct order, starting from the base layer and adding each successive layer on top.
• Docker stores layers in a local directory (typically /var/lib/docker/overlay2 on Linux).
• Inside this directory, each layer has its own folder. However, these are not organized by image, so navigating manually can be complex.
  
  
  
  
  
  
• The final image’s filesystem represents all changes from each layer combined.

11. Image Tagging (Name and Version)

• Docker tags the assembled image with the specified name and version (e.g., nginx:latest).
• Tagging creates a unique reference for the image, making it easier to run or manage later.

12. Confirmation of Successful Pull

• Docker completes the pull process and confirms the image is fully downloaded and assembled.
• The image is now available locally and ready for use, and Docker outputs the image’s ID to confirm success.