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

Editor to share with you the Docker of Dockerfile multi-stage construction principles and sample analysis of the use of scenarios, I hope you will learn something after reading this article, let's discuss it together!

Why multiple FROM instructions are not supported in older versions of Docker

In Docker before version 17.05, only one FROM instruction was allowed in Dockerfile, starting with the nature of mirroring.

As we mentioned earlier, you can simply understand that the image of Docker is a compressed file that contains the programs you need and a file system. In fact, this is not rigorous, Docker image is not just a file, but a pile of files, the most important file is the layer.

In Dockerfile, most instructions generate a layer, such as the following two examples:

# example 1. There are already several layers in the Dockerfile# basic image of the foo image. The FROM ubuntu:16.04# RUN instruction will be added to this layer. In this layer, the git software RUN apt-get update\ & & apt-get install- y-no-install-recommends git\ & & apt-get clean\ & & rm-rf / var/lib/apt/lists/*# example 2 will be added to the DockerfileFROM foo# RUN instruction of the bar image. In this layer, NginxRUN apt-get update\ & & apt-get install- y-- no-install-recommends nginx\ & & apt-get clean\ & & rm-rf / var/lib/apt/lists/* is installed

Assuming that the basic image ubuntu:16.04 already has 5 layers, and the first Dockerfile is packaged into an image foo, then the foo has 6 layers, and the second Dockerfile is packaged into an image bar, then there are 7 layers in the bar.

If other images such as ubuntu:16.04 are not counted, and if there are only foo and bar images in the system, how many layers are saved in the system?

It's 7 layers, not 13, because foo and bar share 6 layers. Layer sharing mechanism can save a lot of disk space and transmission bandwidth. For example, when you already have a foo image locally, and pull the bar image from the image repository, you can only pull the last layer that is not available locally, and you do not need to pull the entire bar image through the root. But how is layer sharing implemented?

Originally, each layer of the Docker image only records file changes. When the container starts, Docker calculates each layer of the image and finally generates a file system, which is called joint mount. If you are interested in this, you can check out AUFS.

The layers of Docker are related, and in the process of joint mount, the system needs to know what kind of foundation to add new files on. Then this requires that a Docker image can have only one starting layer and only one root. Therefore, only one FROM instruction is allowed in Dockerfile. Because multiple FROM instructions can cause multiple roots, it is impossible to implement. But why does Docker allow Dockerfile to support multiple FROM instructions after version 17.05, or does it already support multiple roots?

The meaning of multiple FROM instructions

Multiple FROM instructions are not intended to generate a multi-root layer relationship, and the final image is still based on the last FROM, and the previous FROM will be discarded, so what's the point of the previous FROM?

Each FROM instruction is a construction phase, and multiple FROM is a multi-phase build. Although the final generated image can only be the result of the last phase, the files in the previous phase can be copied to the later phase, which is the greatest significance of multi-phase construction.

The biggest use scenario is to separate the compilation environment from the running environment. For example, before we need to build a Go language program, we need to use a compilation environment such as the go command. Our Dockerfile might look like this:

# Go environment basic image FROM golang:1.10.3# copies the source code to the image COPY server.go / build/# specifies the working directory WORKDIR / build# compiles the image, runs go build to compile the server program RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 GOARM=6 go build-ldflags'- w-s'- o server# specifies the container runtime entry program serverENTRYPOINT ["/ build/server"]

The basic image golang:1.10.3 is very large, because it contains all the Go language compilation tools and libraries, and at run time we only need the compiled server program, do not need compile-time compilation tools, the final generation of a large image is a waste.

The solution to using the pulse cloud is to separate the program compilation from the image, use the pulse cloud compilation build service, choose to add the Go language build tool, and then compile in the build step.

Finally, just copy the compilation interface to the image, so the basic image of Dockerfile does not need to include the Go compilation environment:

# there is no need for Go language compilation environment FROM scratch# to copy the compilation results to the container COPY server / server# specify the container runtime entry program serverENTRYPOINT ["/ server"]

Tip: scratch is a built-in keyword, not a real mirror. FROM scratch uses a completely clean file system that does not contain any files. Because the Go language compiles without runtime, there is no need to install any runtime. FROM scratch minimizes the resulting image, which contains only the server program.

After Docker version 17.05, there is a new solution that can be solved with a single Dockerfile:

# compilation phase FROM golang:1.10.3COPY server.go / build/WORKDIR / buildRUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 GOARM=6 go build-ldflags'- w-s'- o server# runtime FROM scratch# copies the compilation result from the compilation phase to the current image COPY-- from=0 / build/server / ENTRYPOINT ["/ server"] Copy

The mystery of this Dockerfile lies in the from=0 parameter of the COPY instruction, which copies files from the previous phase to the current stage, and when there are multiple FROM statements, 0 represents the first stage. In addition to using numbers, we can also name the phase, such as:

# the compilation phase is named builderFROM golang:1.10.3 as builder#... Omit # run-time FROM scratch# copy the compilation result from the compilation phase to the current image COPY-- from=builder / build/server /

Even more powerful, COPY-from can be copied not only from the pre-phase, but also directly from an existing mirror. such as,

FROM ubuntu:16.04COPY-- from=quay.io/coreos/etcd:v3.3.9 / usr/local/bin/etcd / usr/local/bin/

We directly copy the program in the etcd image to our image, so that when generating our program image, we don't need to compile etcd with source code, just bring the official compiled program file over.

Some programs either do not have an apt source, or the version in the apt source is too old, or simply provide the source code and need to compile themselves. when using these programs, we can easily use the existing Docker image as our base image. But our software may sometimes need to rely on multiple such files, we can not simultaneously use nginx and etcd images as our basic image (does not support multiple roots), in this case, the use of COPY-from is very convenient and practical.

After reading this article, I believe you have a certain understanding of "sample analysis of multi-stage construction principles and usage scenarios of Dockerfile in Docker". If you want to know more about it, please follow the industry information channel. Thank you for reading!

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.