view the rest of the comments
Selfhosted
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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
If you have data else where on your server, you can use the options to volume to direct the mount there
driver: local driver_opts: type: none o: bind device: '/your/current/data'
Also reading the compose spec will help
Thanks, this looks like it'll do the job. I have not a lot of knowledge, so the specs are often a bit technical for me. I'll give it a go, thanks!
that is using bin mounts again. and i don't get why this is discouraged, i actualy do like to know where my data is stored and don't want to spin up a container that backs up using the volumes managed by docker. at that point you are using bind mounts again anyway.
regarding your original question, i don't think it is possible (or even useful) to tell docker where to store the volumes for each compose stack because you are not supposed to access the from the filesystem directly anyway.
just continue using bind mounts