While I was looking for a good “desktop level” virtualization solution, I thought I would evaluate Docker. The public commentary about it is great and the lightweight design that others tend to emphasize sounds very appealing. I thought if it works, it would be a great solution for me. I installed the technology, Docker, and went through the documentation before I realized it was not going to work. This blog post is short, and I have a few short bullet points why Docker is not a good long-term fit for some audiences.
Scenarios Docker Seems to Address Less Well
I will explain the main problem by contrasting Docker with traditional virtualization. Docker is designed to be a lightweight, container-based virtualization platform. When I think about such a thing, I think of a really simple process. What is that process? A single command followed by a single input. The command is the container technology and the input is the specific container. To me, a container is a single file, all inclusive. Docker does not do that, but traditional virtualization is much closer to that. The problems with Docker in that scenario is as follows:
- Assumes an internet connection.
- You are downloading image files from public registries. That can be bandwidth exhausting, especially on capped data plans.
- You have many tools for a single concept, Docker Machine, Docker Swarm, Docker Compose, Docker Registry and so forth.
- Admin privilege for various tasks such as downloading images, configuring, and packaging. Traditional VM can work standard user.
The “hello world” example uses the sudo command. I am thinking, “seriously”? An admin priviledge to do a “hello world” example? Basically, the docker container instance is forked from an admin level process of the super user kind. Despite whatever security precautions are taken inside the container, what happens when an attacker bleeds through those mitigation constructs to the host? I cannot say, traditional vm does better, but it is tough to see Docker as having solved that problem with the approach taken.
It continues with sudo docker logs, sudo docker ps, and sudo docker version. Admin priviledges for read-only version information?
I couldn’t believe that last part so I tried it myself, without the admin requirement. I ran the command requesting the version as standard user. I did get version information followed by an error message. The error message can be summarized as permission denied on network communication.
As I went through many other pages and sections of Docker’s online documentation (no offline version unfortunately) and saw more of the same. The “Principle Least Priviledge” is an extremely important principle. It has to be there and appears to be absent from Docker.
It will depend on your idea of lightweight. I think diffuse became confused with lightweight. It is not a fast productivity solution for an individual workstation in which an operational environment is captured in a single file that can be ported from workstation to workstation. If I missed that, I apologize, but that scenario is not visible at the outset considering the documentation. Rather, Docker appears primarily designed for an environment with abundant network resource, distributed disks, and lots of cloud servers in which making delta updates on union file systems is a convenient administrative target.
I like the idea of Docker. The particular implementation looks beneficial in a data center but not as a stand-alone, self-contained virtualization solution. At least not without substantial accommodation. My search continues for a good virtualization solution in which both hypervisor and guest remain rock solid.