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

Windows Container with Docker: Cannot reach httpd in container from host (Win2016 TP5) #253

Closed
mathiasconradt opened this issue May 9, 2016 · 12 comments

Comments

@mathiasconradt
Copy link

mathiasconradt commented May 9, 2016

I initially posted this on stackoverflow:

I have a Windows Server 2016 TP5 machine that I use as a container host.

I have a Windows Container running that I manage with Docker. Inside this container I have an Apache httpd running on port 88.

The port mapping when I start the container is: 0.0.0.0:80->88/tcp, so I map port 80 of my container host to port 88 of the container. This is the output from docker inspect: http://pastebin.com/AVem1eGV

I can now reach the Apache http start page from any other computer in the network through the DNS or IP.

In my case:

But the same does not work when I try to call the same from the host system itself or from inside the container. So, on the host system, I try to access the same URL via browser or wget, and getting:

wget : Unable to connect to the remote server

in both cases.

But I can ping the host from both the host itself as well as the container.

From the host:

C:\>ping test2016-3.company.com    
Ping wird ausgeführt für TEST2016-3.company.com [fe80::847a:1430:8a10:b120%4] mit 32 Bytes Daten:

From the container:

PS C:\> ping documents.test2016-3.company.com
Pinging documents.test2016-3.company.com [10.10.1.162] with 32 bytes of data:
which seems to be able to resolve the name.

What does work though is to call the Apache default page via the container hostname (which is win-de6u4068naf) and its running port directly (not through the port mapping), both from the host as well as inside the container:

http://win-de6u4068naf:88/

Just going the route through the container host hostname and mapped port from the host or container itself does not work properly!

Firewall rules allow everything on port 80 from any remote address or to port 80 (=inbound and outbound rules are both set to "allow" for "any").

I know that Microsoft/Docker changed the networking code base of the container/docker support from Windows Server 2016 TP4 to TP5. Not sure if that's related, or whether this is a bug or I'm having something not configured correctly yet.

I made a test and left Docker/Container out of the picture above and installed a plain Apache httpd itself on the container host system on port 80 (and no Docker running at all) just to check whether such setup works or not, in order to be sure that it is actually somehow Docker/Container related and not a problem with my network/host configuration in general. And this works fine, I can reach the Apache from outside as well as from the host itself, thus it must be a Docker/Container related problem.

Environment:

  • Windows Server 2016 TP5
  • Docker version 1.12.0-dev, build 2b97201
@StefanScherer
Copy link
Contributor

I also tried different things to be sure that my setup isn't broken. I also can't use the port mapping described in https://msdn.microsoft.com/virtualization/windowscontainers/management/container_networking in TP5 and this docker:

C:\Users\vagrant> docker version
Client:
 Version:      1.12.0-dev
 API version:  1.24
 Go version:   go1.5.3
 Git commit:   2b97201
 Built:        Tue Apr 26 23:51:36 2016
 OS/Arch:      windows/amd64

Server:
 Version:      1.12.0-dev
 API version:  1.24
 Go version:   go1.5.3
 Git commit:   2b97201
 Built:        Tue Apr 26 23:51:36 2016
 OS/Arch:      windows/amd64

I can access the web server with the container's IP address and the port used inside the container. A docker network inspect nat shows the container, firewall rules exist as described.

Is this still a work in progress?

@mathiasconradt
Copy link
Author

mathiasconradt commented May 9, 2016

@StefanScherer Good to know that I'm not the only one with this issue. So, your case is even more extreme, because you cannot access via host hostname and mapped port at all, while for me, it's working from outside/any other PC on the network, just not from the container host (or the container respectively) itself.

@JMesser81
Copy link
Contributor

@mathiasconradt, @StefanScherer - This is a known limitation in our Windows NAT implementation (WinNAT) that you cannot access the external port in a static port mapping directly from the container (NAT) host.

@StefanScherer
Copy link
Contributor

@JMesser81 Oh, thank you. I have never tried to curl from outside of my TP5 VM to the host port. And yes, it works.

@mathiasconradt
Copy link
Author

@JMesser81 Ok,thanks for the info. Good to know.

@mgansler-intland
Copy link

Is there a workaround?

@ghost
Copy link

ghost commented May 19, 2017

@mgansler-intland Are you on the TP5 Server 2016 OS? This post is from a year ago.

If you are having the same problem but on a different OS, there's a solid chance it's a different underlying cause.

If you can provide some more info about your setup (ideally repro steps) I'm happy to help.

@mgansler-intland
Copy link

@mylesbkeating1993 thanks for responding. I know this post is a year old but I'm facing the same issue. We are evaluating the option to move to using Windows Containers for our CI chain. I've started with creating a Jenkins Image and running it on the (virtualized) Windows 2016 1607 (build 14393.1198) Host. From this Host I cannot access the Jenkins instance but I can from another client in the same network.

in the meantime:
Since then, I have installed the Jenkins master on the Host itself and tried to spawn docker containers from there. It kinda works, but I have to use a network with the "transparent" driver so that the jenkins slave can access the master running on the host. But now I'm facing the issue, that I cannot reach our source code repository (DNS is not working and I can't ping the IP address).

tl;dr
What do I need to do to get a container that can be reached from the host and other clients on the network while at the same time can reach the host and the internet?

@ghost
Copy link

ghost commented May 31, 2017

@mgansler-intland Sorry for delay, been traveling.

OK so @kallie-b will know more than me, but here's what I have after a brief search. I haven't had time to try this stuff out, so take it with a grain of salt).

  1. Here's a tutorial
  2. You could also check out Stefan Scherer's Jenkins repos to see if there's any differences
  3. Can't say if it's related but here's some Docker/Jenkins CI reading

Is there anything else that's relevant about your network (e.g., do you use a proxy for internet access)?

@StefanScherer
Copy link
Contributor

@mgansler-intland You can access the Jenkins master from the host by the container IP address. Let's say you have started your Jenkins with something like docker run -d -p 8080:8080 jenkins. To open the default browser use

start http://$(docker inspect -f '{{ .NetworkSettings.Networks.nat.IPAddress }}' jenkins):8080

If you really need access from local host, add a port forwarding rule ( netsh interface portproxy ... ), but this also depends on the random IP address of you Jenkins container. So after a restart you have to update that manually.

@StefanScherer
Copy link
Contributor

And to connect some dots there are some further links in StefanScherer/dockerfiles-windows#145 to other projects starting to use Jenkins with Windows containers. What I have seen it's all a work in progress, there also are some pull requests in jenkins repos to fix some plugins to work inside containers better. Hard topics are eg. working within a volume mount and using Git/Unix tools based on MSYS2 which does not fully work right now due to TTY issues.

@jzabroski
Copy link

@StefanScherer Can you update https://hub.docker.com/r/stefanscherer/registry-windows/ - it says that single machine docker container doesnt work right still.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants