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

This article mainly explains "how to write Dockerfile". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to write Dockerfile.

1. Reduce build time

A development cycle involves building a Docker image, changing the code, and then rebuilding the Docker image. In the process of building an image, if you can take advantage of caching, you can reduce unnecessary repetitive build steps.

Build order affects cache utilization

The order in which the images are built is important. When you add files to the Dockerfile or modify one of the lines, that part of the cache will be invalidated, and the next steps of the cache will be interrupted and need to be rebuilt. So the best way to optimize the cache is to put the rows that don't need to be changed frequently first, and the rows that change most frequently at the back.

Copy only the files you need to prevent cache overflow

When copying files to the mirror, try to copy only the files you need, do not use COPY. Instruction to copy the entire directory. If the contents of the copied file are changed, the cache is corrupted. In the above example, only the built jar package is needed in the image, so you just need to copy this file so that the cache is not affected even if other unrelated files are changed.

Minimize cacheable execution layer

Each RUN instruction is treated as a cacheable unit of execution. Too many RUN instructions will increase the number of layers and volume of the image, while putting all commands in the same RUN instruction will break the cache and delay the development cycle. When installing software using the package manager, it is common to update the software index information before installing the software. It is recommended that you put the update index and the installation software in the same RUN instruction, so that you can form a cacheable execution unit, otherwise you may install the old package.

two。 Reduce the mirror volume

The size of the image is important because the smaller the image, the faster the deployment and the smaller the attack range.

Remove unnecessary dependencies

Remove unnecessary dependencies and do not install debugging tools. If you really need debugging tools, you can install them after the container is running. Some package management tools, such as apt, install recommended packages in addition to user-specified packages, which increases the size of the image for no reason. Apt can ensure that unwanted dependencies are not installed by adding a parameter, no-install-recommends. If you do need some dependencies, add them manually later.

Delete the cache of the package management tool

The package management tool maintains its own cache, which is retained in the image file, and the recommended approach is to delete the cache at the end of each RUN instruction. If you delete the cache in the next instruction, it will not reduce the size of the mirror.

Of course, there are other more advanced methods that can be used to reduce the size of the image, as described in the following multi-phase build. Next we will explore how to optimize the maintainability, security, and repeatability of Dockerfile.

3. Maintainability use official images as much as possible

Using an official image can save a lot of maintenance time because best practices are used in all installation steps of the official image. If you have multiple projects, you can share these mirror layers because they can all use the same base image.

Use more specific tags

Try not to use latest tags for basic images. While this is convenient, latest mirrors can change significantly over time. Therefore, it is best to specify the specific label of the underlying image in Dockerfile. We use openjdk as an example, specifying the label as 8. For more tags, please check the official warehouse.

Use the smallest base mirror

If the label style of the basic image is different, the image volume will be different. Slim-style images are based on Debian distributions, while alpine-style images are based on smaller Alpine Linux distributions. One of the obvious differences is that Debian uses the C standard library implemented by the GNU project, while Alpine uses the Musl C standard library, which is designed to replace the GNU C standard library (glibc) for embedded operating systems and mobile devices. Therefore, compatibility issues may be encountered in some cases when using Alpine. In openjdk, for example, jre-style mirrors contain only Java runtimes, not SDK, which can also greatly reduce the size of the images.

4. reuse

So far, we have been assuming that your jar package is built on the host, which is not ideal because we do not take full advantage of the consistent environment provided by the container. For example, if your Java application relies on libraries for a particular operating system, there may be problems because the environment is inconsistent (depending on the machine on which the jar package is built).

Build from source code in a consistent environment

The source code is the ultimate source for you to build the Docker image, and only the build steps are provided in Dockerfile.

First of all, you should determine all the dependencies needed to build the application. The example Java application in this article is very simple and only needs Maven and JDK, so the basic image should choose the official smallest maven image, which also contains JDK. If you need to install more dependencies, you can add them to the RUN directive. The pom.xml files and src folders need to be copied to the image because these dependent files are used when you finally execute the mvn package command (the-e parameter is used to display errors, and the-B parameter means to run in non-interactive "batch" mode) packaging.

Although we have now solved the problem of environmental inconsistency, there is another problem: * * after each code change, all the dependencies described in pom.xml are retrieved. * * Let's solve this problem.

Get the dependency in a separate step

Combined with the caching mechanism mentioned earlier, we can turn the step of getting dependencies into a cacheable unit, and as long as the contents of the pom.xml file remain unchanged, no matter how the code changes, the cache at this layer will not be broken. The RUN instruction between the two COPY instructions in the figure above is used to tell Maven to get only dependencies.

Now there's a new problem: the image is larger than copying the jar package directly, because it contains a lot of build dependencies that are not needed to run the application.

Use multi-phase builds to remove build-time dependencies

Multi-phase builds can be identified by multiple FROM instructions, each FROM statement represents a new build phase, and the phase name can be specified with the AS parameter. In this example, the name of the first phase is specified as builder, which can be referenced directly by the second phase. The two phases have the same environment, and the first phase contains all build dependencies.

The second phase is the final stage of building the final mirror, which will include all the necessary conditions for the application runtime, in this case the minimum JRE image based on Alpine. Although there will be a lot of caching in the previous build phase, it will not appear in the second phase. To add the built jar package to the final image, you can use the COPY-- from=STAGE_NAME directive, where STAGE_NAME is the name of the previous build phase.

Multi-phase builds are the preferred solution for removing build dependencies.

At this point, I believe you have a deeper understanding of "how to write Dockerfile". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.