您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
理解Docker的多阶段镜像构建
 
140 次浏览     评价:  
 2017-12-4  
 
编辑推荐:
本文来源51CTO,什么是镜像多阶段构建 呢?直接给出概念定义太突兀,这里先卖个关子,我们先从日常开发中用到的镜像构建的方式和所遇到的镜像构建的问题说起。

Docker技术从 2013年诞生 到目前已经4年有余了。对于已经接纳和使用 Docker技术 在日常开发工作中的开发者而言,构建 Docker镜像 已经是家常便饭。但这是否意味着Docker的image构建机制已经相对完美了呢 不是的,Docker官方依旧在持续优化镜像构建机制。这不,从今年发布的 Docker 17.05版本 起,Docker开始支持容器镜像的 多阶段构建(multi-stage build) 了。

什么是 镜像多阶段构建 呢 直接给出概念定义太突兀,这里先卖个关子,我们先从日常开发中用到的镜像构建的方式和所遇到的镜像构建的问题说起。

一、同构的镜像构建

我们在做镜像构建时的一个常见的场景就是:应用在开发者自己的开发机或服务器上直接编译,编译出的二进制程序再打入镜像。这种情况一般要求编译环境与镜像所使用的base image是兼容的,比如说:我在 Ubuntu 14.04 上编译应用,并将应用打入基于 ubuntu系列base image 的镜像。这种构建我称之为“同构的镜像构建”,因为应用的编译环境与其部署运行的环境是兼容的:我在Ubuntu 14.04下编译出来的应用,可以基本无缝地在基于ubuntu:14.04及以后版本base image镜像(比如:16.04、16.10、17.10等)中运行;但在不完全兼容的base image中,比如 centos 中就可能会运行失败。

1、同构镜像构建举例

这里举个同构镜像构建的例子(后续的章节也是基于这个例子的),注意:我们的编译环境为 Ubuntu 16.04 x86_64虚拟机、Go 1.8.3和docker 17.09.0-ce 。

我们用一个Go语言中最常见的http server作为例子:

  1. //github.com/bigwhite/ experiments/multi_stage_image_build /isomorphism/httpserver.go
  2. package main
  3. import (
  4. "net/http"
  5. "log"
  6. "fmt"
  7. )
  8. func home(w http.ResponseWriter, req *http.Request) {
  9. w.Write([]byte("Welcome to this website!\n"))
  10. }
  11. func main() {
  12. http.HandleFunc("/", home)
  13. fmt.Println("Webserver start")
  14. fmt.Println(" -> listen on port:1111")
  15. err := http.ListenAndServe(":1111", nil)
  16. if err != nil {
  17. log.Fatal("ListenAndServe:", err)
  18. }
  19. }

编译这个程序:

  1. # go build -o myhttpserver httpserver.go
  2. # ./myhttpserver
  3. Webserver start
  4. -> listen on port:1111

这个例子看起来很简单,也没几行代码,但背后Go net/http包在底层做了大量的事情,包括很多系统调用,能够反映出应用与操作系统的“耦合”,这在后续的讲解中会体现出来。接下来我们就来为这个程序构建一个docker image,并基于这个image来启动一个myhttpserver容器。我们选择ubuntu:14.04作为base image:

  1. //github.com/bigwhite/ experiments/multi_stage_image_build /isomorphism/Dockerfile
  2. From ubuntu:14.04
  3. COPY ./myhttpserver /root/myhttpserver
  4. RUN chmod +x /root/myhttpserver
  5. WORKDIR /root
  6. ENTRYPOINT ["/root/myhttpserver"]

