I spent weeks trying to connect GitLab-Runner running in the docker container behind the corporate network. I try docker run --add-host<IP> to add the host IP to /etc/hosts in my container, but I can't register my Runner. I am using Cntlm Authentication Proxy Configuration for the proxy
ERROR: Registering runner....failed runner=xxxxxxxxxxxxxxx status=couldn't execute POST
against https://git.scsops.dev/api/v4/runner: POST "https://git.scsops.dev/api/v4/runner":
proxyconnect TCP: dial TCP 127.0.0.1:3128: connect: connection refused
PANIC: Failed to register the runner
Please I need help, Thank you in advance.
I would suggest following the steps in this link this will pass proxy information to containers automatically:
https://docs.docker.com/network/proxy/
Guys I need some help =)
I am trying to install docker/kubernetes/k3d/devspace on a wsl2 ubuntu machine...
My docker seems to be running fine
After creating a k3d cluster like this:
k3d cluster create dev --port 8080:80#loadbalancer --port 8443:443#loadbalancer
I am getting an error message when running kubectl cluster-info:
Unable to connect to the server: dial tcp: lookup unix on 172.25.160.1:53: no such host
Do you guys have any tips where I could start looking for the problem? I am lost
Had the same problem, apparently the kubeconfig server url set to https://unix:6443 cannot be accessed.
Try starting the cluster with --api-port 127.0.0.1:6443
This will set the server property to 127.0.0.1:6443 instead of unix:6443 which works in my case
k3d cluster create test --api-port 127.0.0.1:6443
I'm trying to run docker on windows (OS: Microsoft Windows 10 Pro 64bit, Docker ver: 18.09.0, build 4d60db4), by following the hello-world instruction here.
Then I got this following "server misbehaving" error:
Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: dial tcp: lookup <companyProxy> on 192.168.65.1:53: server misbehaving.
I tried to change the DNS (in Docker setting - Network - DNS Server) from Automatic to Fixed (8.8.8.8 or 8.8.4.4) as suggested here, but still did not solve the problem, and resulted in another type of error ("timeout exceeded").
Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers).
I am behind company's proxy, and have set the proxy (and the credentials) both on environment variable and also docker setting.
I also tried to reinstall both docker and hyperV but still got the same problem.
Can anybody help? Thanks
We had this problem on Linux behind a corporate proxy after upgrading Docker from version 17 to the latest 19 (currently 19.03.5).
# docker run hello-world
Unable to find image 'hello-world:latest' locally
docker: Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: dial tcp: lookup http on 1.2.3.4:53: server misbehaving.
1.2.3.4 is the IP of our DNS server, which itself worked fine - I could resolve different hosts, also registry-1.docker.io from Docker.
Solution
The problem was how we set the proxy globally in /etc/systemd/system/docker.service.d/http-proxy.conf. Since its an MS AD user, it contains the username in the format of domain\user like this:
[Service]
Environment="HTTP_PROXY=http://domain\user:password#proxyserver.internal:80"
Same thing for HTTPS_PROXY. While this worked on version 17, it doesn't seem to work with 19. Now the backslash seems to cause problems. Just remove it like this:
[Service]
Environment="HTTP_PROXY=http://user:password#proxyserver.internal:80"
How to check if this is a problem
I'm not sure if this changed with version 19 or already in version 18, since we skipped 18. But if you upgrade to 18 or 19 this is a thing i'd check. There is a simply way to figure it out:
docker info | grep -i proxy
If you see censored credentials like this
HTTP Proxy: http://xxxxx:xxxxx#proxyserver.internal:80
HTTPS Proxy: http://xxxxx:xxxxx#proxyserver.internal:80
then you're not affected of this issue. But if you see the plain credentials, Docker can't parse them because of the backslash or maybe other special characters included in your env variable.
The timeout in your last configuration is caused by the fact that you're not getting through the proxy to those external DNS servers (8.8.8.8 - 8.8.4.4), I think.
You should be solving the first issue, being the server misbehaving. As was the case with me, mentioned here, this was caused by the unability of docker to authenticate with the proxy. My solution was to use cntml.
The cntlm configuration is actually really straightforward if you follow their guidelines. When you have cntlm running, you need to configure docker to use that as a proxy instead of your corporate proxy. Just a plain proxy without authentication - most likely 127.0.0.1:3128, if you're running it on the same machine. cntlm will handle the authentication on the corporate proxy.
As a reference, this is the cntlm config I used:
Username <username>
Domain <domain>
Password <password>
PassLM <PassLM output of cntlm -H>
PassNT <PassNT output of cntlm -H>
PassNTLMv2 <PassNTLMv2 output of cntlm -H>
Proxy <corporate proxy>:<corporate proxy port>
NoProxy localhost, 127.0.0.*, 10.*, 192.168.*, 172.16.*.*
Listen 3128
You get the hashes by running cntlm -H -u <username>#<domain>.
Make sure you run cntlm in gateway mode cntlm -g (instead of cntlm -v).
Good luck!
I have accepted the above answer but, for an unknown reason, the problem reappeared after a few days with a slightly different error. Luckily I managed to solve it using a different setup, as written below. Hope it can help someone when the accepted answer does not work.
First of all, the condition where this error happens:
CNTLM listens to 127.0.0.1:3128,
docker proxy (set through the GUI) is 127.0.0.1:3128 both for HTTP and HTTPS
Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: dial tcp 10.0.75.1:3128: connect: connection refused
I checked this similar case but the solution also did not work for me.
I tried several different things including turning off firewall, and reproducing the initial problem (my initial question) and redoing the accepted solution, to no avail. I realized that the IP address shown in the error is not my corporate proxy, nor the Cntlm-listened port, nor my localhost, but the IP of the dockerNAT.
Then, I also noticed that when running CNTLM -g -v, below the Cntlm ready, staying in the foreground line, nothing showed up when I run docker pull hello-world (in another terminal).
Inspired by this answer, I tried to change the Cntlm.ini and the proxy setting on docker to 10.0.75.1:3128, and then restarted cntlm and docker. Now things changed slightly. The error message changed to this:
Error response from daemon: Get https://registry-1.docker.io/v2/: Parent proxy unreacheable
and Cntlm terminal now showed something when I hit the docker pull command, indicating that it somehow works. I suspected that the proxy hostname might cause the problem at this stage, since docker might not be able to access DNS server from the VM. Then I changed Cntlm.ini again, changing the hostname of the proxy into its IP address, and voila, now docker pull hello-world works normally!
(TBH I don't fully understand the network theory behind why this solution works. If anyone can give some explanation, that would be helpful.)
I met the same problem with Windows 10 (Host OS) + VMware + Ubuntu.
In my case, the problem is caused by the company's firewall.
Just in case you might meet the same problem. I wrote an article about it:
Solve: Docker pull - "... TLS handshake timeout"
I am trying to make Consul work inside a Docker container, but using Docker for Windows and Linux containers. I am using the official Consul Docker image. The documentation states that the container must use --net=host for Consul's consensus and gossip protocols.
The problem is, as far as I can tell, that Docker for Windows uses a Linux VM under the hood, and the "host" of the container is not the actual host machine, but that VM. I could not find a combination of -bind, -client and -advertise parameters (IP addresses), so that:
Other Consul agents on other hosts can connect to the local agent using the host machine's IP address.
Other containerized services on the same host can query the local agent's REST interface.
Whenever I pass the host machines IP address in the LAN through -advertise, I get these errors inside the container:
2018/04/03 15:15:55 [WARN] consul: error getting server health from "linuxkit-00155d02430b": rpc error getting client: failed to get conn: dial tcp
127.0.0.1:0->10.241.2.67:8300: connect: invalid argument 2018/04/03 15:15:56 [WARN] consul: error getting server health from "linuxkit-00155d02430b": context deadline exceeded
Also, other agents on other hosts cannot connect to that agent.
Using -bind on that address fails - my guess is, since the container is inside the Linux VM, the host machine's address is not the container's host's address, and therefore cannot be bound.
I have tried various combinations of -bind, -client and -advertise, using addresses like 0.0.0.0, 127.0.0.1, 10.0.75.2 (addresss on the Docker virtual switch) and the host machine's IP, but to no avail.
I am now wondering whether this is achievable at all. I have been trying this for quite some time, and I am despairing. Any advice would be appreciated!
I have tried the whole process without using --net=host, and everything works fine. I can connect agents across hosts, and I can query the local agents REST interface from other containerized applications... Is --net=host really crucial to the functioning of Consul?
I am trying to explore dockers. I have got boot2docker installed on my windows machine. My machine is behind corporate firewall.
When I execute the simple command like the one below, I get the error that prevents images being pulled. Any help here ?
Even when I changes the dns nameserver ( in /etc/resolv.conf) to 8.8.8.8 , I have the same issue.
I looked at other issues posted on same subject . Did not get any help .
Please help
Error
docker#boot2docker:~$ docker run -it --rm tomcat:8.0 Unable to find
image 'tomcat:8.0' locally
Pulling repository tomcat
Get link: dial tcp: loo
kup index.docker.io on 10.0.2.3:53: read udp 10.0.2.3:53: i/o timeout
When your host is on the VPN, your boot2docker-vm VM may not have access to the internet at all; in particular if your connection is bridged. You can try NAT.
https://github.com/boot2docker/boot2docker/issues/628