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

Port binding does not work for locahost #458

Closed
minherz opened this Issue Feb 2, 2017 · 32 comments

Comments

Projects
None yet
@minherz
Copy link

minherz commented Feb 2, 2017

Expected behavior

When running windows container with -p<host_port>:<exposed_port> I expect to be able to access the application in container via localhost:<host_port>.

Actual behavior

I need to discover the container IP and access the application in container via <container ip>:<exposed port> only. The application cannot be accessed via localhost:<host_port>.

Information

  • Diagnostic ID: F9F388E9-7AB0-4CE8-BD59-045CF28124A7/2017-02-02_13-49-56
  • Docker for Windows: 1.13.1-rc1-beta40 (9961) Channel: beta 0d026e1
  • Host: Windows 10 x64 Enterprise Version 1607 (OS Build 14393.693)

Steps to reproduce the behavior

  1. Create ASP.NET Core 1.1 web application with a project name AspNetCoreWebApp1
  2. Create Docker image using these commands
FROM microsoft/dotnet:nanoserver
ARG source=./bin/Release/PublishOutput/
COPY $source /app/
WORKDIR /app
ENV ASPNETCORE_URLS http://*:8282
EXPOSE 8282
ENTRYPOINT ["dotnet", "AspNetCoreWebApp1.dll"]

  1. Build the image by calling docker build . -t AspNetCoreWebApp1 from the project root directory.
  2. Run container from the image using docker run -it -d -p 88:8282 AspNetCoreWebApp1
  3. Open http://locahost:88 in the browser on the host

@rn rn added the area/wincon label Feb 2, 2017

@friism

This comment has been minimized.

Copy link

friism commented Feb 2, 2017

This is working as expected: https://blog.sixeyed.com/published-ports-on-windows-containers-dont-do-loopback/

@londoncalling we should document this.

@minherz

This comment has been minimized.

Copy link

minherz commented Feb 2, 2017

Does it mean that using an ethernet interface IP i cannot access the exposed port either? Say, my host has ethernet interface with IP 10.0.0.100 and I have an exposed port bound to the port 88 of the host. Does the above mean that I still cannot access the container by 10.0.0.100:88 from the host?

@friism

This comment has been minimized.

Copy link

friism commented Feb 2, 2017

@minherz you cannot access it from the host, but other hosts on the network will be able to access 10.0.0.100:88

@minherz

This comment has been minimized.

Copy link

minherz commented Feb 3, 2017

Thank you, @friism. Is there a plan to introduce this functionality into roadmap? Although it does not have a big difference for production, this hindrance complicates the development process.

@rn

This comment has been minimized.

Copy link
Contributor

rn commented Feb 3, 2017

@minherz I don't know about MSFTs plans to make this available. With Linux containers on Windows, we have a great deal of flexibility because we have our own component (VPNKit) in the network path.With Windows containers we do not have the necessary hooks to do the same.

@minherz

This comment has been minimized.

Copy link

minherz commented Feb 3, 2017

Thank you.

@minherz minherz closed this Feb 3, 2017

@friism

This comment has been minimized.

Copy link

friism commented Feb 3, 2017

I do believe Microsoft is working on making exposed ports available on localhost for Windows containers. @kallie-b can perhaps help clarify.

@kallie-b

This comment has been minimized.

Copy link

kallie-b commented Feb 6, 2017

@minherz -- apologies for the delay, and I'll be happy to clarify.

We are working on this, and we know that it's a complication that is causing frustration in the development process. There are two cases we're aware of:

  1. Host --> container communication using the host IP
  2. Container --> host communication using localhost (or 127.0.0.1)

The first item is a fix that we have resolved, and should become available soon as a Windows update. We are still working on the second item, and we aim to make the fix available as soon as possible.

@minherz

This comment has been minimized.

Copy link

minherz commented Feb 7, 2017

@kallie-b, great news! And thank you for the update. If there is a chance that you can provide a KB number for the anticipated update, i will appreciate that.

@kallie-b

This comment has been minimized.

Copy link

kallie-b commented Feb 7, 2017

