When running kitchen test with docker it should connect to the docker daemon and run the test kitchen.
Actual behavior
Currently when running under the latest Docker version 1.11.1, build 5604cbe. The test kitchen will fail immediately trying to find the Docker daemon.
Information
Creating …
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
------Exception-------
Class: Kitchen::ActionFailed
Message: Failed to complete #create action: [Expected process to exit with [0], but received ‘1’
---- Begin output of docker -H unix:///var/run/docker.sock build -f C:/ramsay-repo/cookbooks/test/Dockerfile-kitchen20160603-7976-1fs37e2 . ----
STDOUT:
STDERR: Cannot connect to the Docker daemon. Is the docker daemon running on this host?
---- End output of docker -H unix:///var/run/docker.sock build -f C:/ramsay-repo/cookbooks/test/Dockerfile-kitchen20160603-7976-1fs37e2 . ----
Ran docker -H unix:///var/run/docker.sock build -f C:/ramsay-repo/cookbooks/test/Dockerfile-kitchen20160603-7976-1fs37e2 . returned 1]
Please see .kitchen/logs/kitchen.log for more details
Also try running kitchen diagnose --all for configuration
Hi there, thanks for the report. Could you provide some more information to help us reproduce this? Not everyone is familiar with the tools you mention.
We use Chef to automate the creating of some machines. This involves running ruby code to setup the machine. A way to test the code is to run them in a test kitchen which just creates a VM or docker image and runs the code in that. We use the docker kitchen docker driver, https://github.com/test-kitchen/kitchen-docker to create the test kitchen. Since trying the docker beta the driver has stopped being able to connect to the daemon.
This will be relatively difficult to reproduce unless your familiar with the technologies, as it involves installing Chef, creating a cookbook, and then testing that cookbook using the driver mentioned above. http://kitchen.ci/docs/getting-started/ will explain it all but was hoping someone might have been familiar with it.
On Windows, the Docker daemon does not listen on unix:///var/run/docker.sock (this was not the case with toolbox either). I recommend removing the -H parameter, that should cause the docker CLI to do the right thing (which is to use \\.\pipe\docker_engine named pipe on Windows, although there’s also a HTTP fallback at docker:2375 - the latter may go away in the future though).