Red Hat Bugzilla – Bug 1290588
Docker daemon in the CDK is not accessible outside the vagrant image
Last modified: 2016-03-29 03:38:46 EDT
Description of problem:
Docker daemon in the CDK is not accessible outside the vagrant image. According to the output of 'vagrant adbinfo', the Docker daemon should be available:
I don't see anything abound to 2376 when the vagrant image is up and /etc/sysconfig/docker does not include the -H host binding directive. Looking at the daemon process I see:
/usr/bin/docker daemon --selinux-enabled --storage-opt dm.no_warn_on_loop_devices=true --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/VolGroup00-docker--pool --add-registry rcm-img-docker01.build.eng.bos.redhat.com:5001 --add-registry registry.access.redhat.com --insecure-registry rcm-img-docker01.build.eng.bos.redhat.com:5001 --insecure-registry 172.30.0.0/16
Version-Release number of selected component (if applicable):
CDK 2 Beta 3
Steps to Reproduce:
1. 'vagrant up' in the rhel-ose directory of the CDK
2. capture required env vars with 'vagrant adbinfo' and export them
3. invoke any docker client command outside the vm (e.g. 'docker ps')
docker command cannot connect to daemon.
Ability to use docker client commands like 'docker ps' and 'docker build' outside the vagrant image.
I'm able to work around this issue by updating /etc/sysconfig/docker to include the following in the OPTIONS var:
-H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375
Is this an appropriate workaround or is there a preferred alternative?
Thanks for the detailed reply and the quick fix! I tested with the above settings and noticed that the cert used by the Docker daemon in the CDK appears to use 127.0.0.1 in its CN vs. the IP used by the Docker client outside the Vagrant image (10.1.2.2).
Here's the output from any docker client command outside the VM (e.g. 'docker info'):
An error occurred trying to connect: Get https://10.1.2.2:2376/v1.20/containers/json: x509: certificate is valid for 127.0.0.1, not 10.1.2.2
The only workarounds I can think of here are either:
a) Disable tlsverify for the Daemon.
b) Generate a new set of self-signed certs.
Is there another option?
@Keith: Should this bug be closed ?
This was happened due to VagrantFile option in beta-3 and it is now resolved. Closing this bug as 'worksforme'.