This is the 22nd day of my participation in the August More Text Challenge

Without a doubt, containers have become an essential part of enterprise IT infrastructure with many advantages, such as:

  • First: containers are immutable – operating systems, library versions, configurations, folders, and applications are all wrapped inside containers. You guarantee that the same image tested during the quality check will arrive in production with the same behavior.

  • Second: the container is lightweight — the memory footprint of the container is small. The container will only allocate memory for the main process, not hundreds or thousands of MEgabytes.

  • Third: The container is very fast — you can start the container as fast as a typical Linux process. You can start a new container in seconds instead of minutes.

However, many users still treat containers as if they were a typical virtual machine, forgetting that containers have one important feature: they are disposable.

This feature forces users to change how they think about handling and managing containers. So how do you get the best out of your container? Here are 10 things to avoid in Docker containers.

​

1. Don’t store data in containers

Because you can stop, destroy or replace containers. Application version 1.0 running in the container should be easily replaced by version 1.1 without any impact or data loss. Therefore, if you need to store data, store it in batches. In this case, you should also pay attention to whether the two containers are writing data to the same volume, as this can lead to corruption. Make sure your application is written to a shared data store.

2. Don’t deliver your application in two parts

Some people see containers like virtual machines, and most people tend to think that they should deploy the application into an existing running container. During the development phase, it is true that you need to constantly deploy and debug. But for a continuous delivery (CD) pipeline QA and Production, your application should be part of the mirror.

3. Do not create a large mirror

Because the large image will be hard to distribute. Make sure you have only the files and libraries you need to run your application/process. Do not install unnecessary software packages or run “updates” that download many files to a new image layer.

4. Do not use single-layer mirrors

To take advantage of tiered file systems, always create your own base mirroring layer for the operating system, another layer for user name definitions, another layer for runtime installation, another layer for configuration, and finally another layer for the application. Recreating, managing, and distributing images will be easier.

5. Do not create images from a running container

In other words, do not use “Docker Commit” to create the image. This method of creating a mirror is not replicable and should be avoided entirely. Always use a fully copiable Dockerfile or any other S2I (source-to-image) method, and changes to a Dockerfile can be tracked if it is stored in a source-control repository (Git).

6. Don’t just use the “Latest” tag

For Maven users, the latest tag is just like “SNAPSHOT”. Labels are encouraged because of the hierarchical file system nature of containers. You won’t be surprised to retrieve the “latest” version FROM the build cache after a few months of mirroring and finding out that your application doesn’t work because the parent layer (FROM in Dockerfile) was replaced by an incompatible backward new version or an incorrect new version. You should also avoid using the “latest” tag when deploying containers in production, because you cannot track which version of the image is running.

Do not run multiple processes in a single container.

Containers are great for running a single process (HTTP daemons, application servers, databases), but if you have more than one process, it can be more difficult to manage, retrieving logs and updating the process separately.

8. Do not store credentials in the image.

With environment variables, you don’t want to hardcode any usernames/passwords in the image. Retrieve this information from outside the container using environment variables. A good example of this principle is Postgres mirroring.

9. Do not run processes as root

“By default, the Docker container runs as root. As Docker matures, more secure defaults may be available. Currently, requiring root is dangerous for others and may not be available in all environments. Your image should specify a non-root USER to run the container using the USER directive.

10. Don’t rely on IP addresses

Each container has its own internal IP address, which may change if you start and stop the container. If your application or microservice needs to communicate with another container, use environment variables to pass the correct hostname and port from one container to the other.

So, in Docker container applications, these 10 bad habits should not be, beware! Attention! Note again!

​