Container Antipatterns: 5 Mistakes to Avoid when Using Docker

To get the most out of Docker containers, it’s important to avoid mistakes that DevOps teams sometimes make when migrating to Docker. Here are the top five common Docker mistakes to avoid.

Those mistakes include:

Installing an operating system inside a Docker container. This can be done, but there is rarely a good reason to host an entire OS inside a container using Docker. If containerizing a complete OS is your goal, you’re better off using a platform designed specifically for that type of use case, such as LXD or OpenVZ—both of which are system container, rather than application container, platforms.

Running unnecessary services. When building your container image, you should include only the services that are absolutely essential for the app the container will host. Anything extra wastes resources and widens the potential attack vector that could lead to security problems. This is why you should probably not run an SSH server inside your container, for example. There is no need for SSH when you can use the Docker exec call to interact with the containerized app.

Storing critical data inside a container. This is a bad idea for two reasons. First, containerized data is not persistent by default, so you risk losing important data if the data exists inside a container. Second, storing sensitive data inside a container poses security risks because anyone who can access the running container—or, in some cases, even just the image registry that hosts the container image—could potentially gain access to private information.

Storing data other than container images inside a container registry. A container registry is designed solely for the purpose of hosting container images. Don’t use your registry as a general-purpose repository for hosting other types of data. That’s the mistake Vine made last year, when it was using a container registry to host source code.

Hosting too many services inside a container. In general, a container should host a single service. If your app requires other services, run them inside separate containers. Being able to compose your app in this way using multiple containers, with one service running in each container, is the major advantage of using Docker in the first place. Limiting each container to a single service may sometimes not be feasible—especially if your app was ported from a monolithic chunk of code that was not designed with microservices architectures in mind. But wherever possible, stick with one service per container.