The concrete pain is this:
I am working on multiple kgap projects on one platform/laptop -- and I have to shut down one before switching to another.
I would prefer being able to spin them all up and navigate from the one to the other easily.
This is simply caused by the fact that, even when I have independent workfolders and docker-compose files, the launched containers end up binding to the same localhost port numbers.
Surely related to #1 -- as the initial project-setup might very well be used for the assignment of environment variable settings that precisely help avoid these collisions.
But still - listing what is actually colliding is essential, and making sure the env-settings to disambiguity come into place.
List of overlapping resources I can think of already:
[ ] portnumber of graphdb at localhost (!= note the docker-internal 7200 should be kept)
[ ] portnumber of yasgui
[ ] portnumber of jupyter
[ ] repo-name in the graphdb and the connection-strings to it
Another (and additional) approach might be in documentation and suggesting quite different modes of working that single out shareable containers over projects - like graphdb for sure, but equally jupyter instance and surely the yasgui component.
The concrete pain is this: I am working on multiple kgap projects on one platform/laptop -- and I have to shut down one before switching to another. I would prefer being able to spin them all up and navigate from the one to the other easily.
This is simply caused by the fact that, even when I have independent workfolders and docker-compose files, the launched containers end up binding to the same localhost port numbers.
Surely related to #1 -- as the initial project-setup might very well be used for the assignment of environment variable settings that precisely help avoid these collisions.
But still - listing what is actually colliding is essential, and making sure the env-settings to disambiguity come into place. List of overlapping resources I can think of already:
Another (and additional) approach might be in documentation and suggesting quite different modes of working that single out shareable containers over projects - like graphdb for sure, but equally jupyter instance and surely the yasgui component.