Flask and Docker app can't listening on the expected address and will not be reachable by fly-proxy

Questions / Help Build debugging
1

I’m new to Flask and Docker.

I wrote a little app using Flask and containerized it in Docker because it uses Ruby partly in subprocess. It worked locally perfectly.

But when I tried to deploy it following this Deploy via Dockerfile article dependably, I got this warning and my browser was not able to display my app though I accessed app’s address.

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:2:db74:a7b:b4f1:1678:747c:2]:22

My Dockerfile is here:

FROM python:3.11 AS builder
COPY requirements.txt /
RUN pip install --upgrade pip \
    && pip install -r requirements.txt

FROM ruby:3.1.3
COPY --from=builder /usr/local/bin /usr/local/bin
COPY --from=builder /usr/local/lib /usr/local/lib
RUN gem update --system \
    && gem install aozora2html
WORKDIR /app
COPY ./ ./
CMD ["python", "app.py"]

And my app is using Waitress for serving like this:

from waitress import serve

app = Flask(__name__)

if __name__ == "__main__":
    serve(app, host='0.0.0.0', port=8080)

Or I tried to switch the way to call serving in Dockerfile but got same error:

CMD ["waitress-serve", "--host:'0.0.0.0'", "--port=8080", "app:app"]

I didn’t edit fly.toml at all and am leaving it as is from when it generated.

app = "hidden-wood-9810"
primary_region = "nrt"

[build]

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0
  processes = ["app"]

My log is here:

Waiting for logs...
2023-08-30T01:43:33.590 app[e286249b927086] nrt [info] INFO [fly api proxy] listening at /.fly/api
2023-08-30T01:43:33.599 app[e286249b927086] nrt [info] 2023/08/30 01:43:33 listening on [fdaa:2:db74:a7b:99:3165:6de8:2]:22 (DNS: [fdaa::3]:53)
2023-08-30T01:43:33.601 app[e286249b927086] nrt [info] /usr/local/bin/python: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /usr/local/bin/python)
2023-08-30T01:43:33.601 app[e286249b927086] nrt [info] /usr/local/bin/python: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /usr/local/bin/../lib/libpython3.11.so.1.0)
2023-08-30T01:43:33.601 app[e286249b927086] nrt [info] /usr/local/bin/python: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /usr/local/bin/../lib/libpython3.11.so.1.0)
2023-08-30T01:43:33.601 app[e286249b927086] nrt [info] /usr/local/bin/python: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/local/bin/../lib/libpython3.11.so.1.0)
2023-08-30T01:43:33.601 app[e286249b927086] nrt [info] /usr/local/bin/python: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /usr/local/bin/../lib/libpython3.11.so.1.0)
2023-08-30T01:43:34.293 app[6e82996a076687] nrt [info] INFO Main child exited normally with code: 1
2023-08-30T01:43:34.293 app[6e82996a076687] nrt [info] INFO Starting clean up.
2023-08-30T01:43:34.293 app[6e82996a076687] nrt [info] WARN hallpass exited, pid: 256, status: signal: 15 (SIGTERM)
2023-08-30T01:43:34.294 app[6e82996a076687] nrt [info] 2023/08/30 01:43:34 listening on [fdaa:2:db74:a7b:b4f0:1856:fa1d:2]:22 (DNS: [fdaa::3]:53)
2023-08-30T01:43:34.596 app[e286249b927086] nrt [info] INFO Main child exited normally with code: 1
2023-08-30T01:43:34.597 app[e286249b927086] nrt [info] INFO Starting clean up.
2023-08-30T01:43:34.597 app[e286249b927086] nrt [info] WARN hallpass exited, pid: 256, status: signal: 15 (SIGTERM)
2023-08-30T01:43:34.598 app[e286249b927086] nrt [info] 2023/08/30 01:43:34 listening on [fdaa:2:db74:a7b:99:3165:6de8:2]:22 (DNS: [fdaa::3]:53)
2023-08-30T01:43:35.290 app[6e82996a076687] nrt [info] [ 2.203521] reboot: Restarting system
2023-08-30T01:43:35.390 runner[6e82996a076687] nrt [info] machine has reached its max restart count (10)
2023-08-30T01:43:35.595 app[e286249b927086] nrt [info] [ 2.264524] reboot: Restarting system
2023-08-30T01:43:35.783 runner[e286249b927086] nrt [info] machine did not have a restart policy, defaulting to restart
2023-08-30T01:43:38.414 proxy[6e82996a076687] nrt [info] waiting for machine to be reachable on 0.0.0.0:8080 (waited 5.111314207s so far)
2023-08-30T01:43:38.912 app[e286249b927086] nrt [info] [ 0.037486] PCI: Fatal: No config space access function found
2023-08-30T01:43:39.119 app[e286249b927086] nrt [info] INFO Starting init (commit: 5293a085)...
2023-08-30T01:43:39.136 app[e286249b927086] nrt [info] INFO Preparing to run: `waitress-serve --host:'0.0.0.0' --port=8080 app:app` as root
2023-08-30T01:43:39.143 app[e286249b927086] nrt [info] INFO [fly api proxy] listening at /.fly/api
# repeating
2023-08-30T01:44:48.284 runner[e286249b927086] nrt [info] machine has reached its max restart count (10)

How can I fix this and be able to deploy my app?

2

Hello!

Did you try building the Docker image locally and running it?

I bet it will not work; you are building the Python environment and application using a python:3.11 image as the base (these images are based on Debian), and then copying the Python binaries from that image into a different image (ruby:3.1.3) - the errors from the Python interpreter saying it can’t find glibc are likely because the Ruby image is based on a different Debian version than the Python one:

/usr/local/bin/python: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.34' not found (required by /usr/local/bin/python)

What I’d do here is fiddle with the Dockerfile until you get it working locally (docker run your-image should not error. If you try it right now, it will error the same way it’s erroring when trying to deploy) and then attempt your deployment. And in order to get it working locally you’ll need to ensure the final image is compatible with the builder base. There are several ways to do this, for example:

  1. Use a plain Debian or Ubuntu base and install both Ruby and Python packages on the same base so when you copy them to the final deployment image they are compatible and happy with the base’s files and libraries.
  2. Use a more specific tag to target a specific Debian version for both your Ruby and Python images. Example:
from python:3.11.5-bookworm as builder
(etc etc)
from ruby:3.1.4-bookworm  # note they are now both based on bookworm
(etc etc etc)

I’m certain the first option will work. I’m not sure the second will, you will probably need to fiddle with it a bit.

Let me know if this works!

  • Daniel
2 Likes
3

Thanks for your reply.

To my credit, it worked when I built the image with a Dockerfile above and ran a container by a command such docker run -it -d --name self-build -p 8080:8080 self-build using my local Docker Desktop 4.22.1 (118664) before I posted this question.
(I happend to make a typo like --host: not --host= on CMD above, but now I have fixed it.)

However, now it is completely working on Fly too by adopting your second strategy, targeting more specific Debian version. I chose bookworm according to your example.

I’m a so newbee that I couldn’t reach the meaning of the log. Now I have learnt a lesson.
Thanks a lot! :smiley: