Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you what the guidelines for efficient writing of Dockerfile refer to. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Overview

Dockerfile is an orchestration file designed to automate the construction of images (just as Jenkinsfile in the Jenkins 2.0 era was choreographed for Jenkins's Job and Stage), we can build custom Docker images automatically from the steps described by Dockerfile through the docker build command, which is much more efficient than the way we go to the command line to execute one instruction at a time.

On the other hand, because Dockerfile provides a unified configuration syntax, we can distribute it on a variety of different platforms through such a configuration file, and we can get the desired image by building it through Dockerfile when needed.

The last advantage that must be mentioned is that by using Dockerfile in conjunction with mirrors, Docker images can be built to make full use of "mirror caching", so it also improves a lot!

However, writing Dockerfile is like writing code. A well-designed, Clean Code Dockerfile can not only improve readability, but also greatly improve the efficiency of Docker.

So the following will be combined with practice to tell a few Dockerfile practice experience!

Pay attention to the choice of basic image.

In my article "using the K8S technology stack to create a personal private cloud (serial: basic image creation and experiment)", we based on a Linux basic image as the base package, and then packaged it into the functions I needed to form our own image.

You should pay attention to the selection of basic images here:

First, we should try our best to choose the basic image in the official mirror library.

Second, we should choose a lightweight image as the base package.

For a typical Linux basic image, the size relationship is as follows:

Ubuntu > CentOS > Debian

Therefore, compared to Ubuntu, the lightest Debian image is recommended, and it is also a complete Release version, so you can rest assured to use it.

It is good to use the tag Tag more often.

When building an image, tagging it with an easy-to-read image can help you understand the features of the image, such as:

Docker build-t = "centos:wordpress".

For example, the above centos image is used for wordpress, so the wordpress function has been integrated, which is very clear at a glance.

In addition, we should also specify the label Tag clearly in the FROM instruction of Dockerfile, instead of letting Docker daemon guess, such as

FROM debian:codesheep makes full use of mirror cache

What is mirror caching?

The final image constructed by Dockerfile is superimposed layer by layer on top of the base image, so new mirror layers are created in the process. Docker daemon caches a series of intermediate images during the process of building the image.

When docker build mirrors, the instructions in Dockerfile are executed sequentially, and all the sub-images of the current instruction and its underlying image are compared at the same time. If a sub-image is also generated by the same instruction, the cache is hit. At the same time, the sub-image can be directly used to avoid rebuilding.

In order to use cache effectively, it is necessary to ensure the continuity and consistency of instructions in Dockerfile. Try to put the parts of the same instructions in front and the instructions with differences after them.

* * for example: * * if I want to use Dockerfile to build two different images based on the most basic CentOS images, the beginning of the two Dockerfile can be the same:

FROM centos:latest# installs two commonly used tools RUN yum install-y net-tools.x86_64RUN yum install lrzsz# above is the same part of the two Dockerfile files # below is the different part of the two Dockerfile files # .add and the correct use of the COPY instruction

Although both files can be added to the image, in general usage, it is recommended to use the COPY instruction as the first choice, because the ADD instruction is not pure from the COPY instruction, ADD will add some additional features, typically the following ADD when a compressed package, it will not only copy, but also automatically decompress, and sometimes we do not need this additional function.

ADD codesheep.tar.gz / path

In addition, when you need to add multiple files to the image, do not add them all at once, but choose to add them one by one as necessary, because this is beneficial to the use of the mirror cache.

# # try to use docker volume

Although the above principle recommends adding multiple files to the image through the COPY command, in practice, if the file is large and large, you should use the docker-v command to mount the file first, rather than relying on ADD or COPY

Correct understanding and use of CMD and ENTRYPOINT instructions

When Dockerfile creates an image, it combines the CMD and ENTRYPOINT instructions as the default command for the container runtime: CMD + ENTRYPOINT. The default command at this time is composed of:

The ENTRYPOINT instruction is partially fixed and cannot be modified at run time of the container

The instructions in the CMD section can also be changed, showing that when the container is run, the parameters provided in the docker run command will override the instruction contents of the CMD.

For example:

FROM debian:latestMAINTAINER codesheep@163.comENTRYPOINT ["ls", "- l"] CMD ["- a"]

If you run the container with the default command, you can see that you are executing the ls-a-l command:

If the parameter-t is added to docker run

Docker run-it-rm-name test debian:codesheep-t

You can also find that ls-l-t is executed, that is, the original parameter CMD in Dockerfile is overwritten:

Therefore, the recommended way to use is:

Set fixed default commands and parameters using the ENTRYPOINT directive in exec format

Use the CMD instruction to set variable parameters

Port mapping in Dockerfile is not recommended

Dockerfile can map the container port to the host port through the EXPOSE command, but this will cause mirroring on a host to start only one container!

So you should specify the port mapping with the-p parameter in the docker run command, rather than putting the work in Dockerfile:

# avoid this way as far as possible. EXPOSE 8080 EXPOSE 889 users can choose only to expose the port. The task of port mapping is left to docker run to do EXPOSE 8080 and use Dockerfile to share images.

It is recommended to share images by sharing Dockerfile. There are many advantages:

The mirror users built through Dockerfile can clearly see the process of building.

Just as Jenkinsfile can add version control to track CI system changes and step rollback, Dockerfile, as an orchestration file, can also be stored for version control, so it can also be traced back.

Images built using Dockerfile are deterministic and have no metaphysical elements.

These are the guidelines for efficiently writing Dockerfile shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.