Why use Named volume vs Anonymous volume in Docker?

[email protected]

Ok I did not know about this at all. I've been just mounting it on the host which has been a bit of a pain at times.

I just did a massive refactor of my stacks, but now I might have to revisit them to do this.

[email protected]

what?? im definetly using this thanks for makong me aware of it.

[email protected]

I use NFS shares for all of my volumes so they're more portable for future expansion and easier to back up. It uses additional disk space for the cache of course, but i have plenty.

When I add a second server or add a dedicated storage device as I expand, it has made it easier to move with almost no effort.

[email protected]

Dumb question… first time I’m even hearing the volume mount being referred to as “anonymous”… but is there a way to use named volume with an explicit local directory mount? I use named volumes for NFS mount when I have multiple machines, but I still have some “island” machines that’s isolated in their own region/availability zone, so they’re mounting just local directories and I use the “anonymous” volumes on those. So if I can consistently mount local directories the same way, I think it’d be a huge win for consistency.

[email protected]

There's also an NFSv4 driver which is great when you're running TrueNAS

[email protected]

I don't really have a technical reason, but I do only named volumes to keep things clear and tidy, specially compose files with databases.

When I do a backup I run a script that saves each volumes/database/compose files well organized in directories archived with tar.

In have this structure in my home directory: /home/user/docker/application_name/docker-compose.yaml and it only contains the docker-compose.yml file (some times .env/Docker file).

I dunno if this is the most efficient way or even the best way to do things but It also helps me to keep everything separate between all the necessary config files and the actual files (like for Jellyfin) and it seems easier to switch over If I only need one part and not the other (uhhr sorry for my badly worded English, I hope it makes sense).

Other than that I also like to tinker arround and learn things Adding complexity gives me some kind of challenge? XD

[email protected]

I like having everything to do with a container in one folder, so I use ./ the bind mounts. Then I don't have to go hunting all over hells half acre for the various mounts that docker makes. If I backup/restore a folder, I know I have everything to do with that stack right there.

[email protected]

I like named volumes, because all my data is in one place. Makes backups easy.

[email protected]

Supposedly docker volumes are faster than plain bind mounts; but I've not really noticed a difference.

They also allow you to use docker commands to backup and restore volumes.

Finally you can specify storage drivers, which let you do things like mount a network share (ssh, samba, nfs, etc) or a cloud storage solution directly to the container.

Personally I just use bind mounts for pretty much every bit of persistent data. I prefer to keep my compose files alongside the container data organized to my standards in an easy to find folder. I also like being able to navigate those files without having to use docker commands, and regularly back them up with borg.

[email protected]

I don't have to mess around with permissions hellhole using named volume. It is beautifully seamless with guaranteed persistence. No more messing around with PUID and PGID.

[email protected]

That makes sense. I've only ever used local storage on the docker-VM, but for sure it can make sense for using external storage

[email protected]

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?

[email protected]

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.

[email protected]

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]

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]

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]

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]

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]

docker compose down -v is also fun in this context

[email protected]

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.

agnos.is Forums

Why use Named volume vs Anonymous volume in Docker?