New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

server: Add socket activation #3105

Merged
merged 14 commits into from Jan 28, 2014

Conversation

Projects
None yet
@philips
Contributor

philips commented Dec 7, 2013

This adds the ability to socket activate docker by passing in
-H fd://* along with examples systemd configuration files.

The fastest way to test this is to run:

/usr/lib/systemd/systemd-activate -l 127.0.0.1:2001 /usr/bin/docker -d -H 'fd://*'
docker -H tcp://127.0.0.1:2001 ps

This PR is an updated version of #2054

@SvenDowideit

This comment has been minimized.

Contributor

SvenDowideit commented Dec 7, 2013

oh boy @philips you're going to need to help me here, by adding some documentation - both to the commands.go -? help, and to the cli.rst.

in the cli.rst case, we need to tell the user under what circumstances they should choose which (mix) of the 3 options, and what the possible issues are.

@philips

This comment has been minimized.

Contributor

philips commented Dec 7, 2013

@SvenDowideit Sure, I will work on adding the docs.

@philips

This comment has been minimized.

Contributor

philips commented Dec 7, 2013

@SvenDowideit Take a look at 0682ba1

@philips

This comment has been minimized.

Contributor

philips commented Dec 7, 2013

@canoon @tianon @shykes @EpocSquadron @vieux Thoughts on the approach to systemd socket activation in this PR?

@philips

This comment has been minimized.

Contributor

philips commented Dec 10, 2013

@SvenDowideit Ping? How do the docs look?

@philips

This comment has been minimized.

Contributor

philips commented Dec 11, 2013

@SvenDowideit See aa8bb5a for improved docs.

@SvenDowideit

This comment has been minimized.

Contributor

SvenDowideit commented Dec 11, 2013

@tianon

This comment has been minimized.

Member

tianon commented Dec 11, 2013

I think now that we've got some docs we need to get @vieux @shykes @crosbymichael and @creack to take a look.

@philips

This comment has been minimized.

Contributor

philips commented Dec 11, 2013

@canoon Could you take a look too?

@jamtur01

This comment has been minimized.

Contributor

jamtur01 commented Dec 14, 2013

@SvenDowideit @philips I'd suggest adding some whys to the documentation and an embedded example rather than linking to a contrib one.

@SvenDowideit

This comment has been minimized.

Contributor

SvenDowideit commented Dec 14, 2013

@jamtur01 I though so to originally, but now I wonder if this is something only very few people will be setting up (ie packagers and a few that make custom systemd setups). If that is the case, then adding too much information to our docco will confuse more.

that said - I know little about Systemd - so I don't really feel confident about it.

@jamtur01

This comment has been minimized.

Contributor

jamtur01 commented Dec 14, 2013

I wasn't thinking so much about paragraphs but perhaps one more paragraph saying "why should I care" and a quick example. I think that gives a flavor without going overboard. But also see where you are coming from.

@philips

This comment has been minimized.

Contributor

philips commented Dec 14, 2013

@jamtur01 @SvenDowideit I really don't think anyone will care but packagers. As for the why:

"Using socket activation has the advantage that the socket file is immediately available for docker clients to connect to even while docker -d is doing initialization. For systems using socket activation this means a fast and dependency free boot. It also means that docker -d doesn't need to be explicitly started and can be started on demand by the first docker client."

Is this sufficient?

@SvenDowideit

This comment has been minimized.

Contributor

SvenDowideit commented Dec 16, 2013

@philips is this PR about systemd specific socket stuff, or does this apply to all systems?

What are 'systems using socket activation' - and how would the docker user know?

its really not clear to me from what you wrote.

Also - whats the disadvantage? Again, if what you wrote is the entire story, it reads like we don't need the other 2 types of socket.

using my best guesses, as I'm a luddite :)

Systemd socket activation allows the docker daemon to be started on demand by systemd, when docker clients connect to it.

I presume that means that containers are not automatically restarted at boot (unlike now)

I also wonder what happens when the first docker client runs docker images - at this point, if you run docker images while the docker -d is still initialising, things fail, because the daemon hasn't finished finding all the images - will it wait the 90 seconds, or will it say please try again, i'm starting.

@philips

This comment has been minimized.

Contributor

philips commented Dec 16, 2013

On Sun, Dec 15, 2013 at 6:36 PM, Sven Dowideit notifications@github.com wrote:

@philips is this PR about systemd specific socket stuff, or does this apply to all systems

It is "systemd specific" in that systemd is the only init system that
implements socket activation. However, the spec and fd passing
protocol is generic and can be used by other systems.

What are 'systems using socket activation' - and how would the docker user know?

As I mentioned above the only people who are really going to care
about this feature are people writing init configs. I don't think the
average user should know or care how docker -d is started. If they
are interested they should read the authoritative docs on the subject
which are already linked in this PR.

