Docker Important update: Native support multi-stage build (multi-stage build)

This is a creation in Article, where the information may have evolved or changed.

The slogan for Docker is Build, ship, and Run any App, Anywhere.
But we will encounter a problem in the application process, we in the build, the source code is also build in.
And then go ahead and get the source ship out? That's not going to work. All compiled languages are confronted with this problem.
Even in a scripted language, build uses a lot of built-in tools that are not available on-line,
And we want to reduce the volume of the production mirror so that our little whale can pull a little more container.

Traditional practices

Our ultimate goal is to copy the compiled executable into alpine such a mini-image,
So how do you get the compiled files? Based on the idea of Docker, we certainly need to compile in a standard container,
This process is standardized, besides, you can compile a binary file in Ubuntu in Alpine also can not run.

So first we need to prepare a custom image for compilation. The alpine base image is usually used in the corresponding language,
Package all the additional tools needed to compile the project, such as Golang, which currently has no official package management,
You'll need to put your package management tools in.

Then we need to mount a directory of the host through-V on the container when running container.
Let it output the compiled results to this mounted directory so that we can get this file on the host.

Finally, we use a minimal alpine image to copy the binaries in.
Maybe you need to set up a time zone or something.

Continuous integration

The process above has become a problem with the continuous integration tool. You will find that each CI provider is not the same.
You may not have permission to control the host when CI is hosted.

For example Docker Cloud , you need to define a pre-build hook to do the job,
In SEMAPHORE , you find that you have a host, which is the same as our local practice.
In more providers, you will find that they can only build images based on git repositories and Dockerfile,
You can't even make a minimal image with their system ...
China is DaoCloud actually very advanced, very early introduced the concept of security image, let your build through two steps to complete.
However, the content of that configuration too much let the people who do not understand directly faint.

Official programme

In its forthcoming release on May 3, 2017 Docker 17.05.0-ce , Docker has provided a simple, multi-stage build
(multi-stage build) scenario. Let me introduce you to the following examples:

FROM muninn/glide:alpine AS build-envADD . /go/src/appWORKDIR /go/src/appRUN glide installRUN go build -v -o /go/src/app/app-serverFROM alpineRUN apk add -U tzdataRUN ln -sf /usr/share/zoneinfo/Asia/Shanghai  /etc/localtimeCOPY --from=build-env /go/src/app/app-server /usr/local/bin/app-serverEXPOSE 80CMD ["app-server"]

First, there's a keyword behind the first one FROM AS that gives you a name for the stage.
I give an example of this image is official
Golang:alpine Plus build tool Glide, we still install dependencies, build out a binary program.

Then, the second part uses the official alpine image, changes the time zone to China, the new feature is embodied in the COPY keyword,
It can now accept --from= such parameters, copying files from the last stage of our name.

It's so simple, now you just need a Dockerfile to get everything done.

Multi-Project Construction

So now you can build the binaries of several projects in a mini-image, and continue to raise a chestnut:

from debian as build-essentialarg APT_MIRRORrun apt-get updaterun apt-get install -y make gccworkdir /srcfrom build-essential as foocopy src1 .run makefrom build-essential as barcopy src2 .run makefrom alpinecopy --from=foo bin1 .copy --from=bar bin2 .cmd ...

This is the file that compiles two projects and eventually merges into one image.

Well, congratulations to those CI services that don't support multi-segment construction, Docker has helped you to match your competitors.
I have the opportunity to write a support for Docker CI subjective comments, but also welcome everyone Spit Channel CI to provide me with material.