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

What are the eleven Docker rules? in view of this question, this article introduces in detail the corresponding analysis and answers, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

Many people eventually decide to use Docker to solve the problem. Docker has many advantages, such as:

Integration-all operating systems, library versions, configuration files, applications, etc., are packed in containers. This ensures that the image tested by QA will bring the same behavior to the production environment.

Lightweight-the memory footprint is minimal and memory is allocated only for the main process.

Read fast-start with one click, just as fast as starting the usual linux process.

However, many users still treat containers as common virtual machines and forget an important feature of containers:

Discard immediately after use

Because of this feature, some users need to change their concept of containers. In order to better use and give full play to the value of Docker containers, there are some things that should never be done: 1) Don't store data in containers-A container can be stopped, destroyed, or replaced. An application version 1.0 running in container should be easily replaced by the version 1.1 without any impact or loss of data. For that reason, if you need to store data, do it in a volume. In this case, you should also take care if two containers write data on the same volume as it could cause corruption. Make sure your applications are designed to write to a shared data store.

Do not store data containers in container that may be interrupted, replaced, or corrupted. Version 1.0 applications running in a container can easily be replaced by version 1.1 without affecting or causing data loss. Therefore, if you need to store data, store it in a volume (volume). In this case, you should also pay attention to whether the two containers will write data on the same volume, which will lead to corruption. Make sure that the application is suitable for writing to a shared data store.

Don't deliver the application in two parts. some people use the container as a virtual machine, so most of them think that the application should be deployed to an existing running container. This may be true during the development phase that requires constant deployment and debugging, but for QA and production continuous delivery (CD) channels, the application should be part of the mirror. Remember: the container is fleeting.

Do not create large-size mirrors. Large-size images are difficult to assign. Be sure to use only the required files and libraries to run the application. Do not install unnecessary packages and do not run yum update, which downloads a large number of files to the new mirror layer.

Do not use single-layer mirroring to effectively take advantage of the multi-tier file system, always create your own basic mirror layer for the operating system, then create a layer for the user name definition, create a layer for the runtime installation, create a layer for the configuration, and finally create a layer for the application. This makes it easier to recreate, manage, and assign mirrors.

Do not create an image from a running container in other words, do not use the "docker commit" command to create an image. This mirror creation method cannot be replicated, so it should be avoided altogether. Always use Dockerfile or any other fully replicable S21 (from source code to mirror) method, so that if you store it in a source control repository (GIT), you can track changes to Dockerfile.

Don't just use the "latest version" tag, just like the "SNAPSHOT" of Maven users. Containers have the basic feature of a multi-tier file system, so we encourage the use of tags. I'm sure no one wants to find out that after months of building an image, the application can't run because the parent layer (that is, the FROM in Dockerfile) is replaced by a new version (which is not backward compatible or the "latest" version retrieved from the build cache is incorrect). You should also avoid using the "latest version" label when deploying containers during production because the currently running mirror version cannot be tracked.

Do not run more than one process in a single container. It works best when the container runs only one process (HTTP daemon, application server, database), but if you run more than one process, you will have a lot of trouble managing and retrieving logs and updating processes separately.

Do not store license certificates and use environment variables in the mirror. Do not hard-code any username / password in the mirror. Use environment variables to retrieve information from outside the container. Postgres mirroring is an excellent explanation of this principle.

Do not run processes with root permissions "by default, the Docker container runs as root. (…) as Docker technology matures, there are more and more security default options that can be used. currently, requiring root is dangerous for other users, and not all environments can use root. The image should use the USER directive to specify a non-root user for the operation of the container." (from the author's Guide to Docker Images (Guidance for Docker Image Authors))

Do not rely on IP addresses. Each container has its own internal IP address. If you start and then stop the container, the internal IP address may change. If your application or microservice needs to communicate with another container, use environment variables to pass the appropriate hostname and port between containers.

Monitoring container Docker monitoring has been paid more and more attention by developers, real-time monitoring Docker method, Cloudinsight is recommended here. Unlike some monitoring methods that need to write their own scripts, Cloudinsight, as a free SaaS service, can monitor Docker with one click and has a great visual interface. In addition, Cloudinsight also supports the monitoring of a variety of operating systems, databases, etc., and can "display" the performance data of all the basic components of the system being monitored.

The answers to the questions about what are the 11 Docker rules are shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

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.