@minherz, unfortunately I'm unable to provide a KB number for the update--even internally we tend to have only estimates for such things. But if you keep an eye on the Windows Insider updates (I imagine you're already a part of the program, but here's the link just in case), you should see the change soon. Sorry I can't help with more specifics!

@minherz

This comment has been minimized.

Copy link

minherz commented Feb 8, 2017

Thank you a lot.

jonashackt added a commit to jonashackt/ansible-windows-docker-springboot that referenced this issue Feb 23, 2017

Finally fully working Healthcheck with a workaround because we can´t …
…use localhost docker/for-win#458, so we have to obtain the Docker containers Hyper-V IP address - and we also have to workaround this workaround because of templating problems with Powershell Go templates interpreted by Jinja2 with a temporary textfile, see http://stackoverflow.com/a/32279729/4964553, which itself induced the workaround to not pullute the IP address form the textfile with carriage returns

@BartDubois BartDubois referenced this issue May 16, 2017

Closed

Allow url_prefix to define only url path #193

2 of 2 tasks complete
@OliverRC

This comment has been minimized.

Copy link

OliverRC commented Sep 1, 2017

I think it is ridiculous that:

a) This was closed. I don't care that it's a Windows issue. Docker says they support windows and should work with Microsoft to resolve this fundamental use case.
b) After almost a year this issue still persists.

Not allowing local loopbacks to containers is a massive fail and completely undermines the value that docker provides from a local development environment standpoint.

@JanneRantala

This comment has been minimized.

Copy link

JanneRantala commented Sep 1, 2017

@OliverRC I agree completely. Allowing loopbacks would be essential to local development like you said. Is there any news on this feature, @kallie-b or someone else? When can we expect MS to ship this?

@jonashackt

This comment has been minimized.

Copy link

jonashackt commented Sep 21, 2017

Would also love to hear some news!

@JanneRantala

This comment has been minimized.

Copy link

JanneRantala commented Sep 21, 2017

@jonashackt @OliverRC This is the reply I got in Twitter:
https://twitter.com/stefscherer/status/906463103503695872

Although it's not directly from MS but might give some hint on when it should happen. I'd still like to hear the official version from MS people, how about @kallie-b? :)

@kallie-b

This comment has been minimized.

Copy link

kallie-b commented Mar 12, 2018

Hi all,

We now have support for using localhost/loopback to access your container's published ports on Windows 10. Here's the announcement for this support, which is available starting with Windows 10 Insider build 17025.

@daschott @jmesser

@adragoset

This comment has been minimized.

Copy link

adragoset commented Mar 20, 2018

Is there a roadmap for when this functionality will be made available/ported to windows server 2016 for windows containers? For instance i have a windows host running a collection of nanoserver containers that need to communicate with each other. These services communicate with each other through the loopback with -net=host on my linux hosts which is convenient because there is no need to fiddle with trying to discover container ip addresses, force containers onto static ip addresses, do container linking.

@daschott

This comment has been minimized.

Copy link

daschott commented Apr 6, 2018

@adragoset this functionality is available from Windows Server Insider Build 17035 onwards

@SeriousM

This comment has been minimized.

Copy link

SeriousM commented May 9, 2018

Is this feature available in Windows 10 1803? I'm trying hard to get it working on 1803 but no luck..

@adragoset

This comment has been minimized.

Copy link

adragoset commented May 20, 2018

Does not work in Windows Server1803 with lcow containers and docker for windows edge. Haven't tested it to see if its working with pure windows containers yet.

@daschott

This comment has been minimized.

Copy link

daschott commented May 20, 2018

@SeriousM I created a repro machine using a recent Windows 10 1803 build and Docker version 18.05-ce from the Edge channel.

I used the command docker run -p 8080:80 microsoft/iis to try and repro. I am able to use loopback and access the container using http://localhost:8080 or http://127.0.0.1:8080.

What docker version are you using? Does the above work for you?

@adragoset

This comment has been minimized.

Copy link

adragoset commented May 21, 2018

