Docker守护进程需要什么？
这是Docker架构： 
我无法弄清楚为什么需要docker守护进程。 客户端够好。 客户端只需使用Unix套接字访问守护进程。 它可以使用TCP，但我注意到的通常是客户端和守护进程在同一台机器上！ 那么为什么两个单独的实体
如上所述，客户端可以使用TCP与守护进程通信。 那么在团队中工作的首选方式是什么？ 整个团队的一个守护进程在与每个运行客户端的开发者分开的服务器上？ 或者每个开发者都有自己的守护进程。
Docker客户端只提供cli，它只是一个http api包装器，就像aws cli一样。
Docker守护进程是整个操作背后的大脑，就像aws一样。 当你使用docker run命令启动一个容器时，你的docker客户端会把这个命令翻译成http API调用，发送给docker守护进程，然后Docker守护进程评估请求，与底层os进行通信，并提供你的容器。
请注意，docker cli可以连接到远程的docker守护进程，你可以configuration你的docker守护进程使用tcp IP。
问：在我看来，在团队中工作的首选方式是什么？ 整个团队的一个守护进程在与每个运行客户端的开发者分开的服务器上？ 或者每个开发者都有自己的恶魔。
这取决于你，但大多数时候开发者有一个本地的docker守护进程和客户端，使用dockerfiles构build图像。 如果他们需要共享docker图像，您可以提供本地dockerregistry或使用公共的。 这样，利用docker你可以在开发人员处理中拥有完全相同的开发环境。 这个开发环境将与生产环境类似。
问：在我看来，在团队中工作的首选方式是什么？ 整个团队的一个守护进程在与每个运行客户端的开发者分开的服务器上？ 或者每个开发者都有自己的恶魔
每个开发者都在使用它自己的Docker守护进程和容器：Docker的想法是能够指定（Dockerfile）一个容器，每个开发人员可以在本地重build和使用，并保证docker build会产生完全相同的图像。
或者，他们可以通过docker推送一个图像，将其重用到自己的本地docker守护进程实例上。
但是在任何情况下，docker守护进程都是每个服务器，这意味着只有当所述团队访问了一个公共服务器时，才能通过一个团队共享它。 如果没有，他们可以在他们的工作站上安装docker，在这种情况下，每个人都有自己的docker守护进程。