search

myoung34 / docker-github-actions-runner

This will run the new self-hosted github actions runners with docker-in-docker
GNU General Public License v3.0
1.65k stars 389 forks source link

dial tcp 127.0.0.1:5432: connect: connection refused #199

Closed ifeelingz closed 2 years ago

ifeelingz commented 2 years ago

image

dial tcp 127.0.0.1:5432: connect: connection refused

"docker-github-actions-runner" works great. But I got a problem when I simulate the Database and it can't connect.

Meanwhile, if I install it on Ubuntu without Docker, it works fine.

How should I fix this? Can recommend me ?

Best Regards.

ifeelingz commented 2 years ago

Just., Fixed IP !!

image

makarov-roman commented 2 years ago

Hey @ifeelingz, can you elaborate a little bit more? As far I understand you starting new postgres container inside gh-runner, but then you trying to access it via public IP of machine, on which docker with runner works? Do you have only one runner per machine?

makarov-roman commented 2 years ago

it works for me too. But it's more like workaround than solution. Every job with such database service has to be exposed on host machine, which makes it much harder to scale (both vertically and horizontally).

@myoung34 should we reopen the issue?

myoung34 commented 2 years ago

To be honest I still dont understand the issue but this is more configuration than anything else. the runner has nothing to do with the networking configuration and is different per orchestrator. For all I know the issue here is solely related to docker-compose

nmalaguti commented 2 years ago

It looks like the solution was to expose the port on the docker host interface? I'm pretty sure 172.17.0.1 is usually the gateway IP in the default bridge network. Since the runner is on the same bridge network as the service containers, you're able to access them this way. If you're running multiple jobs concurrently you'll almost certainly run into port conflicts.

myoung34 commented 2 years ago

172.17.0.1 is indeed the docker gateway for the service itself to talk to the host.

IE if you run something on 8888 on 0.0.0.0 you can hit it from a container on 172.17.0.1:8888 in most common docker set up scenarios

This behavior is very specific to docker itself and not other CRI's

makarov-roman commented 2 years ago

Thanks for your feedback. Although I understand that it's not specific to this repo, some lost souls like me who had workflows on self-hosted runner without docker and now have this issue would be greatly appreciate it if you could point in the right direction.

jsoneaday commented 1 year ago

Has anyone got this to work without using the 172 ip. I tried that ip and it still getting connection refused. Although I am not using a service for a docker compose up command

myoung34 commented 1 year ago

If youre using docker 4 windows or mac it could be different, but it will be whatever the gateway is