a year ago
Hey there,
I'm trying to establish a connection between two services.
Service A does a request to service B on it's internal DNS (http://xxx.railway.internal:8080). Where 8080 is the port defined via variables. Service B is up and running and health checks work.
However, In service A I'm getting a connection refused error. It's quite hard to debug afaik there's no solution to manually connect to the internal network via VPN or similar.
Thx for the help.
0 Replies
I'm not sure if it's related, but is service B broadcasting on IPv6? Railways internal networking only works if the recepient service uses IPv6
I'm not sure the port is necessary though, I think the .internal domain just ties to the PORT railway provides. I suppose you could try remove the port?
Hey <@301736945610915852> thx for the reply. So B can handle ipv6 requests on that endpoint. Not sure what boradcasting means in this context. not very experienced with ipv6 yet. I can try to remove the port (request 80)
instead of hosting on 0.0.0.0 or 127.0.0.1, you should host on ::1 or maybe :: (see https://stackoverflow.com/questions/25817848/python-3-does-http-server-support-ipv6)
depending on your language / server, it should be relatively simple to change it
<@301736945610915852> hmm starting my server listening on :: instead of 0.0.0.0 the healthchecks are failing 😦 I guess they need ipv4?
a year ago
the healthcheck does indeed need your app to listen on ipv4, as does accessing the service publicly, and communicating via the private network requires your app to listen on ipv6, so your app must be capable of dual stack binding (ipv4 and ipv6)
what kind of app is this? my first guess would be fastapi and uvicorn, since I know uvicorn doesn't support dual stack binding natively
Hey <@539512869780455445> thx for your answer. Your guess is right. This is fastapi and uvicorn.
a year ago
try hypercorn instead, it supports dual stack binding unlike uvicorn.
example start command
hypercorn main:app --bind [::]:$PORTThx <@539512869780455445> will try. It's a bit strange, though. Starting uvicorn with --host [::] I can locally curl with curl 0.0.0.0:8080 as well as curl '[::]:8080' in deployment it doesn't work.
a year ago
docker is a whole different ball game, you can't come into this with the "if it works locally" mindset
So if anybody is interested: switching to hypercorn solved the networking issue but needed some change in the code base lifespan functionality. For now we've setup uvicorn to listen on :: and disabled the health check endpoint.