I have following error when I try to use docker on my Mac:
FATA[0000] Get http:///var/run/docker.sock/v1.17/version: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
It doesn't matter if I use sudo or not... It doesn't matter which docker command I use or if I use brew or boot2docker to install it...
What should I do to resolve this issue ?
The Docker daemon does not run natively on a Mac. Until it does, there will never be a socket for communicating with the daemon at /var/run/. You must therefore use TCP to communicate with the daemon because the daemon must be running on another machine (or a VM). Unix sockets only talk to processes running on the local machine. The unix socket method is very secure since it is only on the local machine and you must be root (or in the docker group) to talk with this socket.
Insecure (but easy) TCP Client-Server Communications
You can run the Docker Engine in a very insecure way by setting some environment variables on the client end and starting your daemon in an insecure way on the daemon end:
Client: substitute the machine's host IP and port
DOCKER_HOST=tcp://host:2375
DOCKER_TLS_VERIFY=0
Daemon
docker -d -H tcp://0.0.0.0:2375
(see also https://docs.docker.com/reference/commandline/cli/#daemon-socket-option)
Secure TCP Communications
Since you probably don't want random people talking to your docker daemon over the internet, you should run with TLS enabled. That's complicated, but all the steps are listed in the docs. boot2docker and kitematic on Macs hides this complexity by setting up the TLS certificates for you and setting the environment variables needed to find the daemon.
Related
I have a Windows 10 Home machine (local machine) where I have installed Docker Toolbox that runs docker inside a VM. IP (192.168.0.6)
Also, there is another Windows 10 Pro machine (remote machine) that has Docker Desktop installed. IP (192.168.0.13). In the Docker Desktop setting, I have enabled "Expose daemon on tcp://localhost:2375 without TLS". At this point, I do not care about the TLS part since both the machines are on the local network. In the firewall setting, I have accepted inbound connections from port 2375.
Now I would like to run docker-compose from a local machine that connects and runs docker on the remote machine. To test connection, the command used on local machine is
docker -H tcp://192.168.0.13:2375 version
The response is
Cannot connect to the Docker daemon at tcp://192.168.0.13:2375. Is the docker daemon running?
I see that it calls https://192.168.0.13:2375/v1.40/info and not http://192.168.0.13:2375.
And in my remote machine, if I enter http://localhost:2375/v1.40/info I get a response but there is no response when I run by providing IP like http://192.168.0.13:2375/v1.40/info
I assume your docker daemon is only listening on localhost or 127.0.0.1.
You try to connect from another machine which connects to your machine with you internal network ip 192.168.0.13.
This means you need to configure your docker daemon to listen to:
192.168.0.13 = only network internal
tcp://192.168.0.13:2375
0.0.0.0 = all ip addresses
tcp://0.0.0.0:2375
In Windows you need to create a Docker-Daemon config file in:
C:\ProgramData\docker\config\daemon.json
with following content:
{
"hosts": ["tcp://0.0.0.0:2376"] # IP Address for container host
}
You can probably define a Subnet but i am not sure about this.
This is because the VM network interface is only binded to your localhost.
Try forwarding the port. From powershell or command prompt with admin privileges:
netsh interface portproxy add v4tov4 listenport=2375 listenaddress=192.168.0.13 connectaddress=127.0.0.1 connectport=2375
I have an application running on my host which has the following features: it listens to port 4001 (configurable) and only accepts connections from a whitelist of trusted IP addresses (127.0.0.1 only by default, other addresses can be be added but one by one, not using a mask).
(It's the interactive brokers gateway application which is run in java but I don't think that's important)
I have another application running inside a docker container which needs to connect to the host application.
(It's a python application accessing the IB API, but again I don't think that matters)
Ultimately I have will multiple containers on multiple machines trying to do the same thing, but I can't even get it working with one running on the same machine.
sudo docker run -t myimage
Error: Couldn't connect to TWS. Confirm that "Enable ActiveX and Socket Clients" is enabled on the TWS "Configure->API" menu.
(No response from IB Gateway on host machine)
IDEALLY I'd be able to set up the docker containers / bridge so that all the docker containers appear as if they are on a specific IP address, add it to the whitelist, and voila.
What I've tried:
1) using -p and EXPOSE
sudo docker run -t -p 4001:4001 myimage
Bind for 0.0.0.0:4001 failed: port is already allocated.
(No response from gateway)
This eithier doesn't work or leads to a "port already in use" conflict. I gather that these settings are designed for the opposite problem (host can't see a particular port on the container).
2) setting --net=host
sudo docker run -t --net=host myimage
Exception caught while reading socket - Connection reset by peer
(no response from gateway)
This should work since the docker container should now look like it's 127.0.0.1... but it doesn't.
3) setting --net=host and adding the local host's real IP address 192.168.0.12 (as suggested in comments) to the whitelist
sudo docker run -t --net=host myimage
Exception caught while reading socket - Connection reset by peer
(no response from gateway)
4) adding 172.17.0.1, ...2, ...3 to the whitelist on the host application (the bridge network is 172.17.0.0 and subsequent containers get allocated in this range)
sudo docker run -t myimage
Error: Couldn't connect to TWS. Confirm that "Enable ActiveX and Socket Clients" is enabled on the TWS "Configure->API" menu.
(no response from host)
This is horribly hacky but doesn't work eithier.
PS Note this is different from the problem of trying to run the host application IB Gateway inside a container - I am not doing that.
I don't want to run the host application inside another container, although in some ways that might be a neater solution.
Running the IB gateway is tricky on a number of different levels, including connecting to it, and especially if you want to automate the process.
We took a close look at connecting to it from other IPs, and finally gave up on it--gateway bug as far as we could tell. There is a setting to white IPs that can connect to the gateway, but it does not work and can not be scripted.
In our build process we create a docker base image, then add the gateway and any/all of the gateway's clients to that image. Then we run that final image.
(Posted on behalf of the OP).
Setting --net=host and changing the port from 4001 so it doesn't conflict with a live version of the gateway on the same network. The only IP address required in the whitelist is 127.0.0.1.
sudo docker run -t --net=host myimage
Use socat to forward port from the gateway to a new port which can listen on any address. For example, set the gateway to listen on port 4002 (localhost only) and use command in the container
socat tcp-listen:4001,reuseaddr,fork tcp:localhost:4002
to forward the port to 4001.
Then you can connect to the gateway from outside of the container using port 4001 when running the container with parameter -p 4001:4001.
In case this one is useful for another person. I tried a couple suggestions that were put here to connect from my python app running on a Docker container to a TWS IBGateway instance running on another server and none of them were 100% working. The socat option was connecting, but then the connection was being drop due an issue with the socat buffer that we couldn't fix.
The solution we found was to create an ssh tunnel from the machine that is running the Docker container to the machine that is running the TWS IBGateway.
ssh -i ib-gateway.pem <ib-gateway-server-user>#<ib-gateway-server-ip> -f -N -L 4002:127.0.0.1:4001
After you establish this ssh tunnel, you can test it running
telnet 127.0.0.1 4002
If this command run successfully, your ssh tunnel is ready. The next step would be to configure your python application to connect to 127.0.0.1 on port 4002 and start your docker container with --net=host to be able to access the ssh tunnel running on Docker host machine.
My Docker install has problems and no longer works properly. When I try to use docker export [containername].
I get the following error
FATA[0000] Get http://%2Fvar%2Frun%2Fdocker.sock/v1.18/containers/json: dial unix /var/run/docker.sock: connect: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
I would like to move the containers on this machine to a new machine that I have setup.
Is there a way to move the containers without using the CLI?
Not sure this is a CLI issue. Technically when you run a docker command it goes CLI > API > Docker daemon. Locally, the API is listening on a UNIX socket but your error says there's nothing listening on the socket. Is your Docker daemon running?
I have added
DOCKER_OPTS="-H tcp://0.0.0.0:2375"
to /etc/default/docker to make the Docker API accessible on my host machine (I'm running Docker in Virtualbox on an Ubuntu VM). However, when I try to run any Docker commands now, I just get this error message:
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
I have tried sudo service docker restart, and restarted the machine, but nothing has worked. Any idea what the problem is?
To use the daemon through the tcp socket the option -H tcp://0.0.0.0:2375 should be added to the command docker (both for the daemon and run).
To access the daemon with its default unix socket make sure that the Docker daemon is also started with the option -H=unix:///var/run/docker.sock.
Note that using the tcp is dangerous if you do not trust the network you are in. Here is the doc from the man page:
-H, --host=[unix:///var/run/docker.sock]: tcp://[host]:[port][path] to bind or unix://[/path/to/socket] to use.
The socket(s) to bind to in daemon mode specified using one or more
tcp://host:port/path, unix:///path/to/socket, fd://* or fd://socketfd.
If the tcp port is not specified, then it will default to either 2375 when
--tls is off, or 2376 when --tls is on, or --tlsverify is specified.
I have a docker daemon installed in UbuntuA machine.
I am using UbuntuB machine as the docker client.
I know that UbuntuA machine has the docker daemon installed and can do operations as well.
But I am not getting on which port it is running.
I am using this command :
sudo docker -H tcp://127.0.0.1:5555 -d &
and after this , when I use the following command:
sudo docker -H tcp://127.0.0.1:5555 info
I am getting an error : docker daemon not found .
How to find out on which port , the daemon is running?
Using the -H tcp://127.0.0.1:5555 docker daemon option on the UbuntuA machine will instruct docker to bind to the loopback network interface (127.0.0.1). As a result it will only accept connections originating from the UbuntuA machine.
If you want to accept connections incoming from any network interface use -H tcp://0.0.0.0:5555. Be aware that anyone that would be able to connect to your UbuntuA machine on port 5555 will be able to control your docker host. You need to protect it with firewall rules to allow only UbuntuB to connect to UbuntuA on port 5555.