⌚ About 2 min read

Linux & Docker Intermediate. 15-30 min

This BAOI guide provides a structured method for identifying what fills docker without multiplying unnecessary changes.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

1

Set perimeter

Identify the equipment, service, affected users and start time.
2

Collect Elements

Record the exact messages, logs and useful settings.
3

Test methodically

Start with the basic dependencies before the application components.
4

Apply correction

Change only the identified parameter or component.
5

Validate

Rewrite the full scenario and document the result.

Commands utiles

docker system df.

docker ps -- size

À retenir

Keep the initial values for a backwards.
Avoid multiple simultaneous changes.
Compare with a functional configuration when possible.

Technical deep dive

Docker: distinguish restart loops from storage-driver growth

Technical checkpoints

docker ps --no-trunc and docker inspect show exit code, restart policy, mounts and configuration; previous-instance logs remain essential.
overlay2 can grow due to writable layers, json-file logs and unused images; named volumes are a different data category.
Restart=always can turn an immediate failure into a loop without fixing the cause.

Docker state

Read size, logs and mounts before any prune.

docker ps -a --no-trunc
docker inspect <container>
docker system df -v

Topic-specific pitfalls

docker system prune -a can remove images required for the next deployment.
Deleting a volume to gain space can delete persistent application data.

How to validate

The container remains up across multiple cycles and its exit code/log no longer reproduces the error.
Disk growth is attributed to a specific layer/log/volume and retention is defined.

Operational context

When Docker storage grows unexpectedly, separate images, writable container layers, volumes, build cache and JSON logs before deleting anything. The largest consumer determines the safe remediation; a generic prune can remove data or artifacts still needed operationally.

Step-by-step checks

Measure filesystem usage first and confirm Docker data is actually the filesystem consumer rather than an unrelated directory.
Use Docker disk-usage reporting to split image, container, volume and build-cache consumption and identify reclaimable versus active data.
Inspect container writable sizes and log paths for unusually large active containers, then map named/anonymous volumes back to their workloads.
For overlay2 or another storage driver, investigate through Docker object ownership instead of manually deleting files under the Docker data root.

Useful verification commands

Use commands only on systems you administer and capture the read-only output before making a configuration change.

df -h

docker system df -v

docker ps --size

docker info --format "{{.DockerRootDir}} {{.Driver}}"

How to validate the result

The identified Docker object or log must explain the filesystem growth, and after an approved cleanup the expected free space should return without breaking running workloads or persistent volumes.

Evidence to keep

Keep filesystem usage before/after, docker system df output, largest container/image/volume IDs, associated workload names and any log-growth evidence.

Frequently asked question

Is docker system prune the right first step?

No. Inventory first. Prune behavior depends on options and can remove stopped containers, unused networks, images or build cache that may still matter operationally.

Related BAOI resources: IT tools · procedures · IT dictionary.