18.1.2.3 Desktop Image Inspection

Desktop image inspection covers the Dashboard's ability to visually break down an image's layer history, size contribution per layer, and embedded metadata, providing a graphical equivalent to commands like docker history and docker inspect that is generally faster to read for understanding why a given image is the size it is.

Visualizing layer-by-layer size contribution

Rather than parsing a text-based docker history output, the Dashboard's image inspection view typically presents each layer with its size visually, making it immediately apparent which specific instruction in the build contributed the most to the image's overall size:

docker history my-api:1.4.2 --no-trunc

Dashboard > Images > my-api:1.4.2 > Layers

Scanning a visual breakdown like this for the largest individual contributor is generally faster than reading through a text table, particularly for an image with many layers where the size figures need to be compared against each other to identify the actual largest contributor.

Viewing the build instruction history

Each layer in the inspection view is associated with the specific Dockerfile instruction that created it, providing a direct, readable record of exactly how the image was constructed, which is useful for understanding an image's structure without needing the original Dockerfile readily at hand:

docker history my-api:1.4.2

CREATED BY
RUN apk add --no-cache curl
COPY package*.json .
RUN npm ci

This is particularly useful when investigating an image whose original Dockerfile source is not immediately available, or when confirming that a specific instruction actually executed and produced the expected layer as part of the build.

Comparing layers between two image versions

For understanding what actually changed between two versions of the same image, comparing their layer histories side by side, where the Dashboard supports this directly, surfaces exactly which layers are shared (identical, reused from cache) versus which are genuinely new or modified between the two versions:

docker history my-api:1.4.1 --no-trunc > v1-history.txt
docker history my-api:1.4.2 --no-trunc > v2-history.txt
diff v1-history.txt v2-history.txt

Even without a dedicated side-by-side comparison feature, generating and diffing the text output of both versions' histories accomplishes the same comparison, and the Dashboard's visual layer view can make the result of that comparison easier to interpret once the actual differing layers are identified.

Viewing embedded labels and metadata

The image inspection view surfaces an image's embedded labels and other metadata directly, useful for confirming build provenance information, commit hash, build date, version, that was embedded as part of the build process:

docker inspect my-api:1.4.2 --format '{{json .Config.Labels}}'

Dashboard > Images > my-api:1.4.2 > Details

Confirming this metadata directly through the Dashboard provides a quick way to verify build provenance information without needing to construct the equivalent docker inspect command and parse its JSON output manually.

Vulnerability findings integrated per layer

Where Docker Scout integration is active, the image inspection view can attribute specific vulnerability findings to the particular layer that introduced them, which is more actionable than a flat list of vulnerabilities alone, since it directly identifies which build instruction is actually responsible for a given finding:

docker scout cves my-api:1.4.2 --format only-packages

Dashboard > Images > my-api:1.4.2 > Vulnerabilities > grouped by layer

Knowing specifically which layer, and therefore which Dockerfile instruction, introduced a given vulnerable package directs remediation effort precisely, rather than requiring a separate investigation to trace a flat vulnerability finding back to its actual source within the build.

Using image inspection to validate optimization efforts

After applying image size-reduction techniques, multi-stage builds, base image changes, dependency pruning, directly inspecting the resulting image's layer breakdown confirms the optimization actually had the intended effect, rather than assuming success based on the Dockerfile's apparent structure alone:

docker images my-api --format "{{.Tag}}: {{.Size}}"

Comparing the before-and-after layer breakdown directly through the inspection view provides concrete, visual confirmation of exactly which layers shrank or disappeared entirely as a result of a specific optimization change.

Common mistakes

• Parsing docker history text output manually when the Dashboard's visual layer breakdown would surface the same information more quickly and clearly.
• Not using layer history to investigate an image's structure when the original Dockerfile source is not readily available.
• Overlooking the ability to attribute a vulnerability finding to its specific originating layer, missing a direct path to the actual responsible build instruction.
• Assuming a size optimization had the intended effect without directly inspecting the resulting image's layer breakdown to confirm it.
• Not comparing layer histories between two image versions when investigating exactly what changed, relying instead on assumption or an incomplete review of the Dockerfile alone.

Desktop image inspection provides a visual, generally faster-to-interpret equivalent to docker history and docker inspect, making layer-by-layer size contribution, build instruction history, embedded metadata, and per-layer vulnerability attribution all directly visible within the same interface, which is particularly useful for validating size optimization efforts and tracing a specific vulnerability finding back to its actual originating build instruction.