Graphs not rendering for Bokeh Server Embed in Flask running in Docker Container

lemgog · July 11, 2021, 11:33pm

So I am not starting the Bokeh server in that manner, I am using the method in this example

bokeh/bokeh/blob/branch-2.4/examples/howto/server_embed/flask_gunicorn_embed.py

try:
    import asyncio
except ImportError:
    raise RuntimeError("This example requries Python3 / asyncio")

from threading import Thread

from flask import Flask, render_template
from tornado.httpserver import HTTPServer
from tornado.ioloop import IOLoop

from bokeh.application import Application
from bokeh.application.handlers import FunctionHandler
from bokeh.embed import server_document
from bokeh.layouts import column
from bokeh.models import ColumnDataSource, Slider
from bokeh.plotting import figure
from bokeh.sampledata.sea_surface_temperature import sea_surface_temperature
from bokeh.server.server import BaseServer
from bokeh.server.tornado import BokehTornado

This file has been truncated. show original

My code to do so is here:

spectrogram_plot = Application(FunctionHandler(spectrogram_plot))

# This is so that if this app is run using something like "gunicorn -w 4" then
# each process will listen on its own port

def is_port_in_use(port):
    import socket
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
        return s.connect_ex(('localhost', port)) == 0
    
from app import settings
settings.init()
for p in range(5006, 5011):
    if is_port_in_use(p):
        continue
    else:
        sockets, settings.port = bind_sockets("localhost", p)
        break

def bk_worker():
    asyncio.set_event_loop(asyncio.new_event_loop())

    bokeh_tornado = BokehTornado({'/spectrogram_plot':spectrogram_plot}, \
        extra_websocket_origins=["127.0.0.1:5000", "127.0.0.1:"+str(settings.port), \
        "0.0.0.0:"+str(settings.port), "localhost:"+str(settings.port), "0.0.0.0:5000", \
            "localhost:5000", "172.21.0.1:5000", "172.21.0.1:"+str(settings.port), "172.21.0.2:5000", "172.21.0.2:"+str(settings.port), "*"])
    bokeh_http = HTTPServer(bokeh_tornado)
    bokeh_http.add_sockets(sockets)

    server = BaseServer(IOLoop.current(), bokeh_tornado, bokeh_http)
    server.start()
    server.io_loop.start()

t = Thread(target=bk_worker)
t.daemon = True
t.start()

Then within my Flask routes.py, I have

spectrogram_plot = server_document('http://localhost:%d/spectrogram_plot' % int(settings.port))

Since this is the way I access the Bokeh server, no logs are output to stdout. Is there a different way that I should configure this that is better? This is what I see when I run my spectrogram_plot.py via the cmd line

However, I don’t get any graphs (just a blank page) when I visit the provided url in my browser. In the same environment, using just the code embedded in my Flask app, the plots render fine, although I suspect this has something to do with the fact that it is using a database module present in my Flask app that isn’t present when just running the Bokeh script by itself. When I visit the provided url in a Docker environment using the Bokeh serve command, it creates the websocket connection successfully and no graphs render, same as in my non-Docker environment. However, in my non-Docker environment, when access through the Flask app, the graphs render successfully, and they dont in the Docker environment

These are the scripts I have embedded in my html template

      <link rel="stylesheet" href="http://cdn.pydata.org/bokeh/release/bokeh-2.3.0.min.css" type="text/css" />
      <link href="http://cdn.bokeh.org/bokeh/release/bokeh-tables-2.3.0.min.css" rel="stylesheet" type="text/css">
      <script type="text/javascript" src="http://cdn.pydata.org/bokeh/release/bokeh-2.3.0.min.js"></script>
      <script src="https://cdn.bokeh.org/bokeh/release/bokeh-widgets-2.3.0.min.js"
        crossorigin="anonymous"></script>
      <script src="https://cdn.bokeh.org/bokeh/release/bokeh-tables-2.3.0.min.js"
        crossorigin="anonymous"></script>

But from what you are saying, I’m guessing I can discard the one’s that aren’t loading. So yes you are correct, the 403’s are spurious. It seems as if the only relevant section from there is the “Failed to load resource: net::ERR_EMPTY_RESPONSE”