Why does Docker have a daemon?

Question

I recently discovered rkt, a competitor container runtime to Docker. It seems like rkt does not need a daemon. For me, rkt is like running any other command and it works easily with systemd (or other init systems).

This makes me wonder about the utility of Docker's daemon.

Why does Docker need a daemon ? What does the daemon provide that would not be possible without it ? Is its only goal to remove the need for an init system like systemd (as can be seen in the Rancher OS) ?

Moira

It provides snadbox bos containers ?? – Leslielesly

Maybe this helps: docs.docker.com/engine/docker-overview/#docker-objects – Ojeda

@Héctor How does this help understanding the utility of the Docker daemon ? – Moira

"The daemon creates and manages Docker objects, such as images, containers, networks, and volumes.", " The Docker client talks to the Docker daemon, which does the heavy lifting of building, running, and distributing your Docker containers." Check this: coreos.com/rkt/docs/latest/rkt-vs-other-projects.html – Ojeda

@Héctor Yes, exactly, so if rkt can do it without a daemon, why does Docker need a daemon ? I mean, the daemon adds additional configuration in most cases (enable services, set permissions on Daemon socket, make sure the daemon is not listening on a public IP, etc). So if it's possible to do without, why have a daemon ? – Moira

It's just a design decision. It has pros and cons and dotCloud people chose a centralized daemon-based system. That's all. – Ojeda

Oh OK ! And what are the pros ? Is it about not needing an init system ? Or is it about managing containers accross multiple physical hosts with a single daemon (which seems not to be a common use case these days) ? – Moira

Or maybe another way of asking this is: why doesn't the client by default just start the server, handle the request and then close the server each time. – Theoretical

Answer 1

Docker was designed as a client/server application which allows you to have remote access to the docker API. This allows tools like the classic container based swarm that were effectively a reverse proxy to a cluster of docker hosts.

The daemon also provides a place for shared state. It's restarting containers according to their restart policy. But it's also managing networks and volumes that may be shared between multiple containers.

Lastly, with the introduction of swarm mode, the daemon is also the central location for these tools that would otherwise be run as their own daemons with tools like kubernetes.

If you need a daemon-less solution but otherwise like docker, then consider using runc which is the runtime environment that docker uses for each container by default.

This doesn't involve the init inside the container. If you need that, docker now includes an optional init that you can enable per container. And you've always had the option to include your own init, like tini, if you needed something to cleanup zombie processes.

Capybara

Great answer! this also cleared some of my doubts, thanks! – Haggle

None of these look like features I want. It is unfortunate that Docker includes all this extra crap be default whereas a much clearer implementation could have been preferred by default. – Theoretical

@fulldecent if you don't need those features, then consider using runc or containerd. – Capybara