Shulou(Shulou.com)06/01 Report--

This article mainly shows you "how to use Docker multi-stage build to reduce the image size". The content is easy to understand and clear. I hope it can help you solve your doubts. Let me lead you to study and learn this article "how to use Docker multi-stage build to reduce image size".

How to greatly reduce the image size through the multi-phase build feature of Docker is suitable for programs that need to be built in Dockerfile (such as javac) and need to install additional images of the compilation tool chain. (e.g. Java)

Let's learn the words first (all Chinese words are used in this article. If you need to query foreign language documents, you can compare them with the vocabulary list. In theory, individuals do not approve of the translation of terms):

Multi-stage multi-stage

Build construction

Image Mirror

Stage stage

Let's take another look at the effect: the original 110m is now 92m.

Compare with Dockerfile.

Dockerfile before optimization:

FROM openjdk:8u171-jdk-alpine3.8ADD. / appWORKDIR / appRUN apk add maven\ & & mvn clean package\ & & apk del maven\ & & mv target/final.jar /\ & & cd /\ & & rm-rf / app\ & & rm-rf / root/.m2ENTRYPOINT java-jar / final.jar

Optimized Dockerfile:

FROM openjdk:8u171-jdk-alpine3.8 as builderADD. / appWORKDIR / appRUN apk add maven\ & & mvn clean package\ & & apk del maven\ & & mv target/final.jar / FROM openjdk:8u181-jre-alpine3.8 as environmentWORKDIR / COPY-- from=builder / final.jar .EntRYPO INT java-jar / final.jar

Obviously, FROM AS is added to the optimized Dockerfile, and two FROM appear. This is a multi-stage build.

Learn about multi-phase builds

Multi-phase build is a new feature of Docker 17.05. it can use multiple FROM statements in a Dockerfile to create multiple Stages (phases). Each phase is independent (source request), and files for other phases can be obtained through COPY-- from. Let's compare the final image to a dish (fried green peppers). Stir-fry the green peppers and serve them.

# compare list image-> first stage of a dish-> stir-fry second stage-> serve

The goal of the two stages is to prepare (generate) the final dish (mirror image). What we need to do is to "put on the table" the food that is "fried" in the first stage. Our goal is to make dishes, and dishes (dishes and intermediates) are the lightest.

The visualization process is as follows:

# the cooking process. Omit raw materials-> [first stage-stir-fry] # at this time there are stir-frying tools, results and intermediates on the plate # this time starts the second stage, leaving only the results of frying and no need for anything else. -> stir-fry results-> [start to serve, keep only the results] # bring the fried green peppers (COPY-- from), and don't-- > end up a dish.

You should now have a general understanding of the multi-phase build process. Let's give the microphone to Java and see what to do in Dockerfile to build a JAR using the compilation tool, leaving only the built JAR and runtime to Image, and throwing away the rest:

# the first stage-compile (stir-fry) FROM openjdk:8u171-jdk-alpine3.8 as builder # comes with compilation tool ADD. / appWORKDIR / appRUN... Omit compilation and cleanup work. # now, JAR has been released. JDK is no longer needed, so it cannot be left in the mirror. # so we started the second phase-- running (on the table) and throwing away all the files in the first phase (including the compilation tools) FROM openjdk:8u181-jre-alpine3.8 as environment # with only the runtime # currently, we have left behind the compilation tools and other things from the previous stage. There is only runtime in the current image, we need to bring the results of the previous phase (speculation), and do not do the rest. COPY-- from=0 / final.jar. # well, now the mirror only has the necessary runtime and JAR. ENTRYPOINT java-jar / final.jar

This is an introduction to multi-phase construction.

Use multi-phase build

The core command of a multi-phase build is FROM. There is no need to say more about FORM for you who have experienced many battles. In a multi-phase build, each FROM opens a new Stage (phase), which can be seen as a new Image (inaccurate, source request), isolated from other phases (and even environment variables). Only the final FROM will be included in the Image.

Let's make an example of the most simple multi-phase build:

# Stage 1FROM alpine:3.8WORKDIR / demoRUN echo "Hello, stage 1" > / demo/hi-1.txt# Stage 2FROM alpine:3.8WORKDIR / demoRUN echo "Hello, stage 2" > / demo/hi-2.txt

You can build the Dockerfile yourself, and then docker save > docker.tar to see what's in it. There should be only / demo/hi-2.txt and Alpine if nothing happens.

In this Dockerfile, we created two phases. The first phase creates the hi-1.txt, the second phase creates the hi-2.txt, and the second phase is added to the final Image, and the others do not.

Copying files-- the bridge between phases

If the phases are completely isolated, then many stages are meaningless-the results of the previous stage will be completely abandoned and move on to the new next phase.

We can get the files for other stages through the COPY command. The use of COPY in multiple stages is exactly the same as that of ordinary applications. You only need to add-form `. So, we modify the previous example so that the final mirror contains the product of two stages:

# Stage 1FROM alpine:3.8WORKDIR / demoRUN echo "Hello, stage 1" > / demo/hi-1.txt# Stage 2FROM alpine:3.8WORKDIR / demoCOPY-- from=0 / demo/hi-1.txt / demoRUN echo "Hello, stage 2" > / demo/hi-2.txt

Rebuild and save (Save), and you will find an extra layer of Layer, which contains hi-1.txt.

Stage naming-- Fast recognition

For us who have only seven seconds of memory, it's not a good thing to use stage index every time. At this time, they can be given names by stage naming to facilitate identification.

Adding a name to the phase is simple, as long as you add as after the FROM.

Now, we update the Dockerfile, give the phase name and use the name to COPY.

# Stage 1, it's name is "build1" FROM alpine:3.8 as build1WORKDIR / demoRUN echo "Hello, stage 1" > / demo/hi-1.txt# Stage 2, it's name is "build2" FROM alpine:3.8 as build2WORKDIR / demo# No longer use indexesCOPY-from=build1 / demo/hi-1.txt / demoRUN echo "Hello, stage 2" > / demo/hi-2.txt

Rebuild and save, the result should be the same as last time.

Build only part of the phase-easy debugging

Docker also provides us with a convenient way to debug-- only part of the build phase. It can make the build stop at a certain stage and not build the later stages. This makes it easy for us to debug and distinguish between production, development and testing.

The last Dockerfile is still used, but built with the-- target parameter:

$docker build-target build1.

Save again and you will find that there is only build1 content.

The above is all the content of the article "how to use Docker multi-phase build to reduce image size". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, 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.