How to see tree view of docker images?

Question

I know docker has deprecated --tree flag from docker images command. But I could not find any handy command to get same output like docker images --tree. I found dockviz. But it seems to be another container to run. Is there any built in cli command to see tree view of images without using dockviz

Answer 1

Update Nov. 2021: for online public image, you have the online service contains.dev.

Update Nov. 2018, docker 18.09.
You now have wagoodman/dive, A tool for exploring each layer in a docker image

To analyze a Docker image simply run dive with an image tag/id/digest:

dive <your-image-tag> 

or if you want to build your image then jump straight into analyzing it:

dive build -t <some-tag> . 

---

The current (Sept 2015, docker 1.8) workaround mentioned by issue 5001 remains dockviz indeed:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock nate/dockviz images -t 

The -t allows to remain in CLI only (no graphics needed)

---

Update Sept. 2016 (post docker 1.10: docker 1.11 soon 1.12), one year later, as mentioned in the same issue 5001, by Michael Härtl:

Since 1.10 the way layer IDs worked has changed fundamentally. For a lengthy explanation of this topic see #20399. There's also #20451 but I'm not sure, if this could be used by the nate/dockviz image.

Personally I find the way the new layers work very very confusing and much less transparent than before. And it's not really well documented either.
AFAIK @tonistiigi's comments in the issue above are the only public explanation available.

Tõnis Tiigi:

Pre v1.10 there was no concept of layers or the other way to think about it is that every image only had one layer. You built a chain of images and you pushed and pulled a chain. All these images in the chain had their own config.

Now there is a concept of a layer that is a content addressable filesystem diff. Every image configuration has an array of layer references that make up the root filesystem of the image and no image requires anything from its parent to run. Push and pull only move a single image, the parent images are only generated for a local build to use for the cache.

If you build an image with the Dockerfile, every command adds a history item into the image configuration. This stores to command so you can see it in docker history. As this is part of image configuration it also moves with push/pull and is included in the checksum verification.

Here are some examples of content addressable configs:
https://gist.github.com/tonistiigi/6447977af6a5c38bbed8

Terms in v1.10: (the terms really have not changed in implementation but previously our docs probably simplified things).

• Layer is a filesystem diff. Bunch of files that when stacked on top of each other make up a root filesystem. Layers are managed by graphdrivers, they don't know anything about images.

• Image is something you can run and that shows up in docker images -a. Needs to have a configuration object. When container starts it needs some kind of way to generate a root filesystem from image info. On build every Dockerfile command creates a new image.

---

You can refer to the more recent project TomasTomecek/sen, which:

• had to understand 1.10 new layer format (commit 82b224e)
• include an image tree representation: