When you build a Docker image, you're essentially creating a series of layers, each representing a step or instruction in your Dockerfile. These layers build on top of each other, forming the final image. Let's break down what the compressed and uncompressed sizes mean in this context:

Uncompressed Image Size

  • What it is: The uncompressed size represents the total size of all the layers in your Docker image as they exist on your local machine. This includes all the intermediate layers created during the build process, as well as any duplicate data that may exist across layers. Think of it as the raw, unoptimized size of your image.
  • Why it's larger: This size is usually much larger because:
    • Intermediate Layers: Docker caches intermediate layers during the build process. These layers are kept for efficiency if you rebuild the image later, but they all contribute to the total uncompressed size.
    • Duplicate Data: When you copy files into your image, Docker might create new layers even if some data is repeated from previous layers. For example, if you copy a directory in an early step and copy it again later with minor changes.
    • Unoptimized Storage: The uncompressed size doesn't take advantage of compression or any optimized storage techniques.

Compressed Image Size

  • What it is: The compressed size is the size of your Docker image after it has been processed and optimized by Docker for storage and transfer. This is the size you'll see when the image is pushed to a registry like Docker Hub or when you manually save it using docker save with compression.
  • How it's smaller: Docker applies several optimizations during this process:
    • Gzip Compression: The most significant optimization is that Docker uses gzip to compress the individual layers of your image. This significantly reduces the amount of storage space required.
    • Layer Deduplication: Docker identifies and removes duplicate data across layers. If two layers contain the same file, only one copy of the data will be stored, and layers can reference that single source.
    • Optimized Storage: Docker takes advantage of optimized storage mechanisms which only takes up space required for differences between layers and ensures it is stored efficiently.

Still Confused?

Imagine you're packing for an outing!

  • Uncompressed: This is like throwing all your clothes, toiletries, and shoes into a big suitcase without any organization. It takes up a lot of space.
  • Compressed: This is like carefully rolling up your clothes, using packing cubes to organize items, and removing any unnecessary duplicate items. The whole suitcase is now much smaller.

TL DR;

  • Local vs. Registry: The uncompressed size is what you see locally while the compressed size is what's stored and transferred to/from a container registry.
  • Transfer Efficiency: Docker optimizes images during upload to a container registry, and because of compression, downloads will also take less time.
  • True Size: The compressed size gives you a more accurate idea of the actual space your image will occupy on a registry or when you save it as a compressed archive.
  • Size Optimization Goal: When trying to optimize your docker image size, the goal is to minimize the compressed size, because that affects download and upload times, and the cost of storage in the registry.

In Summary:

The uncompressed size is a useful metric to observe the effects of your changes during the image building process. However, the compressed size is the true indicator of how large your image is when stored and transferred. It's this compressed size that you should focus on when optimizing your Docker images for better performance and efficiency.

So how to check the size?

You can check the uncompressed size by running docker image ls | grep <your_image_name> command. To check the compressed size you can either push it to DockerHub, or use command docker save <your_image_name> | gzip -c | wc -c to see compressed size in bytes.

Still confused or having doubts?
Write down in comments section!

Author Of article : Atharva Unde Read full article