#538 (comment)

and #559

for some historical context.

I think this would be a great time to also switch to the official unprivileged nginx image, as root isn't required if the ports are mapped anyways.

This would require to change the nginx pid file and the listen port, but the rest could remain the same.

@joshtrichards oh, I didn't know about that.

Yeah, docker on windows is still some sort of mystery. Sadly, I can not test this :/

Thanks for the information.

@peschmae yes, that's another good idea (that can be implemented independent from this improvement).

Since the nginx-proxy autodetects the port, the change in the yml file should be minimal to none. To be safe, you can add the VIRTUAL_PORT env variable to the web service.

It's possible it's handled better under Docker for Windows these days. It's been years since I used Docker on Windows. Unfortunately, I don't have an online Windows workstation handy to test on at the moment.

If someone is able to test a bit on a current setup and report back that would be informative.

Nowadays Docker for Windows uses WSL2. WSL2 is de-facto linux distro running inside Windows and all the tests I do on docker containers i do them in WSL2, without any problems in the past >2 years.

I am unsure on how the image will work on WS2022 + HyperV but I will try it in the next days to see how it behaves on Hyper-V hosts. Docker docs claims there's no difference between HyperV and WSL2.

The only case that I see de-facto untestable is Docker Business + VMware ESXi and I'm pretty sure if there's someone with that combo, he can just run a Linux-based VM with docker inside.

WSL2

Yeah I semi-suspected as much. It'd certainly be great if we could clean this up and still work for >80% of use cases out there.

Just tested on a virtual Windows Server 2022 Datacenter, it uses WSL2 too, so no problems there. I can't enable Hyper-V due hypervisor limitations, probably someone running VMWare hypervisor see this and test it ;)

Alright, so leaning towards making this change. Just want to make sure:

What about remote docker hosts via DD? #559 (comment)

• Is this still a thing?
• Do we care enough that we need to support that scenario?
• Even if yes/yes, is it truly worth complicating our standard example stacks with the clutter it creates (i.e. our current situation)?
• Or... (again, only if yes/yes): What if we just document it instead and/or provide DD specific examples?

Alright, so leaning towards making this change. Just want to make sure:

What about remote docker hosts via DD? #559 (comment)

* Is this still a thing?

* Do we care enough that we need to support that scenario?

* Even if yes/yes, is it truly worth complicating our standard example stacks with the clutter it creates (i.e. our current situation)?

* Or... (again, only if yes/yes): What if we just document it instead and/or provide DD specific examples?

On Windows OS, Docker Desktop uses WSL2 / HyperV too and my last comment still stands. From my reading over the internet I can tell there's no difference between WSL2 and HyperV, so there will be no problems. And honestly I don't think we need to document so edge case, where someone not only uses docker desktop on windows, but he uses it on two separated machines. Even if we get a thousand issues on this, we can always add it at later stage or at least document it.