执行构建:

  1. # docker build -t myrepo/myhttpserver:latest .
  2. Sending build context to Docker daemon 5.894MB
  3. Step 1/5 : FROM ubuntu:14.04
  4. ---> dea1945146b9
  5. Step 2/5 : COPY ./myhttpserver /root/myhttpserver
  6. ---> 993e5129c081
  7. Step 3/5 : RUN chmod +x /root/myhttpserver
  8. ---> Running in 104d84838ab2
  9. ---> ebaeca006490
  10. Removing intermediate container 104d84838ab2
  11. Step 4/5 : WORKDIR /root
  12. ---> 7afdc2356149
  13. Removing intermediate container 450ccfb09ffd
  14. Step 5/5 : ENTRYPOINT /root/myhttpserver
  15. ---> Running in 3182766e2a68
  16. ---> 77f315e15f14
  17. Removing intermediate container 3182766e2a68
  18. Successfully built 77f315e15f14
  19. Successfully tagged myrepo/myhttpserver:latest
  20. # docker images
  21. REPOSITORY TAG IMAGE ID CREATED SIZE
  22. myrepo/myhttpserver latest 77f315e15f14 18 seconds ago 200MB
  23. # docker run myrepo/myhttpserver
  24. Webserver start
  25. -> listen on port:1111

以上是最基本的image build方法。

接下来,我们可能会遇到如下需求:

* 搭建一个Go程序的构建环境有时候是很耗时的,尤其是对那些依赖很多第三方开源包的Go应用来说,下载包就需要很长时间。我们最好将这些易变的东西统统打包到一个用于Go程序构建的builder image中;

* 我们看到上面我们构建出的myrepo/myhttpserver image的SIZE是200MB,这似乎有些过于“庞大”了。虽然每个主机node上的docker有cache image layer的能力,但我们还是希望能build出更加精简短小的image。

2、借助golang builder image

Docker Hub上提供了一个带有go dev环境的官方 golang image repository ,我们可以直接使用这个golang builder image来辅助构建我们的应用image;对于一些对第三方包依赖较多的Go应用,我们也可以以这个golang image为base image定制我们自己的专用builder image。

我们基于golang:latest这个base image构建我们的golang-builder image,我们编写一个Dockerfile.build用于build golang-builder image:

  1. //github.com/bigwhite/ experiments/multi_stage_image_build/ isomorphism/Dockerfile.build
  2. FROM golang:latest
  3. WORKDIR /go/src
  4. COPY httpserver.go .
  5. RUN go build -o myhttpserver ./httpserver.go

在同目录下构建golang-builder image:

  1. # docker build -t myrepo/golang-builder:latest -f Dockerfile.build .
  2. Sending build context to Docker daemon 5.895MB
  3. Step 1/4 : FROM golang:latest
  4. ---> 1a34fad76b34
  5. Step 2/4 : WORKDIR /go/src
  6. ---> 2361824677d3
  7. Removing intermediate container 01d8f4e9f0c4
  8. Step 3/4 : COPY httpserver.go .
  9. ---> 1ff14bb0bc56
  10. Step 4/4 : RUN go build -o myhttpserver ./httpserver.go
  11. ---> Running in 37a1b76b7b9e
  12. ---> 2ac5347bb923
  13. Removing intermediate container 37a1b76b7b9e
  14. Successfully built 2ac5347bb923
  15. Successfully tagged myrepo/golang-builder:latest
  16. REPOSITORY TAG IMAGE ID CREATED SIZE
  17. myrepo/golang-builder latest 2ac5347bb923 3 minutes ago 739MB

接下来,我们就基于golang-builder中已经build完毕的myhttpserver来构建我们最终的应用image:

  1. # docker create --name appsource myrepo/golang-builder:latest
  2. # docker cp appsource:/go/src/myhttpserver ./
  3. # docker rm -f appsource
  4. # docker rmi myrepo/golang-builder:latest
  5. # docker build -t myrepo/myhttpserver:latest .

这段命令的逻辑就是从基于golang-builder image启动的容器appsource中将已经构建完毕的myhttpserver拷贝到主机当前目录中,然后删除临时的container appsource以及上面构建的那个golang-builder image;最后的步骤和第一个例子一样,基于本地目录中的已经构建完的myhttpserver构建出最终的image。为了方便,你也可以将这一系列命令放到一个Makefile中去。

3、使用size更小的alpine image

