Engineer's Opinion: Why You Don't Always Use Docker Anywhere

In our blog we write a lot about the development of the 1cloud cloud service and promising technologies like Docker. The containers over the past year have become a real hit, however, such popularity has a downside. Engineer Nick Barrett on his blog wondered why Docker containers are now starting to be used even to solve tasks that are not suitable for this tool.

Barrett says he loves Docker. By the engineer’s own admission, he spent a lot of time mastering Docker and Kubernetes. In combination with stateless containers, they provide fantastic scalability, service disclosure and almost instant application deployment (except for creating a primary image).

But today, Docker containers are used for everything, and, according to Barrett, this confuses him.

To illustrate this, the engineer suggests considering the situation with the launch of the image storage (Docker Registry) on Docker (v2). Here it is going to:

• run a single instance with Go binary;
• on a box with a large disk space and bandwidth;
• and relatively low CPU / memory.

This is a one-time box that is not needed in the Kubernetes cluster, in addition, in this case, the engineers are not interested in the Docker ability to scale it. So all this can be launched immediately on the hardware.

The trouble is that you cannot find information on how to do this in the installation options. In fact, the “official” way is to use the Docker image. Fortunately, the Dockerfile is nothing more than a limited script to work with, so you can use the path : docker / distribution -> Registry Image -> Dockerfile. Barrett came to this experimentally.

There are other options for working outside of Docker. It's about datastores (temporary storage). Suppose you want to start an Elasticsearch or Galera cluster. Docker containers will offer quick installation, which looks pretty tempting.

But do not rush. How can these services be configured for multiple environments (test / prod clusters)? They do not read ENVvars, and do not know anything about the internal service disclosure tools used. These types of systems have their own configs; they can be elasticsearch.yml or my.cnf. In this and similar cases, the Dockerfile is terribly useless, Barrett says.

The engineer is sure that the most common solution is to simply install other utilities inside the image that would load the configuration before starting the service. And in his opinion, this is an abuse of the very idea of ​​the existence of containers without non-specialized software. Tools like pyinfra and Ansible for this work are much more convenient (they do not install unnecessary trash to generate a config).

After all, you can use easily accessible instances of Elasticsearch / Galera / etc., which is much more useful at the product development stage. The ability to instantly launch a single Elasticsearch instance tied to a specific application branch will save a ton of time. This is by far the best way to deploy stateless applications ever created. Therefore, Barrett advises "just not to bother" with the creation of clusters or complex third-party software using Docker containers.