Hi,
I'm not very familar with HTML and Java, so am very excited that Bokeh is making it possible to create interactive graphs on the web using Python! Since I'm not very familiar with HTML and web hosting, your documentation on deployment scenerios and reverse proxying with Nginx is a little over my head. I'm wondering if you can make a "For Dummies" version of this documentation, since I think there are other people who might be in my position.
In particular, I'm interested in the scenerio where I want to share a Bokeh Server plot with someone on a different network. My understanding is that if I have a website like foo.com, and run:
bokeh serve myapp.py --port 5100 --host foo.com:80
I can access the plot on foo.com/myapp. Is that correct?
Probably not. That tells the Bokeh server that it itself should listen for network connections on port 5100, and that it should reject any connection requests that don't report "foo.com" as the hostname that was trying to be reached. This configuration is more typical when the Bokeh server is running "internally" behind a proxy server. The proxy listens "publicly" on foo.com port 80, and forwards traffic internally (along with the original "foo.com" request host) to a Bokeh server listening on port 5100 (which is not publicly accessible).
If you want to run a Bokeh server publicly facing some network, you want the ports to match:
bokeh serve myapp.py --port 5100 --host foo.com:5100
Then your app is available at http://foo.com:5100/myapp
So if you just want users to use "foo.com" (no port specified) then you'd need to run
bokeh serve myapp.py --port 80 --host foo.com:80
Of course, now nothing else can listen on port 80 on foo.com, which is one reason to use proxy servers.
Am I right to assume that if I share the link with people on different networks, it will only work if my Conda session where I've run that command is open?
The server has to be running and accessible to anyone that you would like to be able to view an app running on it. On a Unix-like system this means either leaving the terminal you ran the server in open all the time, or using some kind of "process control manager". At the simplest end of that are tools like the standard Unix "screen" command. More sophisticated would be things like "supervisord" and others, that will actively monitor and restart processes if they fail.
Also, what are the requirements for foo.com? For example, if I have a site on a host like Weebly or GoDaddy and I know the IP address that they point to, could I use that information to make the site? How would I do that with a bokeh serve command? Is there an easier way to make a site that is sharable with people in other networks?
Any host that you can log into and install/run a Bokeh server on, and can open up any relevant firewall settings should be fine.
And to be clear, I'm right in understanding that all this is easier than trying to embed the Bokeh server plot into HTML code?
I'm not sure I completely understand the question, but Bokeh server apps can be embedded into other HTML documents using the script tag generated by bokeh.embed.autoload_server (but you'd need to configure the Bokeh server to accept connections from whatever host is serving the pages that have the embedded plot).
So, in that case you could run the Bokeh apps on unprivileged ports (i.e. not port 80) on some server, and then embed those into HTML served from somewhere else (a blog platform, your own webserver, etc.) In this kind of scenario you could run as many apps as you like, each on a different port, and embed them in your other HTML pages.
Again, apologize for the basic questions! Would appreciate any suggestions or tips!
Just a few final thoughts:
The size of the intended audience, and the "compute load" of the app matter. If you only expect a relatively small number of connections at a time, if your app is not doing heavy compute-intensive things, then a single server is probably OK for the app. If you expect to have thousands of concurrent users and all of them will be triggering expensive machine learning algorithms at the same time, you would have to worry about scaling out (load balancers, proxies, etc.) Bokeh server is not magic: computation that has to happen, has to happen *somewhere*.
We hope to offer a service some day soon to help take care of the devops aspects of deploying "scaled out" Bokeh apps.
Thanks,
Bryan
···
On Feb 7, 2016, at 4:01 PM, MNobles <[email protected]> wrote:
Thanks!!
--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/af3f02ae-9323-46ba-baad-51af9cbfdee1%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.