The preparation of best practice Dockerfile

Refer to the original article -http: //bjbsair.com/2020-03-22/tech-info/5550/

Although Dockerfile simplifies the process of image building, and this process can be versioned, but a lot of people's time to build the mirror, there is an impulse - the possible use of what are packaged into the mirror. Such improper use can lead to many problems Dockerfile:

• docker mirror too much. If you often use a mirror or mirrored building, you will encounter the kind of big mirror, and even some can reach more than 2G
• docker mirror construction too long. Each build will take a long time for frequently build image (such as unit testing) where this could be a big problem
• repetitive work. Most of the content between multiple mirrored building is exactly the same and repetitive, but each time have to do it again, wasting time and resources

I hope readers can have some understanding of the docker mirror, read this article about the need for at least the premise of knowledge:

• Docker understand basic concepts, running through vessel
• Docker familiar with the basics of the mirror, knowing the hierarchical structure of the mirror
• The best is responsible for building a docker mirror (use docker build command to create a mirror image of myself)

Dockerfile and image building

Dockerfile is composed of one instruction, each instruction corresponding to the final layer of the mirror. The first word of each line is that all of the command string, followed by the parameters of this command, the command on Dockerfile support and their usage, you can refer to the official documentation, not repeat them here.

When run docker build command, the entire construction process is as follows:

1. Send files to a docker daemon reads Dockerfile
2. Read all the files in the current directory (context), sent to the docker daemon
3. Dockerfile for analyzing, processing into a command with parameters corresponding to the structure
4. Order loop through all of the command, call processing corresponding to each command processing functions
5. Each command (except FROM) are performed in one container, a result of execution of a new image is generated
6. Label their final generated image

Some of the best practices for writing Dockerfile

1. Use a unified base image
   ================

Some articles will speak to optimize image as small as possible to promote the use of the base image, such as busybox or alpine and so on. I recommend using a unified base image we are more familiar, such as ubuntu, centos, etc., because the base image can be shared only need to download once, and will not cause too much storage space is wasted. Its advantage is that these ecological mirrored more complete, easy to install our software, in addition to debug the problem.

2. Static and dynamic separation
   =======

And it will not change the basic contents of frequently changing to separate, the less change in the underlying content, create it using a different basis for the upper mirror. For example, you can create a base image in various languages, python2.7, python3.4, go1.7, java7 and so on, these images contain the most basic language library, each group can continue to build application-level image above.

3. Minimum principle: Install only the necessary things
   ================

When a lot of people to build the mirror, there is an impulse - things might use are packaged into the mirror. To curb this idea, the mirror should contain only the necessary things , anything that may or may not have not to put inside. Because the mirror is easy to expand, and run time container is also very easy to modify. This ensures that the mirror as small as possible, as quickly as possible when building, but also to ensure the future of faster transmission, more economical network resources.

4. A principle: Each image is only a function
   ==================

Do not run multiple processes in a container different functions, each mirror only install software packages and file an application, you need to interact with the program to communicate through pod (characteristic kubernetes provided) or between the container network. This ensures that modular, different applications can separate maintenance and upgrade, a single mirror can be reduced in size.

5. Using fewer layers
   =========

Although it looks different commands to try to separate, written in several commands easy to read and understand. But this will lead to the emergence of many mirror layer, and hard to manage and analyze the mirror, and the mirror layer is limited. Related content as far as possible into the same layer, a dividing line breaks, so that image size can be further reduced, and the image for easy viewing history.

RUN apt-get update\  
  && apt-get install -y --no-install-recommends \  
  bzr \  
  cvs \  
  git \  
  mercurial \  
  subversion \  
  && apt get clean  
复制代码

6. Reducing the content of each layer
   ==========

Although the installation must only content, this process may also produce additional content or temporary files, we have to try to make something each installation is kept to a minimum.

• For example, using the --no-install-recommends parameter tells apt-get package not to install the recommended
• After installing the package, clear / var / lib / apt / list / cache
• Delete intermediate files: for example, download the compressed package
• Delete temporary files: If the command creates temporary files, but also a timely deleted

7. Do not modify the file permissions alone in Dockerfile in
   ============================

Because docker image is layered, any changes will add a layer to modify the file or directory permissions as well. If there is a command to modify the permissions large single files or directories, put a copy of these documents, which can easily lead to a large mirror.

Solution is simple, either adding user permissions and put the file set before the Dockerfile, or startup script (entrypoint) in a container to make these changes, or copy files and modify permissions do put together (which ultimately has only increased layer).

8. Use cache to speed up the construction speed
   ===================

If Docker find a layer already exists, it will directly use the layer already exists, and will not run again once. If you run continuously docker build multiple times, you will find the second run was soon over.

But from the 1.10 release, led to the introduction of Content Addressable Storage effectiveness of caching feature, now introduced --cache-from parameter to specify a mirror manually using its cache.

9. Version control and automated build
   ============

Dockerfile preferable to put together and the corresponding application code version control, can then automatically build the mirror. The advantage is that you can track the content of each version of the mirror, easy to understand the different mirror what's the difference, for debugging and roll back a whole.

In addition, if you are running a mirror parameters or environment variables are many, but also a corresponding document giving instructions, and documentation to be updated with Dockerfile change, so anyone can easily reference the document using a mirror, instead of downloading the image I do not know how to use.