Also - whats the disadvantage? Again, if what you wrote is the entire story, it reads like we don't need the other 2 types of socket.

There is no disadvantage on systems that support socket activation. It
is 100% upside.

Systemd socket activation allows the docker daemon to be started on demand by systemd, when docker clients connect to it.

I presume that means that containers are not automatically restarted at boot (unlike now)

Sure, if you want that feature you have to start docker up at boot. In
the init file I gave in contrib docker starts at boot as normal.

I also wonder what happens when the first docker client runs docker images - at this point, if you run docker images while the docker -d is still initialising, things fail, because the daemon hasn't finished finding all the images - will it wait the 90 seconds, or will it say please try again, i'm starting.

The socket exists and all requests will queue in the internal Kernel
socket buffers. If you read the socket activation docs I linked in
this PR it explains how it all works and the advantages to boot times
and simplicity of dependency management.

Thanks,

Brandon

@canoon

This comment has been minimized.

canoon commented Dec 16, 2013

@philips Thanks for taking this this.

Whats the reasoning for mount --make-rprivate /?

Otherwise it looks good.

@philips

This comment has been minimized.

Contributor

philips commented Dec 16, 2013

@canoon lxc needs it and it is from the original systemd unit file: https://github.com/dotcloud/docker/blob/master/contrib/init/systemd/docker.service

@philips

This comment has been minimized.

Contributor

philips commented Dec 16, 2013

What is left to do to get this merged?

@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Dec 16, 2013

@philips Looks good so far. Let me spin up a box with systemd to verify that this works.

@philips

This comment has been minimized.

Contributor

philips commented Dec 16, 2013

@crosbymichael Great, thanks. Highly recommend the /usr/lib/systemd/systemd-activate tool for testing the flags out, way easier than setting up unit files for testing.

@philips

This comment has been minimized.

Contributor

philips commented Dec 18, 2013

@crosbymichael How did the testing go?

Using ``fd://*`` will work perfectly for most setups but you can also specify individual sockets too ``docker -d -H fd://3``.
If the specified socket activated files aren't found then docker will exit.
You can find examples of using socket activation with docker and systemd in the `docker source tree <https://github.com/dotcloud/docker/blob/master/contrib/init/systemd/socket-activation/>`.

This comment has been minimized.

@SvenDowideit

SvenDowideit Dec 18, 2013

Contributor

Hey @philips thankyou for your patience - with your confirmations in the PR discussion, I think I have only one tiny refinement - I'd like to make it bleadingly obvious to the reader who (might know that tcp means exposed on the network, and unix:// is default) has not heard of systemd, that they should ignore this choice (ie, leave fd:// to the packagers)

I think the tiniest change we can do to achieve this is to change To run the daemon with socket activation` to add one word:

To run the daemon with Systemd socket activation`

I suspect you need to rebase too - the -H line has changed :)

This comment has been minimized.

@philips

philips Dec 18, 2013

Contributor

fixed with your change in 61a21e3

@philips

This comment has been minimized.

Contributor

philips commented Dec 18, 2013

I rebased everything onto master again to make this PR mergeable.

@philips

This comment has been minimized.

Contributor

philips commented Dec 27, 2013

What is left to do on this PR? It seems stuck again.

@EpocSquadron

This comment has been minimized.

EpocSquadron commented Dec 30, 2013

Bump.

@philips

This comment has been minimized.

Contributor

philips commented Jan 4, 2014

Rebased this onto master again and added two new changes based on master:

@danscan

This comment has been minimized.

danscan commented Jan 4, 2014

Can't wait for this to merge!

@shykes

This comment has been minimized.

Collaborator

shykes commented Jan 4, 2014

Ok I think we can do a final review this week-end or monday, sorry for the delay, holiday backlog :)

On Fri, Jan 3, 2014 at 9:25 PM, dscanlonpa notifications@github.com
wrote:

Can't wait for this to merge!

Reply to this email directly or view it on GitHub:
#3105 (comment)

@@ -64,6 +64,11 @@ the ``-H`` flag for the client.
# both are equal
To run the daemon with `systemd socket activation <http://0pointer.de/blog/projects/socket-activation.html>`, use ``docker -d -H fd://``.

This comment has been minimized.

@metalivedev

metalivedev Jan 7, 2014

Contributor

This link format is not correct and it ends up rendering as "activation <http://...". Please fix this by appending an underscore:

`systemd socket activation <http://0pointer.de/blog/projects/socket-activation.html>`_
@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Jan 28, 2014

@philips There are still issues with travis

@philips

This comment has been minimized.

Contributor

philips commented Jan 28, 2014

@crosbymichael Fixed in 340b229. I was not in the habit of running with -s for simplify. Thanks.

@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Jan 28, 2014

There is something else wrong, this needs rebased or something because it cannot be merged

philips added some commits Dec 7, 2013