builder image并不能帮助我们为最终的应用image“减重”,myhttpserver image的Size依旧停留在200MB。要想“减重”,我们需要更小的base image,我们选择了 alpine 。 Alpine image 的size不到4M,再加上应用的size,最终应用Image的Size估计可以缩减到20M以下。

结合builder image,我们只需将Dockerfile的base image改为alpine:latest:

  1. //github.com/bigwhite/ experiments/multi_stage_image_build /isomorphism/Dockerfile.alpine
  2. From alpine:latest
  3. COPY ./myhttpserver /root/myhttpserver
  4. RUN chmod +x /root/myhttpserver
  5. WORKDIR /root
  6. ENTRYPOINT ["/root/myhttpserver"]

构建alpine版应用image:

  1. # docker build -t myrepo/myhttpserver-alpine:latest -f Dockerfile.alpine .
  2. Sending build context to Docker daemon 6.151MB
  3. Step 1/5 : FROM alpine:latest
  4. ---> 053cde6e8953
  5. Step 2/5 : COPY ./myhttpserver /root/myhttpserver
  6. ---> ca0527a62d39
  7. Step 3/5 : RUN chmod +x /root/myhttpserver
  8. ---> Running in 28d0a8a577b2
  9. ---> a3833af97b5e
  10. Removing intermediate container 28d0a8a577b2
  11. Step 4/5 : WORKDIR /root
  12. ---> 667345b78570
  13. Removing intermediate container fa59883e9fdb
  14. Step 5/5 : ENTRYPOINT /root/myhttpserver
  15. ---> Running in adcb5b976ca3
  16. ---> 582fa2aedc64
  17. Removing intermediate container adcb5b976ca3
  18. Successfully built 582fa2aedc64
  19. Successfully tagged myrepo/myhttpserver-alpine:latest
  20. # docker images
  21. REPOSITORY TAG IMAGE ID CREATED SIZE
  22. myrepo/myhttpserver-alpine latest 582fa2aedc64 4 minutes ago 16.3MB

16.3MB,Size的确降下来了!我们基于该image启动一个容器,看应用运行是否有什么问题:

  1. # docker run myrepo/myhttpserver-alpine:latest
  2. standard_init_linux.go:185: exec user process caused "no such file or directory"

容器启动失败了!为什么呢 因为alpine image并非ubuntu环境的同构image。我们在下面详细说明。

二、异构的镜像构建

我们的image builder: myrepo/golang-builder:latest是基于golang:latest这个image。 golang base image 有两个模板:Dockerfile-debain.template和Dockerfile-alpine.template。而golang:latest是基于debian模板的,与ubuntu兼容。构建出来的myhttpserver对动态共享链接库的情况如下:

  1. # ldd myhttpserver
  2. linux-vdso.so.1 => (0x00007ffd0c355000)
  3. libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffa8b36f000)
  4. libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffa8afa5000)
  5. /lib64/ld-linux-x86-64.so.2 (0x000055605ea5d000)

debian 系的linux distribution使用了glibc。但alpine则不同, alpine 使用的是 musl libc 的实现,因此当我们运行上面的那个容器时,加载器因找不到myhttpserver依赖的libc.so.6而失败退出。

这种构建环境与运行环境不兼容的情况我这里称之为“异构的镜像构建”。那么如何解决这个问题呢 我们继续看:

1、静态构建

在主流编程语言中,Go的移植性已经是数一数二的了,尤其是Go 1.5之后,Go将runtime中的C代码都用Go重写了,对libc的依赖已经降到最低了,但仍有一些feature提供了两个版本的实现:C实现和Go实现。并且默认情况下,即在CGO_ENABLED=1的情况下,程序和预编译的标准库都采用了C的实现。关于这方面的详细论述请参见我之前写的《也谈Go的可移植性》一文,这里就不赘述了。于是采用了不同libc实现的debian系和alpine系自然存在不兼容的情况。要解决这个问题,我们首先考虑对Go程序进行静态构建,然后将静态构建后的Go应用放入alpine image中。

我们修改一下Dockerfile.build,在编译Go源文件时加上CGO_ENABLED=0:

  1. //github.com/bigwhite/ experiments/multi_stage_image_build /heterogeneous/Dockerfile.build
  2. FROM golang:latest
  3. WORKDIR /go/src
  4. COPY httpserver.go .
  5. RUN CGO_ENABLED=0 go build -o myhttpserver ./httpserver.go

构建这个builder image:

  1. # docker build -t myrepo/golang-static-builder:latest -f Dockerfile.build .
  2. Sending build context to Docker daemon 4.096kB
  3. Step 1/4 : FROM golang:latest
  4. ---> 1a34fad76b34
  5. Step 2/4 : WORKDIR /go/src
  6. ---> 593cd9692019
  7. Removing intermediate container ee005d487ad5
  8. Step 3/4 : COPY httpserver.go .
  9. ---> a095eb69e716
  10. Step 4/4 : RUN CGO_ENABLED=0 go build -o myhttpserver ./httpserver.go
  11. ---> Running in d9f3b3a6c36c
  12. ---> c06fe8dccbad
  13. Removing intermediate container d9f3b3a6c36c
  14. Successfully built c06fe8dccbad
  15. Successfully tagged myrepo/golang-static-builder:latest
  16. # docker images
  17. REPOSITORY TAG IMAGE ID CREATED SIZE
  18. myrepo/golang-static-builder latest c06fe8dccbad 31 seconds ago 739MB

接下来,我们再基于golang-static-builder中已经build完毕的静态连接的myhttpserver来构建我们最终的应用image:

  1. # docker create --name appsource myrepo/golang-static-builder:latest
  2. # docker cp appsource:/go/src/myhttpserver ./
  3. # ldd myhttpserver
  4. not a dynamic executable
  5. # docker rm -f appsource
  6. # docker rmi myrepo/golang-static-builder:latest
  7. # docker build -t myrepo/myhttpserver-alpine:latest -f Dockerfile.alpine .

运行新image:

  1. # docker run myrepo/myhttpserver-alpine:latest
  2. Webserver start
  3. -> listen on port:1111

Note: 我们可以用strace来证明静态连接时Go只使用的是Go自己的runtime实现,而并未使用到libc.a中的代码:

  1. # CGO_ENABLED=0 strace -f go build httpserver.go 2>&1 | grep open | grep -o '/.*\.a' > go-static-build-strace-file-open.txt

打开 go-static-build-strace-file-open.txt 文件查看文件内容,你不会找到libc.a这个文件(在Ubuntu下,一般libc.a躺在/usr/lib/x86_64-linux-gnu/下面),这说明go build根本没有尝试去open libc.a文件并获取其中的符号定义。

2、使用alpine golang builder

我们的Go应用运行在alpine based的container中,我们可以使用alpine golang builder来构建我们的应用(无需静态链接)。前面提到过golang有alpine模板:

  1. REPOSITORY TAG IMAGE ID CREATED SIZE
  2. golang alpine 9e3f14138abd 7 days ago 269MB

alpine版golang builder的Dockerfile内容如下:

  1. //github.com/bigwhite/ experiments/multi_stage_image_build/ heterogeneous/Dockerfile.alpine.build
  2. FROM golang:alpine
  3. WORKDIR /go/src
  4. COPY httpserver.go .
  5. RUN go build -o myhttpserver ./httpserver.go

后续的操作与前面golang builder的操作并不二致:利用alpine golang builder构建我们的应用,并将其打入alpine image,这里就不赘述了。

三、多阶段镜像构建:提升开发者体验

在Docker 17.05以前,我们都是像上面那样构建镜像的。你会发现即便采用异构image builder模式,我们也要维护两个Dockerfile,并且还要在docker build命令之外执行一些诸如从容器内copy应用程序、清理build container和build image等的操作。Docker社区看到了这个问题,于是实现了 多阶段镜像构建机制 (multi-stage)。

