So far I haven’t had any success getting Streamlit to run an application in GCP. I can get Streamlit deployed to both AppEngine and CloudRun and started up. But in both environments even something as basic as “streamlit hello” displays a “Please wait…” message in an st.info() bar and then hangs on the internal connection to “healthz”, eventually failing with a 404 Error. Github issue.
Hi @knorthover, I definitely got it going on GKE myself. I haven’t tried AppEngine or CloudRun, but I’d love to help. My guess is that there might be something boing on with Websocket. It seems to work just fine on GKE, but I am deploying directly with Kubernetes, so it might be a different networking setup. I really appreciate you filing the bug, so I will follow up from there. Also, thanks for uploading all your configuration and Dockerfile.
Thanks Matteo.
For now I’ve deployed on an internal server box. My users are enthusiastic about the application (a dashboard for our call center).
I don’t know enough about tornado to know where the problem is occurring but it seems that Cloud Run and AppEngine (I believe they are basically the same stack) are taking over control of the websocket connections.
Kevin
I’m getting the same issue on app engine. I’m very eager to get streamlit working with either app engine or cloud function.
I’m mainly focus on ML, not good at eng and infra. Streamlit is awesome because I don’t have to be an expert on web dev eng. If Streamlit can be easily deployed to app enigne or cloud function then I don’t have to be an infra expert (e.g. kubernetes & docker) as well .
Yeah, I did not do anything special. How are you doing it? A Service of type LoadBalancer should do it. I also have a setup through an “envoy”-based proxy, but that may require more effort.
Thanks for those last tips. I’ve now got a test app working in AppEngine using this suggestion https://stackoverflow.com/a/59052809 and disabling CORS.
Cloud Run still gives the same error
I’ll attach the Dockerfile and app.yaml files to the Github issue.
It’s possible to get an app to run in AppEngine (as I posted a while back) but they generally stop after a little while because AppEngine doesn’t support a persistent websocket connection. GKE is the recommended approach.
Hi! Do you know if it’s possible to deploy using Google App Engine’s standard environment? I’ve deployed a simple streamlit app with the flex environment (with minimum requirements to run it) but the standard env is way cheaper. Thank you!
Jairo
As far as I know AppEngine will still not run Streamlit for any length of time. That was certainly my experience and I abandoned that approach some months back. The issue is Websocket support and timeout.
GKE deployment is mostly straightforward, it gets more complicated if you want to use the Identity Aware proxy to secure access to your pages. We did increase the Websocket timeouts for our GKE configurations.
Thanks for your prompt reply @knorthover ! I’ll give it a try. Btw, do you think that deployment on AWS would be easier (say, using EC2) than GCP?
It’s interesting because I’ve used the Google App Engine to deploy my simple app with a flex env and it’s worked for a couple of months. I do see however an error once in a while that may have to do with the websocket issue discussed in this forum.
Jairo
I’ve no experience with AWS. All I can tell you is that my summer intern, who has deployed apps on AWS, has just been learning about Google Cloud and tells me GCP is much easier.
Kevin
I’m trying to deploy in App. Engine with no luck. I have followed the comments but I get this error:
Updating service [default] (this may take several minutes)...failed.
ERROR: (gcloud.app.deploy) Error Response: [9]
Application startup error! Code: APP_CONTAINER_CRASHED
2020-09-26 16:37:01.780
Warning: the config option 'server.enableCORS=false' is not compatible with 'server.enableXsrfProtection=true'.
As a result, 'server.enableCORS' is being overridden to 'true'.
More information:
In order to protect against CSRF attacks, we send a cookie with each request.
To do so, we must specify allowable origins, which places a restriction on
cross-origin resource sharing.
If cross origin resource sharing is required, please disable server.enableXsrfProtection.
Usage: streamlit run [OPTIONS] TARGET [ARGS]...
Error: Invalid value: File does not exist: app.py
Is secure to disable XsrfProtection?
There is another way?
None of the suggestions above by the others have worked for me.
Does this mean Google App Engine ( same issue occurs with Google Cloud Run as well) is not an option for deploying Streamlit Apps?
Or… is there a way to override the health endpoint name used by Streamlit ?
I have managed to get around the healthz conflict in a rather nasty way. I also enabled session_affinity to help with websocket connections.
here is my app.yaml, ill explain the healthz fix below:
runtime: python
env: flex
# This is a horrible workaround to get streamlit working on app engine
# https://discuss.streamlit.io/t/has-anyone-deployed-to-google-cloud-platform/931/20
entrypoint: find ${VIRTUAL_ENV}/lib/python3.6/site-packages/streamlit -type f \( -iname \*.py -o -iname \*.js \) -print0 | xargs -0 sed -i 's/healthz/health-check/g' && streamlit run sim_v3.py --server.port $PORT --server.enableCORS=false
runtime_config:
python_version: 3
manual_scaling:
instances: 1
network:
session_affinity: true
The hack is happening in the entrypoint command. I am finding all files in the python virtualenv dependencies folder, site-packages, that are either .py or .js and replacing healthz with health-check
If you are intending on supporting a deployed streamlit app, I suggest you avoid this solution. It will break if
the version of python changes in the google python runtime
streamlit make a change that would break this inline replacement
google decide to change their folder naming conventions
Thanks for stopping by! We use cookies to help us understand how you interact with our website.
By clicking “Accept all”, you consent to our use of cookies. For more information, please see our privacy policy.
Cookie settings
Strictly necessary cookies
These cookies are necessary for the website to function and cannot be switched off. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms.
Performance cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us understand how visitors move around the site and which pages are most frequently visited.
Functional cookies
These cookies are used to record your choices and settings, maintain your preferences over time and recognize you when you return to our website. These cookies help us to personalize our content for you and remember your preferences.
Targeting cookies
These cookies may be deployed to our site by our advertising partners to build a profile of your interest and provide you with content that is relevant to you, including showing you relevant ads on other websites.