When I'm trying to get the Docker integration of IntelliJ (Ultimate 2018.3.3) working together with local running Docker Desktop (Version 2.0.0.3 (31259)), I'm getting the following error:
Cannot connect: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: localhost:127.0.0.1:2375
caused by: java.net.ConnectException: Connection refused: no further information
I found the following question: IntelliJ cannot connect to protected tcp Docker socket
But this solution leads to this error:
Cannot connect: com.github.dockerjava.api.exception.DockerClientException: Enabled TLS verification (DOCKER_TLS_VERIFY=1) but certificate path (DOCKER_CERT_PATH) is not defined.
I searched for the cert path of Docker Desktop but found nothing yet because the new Hyper-V solution of Docker Desktop doesn't run docker-machine native any more.
The solution is to enable exposing the Docker deamon on tcp:localhost:2375 without TLS.
This option can be found in general settings of Docker Desktop (Version 2.0.0.3).
Setting / General / Expose daemon on tcp://localhost:2375 without TLS
Related
docker desktop on mac is getting error:
Unable to connect to the server: x509: certificate signed by unknown authority
The following answers didn't helped much:
My system details:
Operating system: macOS Big Sur Version 11.6
Docker desktop version: v20.10.12
Kubernetes version: v1.22.5
When I do:
kubectl get pods
I get the below error:
Unable to connect to the server: x509: certificate signed by unknown authority
Posting the answer from comments
As appeared after additional questions and answers, there was a previous installation of rancher cluster which left its traces: certificate and context in ~/.kube/config.
The solution in this case for local development/testing is to delete entirely ~/.kube folder with configs and init the cluster from the scratch.
If you are using a corporate laptop, and everything you do goes through a proxy, you will get this message. Hence, when docker desktop tries to connect to the server defined in ~/.kube/config, it will try to go through the proxy and you will need the cert issued by the company. Long story short, you are getting blocked by the the company... To fix, you can add the no proxy props, adding what ever value server: internal.docker defined in~/.kube/config . Meaning, if I am connecting to docker cluster which runs locally in my laptop, do not direct my traffic through proxy.
When doing docker info, after setting no proxy, you should see something like this.
docker info | grep -i proxy
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal,localhost,127.0.0.1,.local,.us.example.com,.examplecorp.com,.examplevcn.com,kubernetes.docker.internal
hubproxy.docker.internal:5000
When working behind a corporate proxy (automatically activated in Windows) by Cisco AnyConnect(v4.7.03052) VPN, I'm unable to pull any docker image either from our docker nexus registry or the official registry.
Funny enough, if I set the proxy settings in the config.json and pass the proxy as build-arg my containers are able to build(from previously pulled images) and talk to the exterior.
Only the docker engine is unable to access the internet through the proxy.
I've already tried the following:
Set the HTTP_PROXY/HTTPS_PROXY as environments variables
Set the proxy settings in the Docker Desktop proxy section - Docker doc
Set the resources network IP to the non-secured Cisco AnyConnect routes IPv4
No firewall rules seems to block the outbound request from the docker engine service.
Edit the deamon.json used by the docker service to register the mirror registries.
Stackoverflow answers not working in this case: docker-win10; docker on windows; docker image proxy
Platform info:
Win 10 - Build 19401
Docker Desktop 4.4.4(73704)
Docker Engine 20.12.12 (Linux container on Hyper-V)
Cisco AnyConnect v4.7.03052
Error message on docker pull:
λ docker pull traefik:2.0
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)
Based on the similar stackoverflow issue briefly executing the command below had it working for a short time:
cd "C:\Program Files\Docker\Docker"
./DockerCli.exe -SwitchDaemon
This was a regression that slipped in the 4.4.4 see github issue.
It seems to have been resolved in the v4.5.0
I've installed Kubernetes on windows 10 pro. I ran into a problem where the UI wasn't accepting the access token I had generated for some reason.
So I went into docker and reset the cluster so I could start over:
But now when I try to apply my configuration again I get an error:
kubectl apply -f .\recommended.yaml
Unable to connect to the server: dial tcp 127.0.0.1:61634: connectex: No connection could be made because the target machine actively refused it.
I have my KUBECONFIG variable set:
$env:KUBECONFIG
C:\Users\bluet\.kube\config
And I have let kubernetes know about the config with this command:
[Environment]::SetEnvironmentVariable("KUBECONFIG", $HOME + "\.kube\config", [EnvironmentVariableTarget]::Machine)
Yet, the issue remains! How can I resolve this? Docker seems fine.
This stack overflow answered my question.
This is what it says:
If you have kubectl already installed and pointing to some other environment, such as minikube or a GKE cluster, be sure to change
context so that kubectl is pointing to docker-desktop:
kubectl config get-contexts
kubectl config use-context docker-desktop
Apparently I had installed minikube which is what messed it up. Switching back to a docker context is what saved the day.
I use Docker CE for Windows on latest Windows 10 and have built an image with a
script that runs a test against a web server.
(A litmus test suite for a WebDAV server to be exact, but I think the problem
is general.)
I run the web server on a Powershell console:
> wsgidav -p 8080 -H localhost
21:04:19.107 - <13348)> wsgidav INFO : Running WsgiDAV/3.0.0a3 Cheroot/6.4.0 Python/3.6.5
21:04:19.107 - <13348)> wsgidav INFO : Serving on http://localhost:8080 ...
From another Powershell console, I run my script in a Docker container (using FROM alpine).
The script starts and tries to access the endpoint, but does not succeed:
> docker pull mar10/litmus
> docker run --rm -p 8080:8080 mar10/litmus http://gateway.docker.internal:8080
-> running `basic':
0. init.................. FAIL (connection refused by `gateway.docker.internal' port 8080: Operation timed out)
I tried so far
Using the gateway.docker.internal hostname
using -p PORT:PORT
using --net=host
restarting the docker daemon (which interestingly sometimes also was neccessary to
fix timeouts in docker pull)
different IP addresses for the web server (127.0.0.1, localhost, 0.0.0.0, local IP)
Nothing worked so far (although the failure message may be different).
Maybe I just missed a working combination of the above, or any other trick?
FWIW, I was able to solve it by building the container with the --network host option and use a real IP of the client (instead of localhost or 0.0.0.0).
Details here: https://hub.docker.com/r/mar10/docker-litmus/
When I use boot2docker to start the boot2docker-vm, then in gitbash I run the docker version command I get the following:
$ docker version
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 7c8fca2
OS/Arch (client): windows/amd64
FATA[0021] An error occurred trying to connect: Get https://192.168.59.103:2376/v1.18/version: dial tcp 192.168.59.103:2376: ConnectEx tcp: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
However when I go into virtual box I see the boot2docker-vm is running.
When I stop the boot2docker-vm, & then start it myself - I can use the vm to use docker - it would be much easier to use gitbash to work with it...anyone have any ideas?
You have to init shell inside gitbash, use:
$ $(boot2docker shellinit)
in terminal.
Here is documentation for mac: https://docs.docker.com/installation/mac/.
This blog post describes the configuration of VirtualBox for Win64 systems after the boot2docker installation.
Change VirtualBox Global Settings to provide DHCP server on network adapter #2 instead of #3 with exactly the same settings as of #3
Change boot2docker-vm network configuration of the host-only network adapter from preconfigured adapter #3 to #2