vendor: add github.com/coreos/go-systemd/activation
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
server: add socket activation
This adds the ability to socket activate docker by passing in
`-H fd://*` along with examples systemd configuration files.

The fastest way to test this is to run:

```
/usr/lib/systemd/systemd-activate -l 127.0.0.1:2001 /usr/bin/docker -d -H 'fd://*'
docker -H tcp://127.0.0.1:2001 ps
```

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
docs: improve the socket activation cli docs
as suggested by SvenDowideit expand the docs to have more information on
socket activation.

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
fix(docs): add Systemd in front of socket activation
Suggested by SvenDowideit.

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
Move listenfd to utility package
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
Allow fd:// like unix:// and tcp://
Somthing like 20605eb

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
fix(cli.rst): add missing underscores
As suggested by @metalivedev

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
fix(contrib/init/systemd): remove mount rprivate
Docker does this now via 157d99a

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
chore(*): go fmt
I noticed that travis was failing, go fmt to make it happy.

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
vendor: bump github.com/coreos/go-systemd/activation
tests now work in the Docker tree with

`go test github.com/coreos/go-systemd/activation`

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
chore(systemd): use activation.Listeners instead of Files
Use this Listeners() API that was exposed to save a few more lines of
boiler plate code.

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
chore(coreos/go-systemd): copy to github.com/dotcloud/docker/systemd/…
…pkg/activation

Via #3105 (comment)

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
fix(docs): fixup based on changes in master
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
fix(api): , _ removed to simplify code in range
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
@philips

This comment has been minimized.

Contributor

philips commented Jan 28, 2014

@crosbymichael Rebased again onto the current master, conflicts in the docs and flags again.

@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Jan 28, 2014

LGTM

ping @vieux Care to check out the API changes?

@philips

This comment has been minimized.

Contributor

philips commented Jan 28, 2014

For reference @crosbymichael tested this on Fedora 20 and said that it worked fine for him with the given socket file.

@vieux

This comment has been minimized.

Collaborator

vieux commented Jan 28, 2014

LGTM

@philips

This comment has been minimized.

Contributor

philips commented Jan 28, 2014

@tianon @vieux @crosbymichael So who presses the merge button now? :)

crosbymichael added a commit that referenced this pull request Jan 28, 2014

@crosbymichael crosbymichael merged commit 2723133 into moby:master Jan 28, 2014

1 check passed

default The Travis CI build passed
Details
@polvi

This comment has been minimized.

polvi commented Jan 28, 2014

Thank you!!

@kingdonb

This comment has been minimized.

kingdonb commented Jan 29, 2014

I am not sure if this fixes my issue, or if it just changes what I need to know. Maybe someone can answer while the change is still freshly merged and in your memory? I was having a problem starting docker containers with systemd using a simple unit like this:

[Unit]
Description=Privileged NTPd
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker run -privileged ntp /usr/sbin/ntpd -p /var/run/ntpd.pid -g -n -u 101:102

[Install]
WantedBy=local.target

The container/service would start successfully on demand, but fail on boot, not giving docker -d a chance to create the docker.sock socket, but instead restarting too many times before it's ready and giving up altogether, like this:

Jan 29 15:08:19 localhost systemd[1]: Started Privileged NTPd.
Jan 29 15:08:19 localhost docker[529]: 2014/01/29 15:08:19 dial unix /var/run/docker.sock: no such file or directory
Jan 29 15:08:19 localhost systemd[1]: ntp.service: main process exited, code=exited, status=1/FAILURE
Jan 29 15:08:19 localhost systemd[1]: Unit ntp.service entered failed state.
Jan 29 15:08:19 localhost systemd[1]: ntp.service holdoff time over, scheduling restart.
Jan 29 15:08:19 localhost systemd[1]: Stopping Privileged NTPd...
Jan 29 15:08:19 localhost systemd[1]: Starting Privileged NTPd...
Jan 29 15:08:19 localhost systemd[1]: ntp.service start request repeated too quickly, refusing to start.
Jan 29 15:08:19 localhost systemd[1]: Failed to start Privileged NTPd.
Jan 29 15:08:19 localhost systemd[1]: Unit ntp.service entered failed state.

Worked around by adding a RestartSec=1 into the [Service] section.

So, can I just take it out when this gets merged into a release upstream, at CoreOS?

@philips

This comment has been minimized.

Contributor

philips commented Jan 29, 2014

@kingdonb Yes, this fixes the race you are seeing here where units that call out to docker would fail because var/run/docker.sock wasn't ready yet. It will show up in the next update.

shykes pushed a commit to shykes/docker-dev that referenced this pull request Oct 2, 2014

chore(coreos/go-systemd): copy to github.com/dotcloud/docker/systemd/…
…pkg/activation

Via moby/moby#3105 (comment)

Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)

@michielbdejong michielbdejong referenced this pull request Jan 18, 2016

Open

Info #2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment