• I tend to use /opt/[service]/, like for example /opt/forgejo/. It’s outside of any user’s Homedir and it seems to fit into what the FHS 3.0 (Filesystem Hierarchy Standard) defines.

    • 3 months

      I use /srv/[service] for services by the same logic, and leave /opt for local user apps. It’s kind of a coin toss though. On another day I night have decided differently.

    • 3 months

      I do this as well. Though if I’m deploying a stack(grafana+prometheus+cadvisor) then it all goes under a single folder like /opt/stackname/

      But if I’m running multiple services that are mostly separate or not in the same stack then they go in their own folders like /opt/nginx/ and /opt/grafana/

  • 3 months

    I have multiple compose stacks with one folder each, and they also contain all the bind volumes and any other extra files needed.

  • 3 months

    My docker mounts just point to the folder they live in.

    I’d rather have the data stored next to the config so it’s easy to find and manage.

    So a folder would be services and have a compose file, config folder, and a data folder with subdirectories per service I run. Any custom dockerfiles get a folder with their build scripts.

  • 3 months

    Bind mounts aren’t specific to Docker. You’re asking specifically about bind mounts as used by Docker?

  • along with the compose.yaml file, unless I need it in a different drive for any reason

    • 3 months

      This is me.

      For example, /srv/docker/synching contains:

      compose.yml .env ./Sync

      That last one is a directory bound to the container which contains all my sync folders.

      Occasionally it makes more sense to put the mounted folder in /srv like /srv/photos is mounted by /srv/docker/photoprism/compose.yml

      However, thats a rarity. Things mostly accessed by a single compose stack are kept alongside the other files for that stack.

  • /docker/compose/<project> for compose and env files

    /docker/data/<project> for data to be retained

    I let the docker overlay handle all the volatile data.

  • 3 months

    I use the same naming convention as you for stacks, but since I’m running a docker swarm I have to mount the NFS in the exact same way on all my nodes, which are just 3 R-Pi 4s. It’s a little janky in that if the NFS goes offline all my services go along with it. Traefik works really well with a swarm, especially when you have it set to auto pick up any services and proxy them.

  • I mount them directly from the NAS inside docker volumes.

    if there are any configuration/local data files that need to be persistent, those are usually kept in ~/project/{container}. the compose file is kept at the root project directory.

    home user is a daemon user created specifically for running docker containers that does not have root privileges.

  • 3 months

    I didn’t think much of what the “correct” location would be. But i have a general kinda everything share at /var/share/[music,books,video,user folders,repo]. And then any caching or config data sits in that dockers home folder under /etc/docker/[jellyfin,immich,kavita,etc] together with its docker-compose file. All docker services run under the group user so they all have access to the share.

  • I run a swarm and the NAS~esque machine has its exportfs entries under /export so all my docker persistence data goes into /export/docks/<stackname>/<service>/<mount>

  • 3 months

    If you using bind mounts - you are using dockers in wrong way. Use named volumes.

  • 3 months

    Xdg. Its the only attempted standard for where to put things. Persistent data in ~/.config/docker/service. Others in similar directories under ~/.local/share, ~/.cache, etx.