Hi all,
I’ve been trying to deploy a dash app that works locally to Azure App Service. I’ve followed advice in a few older posts on this forum but it’s not working for me, so I’m making this new thread in the hopes that if things have changed since then, someone on here has has some wisdom they can share. My issue is similar to this one, where the Deployment seems to be successful but the webpage itself displays an error message.
My code is in a python file called app.py. The body of it is
app = Dash(__name__, prevent_initial_callbacks=True, external_stylesheets=[dbc.themes.BOOTSTRAP])
server=app.server
#MAIN CODE BODY
if __name__ == '__main__':
app.run(debug=True)
Then my configuration Start Command is
gunicorn --bind 0.0.0.0 app:server
Unfortunately, the webpage fails to display. I’ve confirmed that it runs locally with python app.py, as well as using waitress (the windows version of gunicorn). My gut feeling is that it’s something to do with ports, but I don’t know how to verify this. When I do specify something like
gunicorn --bind 0.0.0.0:8050 app:server
it makes no difference.
The build logs indicate that the requirements.txt file was successfully installed, and the build ends with
remote: Generating summary of Oryx build
remote: Parsing the build logs
remote: Found 0 issue(s)
remote:
remote: Build Summary :
remote: ===============
remote: Errors (0)
remote: Warnings (0)
remote:
remote: Triggering recycle (preview mode disabled).
remote: Deployment successful.
If anyone else has experienced this and has some insight, I’d appreciate the help!
Hello @JosephK,
Welcome to the community!
Does it take a while for your app to spin up initially?
If so, that could be the issue due to a timeout that the web apps have by default.
What I have found useful is downloading Docker Desktop and spinning up the application via Docker first - make sure everything works fine. Azure app service is built on Docker itself - so it is easy to debug and potential issue , spinning up time issue in Docker than via SSH on the Azure app service.
Oh that could be the issue! It’s a Weather dashboard that queries forecast data via WMS, and it takes a minute or two to load initially when it’s running those imports etc. Is there a configuration variable to extend that timeout?
That’s a good idea! I’ll see if I can do the troubleshooting in Docker if I can’t figure it out with the SSH tools, thanks!
Try setting the environment variable to the container:
WEBSITES_CONTAINER_START_TIME_LIMIT
to something like 600
Unfortunately, no luck there. I also replaced my app.py with a much simpler app that does nothing but display some text:
from dash import Dash, html
import dash_bootstrap_components as dbc
app = Dash(_name_, prevent_initial_callbacks=True, external_stylesheets=[dbc.themes.BOOTSTRAP])
server=app.server
app.title = “This is a basic app that does nothing”
app.layout = html.Div([
html.H1(children="Maybe one day it will be a real app.", style={'textAlign':'center', 'margin': '10px'}, id='page_refresh'),
])
if _name_ == ‘_main_’:
app.run(debug=True)
This is also not working. Again, it runs fine locally and it is successfully deployed with no errors, but the webpage itself is just an error.
One thing that may or may not matter is that in most working examples I’ve seen, the command used is app.run_server() as opposed to app.run, but run_server is no longer supported.
What is your run command?
gunicorn --bind=0.0.0.0 --timeout 600 testApp:server
So the run command is
gunicorn --bind 0.0.0.0 --timeout 600 app:server
The code still lives in app.py, and the dash object is “app”, so I think this is the correct syntax.
Yeah, that should be working.
Just making sure, but your requirements.txt also has gunicorn on it?
It does!
And good news, it is now running. I replaced my requirements file with a much smaller one for just the newer version of the app containing nothing but dash, dash-bootstrap-components, and gunicorn. I’m now wondering if the issue with the “real” app is that there are a lot of large packages required, and the amount of time it needs to decompress the output.tar.gz file in wwwroot is long enough for it to time out. It’s an app for weather prediction and weather history, so it has things like dash-leaflet for a webmap to choose a location, a wms service, etc etc. I tried decompressing the output.tar.gz folder and it took about 5 minutes before I gave up.
Does that make sense? Have you heard of a virtual environment being “too big” to work with App Service?
It shouldnt be too large, but I also dont know what your requirements are.
It should be able to download the libraries that you need. Sometimes you can run into issues based upon packages not being available for certain types of OS and also Python versions.