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

Cannot set hosts in daemon configuration #453

Open
johnnyhoffman opened this Issue Feb 1, 2017 · 39 comments

Comments

Projects
None yet
@johnnyhoffman

johnnyhoffman commented Feb 1, 2017

Expected behavior

Start docker with the value of "hosts" from the Daemon config

Actual behavior

Failure to start daemon because of conflict with -H flag

Information

  • Diagnostic ID: D6EBFDA6-3FCC-4AD3-BD57-560DCB6D3905/2017-01-31_17-30-49
  • Windows 10 Pro, Version 1607
  • Docker version 1.13.0, build 49bf474

Steps to reproduce the behavior

  1. Go to Settings in GUI
  2. Go to the Daemon tab
  3. Switch from Basic to Advanced
  4. input the following config:
{
  "hosts": [
    "tcp://0.0.0.0:2376",
    "npipe://"
  ]
}
  1. Press Apply

The error is unable to configure the Docker daemon with file C:\ProgramData\docker\config\daemon.json: the following directives are specified both as a flag and in the configuration file: hosts: (from flag: [npipe:////./pipe/docker_engine_windows], from file: [tcp://0.0.0.0:2376 npipe://])

From this stack overflow post, and the GitHub issue reference from it, I can gather that this is because docker is by default running with a -H flag. However, the suggested fix does not seem to apply to Windows. Is there a Windows fix equivalent to setting DOCKER_OPTS to ""?

@dgageot

This comment has been minimized.

Show comment
Hide comment
@dgageot

dgageot Feb 1, 2017

@johnnyhoffman Thanks for the report. hosts settings is not supported on Docker for Windows. Can I ask you why you need this feature?

dgageot commented Feb 1, 2017

@johnnyhoffman Thanks for the report. hosts settings is not supported on Docker for Windows. Can I ask you why you need this feature?

@johnnyhoffman

This comment has been minimized.

Show comment
Hide comment
@johnnyhoffman

johnnyhoffman Feb 1, 2017

@dgageot I wanted the feature so that I could securely communicate with docker on my test server (via the .NET Client for Docker Remote API). I assumed that hosts is/was supported in Docker for Windows because I was following this blog post which uses it in the same way I am attempting to use it.

The Daemon tab in the docker settings GUI tool points directly to this section of the documentation, which explicitly mentions hosts as an allowed configuration option. Perhaps the documentation should be updated, or the link in the GUI should point to a more up-to-date page.

johnnyhoffman commented Feb 1, 2017

@dgageot I wanted the feature so that I could securely communicate with docker on my test server (via the .NET Client for Docker Remote API). I assumed that hosts is/was supported in Docker for Windows because I was following this blog post which uses it in the same way I am attempting to use it.

The Daemon tab in the docker settings GUI tool points directly to this section of the documentation, which explicitly mentions hosts as an allowed configuration option. Perhaps the documentation should be updated, or the link in the GUI should point to a more up-to-date page.

@tinchou

This comment has been minimized.

Show comment
Hide comment
@tinchou

tinchou Feb 8, 2017

I'm also interested in this feature. I have a powerful desktop machine and a laptop on the same network, and I'm trying to open up my desktop docker daemon so I can run all my Linux containers there.

tinchou commented Feb 8, 2017

I'm also interested in this feature. I have a powerful desktop machine and a laptop on the same network, and I'm trying to open up my desktop docker daemon so I can run all my Linux containers there.

@simonferquel

This comment has been minimized.

Show comment
Hide comment
@simonferquel

simonferquel Feb 8, 2017

We have now an internal ticket tracking this issue. Can't give a date on when it will be enabled though.

simonferquel commented Feb 8, 2017

We have now an internal ticket tracking this issue. Can't give a date on when it will be enabled though.

@friism

This comment has been minimized.

Show comment
Hide comment
@friism

friism Feb 8, 2017

@johnnyhoffman @tinchou if we enabled this, how would you want authentication to work?

  • Windows AD login
  • docker login, using your Docker ID
  • None (not a good idea)

friism commented Feb 8, 2017

@johnnyhoffman @tinchou if we enabled this, how would you want authentication to work?

  • Windows AD login
  • docker login, using your Docker ID
  • None (not a good idea)
@tinchou

This comment has been minimized.

Show comment
Hide comment
@tinchou

tinchou Feb 8, 2017

Whatever's best for cross-platform! If one day I move that daemon to a Linux host or a Mac host, ideally it'd be transparent to me. I'm only talking to a docker daemon to run Linux Containers, I don't care about the host.

tinchou commented Feb 8, 2017

Whatever's best for cross-platform! If one day I move that daemon to a Linux host or a Mac host, ideally it'd be transparent to me. I'm only talking to a docker daemon to run Linux Containers, I don't care about the host.

@johnnyhoffman

This comment has been minimized.

Show comment
Hide comment
@johnnyhoffman

johnnyhoffman Feb 9, 2017

Thanks for the updates!
I agree with @tinchou - it would be preferable to have something OS agnostic.
My team doesn't use Windows AD, and it might be overkill to set it up for this use case.

johnnyhoffman commented Feb 9, 2017

Thanks for the updates!
I agree with @tinchou - it would be preferable to have something OS agnostic.
My team doesn't use Windows AD, and it might be overkill to set it up for this use case.

@willseward

This comment has been minimized.

Show comment
Hide comment
@willseward

willseward Feb 17, 2017

Also without that option, I believe running things like the visualizer tool and portainer are prohibited. Correct me if I'm wrong.

willseward commented Feb 17, 2017

Also without that option, I believe running things like the visualizer tool and portainer are prohibited. Correct me if I'm wrong.

@ericwj

This comment has been minimized.

Show comment
Hide comment
@ericwj

ericwj Mar 24, 2017

Perhaps this can be done really simply by putting the -H argument on the service itself so that it can be tweaked through Start parameters in Service Control Manager. You hid it and that makes this a bug...

@dgageot Can I ask you why you need this feature? I want to run swarm and to not be required to spend gigabytes of memory running docker on my dev box.

And I tried to run Docker on Nanoserver in Azure. But the docs I followed appear to be broken over this issue, as I found Docker remains inaccessible whatever I try. The error mentioned above is only visible running Docker from the start menu on Windows 10. The event log is swamped with useless events every 2 seconds, but this error isn't in it. That's a loss on Nanoserver certainly. The service should probably fail with an exit code as well. I suspect it exits gracefully even though dockerd crashed.

@friism Please, since you started about authentication, on Windows, get rid of the friggin PEM files and CA bundles is step 1. The Windows way is to find a suitable (root) certificate from dir Cert:\localmachine -Recurse and to bridge the Linux and Windows ways, configure a plain thumbprint in a config file - on Linux too.

One way to do authentication is to allow client certificates on TCP port 2376. And document a suitable New-SelfSignedCertificate call or two in the docs to create the root cert and those used for server and client authentication.

For dev machines, it's completely OK to allow remote access on TCP port 2375 without authentication. The firewall is on by default and blocks edge traversal. So only the local network can be given access even if docker is allowed through. Docker by default listens only on localhost, which is OK without authentication if *:2376 is configured with TLS and some form of authentication. But there is no reason to block configuring *:2375 instead of localhost:2375. My security is my problem. You can just warn.

The other option which enables at least Azure AD and possibly Docker and a world of alternatives on top of that is OpenID Connect.

ericwj commented Mar 24, 2017

Perhaps this can be done really simply by putting the -H argument on the service itself so that it can be tweaked through Start parameters in Service Control Manager. You hid it and that makes this a bug...

@dgageot Can I ask you why you need this feature? I want to run swarm and to not be required to spend gigabytes of memory running docker on my dev box.

And I tried to run Docker on Nanoserver in Azure. But the docs I followed appear to be broken over this issue, as I found Docker remains inaccessible whatever I try. The error mentioned above is only visible running Docker from the start menu on Windows 10. The event log is swamped with useless events every 2 seconds, but this error isn't in it. That's a loss on Nanoserver certainly. The service should probably fail with an exit code as well. I suspect it exits gracefully even though dockerd crashed.

@friism Please, since you started about authentication, on Windows, get rid of the friggin PEM files and CA bundles is step 1. The Windows way is to find a suitable (root) certificate from dir Cert:\localmachine -Recurse and to bridge the Linux and Windows ways, configure a plain thumbprint in a config file - on Linux too.

One way to do authentication is to allow client certificates on TCP port 2376. And document a suitable New-SelfSignedCertificate call or two in the docs to create the root cert and those used for server and client authentication.

For dev machines, it's completely OK to allow remote access on TCP port 2375 without authentication. The firewall is on by default and blocks edge traversal. So only the local network can be given access even if docker is allowed through. Docker by default listens only on localhost, which is OK without authentication if *:2376 is configured with TLS and some form of authentication. But there is no reason to block configuring *:2375 instead of localhost:2375. My security is my problem. You can just warn.

The other option which enables at least Azure AD and possibly Docker and a world of alternatives on top of that is OpenID Connect.

@rioux602

This comment has been minimized.

Show comment
Hide comment
@rioux602

rioux602 commented Mar 27, 2017

+1

@margic

This comment has been minimized.

Show comment
Hide comment
@margic

margic Apr 24, 2017

+1
Want this issue to run jenkins slaves in the background of a windows box.

margic commented Apr 24, 2017

+1
Want this issue to run jenkins slaves in the background of a windows box.

@louisn

This comment has been minimized.

Show comment
Hide comment
@louisn

louisn May 16, 2017

+1
I also need this feature to run jenkins slaves as windows build agents. It's a blocker.

louisn commented May 16, 2017

+1
I also need this feature to run jenkins slaves as windows build agents. It's a blocker.

@mshareghi

This comment has been minimized.

Show comment
Hide comment
@mshareghi

mshareghi May 24, 2017

+1
The lack of support here presumably prevents configuring TLS over port 2376 (as documented here). If it is supported but these instructions are wrong, please advise with the correct method.

mshareghi commented May 24, 2017

+1
The lack of support here presumably prevents configuring TLS over port 2376 (as documented here). If it is supported but these instructions are wrong, please advise with the correct method.

@chvndb

This comment has been minimized.

Show comment
Hide comment
@chvndb

chvndb May 30, 2017

Like @johnnyhoffman, I have been banging my head against the wall getting this to work, following this blog post.

This bug blocks me in my deploy process. I setup, develop and test my application locally. Then, I create a release of my application by creating tagged images which I push to a private remote docker registry. From my client I use my build system to then upgrade from the previous version of my application to the new. This fails as I need to be able to connect remotely to the docker host running on a Windows Server.

Is there any workaround in the meanwhile?

chvndb commented May 30, 2017

Like @johnnyhoffman, I have been banging my head against the wall getting this to work, following this blog post.

This bug blocks me in my deploy process. I setup, develop and test my application locally. Then, I create a release of my application by creating tagged images which I push to a private remote docker registry. From my client I use my build system to then upgrade from the previous version of my application to the new. This fails as I need to be able to connect remotely to the docker host running on a Windows Server.

Is there any workaround in the meanwhile?

@Norbinsh

This comment has been minimized.

Show comment
Hide comment
@Norbinsh

Norbinsh Oct 16, 2017

So, it's unclear what's the best approach? running on Debian, do we ignore the /etc/default/docker message saying not to configure the daemon there?
Should we edit the systemd unit instead?

Norbinsh commented Oct 16, 2017

So, it's unclear what's the best approach? running on Debian, do we ignore the /etc/default/docker message saying not to configure the daemon there?
Should we edit the systemd unit instead?

@ericwj

This comment has been minimized.

Show comment
Hide comment
@ericwj

ericwj Oct 24, 2017

One way to hurt Microsoft is to let this drag so long people give up and switch to Linux?

ericwj commented Oct 24, 2017

One way to hurt Microsoft is to let this drag so long people give up and switch to Linux?

@kiahmed

This comment has been minimized.

Show comment
Hide comment
@kiahmed

kiahmed Nov 18, 2017

Looks like they still haven't enabled it. I wanted to use host to be able to use docker engine api. So, are we saying api can't be used from a docker windows host? That't a bummer! Why auth is an issue? It could use any basic auth also with tls

kiahmed commented Nov 18, 2017

Looks like they still haven't enabled it. I wanted to use host to be able to use docker engine api. So, are we saying api can't be used from a docker windows host? That't a bummer! Why auth is an issue? It could use any basic auth also with tls

@nicferrier

This comment has been minimized.

Show comment
Hide comment
@nicferrier

nicferrier Nov 25, 2017

I am having issues with this as well. I was trying to use docker for windows from WSL (WIndows Subsystem for Linux) because there are plenty of blog posts around saying it's possible.

There is also this FAQ https://docs.docker.com/docker-for-windows/faqs/#how-do-i-connect-to-the-remote-docker-engine-api which suggests that the host option was turned on for Docker for Windows at one point.

So I'm a bit confused by this thread which suggests that it wasn't.

Any clarification?

nicferrier commented Nov 25, 2017

I am having issues with this as well. I was trying to use docker for windows from WSL (WIndows Subsystem for Linux) because there are plenty of blog posts around saying it's possible.

There is also this FAQ https://docs.docker.com/docker-for-windows/faqs/#how-do-i-connect-to-the-remote-docker-engine-api which suggests that the host option was turned on for Docker for Windows at one point.

So I'm a bit confused by this thread which suggests that it wasn't.

Any clarification?

@kiahmed

This comment has been minimized.

Show comment
Hide comment
@kiahmed

kiahmed Nov 25, 2017

I created thread weeks ago on docker forum with screenshot but no response. Its turned off on windows what does that mean it works on Linux and mac? I have it on mac but mac has its own issue doesn't connect with network bridge (at least I couldn't final a solution yet).. Did anybody succeed using the engine api on Linux hosts?

kiahmed commented Nov 25, 2017

I created thread weeks ago on docker forum with screenshot but no response. Its turned off on windows what does that mean it works on Linux and mac? I have it on mac but mac has its own issue doesn't connect with network bridge (at least I couldn't final a solution yet).. Did anybody succeed using the engine api on Linux hosts?

