You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
user has to define a path for the graphDB home on the host
if the user leaves the default path and starts multiple compose stacks, they may end up sharing the same graphDB home, leading to conflicts
removing or cleaning up the graphDB home is something the user has to do outside of docker/docker-compose via regular FS operations (i.e. rm -rf ...)
There will never be a use case for us to write to the graphDB home from the host computer because only the container will write to it and read from it. I.e.: as long as the container has access to the graphDB home, we don't care if the host can see this directory as well. That's exactly what docker volumes are meant to handle: https://docs.docker.com/storage/volumes/
So we should switch from bind-mounts to volumes for graphDB
Unclear documentation
No response
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
New feature
Right now, we store the graphDB home for each docker compose stack on the host FS directly via bind-mounts:
recipes/docker-compose.yml
Lines 34 to 35 in f7715a2
This causes at least these issues
rm -rf ...
)There will never be a use case for us to write to the graphDB home from the host computer because only the container will write to it and read from it. I.e.: as long as the container has access to the graphDB home, we don't care if the host can see this directory as well. That's exactly what docker volumes are meant to handle: https://docs.docker.com/storage/volumes/
So we should switch from bind-mounts to volumes for graphDB
Unclear documentation
No response
The text was updated successfully, but these errors were encountered: