Why use Named volume vs Anonymous volume in Docker?
-
[email protected]replied to [email protected] last edited by
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: bind
It's a bit verbose, but at least I know which folder and partition holds the data, while keeping the benefits of named volumes.
-
[email protected]replied to [email protected] last edited by
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)?
-
[email protected]replied to [email protected] last edited by
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
-
[email protected]replied to [email protected] last edited by
- 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 --all
as 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 --all
regularly 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. -
[email protected]replied to [email protected] last edited by
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.
-
[email protected]replied to [email protected] last edited by
docker compose down -v
is also fun in this context -
[email protected]replied to [email protected] last edited by
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.
-
[email protected]replied to [email protected] last edited by
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.