This author writes about alternatives to docker, such as Podman, Buildah and Skopeo.

In addition you can run docker images without the Docker Daemon using nspawn.

But I want to run docker-compose and link my containers. I want to give a declarative description of my system to Rancher or Kubernetes and have it spin up the dependencies of my software system, across a cluster of machines if required.

Hypothetically, how much would you lose by not having a daemon-based container host? To me it seems to be both declarative container linking (in docker-compose) - although I can imagine how you might achieve that without a daemon process, and cluster scheduling.

My question is: Would you lose any benefits of docker if the docker service ceased to be a daemon?


The main reason it's a daemon is for container monitoring. You want something that occasionally checks if the container is healthy, and restarts it if it isn't. This requires some sort of process running in the background, or at least waking up periodically.

Now, there's no reason that has to be one centralized system daemon. You could make smaller ones for individual containers. I'm not familiar enough with the docker alternatives to know how those work.

However, if starting that container requires special privileges, your process that restarts the container requires the same privileges. Having a single privileged process instead of potentially one per container has certain security advantages.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.