Why use Named volume vs Anonymous volume in Docker?

[leo@sh.itjust.works]

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

[darkassassin07@lemmy.ca]

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.

[hempster@lemm.ee]

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.

[klangcola@reddthat.com]

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

[klangcola@reddthat.com]

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?

[klangcola@reddthat.com]

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.

[klangcola@reddthat.com]

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.

[klangcola@reddthat.com]

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)?

[klangcola@reddthat.com]

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

[vegetaaaaaaa@lemmy.world]

• 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.

[ikidd@lemmy.world]

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.

[spongeborgcubepants@lemmy.world]

docker compose down -v is also fun in this context

[irotsoma@lemmy.blahaj.zone]

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.

[sugar_in_your_tea@sh.itjust.works]

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.