If I have
version: "3.8"
services:
example1:
image: example.com/example1:latest
ports: 8000:80
volumes:
- shared_example:/data
services:
example2:
image: example.com/example2:latest
ports: 8080:80
volumes:
- shared_example:/data
volumes:
shared_example:
driver_opts:
type: nfs
o: "192.100.1.100, nolock,soft,rw"
device: ":/local/shared"
Will that slow things down or is the proper solution to have
volumes:
shared_example1:
driver_opts:
type: nfs
o: "192.100.1.100, nolock,soft,rw"
device: ":/local/shared"
shared_example2:
driver_opts:
type: nfs
o: "192.100.1.100, nolock,soft,rw"
device: ":/local/shared"
Or even
volumes:
shared_example1:
shared_example2:
driver_opts:
type: nfs
o: "192.100.1.100, nolock,soft,rw"
device: ":/local/shared"
Thanks. This all came around as a result of me playing with Lidarr and Headphones. Lidarr was super slow to scan my music directory and I was already anxious about it doing too much and trying to delete my music collection. Headphones just wasn't working at all, though I've now found out that was due to its dependencies being out of date. Needless to say, I started blaming my shared volumes and trying to find a solution to a non problem. Though in doing so, I kinda liked the idea of being able to assign different references to the same volume.
What's good is that I've come away with the knowledge that I can share volumes between services without concern. It's one of those things I knew in the back of my head but never confirmed, until now.
Not necessarily without concern. Some containers have startup scripts that chown or chmod all files in some locations. It can mess up access for other containers if shared.