Please document websockets and Panel apps on Fly

[cdeil]

I found an issue with this document.

Title: Python on Fly.io Location: https://fly.io/docs/python/ Source: https://github.com/superfly/docs/blob/main/python/index.html.md

Describe the issue

Monkey tried to deploy a Python Panel app on Fly but Monkey no luck. 🙈 🙈 🙈

https://github.com/cdeil/fly-panel

Can fly experts please write 📖 how 🐒 can succeed with websockets?

[cdeil]

I guess the problem is that I don't have a correct fly.toml configuring the services?

https://fly.io/docs/reference/configuration/#the-services-sections

Should I simply try the one from here?

https://fly.io/blog/websockets-and-fly/

Or anyone has a working example or knows how it should work?

cc @philippjfr

[fliepeltje]

hey! generally speaking, there's nothing special that needs to happen to connect with a websocket. I cannot tell you at which time we will fully support panel, but I can help you on your way now :)

Currently you are running the app with this command:

CMD ["/app/.venv/bin/panel", "serve", "app.py", "--port", "8080", "--allow-websocket-origin=localhost"]

The offender here is the --allow-websocket-origin parameter; right now you are only allowing ws connections from localhost; this is fine when both the server and the client are on 1 machine, but in this case the server is on fly and the client is your machine.

Modify this line to accept connections from other hosts:

CMD ["/app/.venv/bin/panel", "serve", "app.py", "--port", "8080", "--allow-websocket-origin=*"]

[cdeil]

@fliepeltje - thank you!

I applied the change you suggested: https://github.com/cdeil/fly-panel/commit/33011f6a543d2b10a4486370f586dffc1591f13b

Seems to work OK: https://fly-panel-test.fly.dev/app

I see this warning when running fly deploy:

WARNING The app is not listening on the expected address and will not be reachable by fly-proxy.
You can fix this by configuring your app to listen on the following addresses:
  - 0.0.0.0:8080
Found these processes inside the machine with open listening sockets:
  PROCESS        | ADDRESSES                            
-----------------*--------------------------------------
  /.fly/hallpass | [fdaa:9:6fbb:a7b:43:dda7:a651:2]:22  

What do I have to change (presumably in fly.toml) to fix this warning?

[fliepeltje]

Hmm, incidentally this is something that I ran into myself; this seems like an issue in flyctl; it's on my radar to find out what is going on there; I've made an issue to track this.

[cdeil]

I checked back on https://fly-panel-test.fly.dev/ today (next day) and the app is down.

I'm not a fly expert, to me it isn't obvious from the logs and admin interface why it went down and isn't working.

:-(

[fliepeltje]

Soo, this seems like a panel quirk; if you go to https://fly-panel-test.fly.dev/app it does work. I'm unsure what happens in panel that it does not work on the root level, but it seems like some weird interaction between auto_stop features and how panel handles requests.

[cdeil]

I cannot reach this either today in the past hours: https://fly-panel-test.fly.dev/app

So for you it responds?

Then if it works for you but not me the issue is routing-related?

[cdeil]

Panel is running on Bokeh Server which is Tornado server.

There's docs here with lots of infos: https://docs.bokeh.org/en/latest/docs/user_guide/server.html

I'm not a web traffic / server expert. I don't know if there's anything special about Fly or Bokeh that makes both together challenging or some config settings to make HTTPS and WS work stable.

[fliepeltje]

I'll read the docs later and see if I can figure out what is up :)

[cdeil]

I get DNS_PROBE_FINISHED_NXDOMAIN with Chrome on MacOS.

https://downforeveryoneorjustme.com/fly-panel-test.fly.dev?proto=https

It's not just you! fly-panel-test.fly.dev is down. Last updated: Jul 23, 2024, 5:05 PM (1 second ago)

[fliepeltje]

This is very weird :sweat_smile:

[cdeil]

I'm in Heidelberg, Germany. I'm in corporate office network, there might be ZScaler or various network effects with my traffic. But my location and network shouldn't matter for status from "is up" services.

[fliepeltje]

Hey, revisiting this, here's what I see:

• If I go to https://downforeveryoneorjustme.com/fly-panel-test.fly.dev?proto=https it will indeed tell me the app is down
• If I actually visit the app, it will launch fine
• If I visit https://downforeveryoneorjustme.com/fly-panel-test.fly.dev?proto=https again, it will now be upp

The app gets stopped for sure and it wakes up just fine, but only if you visit it from a browser. This makes me think that there some logic in panel that returns an unexpected status code if you do not approach the app from a browser.

[philippjfr]

Not aware of any mechanism in tornado, Bokeh or Panel that differentiates between browser based requests and other requests. Only the browser will actually initiate the websocket but the initial http(s) request is what should matter.