How severe does this issue affect your experience of using Ray?
- Medium: It contributes to significant difficulty to complete my task, but I can work around it.
I’m trying to ensure that the Dashboard on the head node is easily accessible by others and so far the best way I have found is through port fwd. This is less than ideal and not realistic in enterprise scenarios.
Would love to hear if others have solved for this and how.
One idea: The dashboard UI can be hosted separately from a CDN or basic static file server. Then, the API can be proxied over to the dashboard API server running on the head node, usually on port 8265.
Thanks for the idea but tbh it isn’t exactly clear to me what you are outlining above. Are you suggesting that we pull the UI out from the code base, host it, and route all requests from the local api to the remote api?
Surprised there isn’t more demand for simply allowing the UX to be easily accessible without this complexity.
Accessing the dashboard requires access to the hosted HTTP server. There is nothing special about the dashboard UI or API server that makes it more complex than any other server.
Without understanding your limitations (ex: why can’t you use port forward?), it’s hard to suggest a solution.
Port forward is a super easy way of providing access to a port in a remote server.
If the issue is with accessing a non-standard port, A reverse proxy like nginx can be used to forward traffic from port 80 to the dashboard server.
If the issue is that you can’t easily open a browser window in the remote server, then the dashboard UI can be served somewhere that’s accessible and the API calls can be forwarded to the remote server.
What I’ve seen most folks do is they can either 1. Directly access the address + port from the browser, or 2. Use a reverse proxy that they can hit from their local machine.