I have an Organization with 4 apps and a database. One of them is a NodeJS server that needs to make http requests to a rails API. I cannot seem to get app-name.internal to resolve properly.
If I pop in using fly ssh console, then open up a Node REPL, await dns.promises.resolveTxt("_apps.internal") gives me the correct list of apps. However, resolving app-name.internal:8080 give me a ENOTFOUND.
Ive tried quite a few different things and read through Flys Internal DNS Docs so i feel like im missing something obvious…
1 Like
dns.promises.resolve does not automatically strip ports. DNS does not handle ports, so when you specify 8080, it breaks. But if you use the something.internal:8080 from within you app via fetch or some such, it will work fine.
Look at this nodejs 6pn example: github/fly-apps/privatenet/lookup.js.
Do note that your fly apps would also need to be listening on fly-local-6pn address on whatever 6pn port you intend to connect to.
Quoting from Specify instance-id in fly-replay header - #10 by ignoramous
…forwarding requests over Fly’s 6pn (“internal services” listening on fly-local-6pn or :: or _local_ip.internal Private networking not working - #4 by kurt) to the primary instance at <fly-alloc-id>.vm.appname.internal should work just as well: Send request to a specific VM - #2 by greg
Read also: github/fly-apps/nginx-cluster/readme:discovery.
Trying from fetch to app-name.internal:8080/handshake gives an ECONNREFUSED. request never reaches the second server. Seems this should work, no?
Can you share code snippets?
Without that, my guess is:
- Server (peer) isn’t listening on
fly-local-6pn:8080.
- Client (peer) isn’t explicitly connecting over IPv6.
- Where TLS is involved, prefer plain-text (
h2c & http1.1 without TLS) instead; or setup TLS termination appropriately.
Hmm. looks like delayed feedback, i redeployed everything again with Rails listening to both v4 & v6 like so CMD ["bin/rails", "server", "-b", "[::]", "-p", "8080"]. and was able to make a connection.
Thanks for your help!
1 Like