Skip to content
This repository has been archived by the owner on Jul 29, 2018. It is now read-only.

docker daemon configuration #266

Open
navidshaikh opened this issue Mar 1, 2016 · 10 comments
Open

docker daemon configuration #266

navidshaikh opened this issue Mar 1, 2016 · 10 comments

Comments

@navidshaikh
Copy link
Contributor

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.
@LalatenduMohanty
Copy link
Contributor

+1 for the idea.

@LalatenduMohanty LalatenduMohanty added this to the ADB 2.0 GA milestone Mar 2, 2016
@bexelbie
Copy link
Contributor

bexelbie commented Mar 7, 2016

+1 for

  1. Reconfig dockerd to be Unix Socket only by default in ADB VM
  2. Ensure that vagrant-service-manager plugin's provisioner reconfigures it for tcp with all IPs.

@praveenkumar
Copy link
Contributor

@navidshaikh Is it now implemented in service-manager? if yes then we can start with modify KS file.

@navidshaikh
Copy link
Contributor Author

@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.

@hferentschik
Copy link
Contributor

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.

@bexelbie
Copy link
Contributor

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.

@LalatenduMohanty
Copy link
Contributor

@bexelbie @navidshaikh This is not an issue anymore right? Can we close this?

@navidshaikh
Copy link
Contributor Author

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.

@navidshaikh
Copy link
Contributor Author

@LalatenduMohanty @praveenkumar : ping

@bexelbie
Copy link
Contributor

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants