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.

  • vegetaaaaaaa@lemmy.worldEnglish
    1·
    4 days ago
    • 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
    1·
    4 days ago

    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.

    • klangcola@reddthat.comOPEnglish
      0·
      4 days ago

      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.

      • ikidd@lemmy.world
        1·
        4 days ago

        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.

  • peregus@lemmy.worldEnglish
    1·
    5 days ago

    Good question, I’m interested too. Personally I use this kind of mapping

    volumes:
  - /var/docker/contanier_name/data:/data

    because it helps me with backups, while I keep all the docker-compose.yaml in /home/user/docker-compose/container_name so I can mess with the compose folder whithout worrying too much about what’s inside of it 🙈