前言
docker的口号是build,ship,and run any app,anywhere，在我们使用 docker 的大部分时候，的确能感觉到其优越性，但是往往在我们 build 一个应用的时候，是将我们的源代码也构建进去的，这对于类似于 golang 这样的编译型语言肯定是不行的，因为实际运行的时候我只需要把最终构建的二进制包给你就行，把源码也一起打包在镜像中，需要承担很多风险，即使是脚本语言，在构建的时候也可能需要使用到一些上线的工具，这样无疑也增大了我们的镜像体积。
在应用了容器技术的软件开发过程中，控制容器镜像的大小可是一件费时费力的事情。如果我们构建的镜像既是编译软件的环境，又是软件最终的运行环境，这是很难控制镜像大小的。所以常见的配置模式为：分别为软件的编译环境和运行环境提供不同的容器镜像。比如为编译环境提供一个 dockerfile.build，用它构建的镜像包含了编译软件需要的所有内容，比如代码、sdk、工具等等。同时为软件的运行环境提供另外一个单独的 dockerfile，它从 dockerfile.build 中获得编译好的软件，用它构建的镜像只包含运行软件所必须的内容。这种情况被称为构造者模式(builder pattern)，本文将介绍如何通过 dockerfile 中的 multi-stage 来解决构造者模式带来的问题。
常见的容器镜像构建过程
比如我们创建了一个 go 语言编写了一个检查页面中超级链接的程序 app.go(请从 （sparkdev ）获取本文相关的代码)：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
package mainimport ( "encoding/json" "fmt" "log" "net/http" "net/url" "os" "strings" "golang.org/x/net/html")type scrapedatastore struct { internal int `json:"internal"` external int `json:"external"`}func isinternal(parsedlink *url.url, siteurl *url.url, link string) bool { return parsedlink.host == siteurl.host || strings.index(link, "#") == 0 || len(parsedlink.host) == 0}func main() { urlin := os.getenv("url") if len(urlin) == 0 { urlin = "https://www.cnblogs.com/" } resp, err := http.get(urlin) scrapedata := &scrapedatastore{} tokenizer := html.newtokenizer(resp.body) end := false for { tt := tokenizer.next() switch { case tt == html.starttagtoken: token := tokenizer.token() switch token.data { case "a": for _, attr := range token.attr { if attr.key == "href" { link := attr.val parsedlink, parselinkerr := url.parse(link) if parselinkerr == nil { if isinternal(parsedlink, siteurl, link) { scrapedata.internal++ } else { scrapedata.external++ } } if parselinkerr != nil { fmt.println("can't parse: " + token.data) } } } break } case tt == html.errortoken: end = true break } if end { break } } data, _ := json.marshal(&scrapedata) fmt.println(string(data))} |
下面我们通过容器来构建它，并把它部署到生产型的容器镜像中。
首先构建编译应用程序的镜像：
|
1
2
3
4
5
|
from golang:1.7.3workdir /go/src/github.com/sparkdevo/href-counter/run go get -d -v golang.org/x/net/htmlcopy app.go .run cgo_enabled=0 goos=linux go build -a -installsuffix cgo -o app . |
把上面的内容保存到 dockerfile.build 文件中。
接着把构建好的应用程序部署到生产环境用的镜像中：
|
1
2
3
4
5
|
from alpine:latest run apk --no-cache add ca-certificatesworkdir /root/copy app .cmd ["./app"] |
把上面的内容保存到 dockerfile 文件中。
最后需要使用一个脚本把整个构建过程整合起来：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
#!/bin/shecho building sparkdevo/href-counter:build# 构建编译应用程序的镜像docker build --no-cache -t sparkdevo/href-counter:build . -f dockerfile.build# 创建应用程序docker create --name extract sparkdevo/href-counter:build# 拷贝编译好的应用程序docker cp extract:/go/src/github.com/sparkdevo/href-counter/app ./appdocker rm -f extractecho building sparkdevo/href-counter:latest# 构建运行应用程序的镜像docker build --no-cache -t sparkdevo/href-counter:latest . |
把上面的内容保存到 build.sh 文件中。这个脚本会先创建出一个容器来构建应用程序，然后再创建最终运行应用程序的镜像。
把 app.go、dockerfile.build、dockerfile 和 build.sh 放在同一个目录下，然后进入这个目录执行 build.sh 脚本进行构建。构建后的容器镜像大小：
从上图中我们可以观察到，用于编译应用程序的容器镜像大小接近 700m，而用于生产环境的容器镜像只有 10.3 m，这样的大小在网络间传输的效率是很高的。
运行下面的命令可以检查我们构建的容器是否可以正常的工作：
|
1
2
|
$ docker run -e url=https://www.cnblogs.com/ sparkdevo/href-counter:latest$ docker run -e url=http://www.cnblogs.com/sparkdev/ sparkdevo/href-counter:latest |
ok，我们写的程序正确的统计了博客园首页和笔者的首页中超级链接的情况。
采用上面的构建过程，我们需要维护两个 dockerfile 文件和一个脚本文件 build.sh。能不能简化一些呢？ 下面我们看看 docker 针对这种情况提供的解决方案：multi-stage。
在 dockerfile 中使用 multi-stage
multi-stage 允许我们在 dockerfile 中完成类似前面 build.sh 脚本中的功能，每个 stage 可以理解为构建一个容器镜像，后面的 stage 可以引用前面 stage 中创建的镜像。所以我们可以使用下面单个的 dockerfile 文件实现前面的需求：
|
1
2
3
4
5
6
7
8
9
10
11
|
from golang:1.7.3workdir /go/src/github.com/sparkdevo/href-counter/run go get -d -v golang.org/x/net/htmlcopy app.go .run cgo_enabled=0 goos=linux go build -a -installsuffix cgo -o app .from alpine:latestrun apk --no-cache add ca-certificatesworkdir /root/copy --from=0 /go/src/github.com/sparkdevo/href-counter/app .cmd ["./app"] |
把上面的内容保存到文件 dockerfile.multi 中。这个 dockerfile 文件的特点是同时存在多个 from 指令，每个 from 指令代表一个 stage 的开始部分。我们可以把一个 stage 的产物拷贝到另一个 stage 中。本例中的第一个 stage 完成了应用程序的构建，内容和前面的 dockerfile.build 是一样的。第二个 stage 中的 copy 指令通过 --from=0 引用了第一个 stage ，并把应用程序拷贝到了当前 stage 中。接下来让我们编译新的镜像：
|
1
|
$ docker build --no-cache -t sparkdevo/href-counter:multi . -f dockerfile.multi |
这次使用 href-counter:multi 镜像运行应用：
|
1
2
|
$ docker run -e url=https://www.cnblogs.com/ sparkdevo/href-counter:multi$ docker run -e url=http://www.cnblogs.com/sparkdev/ sparkdevo/href-counter:multi |
结果和之前是一样的。那么新生成的镜像有没有特别之处呢：
好吧，从上图我们可以看到，除了 sparkdevo/href-counter:multi 镜像，还生成了一个匿名的镜像。因此，所谓的 multi-stage 不过时多个 dockerfile 的语法糖罢了。但是这个语法糖还好很诱人的，现在我们维护一个结构简洁的 dockerfile 文件就可以了！
使用命名的 stage
在上面的例子中我们通过 --from=0 引用了 dockerfile 中第一个 stage，这样的做法会让 dockerfile 变得不容易阅读。其实我们是可以为 stage 命名的，然后就可以通过名称来引用 stage 了。下面是改造后的 dockerfile.mult 文件：
|
1
2
3
4
5
6
7
8
9
10
11
|
from golang:1.7.3 as builderworkdir /go/src/github.com/sparkdevo/href-counter/run go get -d -v golang.org/x/net/htmlcopy app.go .run cgo_enabled=0 goos=linux go build -a -installsuffix cgo -o app .from alpine:latestrun apk --no-cache add ca-certificatesworkdir /root/copy --from=builder /go/src/github.com/sparkdevo/href-counter/app .cmd ["./app"] |
我们把第一个 stage 使用 as 语法命名为 builder，然后在后面的 stage 中通过名称 builder 进行引用 --from=builder。通过使用命名的 stage， dockerfile 更容易阅读了。
总结
dockerfile 中的 multi-stage 虽然只是些语法糖，但它确实为我们带来了很多便利。尤其是减轻了 dockerfile 维护者的负担(要知道实际生产中的 dockerfile 可不像 demo 中的这么简单)。需要注意的是旧版本的 docker 是不支持 multi-stage 的，只有 17.05 以及之后的版本才开始支持。好了，是不是该去升级你的 docker 版本了？
好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对服务器之家的支持。
参考：
原文链接：http://www.cnblogs.com/sparkdev/p/8508435.html
