10 bad habits to avoid in Docker container applications

There is no doubt that containers have become an indispensable part of enterprise IT infrastructure. They have many advantages, such as:

• First: Containers are immutable — the operating system, library versions, configurations, folders, and applications are all packaged inside the container. You guarantee that the same image that you tested in QA will reach production with the same behavior.
• Second: Containers are lightweight — containers have a small memory footprint. The container will only allocate memory for the main process, rather than hundreds or thousands of MB.
• Third: Containers are very fast - you can start a container as quickly as you start a typical Linux process. You can spin up a new container in seconds instead of minutes.
  

However, many users still treat containers like typical virtual machines, forgetting that containers have an important characteristic: they are disposable.

This characteristic forces users to change their perspective on how to handle and manage containers. So how do you keep containers at their best? Here are 10 things you should avoid in Docker containers.

1. Don’t store data in containers

Because you can stop, destroy or replace the container. Version 1.0 of an application running in a container should be easily replaced by version 1.1 without any impact or data loss. So if you need to store data, store it in batches. In this case, you should also be careful if two containers write data on the same volume, as this may cause corruption. Make sure your application is designed to write to the 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 their applications into an existing running container. During the development phase, you need to constantly deploy and debug, and rightly so. But for a continuous delivery (CD) pipeline for QA and Production, your application should be part of the image.

3. Don’t create large images

Because large images will be difficult to distribute. Make sure you have only the files and libraries you need to run your application/process. Do not install unnecessary packages or run "update" which downloads many files into a new image layer.

4. Don’t use single-layer images

To effectively utilize a layered file system, always create your own base image layer for the operating system, another layer for username definitions, another layer for runtime installation, another layer for configuration, and finally another layer for your application. It will be easier to recreate, manage and distribute images.

5. Don’t create images from running containers

In other words, don't use "docker commit" to create images. This method of creating images is not reproducible and should be avoided entirely. Always use a fully reproducible Dockerfile or any other S2I (source to image) approach, if you store your Dockerfile in a source control repository (git) you can track changes to your Dockerfile.

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

For Maven users, the latest tag is like a "SNAPSHOT". Due to the layered filesystem nature of containers, the use of tags is encouraged. You won't be surprised to build an image a few months later and find out that your application doesn't run because a parent layer (FROM in the Dockerfile) was replaced by a new version that is either backwards incompatible or a buggy one, and the "latest" version was retrieved from the build cache. You should also avoid using the "latest" tag when deploying containers in production, as you will lose track of which version of the image you are running.

7. Don’t run multiple processes in a single container.

Containers are great for running a single process (http daemon, application server, database), but if you have multiple processes, you might have more trouble managing, retrieving logs, and updating the processes individually.

8. Don’t store credentials in images.

Use environment variables, you don't want to hardcode any username/password in your image. Use environment variables to retrieve that information from outside the container. A good example of this principle is Postgres mirroring.

9. Don’t run processes as root

"By default, docker containers run as the root user. As docker matures, more secure defaults may be provided. Currently, requiring the root user is dangerous to others and may not be available in all environments. Your image should use the USER directive to specify a non-root user for running containers.

10. Don’t rely on IP addresses

Each container has its own internal IP address, which may change if you start and stop containers. 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 another.

The above are the details of 10 bad habits in the application of Docker containers. For more information about Docker container applications, please pay attention to other related articles on 123WORDPRESS.COM!