Container Images & Filesystems

Most important commands to remember

• docker image inspect — inspect an image’s identity and layers.
• docker diff — inspect filesystem changes made by a container.
• docker rm — remove the stopped example container.

Commands and flags

Command or syntax	Meaning
--format '{{.Id}} {{json .RootFS.Layers}}'	Print the image ID and layer identifiers using Docker’s template format.
docker run --name btc-image-lab	Create and run the named disposable container.
--pull=never	Use the local image only; fail if it is missing.
sh -c '…'	Run the quoted shell command inside the container.
printf "hello\n" > /lab.txt	Create a test file in its writable layer.
docker diff btc-image-lab	Report added, changed, and deleted filesystem paths.
docker rm btc-image-lab	Remove the stopped container and its writable layer.

The redirect targets the container’s filesystem, not a host file. No volume or host directory is mounted.

The concepts that matter

1. An image is a reusable starting filesystem and configuration

A container image supplies filesystem content and execution configuration. Image layers describe changes that combine into the filesystem a container starts with. Multiple containers can reuse the same image content.

An image tag is a name that can move to different content. An image ID or registry digest identifies content more precisely. Recording only a tag is therefore weaker evidence of what ran than recording the resolved content identity.

2. Each container gets its own writable changes

A container normally adds a writable layer above the image. Creating or changing files affects that container’s view rather than editing the reusable image for every other container.

The implementation may use copy-on-write or snapshot mechanisms depending on the engine’s storage backend. The stable concept is the separation between shared image content and a container’s changes, not one universal on-disk directory layout.

3. Stopping and removing have different storage effects

Stopping a container ends its running processes but normally retains its writable layer. Starting that same container can therefore reveal files written earlier.

Removing the container removes that layer. Starting a new container from the same image does not automatically recover the removed changes. This explains why recreating an apparently identical container can lose application data that was stored only inside it.

4. Persistent mounts have an independent lifecycle

Volumes and bind mounts place data outside the container’s ordinary writable layer. They can let data survive container replacement, but their lifetime and ownership must be managed explicitly.

A mount can also hide image content at its target path without deleting the underlying image files. Persistence is not a backup or an application-consistency guarantee. Decide separately how data is initialized, shared, protected, and recovered.

One small example

Optional: use the stated local image and test engine. Run lines individually. If image inspection or container creation fails, stop; do not inspect or remove an unrelated pre-existing container with the same name.

docker image inspect alpine:3.20 --format '{{.Id}} {{json .RootFS.Layers}}'
docker run --name btc-image-lab --pull=never alpine:3.20 sh -c 'printf "hello\n" > /lab.txt'
docker diff btc-image-lab
docker rm btc-image-lab

The shell writes /lab.txt and exits, leaving a stopped container for inspection. docker diff should include an added-path entry for that file; other runtime changes may also appear. A, C, and D mean added, changed, and deleted, not file permission modes.

The image’s recorded identity remains the starting image identity; the test file belongs to the container. The final command removes that container and its test file. It leaves the local image available. This example demonstrates the writable layer, not volume persistence or image rebuilding.

Keep this idea: An image is the reusable starting point; a container’s writable layer and its persistent mounts have different lifecycles.