Add daemon or engine subcommand

[cpuguy83]

In the past, docker had the daemon built-in as a single binary under the daemon subcommand (or if you go far enough back just the -d flag as I recall).

I propose that we add this subcommand back... only better.
The subcommand would be responsible for setting up the daemon on the client node.

On linux this would be starting a daemon as normal.
If docker is run as unprivileged, it could be responsible for setting up all the rootless stuff.
Perhaps could be rootless by default or even rootless only (since it is the client after all).

On non-native platforms this could also be extended to support other cases such as spinning up a platform-native VM to run the daemon, setup socket access, etc.
But anything that we don't actually support the subcommand would just error out as not supported.

In any case this would also configure a context to connect to the daemon.

Honestly this is not a concrete proposal, just exploring some ideas.

I think having the rootless experience tied in with the CLI would be extremely interesting.

[cpuguy83]

Ping @AkihiroSuda re: rootless

[AkihiroSuda]

We already have dockerd-rootless-setuptool.sh for setting up the systemd unit for the daemon

https://github.com/moby/moby/blob/master/contrib/dockerd-rootless-setuptool.sh

Does it cover the use case?

[cpuguy83]

@AkihiroSuda Not really. As a user I want polish, I don't want to hunt down other things for making it work. I just want it to work.

I could even see having a special context for rootless (like default is special) and docker run could even handle the case of no daemon being up.

[AkihiroSuda]

The "default" context SGTM, then we don't need "daemon" sub command?

I'd expect it to work like this

$ docker run hello-world
Docker daemon isn't running, would you want to:
1) Set up the daemon as the root
2) Set up the daemon as non-root user
3) Connect to a remote daemon

Choose 1 if you don't have an idea.

Enter the number: 2 [RET]

Running `dockerd-rootless-setuptool.sh`...done
Creating a new context "rootless" for unix:///run/user/1000/docker.sock
Setting "rootless" as the new default context

Running `docker run hello-world`

Hello from Docker

[cpuguy83]

Toying around with this a bit over the weekend.
Currently the UX would be something like:

docker context create --docker="user" my_user_context

Any context created with --docker user will trigger, at runtime, a connection to a local daemon managed by the CLI.
I haven't quite worked out the logistics of how the daemon will be started, ie. is it automatic or will it require something like docker daemon start. Either way it would look at the context to figure out where the runtime and persistent state should go (based on context name).
This would allow for multiple "user daemon" contexts... which may be overkill, but seems interesting as well.

---

Edited for typos

[thaJeztah]

Thanks for opening; wanted to leave a comment, but didn't get to that, so some quick first thoughts;

• I'm quite hesitant to use docker engine for this (after we had the docker engine subcommands, which erm, wasn't the best experience).
• One of the issues with docker engine (which used containerd to install things, so not an exact comparison) was that it could only work in a local situation (daemon running on your local machine). The feature proposed here would have the same problem (unless we added provisioning remote machines, but that would kinda bring back docker machine).
• Adding to the above, given that (strictly speaking), the "cli" is an optional install when installing the engine, I'm wondering if this should be part of the dockerd CLI. IoW; allow the daemon to configure the right settings to run rootless
  • the daemon could have an option to export a context.tar.gz, which can be imported by the CLI. This would also help with Sterner warnings and deprecation notice for unauthenticated tcp access moby/moby#41285 (i.e., it could generate the client certificates, and include those in the exported context)
  • we could potentially even embed the non-rootless systemd unit files, so that I could write those to a file to install

For rootless install; we also have a roadmap issue for "Docker Desktop for Linux" docker/roadmap#39. If that would be worked on, I can imagine such a package to do a rootless install (and other configurations, e.g. using FUSE for bind-mounts etc)

/cc @nebuk89 @chris-crone

[thaJeztah]

Thinking some more about the "Desktop for Linux" idea; those may still need some command/installer if we want to allow that package to be installed without root permissions. Perhaps it's ok for the initial installation (similar to how Docker Desktop for Mac requires privileges on the initial install);

the tricky bit on Linux is that (also see moby/moby#40761 (comment))

• we can create a docker desktop .deb / .rpm, however, .deb and .rpm packages are always "system-wide" installs, so cannot be installed per-user. Because of that, they will require root for the installation.
• So even with such packages for Linux, I guess there's still a tool/command needed to do an actual local, unprivileged, per-user install

[cpuguy83]

I'm wondering if this should be part of the dockerd CLI.

It can certainly... however this is not the experience I'd like to have.... or perhaps more correct, I'd like the docker command to undertand how to do this, because that's what people interact with. Even if docker literally execs dockerd and defers to dockerd to deal with it, I'd like this flow to be generated from docker... actually relying on a separate binary (dockerd) could actually be helpful in adding support for other (non-Linux) platforms.

This is not really any different than other tools out there that depend on a separate "helper" daemons.

One of the issues with docker engine (which used containerd to install things, so not an exact comparison) was that it could only work in a local situation (daemon running on your local machine). The feature proposed here would have the same problem (unless we added provisioning remote machines, but that would kinda bring back docker machine).

This would be implemented for linux only for now.
In fact, the entire intent is specifically for the local context.

It could be extended to spin up a platform specific VM to run dockerd in, but I'd expect that this would be specifically the case that docker-for-mac/windows provides.
This is a very different case than docker machine