Client/server model is one of the leakiest things of Docker. Try mounting a relative path, or run docker inside docker, or try to inherit the current user’s security privileges.
To this day I don’t understand what problems the client/server model solved, and why it was worth all the problems it created.
I guess - and I might be very wrong here - that the reason for client / server architecture was to be able to schedule docker containers on several hosts without the need to ssh into them. And I guess something like docker-in-docker or docker containers accessing the Unix socket would be more complicated.
But why the need for Unix sockets or anything like that? Creating a container is a fancy fork(), and executing that through a foreign process (especially when on the same server) makes no sense to me.
Remember, containers are just Linux cgroups, there is nothing “special” about a container that requires a client/server.
For me and my coworkers, the leakiness is mostly around networking. If you start the wrong vpn, docker doesn’t work. If your ip tables aren’t set up just so, docker doesn’t work. Yet the documentation would lead you to believe that how docker does networking should be considered an implementation detail.
