Technical Dry Goods | 10 common pitfalls to avoid in Docker containers

The three main advantages of Docker containers are:

1. First: A constant feature – operating system, library version, configuration, folders, and applications are all covered. You can introduce the test images used in the quality inspection process to the production environment intact.

2. Second: lightweight – The container is very small in size. Compared to hundreds of MB of operating systems, it requires only the memory required for the main process plus dozens of MB of additional capacity.

3. Third: The speed is amazing – you can enjoy the same container startup speed as a single process. Compared to a few minutes of traditional load start-up time, we are now fully capable of starting a new set of containers within seconds.
   However, many users are still looking at containers in the same way as typical virtual machines, in which case they often have no way of taking advantage of the various advantages that container technology implies. We therefore need to emphasize again a fundamental principle: the container has a one-time feature.

Container motto: "The container belongs to a temporary (one-time) system. ”

650) this.width=650; "src=" http://blog.dataman-inc.com/content/images/2016/03/11.jpg "style=" Border:0px;height: Auto;padding:.6em 0px; "The existence of/> requires the user to change existing ideas and choose a more appropriate approach for handling and managing containers." Next, I will help you understand the reasonable way to play the container advantage through 10 common mistakes:

1) do not store the data in the container – the container system can be stopped, destroyed or replaced at any time. The 1.0 version of the application running in a container environment should be easily replaced with the 1.1 version without affecting or destroying the relevant data. With this in mind, if you need to save the data, store it in a storage volume, but be aware that if two sets of containers point to the same storage volume at the same time, a failure can occur. You must ensure that your application uses a write design that targets a shared data storage mechanism.

2) do not publish the application in Split mode – some friends still look at the container with a virtual machine mentality. Most of them think they should deploy the application to the currently running container. However, this approach is only applicable to the development phase, which enables continuous deployment and commissioning necessary for application development, and once transferred to a continuous deployment process in the quality inspection and production environment, the application must be part of the image itself. Keep in mind that containers have constant characteristics.

3) do not create large mirrors – images that are too large will increase the difficulty of publishing. You need to ensure that only the files and libraries necessary to run the application/process are preserved in the image. Do not install any nonessential packages or run "Update" (yum Update) during the build process.

4) do not use single-layer mirroring – for a more rational use of tiered file systems, be sure to create separate tiers for the operating system, installation software, configuration, and applications, respectively. This not only simplifies the creation and management of images, but also reduces the difficulty of distribution.

5) do not create a mirror with a running container-in other words, do not create a mirror using "Docker commit". Images created in this way are not re-productive and cannot be versioned, so it is definitely not worth advocating. Conversely, using dockerfile or any s2i (that is, source-to-mirror) methods can effectively ensure overall re-production.

6) do not use only the "newest" label – the latest label is similar to the "SNAPSHOT" that Maven users are familiar with. Each label is only suitable for use in a tiered file system. If you were to accidentally discover that your application was missing a backward compatibility due to a top-level version replacement after two months of mirroring build-up, or that the build cache "up-to-date" version didn't work, it would be a huge hassle. In general, when deploying containers to a production environment, you must avoid using the latest labels.

7) do not run multiple processes within a single container – Container systems are ideal for running single processes (such as HTTP domain names, application servers, databases, and so on), but if you use multiple processes within a container, it may be difficult to manage them, get logging, and update them separately.

8) do not save credentials in the image, it is recommended to use environment variables – you should never save any username/password in hard-coded form in the image. Instead, we should use environment variables to obtain such information from outside the container. In this regard, the most perfect example is the postgres image.

9) Run the process as a non-root user – "By default, the Docker container runs as root." As Docker continues to evolve, more and more secure default options are also emerging. For now, the use of root privileges can still pose a security risk and lack a good fit for all environments. Everyone's image should use the user directive to designate the container as a non-root user role. " (from the Docker Image creator guide)

do not rely on IP addresses – each container has its own internal IP address, and each start and stop of the container can cause the IP address to change. If the application or microservices need to communicate with other containers, use the name and/or environment variables that can pass the relevant information to the container from this container.

Docker technology, as the most popular technology today, is still in the process of landing and popularization. Everyone in the use of the process should be put aside the traditional ideas and ideas, to avoid the misunderstanding, detours, in the process of technological transformation, one step forward.

This article is from the creator think blog, so be sure to keep this source http://strongit.blog.51cto.com/10020534/1749478

Technical Dry Goods | 10 common pitfalls to avoid in Docker containers