Check that the previous build meets expectations by adding some RUN instructions to the dockerfile that you need to test. In order not to affect the production image, pass the test instructions through the # test: comment. Remove the # test: tag with the command before the test is executed, and then use the temporary test dockerfile. Build the image directly during the build phase without worrying about the annotated test instructions. On the other hand, it also has a certain role for developers.
pros
Before release, check whether the image meets the requirements through CI to discover problems in advance and reduce bugs in production
With dockerfile, you can see more details and important information about container construction, which is always more important for the target content of the test. For example, whether the source code build or install program commands are available, or whether the specified program version is satisfied, whether the file added to the container exists, and so on.
cons
Because you need to use a RUN instruction for detection, you need to add another layer when writing the dockerfile, even if the instruction is commented out during production. When you write, however, there is an instruction to break up an otherwise long RUN instruction into multiple RUN instructions and insert tests into them. This undoubtedly increases the number of layers of the container image.
If you consider not disassembling the existing RUN instruction, you can add build-args to pass a TEST=true environment variable when testing, and judge and test in the shell logic of the existing RUN instruction. However, this will increase the complexity of the RUN instruction and increase the development cost.
On the issue of the number of layers of dockerfile, in the early docker practice, it was proposed to minimize the number of layers, and there are some views on the concept of not exceeding many layers. But that's rarely seen now. By using the cloud-native build tool buildpacks, we can see that in order to maximize the reuse of the container system, each layer will be very small, and the final number of layers of the image is very large, of course, we can also see that the number of building layers of some mainstream images reaches more than 10 layers.
whg517
commented
1 month ago
example
explain
Check that the previous build meets expectations by adding some
RUNinstructions to the dockerfile that you need to test. In order not to affect the production image, pass the test instructions through the# test:comment. Remove the# test:tag with the command before the test is executed, and then use the temporary test dockerfile. Build the image directly during the build phase without worrying about the annotated test instructions. On the other hand, it also has a certain role for developers.pros
cons
If you consider not disassembling the existing RUN instruction, you can add build-args to pass a TEST=true environment variable when testing, and judge and test in the shell logic of the existing RUN instruction. However, this will increase the complexity of the RUN instruction and increase the development cost.
On the issue of the number of layers of dockerfile, in the early docker practice, it was proposed to minimize the number of layers, and there are some views on the concept of not exceeding many layers. But that's rarely seen now. By using the cloud-native build tool buildpacks, we can see that in order to maximize the reuse of the container system, each layer will be very small, and the final number of layers of the image is very large, of course, we can also see that the number of building layers of some mainstream images reaches more than 10 layers.