Hacker News Reader

Comment by esamatti | Hacker News Reader

> If you are a Docker user, you understand that there is a daemon process that must be run to service all of your Docker commands. I can’t claim to understand the motivation behind this but I imagine it seemed like a great idea, at the time, to do all the cool things that Docker does in one place and also provide a useful API to that process for future evolution.

I guess that would be for the Windows and macOS support as it should make things easier implement in a cross platform way when you can just proxy the cli commands to a daemon running in a Linux VM even when you are on Windows or macOS?

View on HN

There were a few reasons for this. The original golang version of docker required root, full stop. There was no difference between the client and server.

The first reason was to reduce privileges of the client interface. This would provide the possibility to reduce privileges and restrict what unprivileged could do later on. The communication over the socket is just http, which allows for remote management of docker containers.

A second reason was to build a strong contact between the client and server. The client became syntactic sugar for the rest calls, which helped stabilize docker. This would ultimately lead to enabling osx and win support via a VM on the host.

Another major goal was to enable the docker in docker use case which helped significantly when developing on docker itself.

Source: I was there. :)

Since you were there, can you comment on discussions you might have had, where tradeoffs were chosen which would have led to buildah instead of Docker e.g. prioritization on cross platform support? Your comment seems written in a very after the fact way, but surely someone was agonizing overs these choices before they became history.

Sorry for the slow response, just got off an airplane. These were not after the fact. Instead, we knew these were the potential benefits and we moved over. I personally wasn't happy about having to run a daemon to get a container, but we saw the benefits far outweighed the downside for the approach. The other approach on the table was for docker (pre client/server split) to continue requiring sudo. I don't recall anyone suggesting an alternative approach though.

Oh on multi arch support. This was purely about keeping focus and reducing the original scope. I shared the same concerns and brought up this exact topic with Solomon. A change here meant changes in docker hub and other key places including devops which would further burden an already stretched team.

I should review the comment a bit more carefully sometimes.

Reply on news.ycombinator.com