Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about what should be avoided in the Docker container, which may not be well understood by many people. In order to make you understand better, the editor has summarized the following for you. I hope you can get something according to this article.

There is no doubt that containers have become an essential part of the enterprise IT infrastructure. It has many advantages, but containers are disposable. So how to maintain the good benefits of the container? Here are 10 things that should be avoided in Docker containers.

There is no doubt that containers have become an essential part of the enterprise IT infrastructure, with many advantages, such as:

Containers are immutable-operating systems, library versions, configurations, folders, and applications are all packaged in the container. You guarantee that the same image tested during the quality inspection will arrive in the production environment with the same behavior.

The container is very light-the container has a small amount of memory. The container will only allocate memory to the main process, not hundreds or thousands of MB.

Containers are very fast-- you can start containers as quickly as you start a typical Linux process. You can start a new container in seconds instead of minutes.

However, many users still treat the container like a typical virtual machine, forgetting that the container has an important feature: that the container is disposable.

This feature forces users to change their views on how containers are handled and managed. So how do you maintain the best benefit of the container? Here are 10 things that should be avoided in Docker containers.

1. Do not 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 bulk. In this case, you should also pay attention to whether the two containers write data on the same volume, as this can lead to corruption. Make sure your application is designed to write to a shared data store.

two。 Do not deliver the application in two parts. Some people see containers like virtual machines, and most people tend to think that they should deploy the application to an existing running container. During the development phase, you need to constantly deploy and debug, which is correct. But for a continuous CD pipeline QA and Production, your application should be part of the mirror.

3. Do not create large images because large images will be difficult to distribute. Make sure you have only the files and libraries needed to run the application / process. Do not install unnecessary packages or run "updates" that download many files to the new mirror layer.

4. Instead of using single-layer mirroring, to make effective use of the hierarchical file system, always create your own underlying mirror layer for the operating system, another layer for the user name definition, another layer for the runtime installation, another layer for the configuration, and finally another layer for the application. It will be easier to recreate, manage, and distribute images.

5. Do not create an image from a running container. In other words, do not use "docker commit" to create a mirror. This method of creating a mirror cannot be replicated and should be completely avoided. Always use a fully replicable Dockerfile or any other S2I (source to mirror) method, and if you store Dockerfile in a source control repository (git), you can track changes to Dockerfile.

6. Don't just use the "latest" tag. For Maven users, the latest tag is like "SNAPSHOT". The use of tags is encouraged because of the hierarchical file system nature of the container. Generate a mirror a few months later and find that your application won't work because the parent layer (FROM in Dockerfile) has been replaced by an incompatible backward or wrong new version, and you won't be surprised to retrieve the "latest" version from the build cache. You should also avoid using the "up-to-date" label when deploying containers in a production environment, as you cannot track which version of the image is running.

7. Do not run multiple processes in a single container. The container is ideal for running a single process (http daemon, application server, database), but if you have multiple processes, you may have more trouble managing, retrieving logs, and updating processes separately.

8. Do not store credentials in the mirror. Using environment variables, you don't want to hard-code any username / password in the image. Use environment variables to retrieve this information from outside the container. A good example of this principle is Postgres mirroring.

9. Do not run the process as root. "by default, the docker container runs as the root user. As docker matures, more secure default options may be provided. Currently, requiring root users 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 the running container.

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

After reading the above, do you have any further understanding of what should be avoided in the Docker container? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.