adb-atomic-developer-bundle
adb-atomic-developer-bundle copied to clipboard
docker daemon configuration
Presently docker
daemon is configured to run on unix socket as well as TCP socket.
For VirtualBox provider, one needs to configure private networking for the box. Private networking is attached to box after the box and its services (including docker) has booted up and running, which causes the TLS certs for docker daemon to be generated for IP provided by eth0
, which is incorrect.
To tackle this, service-manager plugin re-configures the docker daemon when box boots up.
ATM, we are configuring and generating the TLS certs for docker when box boots up, which stays as useless entity in the box as well as extra code in KS file.
Proposal: Configure docker daemon to run only on unix socket in KS file and re-configure docker daemon to run on TCP and generate certs as part of the service-manager plugin. Few more points
- If docker is configured on unix socket,
vagrant ssh
use case is covered. - If user wants to connect to daemon using docker CLI, user needs to have service-manager plugin, having service-manager plugin installed and box booted up, the daemon will be guaranteed to be configured to run on TCP as well.
+1 for the idea.
+1 for
- Reconfig dockerd to be Unix Socket only by default in ADB VM
- Ensure that vagrant-service-manager plugin's provisioner reconfigures it for tcp with all IPs.
@navidshaikh Is it now implemented in service-manager? if yes then we can start with modify KS file.
@navidshaikh Is it now implemented in service-manager? if yes then we can start with modify KS file.
We did not have it implemented in plugin yet, if we can do this, have a PR in ADB modifying the kickstart with a scratch build, then we can have PR in plugin and test against the brewed box.
which causes the TLS certs for docker daemon to be generated for IP provided by eth0, which is incorrect.
Is the core issue not that the service-manager assumes a specific network interface to be up and running. Provided the service-manager implements the right action hook, I would think that one should be able to extract the correct IP from the Vagrant metadata.
I think we need to re-examine the ip detection code over time, however no one seems to have a great answer here. Everyone I can find does something similar to what we do. That said, I'd rather us leverage another code base if we can so we don't reinvent the wheel.
@bexelbie @navidshaikh This is not an issue anymore right? Can we close this?
This is not an issue anymore right? Can we close this?
It was never an issue, the problem is
- docker daemon inside the box is configured to run on unix as well as TCP socket
- For TCP socket, the configuration is wrong, no client (without interaction of plugin) will ever be able to connect to daemon using the certs, because the certs are generated for wrong IP address
This point here is to be precise in configuring the docker daemon and have it configured only with unix socket. When needed (with vsm plugin), we re-configure the daemon to run on TCP socket along with unix socket and we do it correctly.
@LalatenduMohanty @praveenkumar : ping
Moving to start docker on request is still valid, imho. It makes docker work like other services and sets us up for rkt or other dev ideas. I'd call this lower priority but a good idea.