To be reachable by fly-proxy
an app needs to listen on 0.0.0.0 and
bind to internal_port
defined in fly.toml
.
Some frameworks listen on 127.0.0.1 by default. They also define different
default ports - 3000, 8000, 8080, etc.
It’s quite easy to make a mistake and configure your app in a way that makes
it impossible for fly-proxy
to route requests to it.
And it can be difficult to debug, especially if the framework you use does not
print listening address to logs and your image does not have netstat
or ss
tools.
flyctl
now outputs a helpful warning message during deploy if it finds out
that the app is not listening on the expected address.
How it works
For the first machine in each process group, flyctl
queries a list of
processes running inside the machine together with their TCP sockets in LISTEN state.
It then cross-references the sockets with the service definitions in fly.toml
and,
if not all services are covered by the running processes, outputs a warning.
How it looks
❯ fly deploy
==> Verifying app config
Validating /home/pbor/apps/pbor-processes/fly.toml
Platform: machines
✓ Configuration is valid
--> Verified app config
==> Building image
<skip>
Watch your app at https://fly.io/apps/pbor-test/monitoring
Updating existing machines in 'pbor-test' with rolling strategy
[1/2] Machine 9080e51df39587 [app] update finished: success
WARNING The app is listening on the incorrect 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:3000
Found these processes inside the machine with open listening sockets:
PROCESS | ADDRESSES
-----------------*---------------------------------------
/app | 127.0.0.1:3000
/.fly/hallpass | [fdaa:1:d615:a7b:140:5c20:a996:2]:22
[2/2] Machine 9185793eb11048 [app] update finished: success
Finished deploying
Feedback
If you have feedback, comments or questions, please share!