How do we know how much time it will be taken? when we pull image from repository

Hello Team,

When we pull the docker image from the repository, How do we know how much time it will be taken?
Any command like timestamp is there.
So we can know it will approx time.

You want to know how long time it takes to download an image?
This is not a feature that is present in docker.

Also it depends on your hardware, since after it downloads, it also has to extract on your host.

Is there any way we can identify it? any log is generated so we can rectify it.

If you want to predict the time required to download an image, you need to know the size of the image and the speed of the network traffic between the server and your machine. It can change any time like it changes when you download something from a webbrowser. Docker does not have this feature yet.

If you want to know the speed after downloading the image, you can try the time command on linux.

time docker pull php:5.6-fpm
5.6-fpm: Pulling from library/php
711c3a2baeda: Pull complete
0a273a3c3223: Pull complete
9dbe9d898f22: Pull complete
ac488f1008ef: Pull complete
388cbbc3d152: Pull complete
d8db1921abd4: Pull complete
5083f74b6974: Pull complete
9ddc237958ce: Pull complete
776d01e7fbc0: Pull complete
89ea877dfcd4: Pull complete
Digest: sha256:4f070f1b7b93cc5ab364839b79a5b26f38d5f89461f7bc0cd4bab4a3ad7d67d7
Status: Downloaded newer image for php:5.6-fpm
docker.io/library/php:5.6-fpm
docker pull php:5.6-fpm  0.09s user 0.07s system 1% cpu 14.333 total

The last line is the executed command and the time it took to run.

0.09s user 0.07s system 1% cpu 14.333 total

I assume you are asking because you want to minimise or you have a specific use case where this is critical ?

As others have said, a docker pull is a product of the size of the image and the speed of your connection to the repository (there is the ‘extract’ phase too, but only significant for very large images - e.g. Windows containers especially). So obviously one potential optimisation is to reduce the size of the image during build (if you are using a custom image). There are a lot of blogs you can find that provide details how to do that effectively (combining commands, multi-stage, etc, etc). If you are using images maintained by someone else (public), you may find they provide a lighter weight variant based on alpine or even scratch.

The network speed may or may not be something you can control. That said, the location of the repository could be within your gift. For example you could decide to create your own private registry on your on-premise network and use that both as a mirror cache for public images as well as the location where you publish any images that you create. Many CISO’s don’t allow pulling images from public registries/repositories, or at least not without some form of image assurance scanning in place, so this may be a requirement for your org anyway.

There are other strategies that can help you. Caching images onto nodes where they are used is certainly very doable. It’s pretty straight forwards to create automation to replicate image versions periodically across your nodes/clusters rather than pull them on-demand. Similarly for images that don’t change much you could even ‘bake’ then into the machine (VM) images that you use to create your infrastructure (unless you are solely relying on managed services).

Anyway a few ideas, most of which I’m sure you have considered.

HtHs

Fraser.