Info about accessing the network under WSL2

[tostt]

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.

[AbdBarho]

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]

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]

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]

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]

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

[TWIISTED-STUDIOS]

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]

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]

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?