Why use Named volume vs Anonymous volume in Docker?
-
Wow thanks for this! Reading the official docker documentation I somehow missed this. Using regular well documented linux mount.<type> tools and options will be so much better than looking for docker-specific documentation for every single type.
And knowing the docker container won't start unless the mount is available solves so much.
Does the container stop or freeze if the mount becomes unavailable? For example if the smb share host goes offline? -
Yeah that's fair, permission issues can be a pain to deal with. Guess I've been lucky I haven't had any significant issues with permissions and docker-containers specifically yet.
-
This has been my thinking too.
Though after reading mbirth's comment I realised it's possible to use named volumes and explicitly tell it where on disk to store the volume:
volumes: - my-named-volume:/data/ volumes: my-named-volume: driver: local driver_opts: type: none device: "./folder-next-to-compose-yml" # device: "/path/to/well/known/folder" o: bindIt's a bit verbose, but at least I know which folder and partition holds the data, while keeping the benefits of named volumes.
-
How does this work? Where is additional space used for cache, server or client?
Or are you saying everything is on one host at the moment, and you use NFS from the host to the docker container (on the same host)?
-
I hadn't considered giant data sets, like Jellyfin movie library, or Immich photo library. Though for Jellyfin I'd consider only the database and config as "Jellyfin data", while the movie library is its own entity, shared to Jellyfin
-
- step 1: use named volumes
- step 2: stop your containers or just wait for them to crash/stop unnoticed for some reason
- step 3: run
docker system prune --allas one should do periodically to clean up the garbage docker leaves on your system. Lose all your data (this will delete even named volumes if they are not in use by a running container) - step 4: never use named or anonymous volumes again, use bind mounts
The fact that you absolutely need to run
docker system prune --allregularly to get rid of GBs of unused layers, test containers, etc, combined with the fact that it deletes explicitely named volumes makes them too unsafe for my taste. Just use bind mounts. -
I guess on the rare occasions you need to specify the driver, this is the answer. Otherwise, it's a lot of extra work for no real benefit.
-
docker compose down -vis also fun in this context -
Yeah, the system was on a single server at first and eventually expanded to either a docker swarm or Kubernetes cluster. So the single server acts as both a docker host and an NFS server.
I've had this happen multiple times, so I use this pattern by default. Mostly these are volumes with just config files and other small stuff that it's OK if it's duplicated in the docker cache. If it is something like large image caches or videos or other volumes that I know will end up very large then I probably would have started with storage off the server in the beginning. It saves a significant amount of time to not have to reconfigure everything as it expands if I just have a template that I use from the start.
-
I also like browsing folders of data, which makes backups easy. I only use volumes for sharing incidental data between containers (e.g. certificates before I switched to Caddy, or build pipelines for my coding projects).
Use volumes if you don't care about the data long term, but you may need to share it with other containers. Otherwise, or if in doubt, use bind mounts.
-
- You can verry well share bind mounts between containers
- named volumes are actually directories too, you know? Under
/var/lib/docker/volumes/by default
Still, use bind mounts. Named or anonymous volumes are only good for temporary junk.
-
- Absolutely!
- Yes, but they get cleaned up with prune, so you could accidentally blow all your data away
