Open nathang21 opened 1 month ago
Hi @nathang21,
thanks for Your suggestion. Indeed, using one instance of socket-proxy for multiple services is a popular topic.
A yaml file would allow configuring this without breaking existing installations. Just give me a few days :)
Also, thanks for the list of the services you'd like to use. I only get to know how others use socket-proxy through feedback. So this is very important to me.
Fantastic, thanks for the quick turnaround. Happy to help test when the time comes if needed.
If it helps, I'm also considering to add this soon, which has a native docker service discovery integration that requires the socket as well. https://github.com/gethomepage/homepage
Thanks for the additional information. BTW, I tested homepage by myself because of a question here: https://github.com/gethomepage/homepage/discussions/3266#discussioncomment-9239716
Thanks for sharing the homepage requirements!
Just wanted to check back in, looking forward to harding my services with this.
Sorry for the delayed answer. I plan to get it done this month.
Describe the feature request Naturally many services require access to the docket socket, and while socket proxy is an excellent solution, to achieve minimal permissions for each each service would require a seperate sidecar for each. Multiple hostname support in #15 is great, but they all have to share the same permissions. While socket-proxy is very lightweight, i'm not a huge fan of running this many sidecar containers in general.
In my case I have 8 services, and would need 8 sidecars, some of these are read-only, while others also write. If interested, here are the 8 I use now:
ofelia, dozzle, watchtower, autoheal, beszel, boinc, dockwatch, portainer
.I realize supporting this would add complexity, but my ideal solution would be to have allow a separate configuration for each rest API Method on a per host (ip/hostname) basis. I suspect adjusting the configuration via environment variables or an configuration file would be required to make this maintainable.
I could imagine something like this:
Are you open to supporting this use case?