does Docker actually clone the image
Typically no, it uses a layered filesystem, by default that's overlay2 on my systems. A decent example of this comes from the arch wiki:
- The lower directory can be read-only or could be an overlay itself.
- The upper directory is normally writable.
- The workdir is used to prepare files as they are switched between the layers.
The lower directory can actually be a list of directories separated by
:, all changes in the merged directory are still reflected in upper.
Example:
# mount -t overlay overlay -o lowerdir=/lower1:/lower2:/lower3,upperdir=/upper,workdir=/work /merged
how can I see the actual disk space used by a container?
Docker will show you the disk used by all containers in a docker system df
.
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 183 4 37.59GB 37.34GB (99%)
Containers 7 3 2.23kB 1.114kB (49%)
Local Volumes 10 1 4.816GB 305.8MB (6%)
Build Cache 511 0 20.49GB 20.49GB
For a container, this number is not static (unlike images that are read only), so I don't think this shows in any of the inspect commands. But you can see the underlying filesystems used:
$ docker container inspect 056 --format '{{json .GraphDriver}}' | jq .
{
"Data": {
"LowerDir": "/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6-init/diff:/home/docker/overlay2/22281f31287edf3342709add6123436540bd04dea60e474c961421e47b2dd58f/diff:/home/docker/overlay2/6a7a1eee38c2496928dff4741c2f9a1365f177a3e620ef7cf8adb816bba69b55/diff:/home/docker/overlay2/fcf371f07f06a42d328027281afb52c8044000cb51c4bb01a1f0dca2701062ec/diff:/home/docker/overlay2/89f8b12195e051bc439ac66d2bb299975884cdb229146dd570b1cac4011a08e6/diff:/home/docker/overlay2/d5a7a5c1c11746080d802b4dd076fd4d775099cb16b73d82c06db71e93b4e0c5/diff",
"MergedDir": "/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/merged",
"UpperDir": "/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/diff",
"WorkDir": "/home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/work"
},
"Name": "overlay2"
}
In this case, I can look at the disk usage of UpperDir to see how much space is used by that container:
$ sudo du -sh /home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/diff
80K /home/docker/overlay2/ba813e6876186f8792d263ced7dc912921870393a085644188a8adadcf73d3e6/diff
The actual disk space used by a container includes the filesystem changes made by the container, since overlay is a copy-on-write filesystem. Each file changed is first copied to the container specific filesystem, even for a timestamp, permission, or owner change to the file metadata. This allows multiple containers to use the same immutable image layers without seeing changes made by the other containers.
Docker also keeps container logs, stdout and stderr, for each container. These logs are by default unlimited.
What you won't see is a full copy of the image filesystem, unless the overlay and similar graph drivers are unavailable to the docker engine. The fallback on an unsupported host filesystem, or kernel missing the needed features, is to use the vfs
graph driver in docker, which I believe is the same as the native
snapshotter in containerd. I see this happen occasionally with a docker-in-docker build environment where you cannot run an overlay filesystem on top of the overlay container filesystem (the fix there is typically to mount a volume that is on a supported filesystem outside of the container's overlay filesystem).