Panel deployment in fly.io

Panel
1

I have a simple app that uses panel and that I want to run in the free tier in fly. io. The idea is pretty simple, you just have a requirements.txt and a Dockerfile. The latter looks like this:

FROM continuumio/miniconda3
RUN conda install -c conda-forge nodejs
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .
CMD panel serve --show app.py --address 0.0.0.0 --port 8080 --allow-websocket-origin="*"

Port 8080 is mentioned in the fly io documentation. In theory, all that’s needed is to create the app and then launch it. The creation process results in some questions and a toml file:


app = "something-or-other"
kill_signal = "SIGINT"
kill_timeout = 5
processes = []

[env]

[experimental]
  auto_rollback = true

[[services]]
  http_checks = []
  internal_port = 8080
  processes = ["app"]
  protocol = "tcp"
  script_checks = []
  [services.concurrency]
    hard_limit = 25
    soft_limit = 20
    type = "connections"

  [[services.ports]]
    force_https = true
    handlers = ["http"]
    port = 80

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

  [[services.tcp_checks]]
    grace_period = "1s"
    interval = "15s"
    restart_limit = 0
    timeout = "2s"

The app is launched and successfully deployed. I can’t. however, access it’s webpage (I just get a timeout on the browser).

Has anyone succeeded with fly and have any suggestions?

1 Like
2

Hi @xgomez,

Have you eventually managed to deploy your Panel app to fly.io?

3

I’m afraid not. Everything is running according to the logs, only that I get a broken connection when I access using the browser, and the fly.io logs shows no hits whatsoever.

4
  • Does you browser console show any errors?
  • Could you try without --show in your Dockerfile.
  • Can you see if the panel server started in the fly.io logs?

Please share as much information including screenshots as you can to give us a chance to help you.

Unfortunately I’m working in a highly secure and constrained environment so I cannot install the flyctl cli. If there is any other, easy way to try to deploy let me know.

5

@Marc thanks for your reply. I removed the --show option from the Dockerfile. On the fly.io dashboard, everything works and the logs show:


Waiting for logs...

2023-03-14T18:11:27.693 runner[2cf1500b] lhr [info] Starting instance

2023-03-14T18:11:27.767 runner[2cf1500b] lhr [info] Configuring virtual machine

2023-03-14T18:11:27.768 runner[2cf1500b] lhr [info] Pulling container image

2023-03-14T18:11:38.652 runner[2cf1500b] lhr [info] Unpacking image

2023-03-14T18:11:59.071 runner[2cf1500b] lhr [info] Preparing kernel init

2023-03-14T18:11:59.474 runner[2cf1500b] lhr [info] Configuring firecracker

2023-03-14T18:11:59.568 runner[2cf1500b] lhr [info] Starting virtual machine

2023-03-14T18:11:59.832 app[2cf1500b] lhr [info] Starting init (commit: 08b4c2b)...

2023-03-14T18:11:59.870 app[2cf1500b] lhr [info] Preparing to run: `panel serve app.py --address 0.0.0.0 --port 8080 --allow-websocket-origin=*` as root

2023-03-14T18:11:59.906 app[2cf1500b] lhr [info] 2023/03/14 18:11:59 listening on [fdaa:1:6da9:a7b:276d:2cf1:500b:2]:22 (DNS: [fdaa::3]:53)

2023-03-14T18:12:02.381 app[2cf1500b] lhr [info] 2023-03-14 18:12:02,380 Starting Bokeh server version 2.4.3 (running on Tornado 6.2)

2023-03-14T18:12:02.382 app[2cf1500b] lhr [info] 2023-03-14 18:12:02,381 Host wildcard '*' will allow connections originating from multiple (or possibly all) hostnames or IPs. Use non-wildcard values to restrict access explicitly

2023-03-14T18:12:02.382 app[2cf1500b] lhr [info] 2023-03-14 18:12:02,382 User authentication hooks NOT provided (default user enabled)

2023-03-14T18:12:02.385 app[2cf1500b] lhr [info] 2023-03-14 18:12:02,385 Starting Bokeh server with process id: 520 pp

2023-03-14T18:12:02.385 app[2cf1500b] lhr [info] 2023-03-14 18:12:02,385 Starting Bokeh server with process id: 520```

I have tried connecting to the website, but nothing happens. I get a "The connection was reset" error. But as you can see from the logs above, the panel server isn't reporting any connections.
6

Do you know how much cpu and memory you get on fly.io? It could be too little to power a Panel server. I’ve experienced that at lightning.ai.

Do you know if fly.io is testing the webserver by requesting a response? I’ve experienced at lightning.ai that they did that. Because Panel is much slower than a typical FastAPI response on the initial response they kept restarting the Panel server.

Could you please also share what you see in your browser console? There might be additional logs there. Check out Finding Your Browser’s Developer Console | Balsamiq

7

I think it is 1 core and ~256Mb of RAM. Given the logs, it would appear that nothing is hitting the panel server (the logs haven’t changed in the last two hours from what I posted then). The server load is negligible (0.07!)

The console shows nothing. You can try the actual URL, but I think there’s no communication between the URL and the panel server in the Docker file.

Thanks!