this post was submitted on 01 Feb 2025
1 points (100.0% liked)

Selfhosted

46562 readers
1172 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

What are the pros and cons of using Named vs Anonymous volumes in Docker for self-hosting?

I've always used "regular" Anonymous volumes, and that's what is usually in official docker-compose.yml examples for various apps:

volumes:
  - ./myAppDataFolder:/data

where myAppDataFolder/ is in the same folder as the docker-compose.yml file.

As a self-hoster I find this neat and tidy; my docker folder has a subfolder for each app. Each app folder has a docker-compose.yml, .env and one or more data-folders. I version-control the compose files, and back up the data folders.

However some apps have docker-compose.yml examples using named volumes:

services:
  mealie:
    volumes:
      - mealie-data:/app/data/
volumes:
  mealie-data:

I had to google documentation https://docs.docker.com/engine/storage/volumes/ to find that the volume is actually called mealie_mealie-data

$ docker volume ls
DRIVER    VOLUME NAME
...
local     mealie_mealie-data

and it is stored in /var/lib/docker/volumes/mealie_mealie-data/_data

$ docker volume inspect mealie_mealie-data
...
  "Mountpoint": "/var/lib/docker/volumes/mealie_mealie-data/_data",
...

I tried googling the why of named volumes, but most answers were talking about things that sounded very enterprise'y, docker swarms, and how all state information should be stored in "the database" so you shouldnt need to ever touch the actual files backing the volume for any container.

So to summarize: Named volumes, why? Or why not? What are your preferences? Given the context that we are self-hosting, and not running huge enterprise clusters.

top 5 comments
sorted by: hot top controversial new old
[–] Semi_Hemi_Demigod@lemmy.world 1 points 3 months ago (1 children)

Named volumes let you specify more details like the type of driver to use.

For example, say you wanted to store your data in Minio, which is like S3, rather than on the local file system. You’d make a named volume and use the s3 driver.

Plus it helps with cross-container stuff. Like if you wanted sabnzbd and sonarr and radarr to use the same directory you just need to specify it once.

[–] mbirth@lemmy.ml 1 points 3 months ago (1 children)

Or just something as simple as using a SMB/CIFS share for your data. Instead of mounting the share before running your container, you can make Docker do it by specifying it like this:

services:
  my-service:
    ...
    volumes:
      - my-smb-share:/data:rw

volumes:
  my-smb-share:
    driver_opts:
      type: "smb3"
      device: "//mynas/share"
      o: "rw,vers=3.1.1,addr=192.168.1.20,username=mbirth,password=supersecret,cache=loose,iocharset=utf8,noperm,hard"

For type you can use anything you have a mount.<type> tool available, e.g. on my Raspberry this would be:

$ ls /usr/sbin/mount.*
/usr/sbin/mount.cifs*  /usr/sbin/mount.fuse3*       /usr/sbin/mount.nilfs2*  /usr/sbin/mount.ntfs-3g@  /usr/sbin/mount.ubifs*
/usr/sbin/mount.fuse@  /usr/sbin/mount.lowntfs-3g@  /usr/sbin/mount.ntfs@    /usr/sbin/mount.smb3@

And the o parameter is everything you would put as options to the mount command (e.g. in the 4th column in /etc/fstab). In the case of smb3, you can run mount.smb3 --help to see a list of available options.

Doing it this way, Docker will make sure the share is mounted before running the container. Also, if you move the compose file to a different host, it'll just work if the share is reachable from that new location.

[–] theRealBassist@lemmy.world 1 points 3 months ago

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.

[–] vegetaaaaaaa@lemmy.world 1 points 3 months ago (1 children)
  • 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.

[–] sugar_in_your_tea@sh.itjust.works 1 points 2 months ago* (last edited 2 months ago)

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.