Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Info about accessing the network under WSL2 #114

Closed
tostt opened this issue Oct 2, 2022 · 8 comments
Closed

Info about accessing the network under WSL2 #114

tostt opened this issue Oct 2, 2022 · 8 comments
Labels
bug Something isn't working

Comments

@tostt
Copy link

tostt commented Oct 2, 2022

This is not really a bug report, but more a suggestion.
I encountered a network issue under WSL2 which I fixed by modifying the docker-compose file.

On WSL2, when initially running docker compose --profile auto up --build I got a network access problem:

#0 0.595 Cloning into 'repositories/stable-diffusion'...
#0 5.636 fatal: unable to access 'https://github.com/CompVis/stable-diffusion.git/': Could not resolve host: github.com

The fix was to add (in the docker-compose file) a network key to each service which has a build section.

As an example (for the download service) :
Before change:

build: ./services/download/

After change:

build:
  context: ./services/download/
  network: "host"

This fix could either be documented in the wiki or implemented in the docker-compose YAML file. For the latter, the host key could be left out to avoid any breaking changes. This way it would be easier for users to add the network key in case the problem occurs.

@tostt tostt added the bug Something isn't working label Oct 2, 2022
@AbdBarho
Copy link
Owner

AbdBarho commented Oct 2, 2022

Thanks for the suggestion, I am very interested in the reason why it did not work with the default virtual network that is created by docker.

I would presume this is a docker configuration problem, rather than something related to this repo.

Do you have some sort of proxy setup? Or maybe using a different / private DNS setup that did not allow the containers to reach the internet?

BTW. I am also running inside WSL2 and I did not face this problem

@tostt
Copy link
Author

tostt commented Oct 2, 2022

Thank you for getting back.
To answer your question, I didn't install a proxy.
I ran /cat/etc/resolv.conf both in the container and in ubuntu.

  • In the container : nameserver 127.0.0.11
  • In ubuntu : nameserver 172.17.64.1

I'm not sure what it means. But I believe my install isn't completely standard for some reason. I you want me to run commands to investigate more let me know. For me it's working great now. So thank you for your work. 👏

@AbdBarho
Copy link
Owner

AbdBarho commented Oct 2, 2022

Ran the same commands on my side

  • WSL nameserver 172.24.176.1
  • container nameserver 127.0.0.11

Which I would guess is similar to yours and is correct, container is resolving through docker and wsl is resolving through windows DNS server.

TBH this seems like a wsl kink, some users reported a restart is enough, others say its ip collision in the docker / host bridge, also here, others say you need to enable the Hyper-V extension

I will add this info to the wiki, is there is simpler solution than adding it manually to each service?

@tostt
Copy link
Author

tostt commented Oct 2, 2022

Thanks for the tips, I will look into your leads (restarting docker didn't help).
Regarding a simpler compose file, I tried to concoct something with the YAML merge key (“<<” ) in multiple ways, but that didn't work.

Another option is to use a config file and launch the services with the --env-file option. However, I think it's overkill.

@AbdBarho
Copy link
Owner

AbdBarho commented Oct 3, 2022

I updated the wiki with a small description and a link back to this issue.

@AbdBarho AbdBarho closed this as completed Oct 3, 2022
@TWIISTED-STUDIOS
Copy link

TWIISTED-STUDIOS commented Oct 31, 2022

I updated the wiki with a small description and a link back to this issue.

build:
context: ./services/AUTOMATIC1111
network: "host"

I just tried this and when i try to run the command again i am then met with services.build Additional property context is not allowed any idea why?

@TWIISTED-STUDIOS
Copy link

I updated the wiki with a small description and a link back to this issue.

build: context: ./services/AUTOMATIC1111 network: "host"

I just tried this and when i try to run the command again i am then met with services.build Additional property context is not allowed any idea why?

ok so i fixed this issue using another method by adding dns to the docker desktop engine and setting a bip as well, but now I'm experiencing the bash error

@tostt
Copy link
Author

tostt commented Nov 1, 2022

The context and network items must be indented as shown in the top comment.

I updated the wiki with a small description and a link back to this issue.

build: context: ./services/AUTOMATIC1111 network: "host"

I just tried this and when i try to run the command again i am then met with services.build Additional property context is not allowed any idea why?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants