docker

in Development

5 Docker Pitfalls

docker

via yazpik.github.io

Docker continues to be a popular topic among developers and industry professionals.  A brief refresher on what Docker does: It works as a container system that takes the building blocks required to run a software application (code, runtime, system tools, system libraries), and wraps them into little neat packages that execute on any server.  The merit of Docker lies in its ability to allow two or three times more application instances on a given server than with virtual machines.  This is a promising tool for the future of development, but even after the incredible progress Docker has made, flaws remain.  Let’s take a look at 5 major Docker pitfalls:

1. Better Networking Between Containers on Multiple Docker Hosts

Docker CEO, Solomon Hykes, said it himself at a LinuxCon — Docker lacks high level networking between containers.  Part of the problem is that Docker best practices do not encourage running more than one service in one container, and that means communication with other containers is of great importance.  At scale this might become an issue when the need arises for containers to talk to other containers that may not reside on the same Docker host. Because many applications require specific networking environments for security and functionality purposes, the native networking functionality of Docker is somewhat limited when trying to solve this problem at scale.

Another aspect of this networking problem is Docker’s lack of native service discovery.  With the potential for applications and services to have numerous and wide ranging components,  service discovery becomes a necessity when we are talking about applications at large scale. One way the community deals with this issue is implementing etcd with skydns.

Docker 1.7 introduced libnetwork, and while it is still in early form, it promises to provide a solution to the networking woes of native Docker implementations. In addition, third party projects like Weave, have been created to expand Docker’s networking capabilities, but this only adds layers of complexity to a software whose aim is to simplify development and make deployment of applications and services easier.

2. Scaling
For the majority of startups, scale will not be an issue in the beginning.  In fact, many companies will likely never need more than a handful of servers to run their application.  For the companies that will, however, building a Docker cluster is no easy task.  Many projects have evolved around this topic, including Docker Swarm, which is Docker’s answer to scheduling container workloads onto a cluster of Docker Machines.  The main issue with this, is that Docker Swarm is not production ready, and for those companies who want to start building Docker clusters NOW, they are limited in their options.

One production ready option is a project started by Google, called Kubernetes.  Other options are based on Apache Mesos, or cluster centric linux distributions like CoreOS.  These solutions have one thing in common: not easy to setup.  Google helps you by allowing you to easily create Kubernetes clusters on the Google Compute Engine service, but what about those enterprise customers who want to build a private Docker cluster?  One thing is true, building a Docker cluster needs to be easier, and surely services will sprout up around this subject.

3. Security
There’s not much agreement as to how secure containers are, which is a security problem in and of itself.  In comparison to VMs, containers provide less isolation and security. Security documentation from Docker states:
Running containers (and applications) with Docker implies running the Docker daemon. This daemon currently requires root privileges.

Docker needs access to the root to function, and that implies an immense opportunity to wreak havoc should something go awry.  Docker’s answer is to restrict Docker to ‘trusted users’ only, but everyone knows even trusted users create bad passwords sometimes. It’s way too easy for a user to do something untrustworthy, because if one of these passwords was to be hacked — all of the containers on a host would be compromised.
Docker is able to isolate many aspects of the underlying host from an app running in a container, but this separation is weaker than VMs.

NCM security expert, Lenny Zeltzer, notes the security difference: VMs run independent OS instances on a hypervisor without sharing the kernel with the underlying OS.  Ultimately, any hacker who gains root access to the container OS would then have the ability to access the Docker daemon running as root on the Docker host — which could stir up some real trouble.  Docker’s security is still immature, and perhaps worse — still a bit murky.

4. Not for Everyone
Docker’s status quo is going to require users to have more systems management know-how to use Docker than the average developer.  Many Docker articles purport simple use-cases, but dismiss the intricacies of using Docker on multi-host systems.  This can be misleading as to what it actually takes to run Docker in development.

Using Docker in development actually requires developers to have a strong foundation in systems management, and the learning curve might be steep.  In other words, it’s just not as simple as it’s trying to be.
Managing Docker in a production environment requires even more skill. Careful attention must be paid to variables such as: managing container logs & data, networking between multiple hosts, private image repository, directing container deployments without downtime, and many, many more.

5. Containers vs. VMs
Yes, the benefit of containers over VMs are obvious – the ability to run multiple server instances on a server instances without slowing down.  This speed is possibly at the cost of reduced stability, security, and compatibility.  Running incompatible or untested in the kernel and userspace can result in unexpected behavior.

Hypervisor performance is faster than ever before, and on-demand VMs are becoming faster and cheaper by the day.  Virtualization performance varies depending on workload types, obviously heavy applications result in slower performances.  Those are cases where containerization is a better approach, but you should use containers for precise case needs — otherwise your speed gains may not be worth the risks.

Docker holds promise for packaging and shipping applications easier, better, and faster.  Regardless, the flaws are fairly prominent, especially when compared to modern VMs.  All criticism aside, Docker is committed to improving and innovating for the future of development, they are already at version 1.8 and are well on their way to solving these issues.