As we know, that Docker Images command will list
out all of the Docker Images stored in our machine
with some basic information, such as image id,
repository name, and image tag to identify
different images. But what if we want to know more
about any particular image?
Well, for that, we have docker inspect command.
'docker inspect' command returns information about every single
Docker object who has contributed in the creation
of a particular Docker Image, which can be very
useful at the time of debugging. Let's list out
all of the Ubuntu images available on our local
machine by writing command docker images ubuntu.
Here we are, we have four ubuntu images with
different image tags under ubuntu repository.
Let's inspect ubuntu:latest Docker image,
type docker image inspect command followed by the
image name that you want to inspect. We will type
ubuntu:latest here. Press enter and as
you can see, it has displayed the detailed
information about the latest ubuntu image in JSON array.
Here we can see the extended image Id of
ubuntu:latest followed by Repo name and RepoDigests
which is the 64 digit hex number.
Next, we have Container identifier. Don't confuse it with
the container running Ubuntu image, it is the
intermediate container which Docker has created
while building the Ubuntu image from Dockerfile.
ContainerConfig is the configuration details
about the same intermediate container which is
stored as images metadata for reference.
Next is the information related to scratch image and it's
architecture which is used as the base image here.
It also mentions the actual and VirtualSize of
the final image. And at last, we have RouteFS
identifier which shows digest of all intermediate
layers of this image. If you want to access a
specific detail about an image, you can format the
output of docker inspect command, type docker inspect
followed by the format tag.
Provide arguments to format flag between inverted commas,
RepoTags and RepoDigest separated by colon.
At last, type docker image name, press enter and as
a result, we got the RepoTag and RepoDigest of ubuntu:latest.
We can also save the inspect
results of an image to a file in JSON format for
future references. Here we want to store the
configuration details about this image in a text file.
To do so, type 'docker image inspect --format',
followed by json .Config in double inverted
commas and curly braces, 'ubuntu' and store the
result in 'inspect_report_ubuntu.txt' file.
It is just a name that we have given to the file.
You can give any name which you want.
List out all of the available files.
inspect report Ubuntu has been successfully
created. Let's check out the contents of this file.
Config details about latest Ubuntu image
is available in the text file.
If you remember, RootFS identifier in the
inspection of ubuntu:latest image showed only the
digest of all intermediate layers in the image.
Based on only digests it is difficult to determine
how the image was built, for that we have docker
history command. 'docker history' will show us all
the intermediate layers of an image. Let's find
out the intermediate layers of this image.
Type 'docker image history ubuntu' in terminal, we got
all the intermediate layers for our latest Ubuntu image.
These layers are stacked sequentially,
starting from the base image at the bottom to the
CMD layer at the top of the results.
All the layers have their associated image ids, sizes and
their creation time. To dig deeper into this, let
us find history of one of the image which we have
built on our local Docker host. We will find
history of img_apache. Now type docker image history
followed by the image name, which is
img_apache and press enter. You might
be wondering why some of the rows have image
column in both the results contained missing
and some of them have their image ids. As you may
remember, the intermediate image ids are given to
the layers created by Dockerfile instructions.
And they can be used for caching purpose by our own
Docker host. But if an image is pulled from Docker
Hub, such caching would not happen and since it
may cause environmental clashes. So we are not
provided any image ids for intermediate layers
of pulled images, all we can know is they exist.
We have two types of intermediate images,
which are easy to distinguish, one, which are built
by some other Docker host and we have just used it
as base image and the ones which are committed by
our instructions. You can also identify them by
the time they were committed. The base image
intermediate layers are 17 months old,
whereas the other ones are committed just a few hours ago.