我们先来看一下针对上面例子,multi-stage build所使用Dockerfile:

  1. //github.com/bigwhite/ experiments/multi_stage_image_build /multi_stages/Dockerfile
  2. FROM golang:alpine as builder
  3. WORKDIR /go/src
  4. COPY httpserver.go .
  5. RUN go build -o myhttpserver ./httpserver.go
  6. From alpine:latest
  7. WORKDIR /root/
  8. COPY --from=builder /go/src/myhttpserver .
  9. RUN chmod +x /root/myhttpserver
  10. ENTRYPOINT ["/root/myhttpserver"]

看完这个Dockerfile的内容,你的第一赶脚是不是把之前的两个Dockerfile合并在一块儿了,每个Dockerfile单独作为一个“阶段”!事实也是这样,但这个Docker也多了一些新的语法形式,用于建立各个“阶段”之间的联系。针对这样一个Dockerfile,我们应该知道以下几点:

  • 支持Multi-stage build的Dockerfile在以往的多个build阶段之间建立内在连接,让后一个阶段构建可以使用前一个阶段构建的产物,形成一条构建阶段的chain;
  • Multi-stages build的最终结果仅产生一个image,避免产生冗余的多个临时images或临时容器对象,这正是我们所需要的:我们只要结果。

我们来使用multi-stage来build一下上述例子:

  1. # docker build -t myrepo/myhttserver-multi-stage:latest .
  2. Sending build context to Docker daemon 3.072kB
  3. Step 1/9 : FROM golang:alpine as builder
  4. ---> 9e3f14138abd
  5. Step 2/9 : WORKDIR /go/src
  6. ---> Using cache
  7. ---> 7a99431d1be6
  8. Step 3/9 : COPY httpserver.go .
  9. ---> 43a196658e09
  10. Step 4/9 : RUN go build -o myhttpserver ./httpserver.go
  11. ---> Running in 9e7b46f68e88
  12. ---> 90dc73912803
  13. Removing intermediate container 9e7b46f68e88
  14. Step 5/9 : FROM alpine:latest
  15. ---> 053cde6e8953
  16. Step 6/9 : WORKDIR /root/
  17. ---> Using cache
  18. ---> 30d95027ee6a
  19. Step 7/9 : COPY --from=builder /go/src/myhttpserver .
  20. ---> f1620b64c1ba
  21. Step 8/9 : RUN chmod +x /root/myhttpserver
  22. ---> Running in e62809993a22
  23. ---> 6be6c28f5fd6
  24. Removing intermediate container e62809993a22
  25. Step 9/9 : ENTRYPOINT /root/myhttpserver
  26. ---> Running in e4000d1dde3d
  27. ---> 639cec396c96
  28. Removing intermediate container e4000d1dde3d
  29. Successfully built 639cec396c96
  30. Successfully tagged myrepo/myhttserver-multi-stage:latest
  31. # docker images
  32. REPOSITORY TAG IMAGE ID CREATED SIZE
  33. myrepo/myhttserver-multi-stage latest 639cec396c96 About an hour ago 16.3MB

我们来Run一下这个image:

  1. # docker run myrepo/myhttserver-multi-stage:latest
  2. Webserver start
  3. -> listen on port:1111

四、小结

多阶段镜像构建可以让开发者通过一个Dockerfile,一次性地、更容易地构建出size较小的image,体验良好并且更容易接入CI/CD等自动化系统。不过当前多阶段构建仅是在Docker 17.05及之后的版本中才能得到支持。如果想学习和实践这方面功能,但又没有环境,可以使用 play-with-docker 提供的实验环境。

Play with Docker labs

   
 订阅
  捐助
相关文章

云计算的架构
对云计算服务模型
云计算核心技术剖析
了解云计算的漏洞
相关文档

云计算简介
云计算简介与云安全
下一代网络计算--云计算
软浅析云计算
相关课程

云计算原理与应用
云计算应用与开发
CMMI体系与实践
基于CMMI标准的软件质量保证
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号