A mount point is the target path where mounted storage appears inside a container. Use a volume mount when an application must keep data after its container is replaced: the volume is managed by Docker and has a separate lifecycle from the container. section 6.4 section 6.5
Choose the storage source to match the job:
- Use a Docker volume for application data that must survive a container upgrade. section 6.5
- Use a bind mount to make host files available in a container, such as source code being edited locally. section 6.5
- Use the container’s writable layer for disposable data, such as a cache; removing the container removes that data. section 6.5
Watch what is already at the target path. Mounting a directory over a directory from the image hides the image’s files there; it does not merge the two directories. A single-file bind mount can instead appear alongside existing files in Linux containers, but that feature is not supported in Windows Server containers. section 6.4
cd ./ch06/exercises/bind-mount # set up the paths - for Windows Server containers: $source="$(pwd)\new"; $target="C:\init" # OR for Linux containers: source="$(pwd)/new" && target='/init' docker container run diamol/ch06-bind-mount:2e docker container run ` --mount "type=bind,source=$source,target=$target" ` diamol/ch06-bind-mount:2e
Run the directory-listing image first without a mount, then with a host directory mounted at its target. Compare the listed files to see the mount hide the image’s directory contents. section 6.4
Keep a to-do list across containers
Run the to-do app image and inspect its initial tasks. Then run the same image with mounts so the list starts empty and saved tasks go to a Docker volume. This tests whether the data lives outside the container being replaced. section 6.6 section 6.1