@clivecrous

This comment has been minimized.

Show comment
Hide comment
@clivecrous

clivecrous Dec 5, 2017

Is there absolutely no way to get docker for windows to listen externally then? This is a huge issue for me.

clivecrous commented Dec 5, 2017

Is there absolutely no way to get docker for windows to listen externally then? This is a huge issue for me.

@amrun

This comment has been minimized.

Show comment
Hide comment
@amrun

amrun Jan 17, 2018

Does anybody have an update on this? It is an issue of high importance, regarding that docker containers are intended to be highly portable and so on... :(

amrun commented Jan 17, 2018

Does anybody have an update on this? It is an issue of high importance, regarding that docker containers are intended to be highly portable and so on... :(

@ericwj

This comment has been minimized.

Show comment
Hide comment
@ericwj

ericwj Jan 21, 2018

Just redirect. This thread appears to be pork.

ericwj commented Jan 21, 2018

Just redirect. This thread appears to be pork.

@amrun

This comment has been minimized.

Show comment
Hide comment
@amrun

amrun Jan 30, 2018

@clivecrous and others
My problem at the moment was limited to not be able to use Portainer to manage my local Docker for Windows installation.
I got it running and documented it in this blogpost https://dungeonfire.blogspot.ch/2018/01/use-portainer-locally-with-docker-for.html
Maybe it is of any help for you guys at other problems.

amrun commented Jan 30, 2018

@clivecrous and others
My problem at the moment was limited to not be able to use Portainer to manage my local Docker for Windows installation.
I got it running and documented it in this blogpost https://dungeonfire.blogspot.ch/2018/01/use-portainer-locally-with-docker-for.html
Maybe it is of any help for you guys at other problems.

@heaths

This comment has been minimized.

Show comment
Hide comment
@heaths

heaths Feb 7, 2018

I'm running Docker client/server version 17.12.0-ce and "hosts" is working for me. Has for a couple of stable versions, actually. What version are you running?

screenshot

heaths commented Feb 7, 2018

I'm running Docker client/server version 17.12.0-ce and "hosts" is working for me. Has for a couple of stable versions, actually. What version are you running?

screenshot

@mariusmarais

This comment has been minimized.

Show comment
Hide comment
@mariusmarais

mariusmarais Feb 7, 2018

@heaths That's exactly what I need, but the "Apply" button is greyed out on my side with the red error "hosts": Cannot be used in Docker for Windows.

Changing "hosts" to [] in linux-daemon-options.json allows the change to take place, but the daemon does not start up after that.

Engine: 18.02.0-ce-rc2-win51 (15631) Edge channel

mariusmarais commented Feb 7, 2018

@heaths That's exactly what I need, but the "Apply" button is greyed out on my side with the red error "hosts": Cannot be used in Docker for Windows.

Changing "hosts" to [] in linux-daemon-options.json allows the change to take place, but the daemon does not start up after that.

Engine: 18.02.0-ce-rc2-win51 (15631) Edge channel

@jlouisfoster

This comment has been minimized.

Show comment
Hide comment
@jlouisfoster

jlouisfoster Feb 15, 2018

For those trying to connect the Windows Server 2016 dockerhost to Jenkins, you don't need to use the "hosts" parameter in the daemon. You can install docker ee using this procedure: https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server | and then use the -H option when launching docker as a service following this procedure: https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon
Exact parameter would be: sc config docker binpath= ""C:\Program Files\docker\dockerd.exe" --run-service -H tcp://0.0.0.0:2375"

Just ensure that the proper ports are open and in jenkins connect using the IP address of the Windows Server 2016 hosts.

jlouisfoster commented Feb 15, 2018

For those trying to connect the Windows Server 2016 dockerhost to Jenkins, you don't need to use the "hosts" parameter in the daemon. You can install docker ee using this procedure: https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server | and then use the -H option when launching docker as a service following this procedure: https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon
Exact parameter would be: sc config docker binpath= ""C:\Program Files\docker\dockerd.exe" --run-service -H tcp://0.0.0.0:2375"

Just ensure that the proper ports are open and in jenkins connect using the IP address of the Windows Server 2016 hosts.

@msmith-techempower

This comment has been minimized.

Show comment
Hide comment
@msmith-techempower

msmith-techempower Mar 22, 2018

Screenshot (Was not a long-lived image host; that's my bad. See heaths from above as similar)

@heaths I am on the same version as you, but I get "hosts": Cannot be used in Docker for Windows.

I have also confirmed this in edge (which is currently 18.03.0-ce-rc4)

msmith-techempower commented Mar 22, 2018

Screenshot (Was not a long-lived image host; that's my bad. See heaths from above as similar)

@heaths I am on the same version as you, but I get "hosts": Cannot be used in Docker for Windows.

I have also confirmed this in edge (which is currently 18.03.0-ce-rc4)

@raesene

This comment has been minimized.

Show comment
Hide comment
@raesene

raesene Mar 29, 2018

I'll add one to @heaths on the "this works for me" pile. The trick to getting hosts working appears to be putting Docker for Windows into "windows containers" mode. If I try the same process in "linux containers" mode it doesnt' work. with recent updates though you can run Linux containers fine in Windows container mode with --platform linux.

I've tried it on two systems today and it worked fine. I've done a write-up of the process here https://raesene.github.io/blog/2018/03/29/WSL-And-Docker/

raesene commented Mar 29, 2018

I'll add one to @heaths on the "this works for me" pile. The trick to getting hosts working appears to be putting Docker for Windows into "windows containers" mode. If I try the same process in "linux containers" mode it doesnt' work. with recent updates though you can run Linux containers fine in Windows container mode with --platform linux.

I've tried it on two systems today and it worked fine. I've done a write-up of the process here https://raesene.github.io/blog/2018/03/29/WSL-And-Docker/

@kuritsu

This comment has been minimized.

Show comment
Hide comment
@kuritsu

kuritsu May 3, 2018

+1, this feature is very needed if we want to run a Jenkins and a slave dockerized and separated both in Windows.

kuritsu commented May 3, 2018

+1, this feature is very needed if we want to run a Jenkins and a slave dockerized and separated both in Windows.

@teohhanhui

This comment has been minimized.

Show comment
Hide comment
@teohhanhui

teohhanhui Jun 21, 2018

@raesene The installation instructions for Docker in WSL should be: https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-using-the-repository

It's a very bad idea to download the binary manually as it'll not be automatically updated.

teohhanhui commented Jun 21, 2018

@raesene The installation instructions for Docker in WSL should be: https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-using-the-repository

It's a very bad idea to download the binary manually as it'll not be automatically updated.

@raesene

This comment has been minimized.

Show comment
Hide comment
@raesene

raesene Jun 22, 2018

@teohhanhui So the problem with using the Docker-CE install from the Docker site for the client end in WSL is that you're not actually looking to install the full package there, and that installs the Docker daemon as well as the client. In WSL we're just looking for the client binary.

Trade-off as you mention is that you need to maintain it manually...

raesene commented Jun 22, 2018

@teohhanhui So the problem with using the Docker-CE install from the Docker site for the client end in WSL is that you're not actually looking to install the full package there, and that installs the Docker daemon as well as the client. In WSL we're just looking for the client binary.

Trade-off as you mention is that you need to maintain it manually...

@teohhanhui

This comment has been minimized.

Show comment
Hide comment
@teohhanhui

teohhanhui Jun 23, 2018

@raesene But if having the docker daemon binary around doesn't cause any issues...

teohhanhui commented Jun 23, 2018

@raesene But if having the docker daemon binary around doesn't cause any issues...

@teohhanhui

This comment has been minimized.

Show comment
Hide comment
@teohhanhui

teohhanhui Jun 23, 2018

@raesene It's also important to mention that what you get with --platform linux is LCOW (Linux Containers On Windows), which has some issues.

teohhanhui commented Jun 23, 2018

@raesene It's also important to mention that what you get with --platform linux is LCOW (Linux Containers On Windows), which has some issues.

@Johnsel

This comment has been minimized.

Show comment
Hide comment
@Johnsel

Johnsel Jun 30, 2018

As a workaround you can run a TCP proxy, easiest to run it in a container using:
docker run -it --rm -p 2376:2375 hpello/tcp-proxy docker.for.win.localhost 2375
Make sure you check the "Expose daemon without TLS" checkbox in the Docker for Windows settings under general. You can now connect to the host using docker -H=tcp://xyz:2376 ps
Obviously this is wildly insecure and you should ensure this port will never be exposed to anything even remotely untrustworthy.

You may get an error saying server gave HTTP response to HTTPS client which is probably due to the docker-machine env command having set the DOCKER_TLS_VERIFY env var. You can unset it with:
unset DOCKER_TLS_VERIFY to tell the client to not use TLS.

Johnsel commented Jun 30, 2018

As a workaround you can run a TCP proxy, easiest to run it in a container using:
docker run -it --rm -p 2376:2375 hpello/tcp-proxy docker.for.win.localhost 2375
Make sure you check the "Expose daemon without TLS" checkbox in the Docker for Windows settings under general. You can now connect to the host using docker -H=tcp://xyz:2376 ps
Obviously this is wildly insecure and you should ensure this port will never be exposed to anything even remotely untrustworthy.

You may get an error saying server gave HTTP response to HTTPS client which is probably due to the docker-machine env command having set the DOCKER_TLS_VERIFY env var. You can unset it with:
unset DOCKER_TLS_VERIFY to tell the client to not use TLS.

@b01

This comment has been minimized.

Show comment
Hide comment
@b01

b01 Jun 30, 2018

I need to be able to connect to the docker daemon on Windows 10 so that I can configure Jetbrains PHPStorm. Its an IDE that allows you to build PHP applications. I have a container with PHP installed. The IDE wants to connect to the Docker Engine API over TCP (currently no other way) in order to detect and use the PHP binary installed in the container, so that I can aid in auto-completion and profiling.

b01 commented Jun 30, 2018

I need to be able to connect to the docker daemon on Windows 10 so that I can configure Jetbrains PHPStorm. Its an IDE that allows you to build PHP applications. I have a container with PHP installed. The IDE wants to connect to the Docker Engine API over TCP (currently no other way) in order to detect and use the PHP binary installed in the container, so that I can aid in auto-completion and profiling.

@alexdashkov

This comment has been minimized.

Show comment
Hide comment
@alexdashkov

alexdashkov Jul 20, 2018

@b01 I have the same issue with Pycharm.

alexdashkov commented Jul 20, 2018

@b01 I have the same issue with Pycharm.

@KylePreuss

This comment has been minimized.

Show comment
Hide comment
@KylePreuss

KylePreuss Aug 24, 2018

+1 on this. I'm trying to use the Microsoft Docker.DotNet NuGet package to interact with the Docker daemon on a separate Windows host (in Linux container mode). I was quite surprised to see this is not possible.

KylePreuss commented Aug 24, 2018

+1 on this. I'm trying to use the Microsoft Docker.DotNet NuGet package to interact with the Docker daemon on a separate Windows host (in Linux container mode). I was quite surprised to see this is not possible.

@tinda

This comment has been minimized.

Show comment
Hide comment
@tinda

tinda Aug 30, 2018

I found docker settings "expose daemon on tcp://loclhost:2375 with TLS" checked may be work with Pycharm

image

tinda commented Aug 30, 2018

I found docker settings "expose daemon on tcp://loclhost:2375 with TLS" checked may be work with Pycharm

image

@msmith-techempower

This comment has been minimized.

Show comment
Hide comment
@msmith-techempower

msmith-techempower Sep 21, 2018

I have been playing with WSL lately, and while exposing the daemon on tcp://localhost:2375 without TLS works at a high level, it kind of falls apart as I mess with it more and more.

TechEmpowerFrameworkBenchmarks relies heavily on Docker, and it expects 3 machines to be set up such that a docker daemon is accepting requests. For local development on Linux machines, this is trivial as we mount /var/run/docker.sock into the running container, and allow the container to talk to the host docker daemon via that socket. In a production setting we simply lock the three machines on a local network and configure the daemon to listen on 10.0.0.x and accept tcp connections. Both work great.

However, WSL+D4W seems to have an issue: I can run the immediate container fine, but when that container attempts to communicate with the docker daemon (via tcp://localhost:2375), I get a 'Connection refused'.

The simplest way to illustrate my particular issue is to try out Docker in Docker with Docker4Windows running and exposing the daemon on tcp://localhost:2375 without TLS:

$ docker -H tcp://0.0.0.0:2375 run --network=host hello-world
$ docker -H tcp://0.0.0.0:2375 run --network=host docker:dind docker -H tcp://0.0.0.0:2375 run --network=host hello-world

The first run is to prove that D4W works while accepting connections over tcp to localhost: it does.

I expect the second one to run a docker container that has the docker client available, then tell that docker client to issue the same call as the first one from within the container. However, this fails with "docker: Cannot connect to the Docker daemon at tcp://0.0.0.0:2375. Is the docker daemon running?."

The interesting thing here is that with the --network=host flag, it should be using the host network stack, so I expect localhost to effectively hit my windows host from within the container, but that doesn't seem to be true.

EDIT: Playing with this some more, I'm not sure this is a Docker4Win issue and may actually be a Docker issue... checking on a linux env.

EDIT2: Actually, I tried the above example on Linux and it ran perfectly with -H tcp://0.0.0.0:2375 added to /usr/lib/systemd/system/docker.service.

msmith-techempower commented Sep 21, 2018

I have been playing with WSL lately, and while exposing the daemon on tcp://localhost:2375 without TLS works at a high level, it kind of falls apart as I mess with it more and more.

TechEmpowerFrameworkBenchmarks relies heavily on Docker, and it expects 3 machines to be set up such that a docker daemon is accepting requests. For local development on Linux machines, this is trivial as we mount /var/run/docker.sock into the running container, and allow the container to talk to the host docker daemon via that socket. In a production setting we simply lock the three machines on a local network and configure the daemon to listen on 10.0.0.x and accept tcp connections. Both work great.

However, WSL+D4W seems to have an issue: I can run the immediate container fine, but when that container attempts to communicate with the docker daemon (via tcp://localhost:2375), I get a 'Connection refused'.

The simplest way to illustrate my particular issue is to try out Docker in Docker with Docker4Windows running and exposing the daemon on tcp://localhost:2375 without TLS:

$ docker -H tcp://0.0.0.0:2375 run --network=host hello-world
$ docker -H tcp://0.0.0.0:2375 run --network=host docker:dind docker -H tcp://0.0.0.0:2375 run --network=host hello-world

The first run is to prove that D4W works while accepting connections over tcp to localhost: it does.

I expect the second one to run a docker container that has the docker client available, then tell that docker client to issue the same call as the first one from within the container. However, this fails with "docker: Cannot connect to the Docker daemon at tcp://0.0.0.0:2375. Is the docker daemon running?."

The interesting thing here is that with the --network=host flag, it should be using the host network stack, so I expect localhost to effectively hit my windows host from within the container, but that doesn't seem to be true.

EDIT: Playing with this some more, I'm not sure this is a Docker4Win issue and may actually be a Docker issue... checking on a linux env.

EDIT2: Actually, I tried the above example on Linux and it ran perfectly with -H tcp://0.0.0.0:2375 added to /usr/lib/systemd/system/docker.service.

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