The question about the official document on how to config the Windows’s dockerd
On official document, Windows 10, Docker Desktop version 20, I have set all hidden files could be seen, but I still can not find the C:\ProgramData\docker\config\daemon.json. Instead, I found the same name file in C:\Users\user\.docker\daemon.json, I tried to change it to look like what your document said:
Interesting. That might work (however I don’t completely understand why that portforwarding helps) so thanks for sharing your solution with us, but could you explain why you would not change that file in case of Docker desktop? Isn’t that file mounted to the desktop vitual machine?
@haishui250 Your shared config is not a json. If this was really the content you saved it is understandable why Docker could not start.
First of all, the json does not have the opening and closing parenthesis of the root node which is probably just how you copied the content out, and second there was no comma after the hosts configuration line:
"hosts": ["tcp://192.168.59.3:2376"]
The correct line would have been:
"hosts": ["tcp://192.168.59.3:2376"],
I know it is an old question so you have probably solved it by now, but it might help someone else. Always make sure the json is valid. On linux, I usually use the jq command to do that.
Well the issue I ran into was that docker desktop would not start after adding the hosts directive to it.
If you do a netstat -an |find /i “2375” you will see the port is only available via 127.0.0.1:2735 the loopback. Which in a nutshell is why I proxied it.
It might make sense if the intend it to make the docker engine port accessible for the whole LAN.
But it does so in an unproteded way, whoever can access the port, can control the docker engine from a remote host in the LAN. If you intend to expose the docker engine port to the whole network, at least protect it with tls and certificate based authentification.
If this is not the intend, then better let the hosts configuration as it was, as the docker engine is still reachable for the docker cli the way it was.
WARNING: exposing the docker engine port unprotected could be an unnecessary potential security risk!
I agree, you can use the firewall to only allow traffic from the Jenkins master and the windows docker desktop.
Because my instance is only educational and on my personal network I am not as concerned.
My intent was to help anyone else struggling with the Jenkins Server → Windows Docker Desktop setup. I had the same connectivity issue and the amount of posts regarding this that pointed to things that did not work are pretty numerous. I love when people post answers to even old posts as it helps people get past issues.
I have been teaching myself devops tools, jenkins, terraform, puppet, git. I will say most of the videos are super out dated, when I get to be more familiar I may create some new ones.
So your answer is about a usecase where a remote service (in your case an externaly running Jenkins master) tries to access the docker engine from Docker Desktop. After the context is clear, this indeed is a valid solution for that scenario - still the implications must be clear, so people understand the implications of this actions and how to mitigate/control the implications…
It’s much appreciated to straighten out unanswered issues or answers that are workarounds!
Again this is being used for educational purposes. However, as in the diagram you can setup your internal network, your windows firewall to only allow the docker traffic to the necessary ports from the Jenkins server, this would ensure that no other machines, or actors could access and control your docker agent.
Hope this clears it up.
And as stated above you need to run the following command to make that port available:
