cstpdk
commented
9 years ago Hello there,
Your link points to two lines, that are trivially similar to those before them. I assume a mistake in your link? In case not: They denote a name for the systemd service file, docker.service, and a command, start, which means that the unit will run rather than only being enabled.
Anyway, it's great that you ask this question, as it reminds me to get this repo cleaned up at some point in the near future. The unit file for the docker service is taken from a CoreOS default docker service file some time back. I think some of the options are redundant with new versions of docker. The important part in this context is that:
-
The docker daemon is started with a static bridge ip
--bip=172.17.42.1/16
-
The docker daemon is using both its own bridge ip and a public dns adress for all containers spawned:
--dns 172.17.42.1 --dns 8.8.8.8
The above enables me to dnsmasq a hostname (.local) on the bridge ip, meaning that the docker daemon will get the requests, which will hit haproxy and continue on their service discovery path.
The rest of the service file mimicks CoreOS' default completely so as to not create inconsistencies. One interesting bit is the NOFILE and NPROC limits, which are discussed here, and explained here (sorry, you have to search, no anchors).
The docker options are well described with
docker --help
But for thoroughness:
- -d Start in daemon mode
- -s=btrfs, use btrfs instead of AUFS. This is supported and preferred by CoreOS for speed, honour and glory
- -r=false, used to be do not restart units. Looks deprecated now, at least doesn't appear docker --help in version 1.4. The idea is that fleet will handle this instead of the docker daemon
- -H=fd://, dictates which host the docker daemon will bind to
Let me know if some of the above answers your question!
gegere
Greetings, I noticed in your cloud-config.yaml file, the following highlights regarding Docker would you be able to help me and explain?