Proxy dashboard to client

[selshowk]

I was discussing #4396 with @marcosmoyano and @mrocklin and wanted to suggest an idea to resolve the issue @mrocklin mentioned. Two proposals to re-enable the dashboard when only one port is available:

• have the client run a local http/websocket proxy that proxies all data back to the scheduler over the standard websocket connection.
• alternatively pull the dashboard out to a separate process that communicates with the scheduler over websockets. this process can optionally be run on the client side which would again mean that only one port is needed to connect the client to the server (via two-way tls).

In both cases the user could still access the dashboard locally though the second case is nicer in the sense that the dashboard really becomes a modular piece of the architecture that can be moved around (this is presumably much more work).

@ian-r-rose, @mrocklin thought you might have some input into the feasibility of something like this.

/cc @jacobtomlinson

[mrocklin]

So the dashboard requires full access to the scheduler state, so pulling out the server-side components to a separate process would be a challenge (although doable with sufficient effort). I think that it's more likely possible to put the interface boundary at the Bokeh server <-> Bokeh web frontend split. My guess is that this would probably look like a traditional web proxy, but hosted over Dask comms?

[jacobtomlinson]

Only having one port available is a pretty extreme constraint. I worry about major refactoring or decoupling work to satisfy a niche requirement (only Coiled?).

Perhaps deploying a popular proxy (nginx, traefik, etc) in front of your scheduler to aggregate the websocket comm and dashboard onto a single port would satisfy your use case?