从Docker版本 17.05.0-ce 开始,就⽀持了⼀种新的构建镜像的⽅法,叫做:多阶段构建(Multi-stage builds),旨在解决Docker构建应⽤容器中的⼀些痛点。在⽇常构建容器的场景中,经常会遇到在同⼀个容器中进⾏源码的获取,编译和⽣成,最终才构建为镜像。这样做的劣势在于:
1. 不得不在容器中安装构建程序所必须的运⾏时环境
2. 不得不在同⼀个容器中,获取程序的源码和构建所需的⼀些⽣态⼯具
3. 构建出的镜像甚⾄包含了程序源码和⼀些不必要的⽂件,导致容器镜像尺⼨偏⼤
当然,还有⼀种稍微优雅的⽅式,就是我们事先在外部将项⽬及其依赖库编译测试打包好后,再将其拷贝到构建⽬录中,这种虽然可以很好地规避第⼀种⽅式存在的风险点,但是也需要考虑不同镜像运⾏时,对于程序运⾏兼容性所带来的差异。其实,这些痛点,Docker也想到了,官⽅提供了简便的多阶段构建 (multi-stage build) ⽅案。所谓多阶段构建,也即将构建过程分为多个阶段,在同⼀个Dockerfile中,通过不同的阶段来构建和⽣成所需要的应⽤⽂件,最终将这些应⽤⽂件添加到⼀个release的镜像中。这样做能完全规避上⾯所遇到的⼀系列问题。实现多阶段构建,主要依赖于新提供的关键字:from 和 as。
下⾯举个栗⼦:
FROM muninn/glide:alpine AS build-envADD . /go/src/my-proj
WORKDIR /go/src/my-projRUN go get -v
RUN go build -o /go/src/my-proj/my-server
FROM alpine
RUN apk add -U tzdata
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtimeCOPY --from=build-env /go/src/my-proj/my-server /my-serverEXPOSE 80
CMD [\"my-server\"]
多阶段构建的Dockerfile看起来像是把两个或者更多的Dockerfile合并在了⼀起,这也即多阶段的意思。as 关键字⽤来为构建阶段赋予⼀个别名,这样,在另外⼀个构建阶段中,可以通过 from 关键字来引⽤和使⽤对应关键字阶段的构建输出,并打包到容器中。
在多阶段构建完成之后,输出的镜像仅仅包含了最终输出的my-server应⽤,没有其他的源码⽂件和第三⽅源码包,⾮常的⼲净和简洁。因为 build-env 阶段只是⼀个构建的中间过程⽽已。
甚⾄,我们还可以使⽤更多的构建阶段来构建不同的应⽤,最终将这些构建产出的应⽤,合并到⼀个最终需要发布的镜像中。我们可以看⼀个更复杂⼀点的栗⼦:
from debian as build-essentialarg APT_MIRRORrun apt-get update
run apt-get install -y make gccworkdir /src
from build-essential as foocopy src1 .run make
from build-essential as barcopy src2 .run make
from alpine
copy --from=foo bin1 .copy --from=bar bin2 .cmd ...
多阶段构建的好处不⾔⽽喻,既可以很⽅便地将多个彼此依赖的项⽬通过⼀个Dockerfile就可轻松构建出期望的容器镜像,并且不⽤担⼼镜像太⼤、源码泄露等风险。不得不说,这是⼀个⾮常不错的改进。以上就是本⽂的全部内容,希望对⼤家的学习有所帮助,也希望⼤家多多⽀持。
因篇幅问题不能全部显示,请点此查看更多更全内容