I'll give the iis test windows container a try. But it didn't work running a lcow test webserver container.
docker run -d --name web-test -p 80:8000 crccheck/hello-world

could not access port 80 from localhost.

Trying to run docker run -p 8080:80 microsoft/iis result in no manifest for windows/amd64

I think in on the wrong version of docker-ee. Are there instructions to get the correct version of docker-ee onto windows server version 1803?

Install commands were:

Uninstall-Module DockerMsftProvider -force
Install-Module DockerProvider -force
Install-Package -Name docker -ProviderName DockerProvider -RequiredVersion preview -Force
Start-Service Docker

docker version:
Client:17.10.0-ee-preview-3
Server:17.10.0-ee-preview-3

Windows Server version:
OS-Version: 1803
OS-Build: 17666
Installed on Bare Metal

@SeriousM

This comment has been minimized.

Copy link

SeriousM commented May 23, 2018

Same issue herer @adragoset, just OS-Build is 17661.

@SeriousM

This comment has been minimized.

Copy link

SeriousM commented May 24, 2018

Could we reopen this issue please?

@daschott

This comment has been minimized.

Copy link

daschott commented May 25, 2018

@SeriousM @adragoset We have investigated this further and I can confirm that this is indeed a known issue. We are actively working on a fix for this and I will let you know once it is out!

@CuddleBunny

This comment has been minimized.

Copy link

CuddleBunny commented Jun 15, 2018

@daschott - could we re-open either this issue, #204, or create a new one so folks waiting on this have something to track?

@daschott

This comment has been minimized.

Copy link

daschott commented Jun 19, 2018

@SeriousM @adragoset Thank you for your patience -- I wanted to give you a quick update here. We have checked in a fix for this that should be available in Windows Insider build 17692 and above. Since this is an Insider build, I will try to validate that there are no other regressions that could cause this to fail and post back here.

We are also working on all the checkmarks that are needed to be able to propagate this fix to Windows April 2018 Update and Windows Server, version 1803. I will post back here if a KB is released.

@daschott

This comment has been minimized.

Copy link

daschott commented Jun 27, 2018

@SeriousM @adragoset Just wanted to confirm that I validated the fix to make sure it works, both on a VM and my personal physical workstation from Windows Insider build 17692 and above. For example, I tried builds 17692 and 17704.

If you are on an older build and you are seeing this issue (e.g. 17686) please check for a network adapter with an APIPA (169.254.x.y) address. The workaround is to disable any adapters which have an APIPA (169.254.x.y) IP address assigned.

That being said, we are still working on servicing this fix back to Windows April 2018 Update and Windows Server, version 1803.

@HunderlineK

This comment has been minimized.

Copy link

HunderlineK commented Jul 4, 2018

Okay, I had this issue, and it was related to where I was running the commands.

Running the command with gitbash would fail to bind the ports properly, but running docker run ... on cmd works just fine

@LordRahl90

This comment has been minimized.

Copy link

LordRahl90 commented Jul 11, 2018

@HunderlineK Its still not binding with golang even while running it on cmd

@daschott

This comment has been minimized.

Copy link

daschott commented Jul 30, 2018

@SeriousM @adragoset @HunderlineK @LordRahl90 @CuddleBunny
Thanks for patiently waiting! We backported the container localhost/loopback access fix for Windows April 2018 Update (Windows 10 version 1803) through KB4340917, available now.

To validate this fix, you can use docker run -p 8080:80 microsoft/iis command. Once the container is running, you should be able to use loopback and access the container using http://localhost:8080 or http://127.0.0.1:8080.

@thinkriver

This comment has been minimized.

Copy link

thinkriver commented Sep 28, 2018

@daschott
I still have this issue after updating Windows 10 pro to September 26, 2018—KB4458469 (OS Build 17134.320)https://support.microsoft.com/en-us/help/4458469/windows-10-update-kb4458469

I have tried following cmd:
docker run -p 8080:80 microsoft/iis command

and access http://localhost:8080 is not working for me. But I can use host's IP address to access container, like http://10.24.10.10:8080 is working. Nether localhost nor 127.0.0.1 works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment