connect: connection refused when running in WSL2
cpswan opened this issue · 7 comments
I've installed the dependabot cli in Ubuntu 20.04.6 running on WSL2, and whenever I run dependabot update ... there seems to be a connection problem with the proxy:
proxy | 2023/05/09 09:46:49 [479] POST http://host.docker.internal:34279/update_jobs/cli/record_update_job_error
proxy | 2023/05/09 09:46:49 [479] No response from server
updater | 2023/05/09 09:46:49 ERROR dial tcp 192.168.65.2:34279: connect: connection refused
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
docker version
Client:
Version: 20.10.21
API version: 1.41
Go version: go1.18.1
Git commit: 20.10.21-0ubuntu1~20.04.2
Built: Thu Apr 27 05:56:19 2023
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Desktop
Engine:
Version: 20.10.24
API version: 1.41 (minimum version 1.12)
Go version: go1.19.7
Git commit: 5d6db84
Built: Tue Apr 4 18:18:42 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.18
GitCommit: 2456e983eb9e37e47538f59ea18f2043c9a73640
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker network ls
NETWORK ID NAME DRIVER SCOPE
82ed92ae2b3e bridge bridge local
290c4fb24a0d host host local
a4a6a0f0e11e none null local
I can reproduce this, it seems to not be able to contact the server running on the host in WSL via host.docker.internal. It seems like this might be related: docker/for-win#12673
I'll have to dig into this more sometime and see if there's a way around the issue.
I suspect my issue may be related, but not on WSL. My case is running the dependabot client within a docker container.
I'm able to run this directly on a linux box (debian), no Windows, no vm involved works as expected:
dependabot update maven local/scan --local . -o dependabot.yaml
...
updater | 2023/06/15 14:32:25 INFO Starting job processing
proxy | 2023/06/15 14:32:25 [001] POST http://host.docker.internal:33593/update_jobs/cli/update_dependency_list
{"data":{"dependencies":...
proxy | 2023/06/15 14:32:25 [001] 200 http://host.docker.internal:33593/update_jobs/cli/update_dependency_list
proxy | 2023/06/15 14:32:25 [002] POST http://host.docker.internal:33593/update_jobs/cli/increment_metric
But when I effectively run the same command within a docker container, the proxy fails to reach the API:
updater | 2023/06/14 20:24:33 INFO Starting job processing
proxy | 2023/06/14 20:24:33 [001] POST http://host.docker.internal:33549/update_jobs/cli/update_dependency_list
proxy | 2023/06/14 20:24:33 [001] No response from server
updater | 2023/06/14 20:24:33 ERROR dial tcp 172.17.0.1:33549: connect: connection refused
updater |
updater | 2023/06/14 20:24:33 ERROR /home/dependabot/dependabot-updater/lib/dependabot/api_client.rb:113:in `update_dependency_list'
updater | 2023/06/14 20:24:33 ERROR /home/dependabot/dependabot-updater/lib/dependabot/service.rb:61:in `update_dependency_list'
updater | 2023/06/14 20:24:33 ERROR /home/dependabot/dependabot-updater/lib/dependabot/update_files_command.rb:28:in `perform_job'
updater | 2023/06/14 20:24:33 ERROR /home/dependabot/dependabot-updater/lib/dependabot/base_command.rb:52:in `run'
updater | 2023/06/14 20:24:33 ERROR bin/update_files.rb:23:in `<main>'
I'm not sure what I might be doing wrong. I am passing /var/run/docker.sock to my container, as well as --add-host host.docker.internal:host-gateway
Hmm yeah this might be related to the WSL issue.
Just so we're on the same page, the current network setup is this:
flowchart LR
proxy --> internet
proxy-- host.docker.internal -->api
subgraph host
api
subgraph internal
updater --> proxy
end
end
By mounting the host's Docker socket, we end up with this:
flowchart LR
proxy --> internet
proxy-- host.docker.internal --> nothing
subgraph host
nothing
subgraph internal1
api
subgraph internal2
updater --> proxy
end
end
end
The API isn't going to be routable from the layer below unless we set the port explicitly, and then bind the same port to the host.
I just tested that out and it seems to work. I can put up a PR to allow setting the API's PORT with an environment variable. Then you'll need to pass Docker options like -p 8088:8088 -e "FAKE_API_PORT=8088".
This would be wonderful! Thanks for the fast response!
I would like to confirm that this fix does address the issue. I built the client in my docker container and ran it with the new port specified, and it ran flawlessly.
Thank you again!
@cpswan I was able to get it working under WSL2 using export FAKE_API_HOST="127.0.0.1" which overrides the default Linux setting here:
Lines 44 to 46 in 940adb3
I typically default serving to 127.0.0.1 since it's more secure, but for Linux the calls get connection refused coming from a Docker container unless it's serving on 0.0.0.0. That's why I added that condition for Linux.
Strangely though in WSL2 0.0.0.0 doesn't seem to work, but setting it back to 127.0.0.1 does work!
It would be nice if this all would just work without messing with environment variables. So someone figures out how to get 127.0.0.1 working on Linux or 0.0.0.0 working on WSL, let me know or put up a PR 😄.
I'm going to close this out since we have a method for making it work. As I said above, if there are any ideas on making this work without messing with environment variables let me know and PRs welcome!