编写 Dockerfile 的五个最佳实践

此文适合Docker初学入门读者,大师请绕行!,遵守最佳实践可少踩坑、提升性能体验及可移植性,期望对读者有所帮助!

什么是Dockerfile

Dockerfile 是一个文本文件,里面包含了打包Docker镜像所需要用到的命令。Docker 可以通过读取 Dockerfile 里面的命令来自动化地构建Docker镜像。通过执行 docker build 就可以启动这样的一个自动化流程。

$ docker build -f Dockerfile .
Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM nginx:latest
 ---> f895b3fb9e30
Successfully built f895b3fb9e30

容器镜像层

Docker镜像由只读层组成,每个层都代表一个Dockerfile指令,这些层是堆叠的,每一层都是前一层变化的增量。运行镜像并生成容器时,可以在基础镜像的顶部添加新的可写层(“容器层”)。对正在运行的容器所做的所有更改(例如写入新文件,修改现有文件和删除文件)都将写入此可写容器层。

这里写图片描述

01 了解Docker Build上下文(Context)

Docker build有一个重要参数context,默认是当前目录,采用.代替,但为了避免将不必要的文件打包到镜像,造成context及镜像大小过大,也可以用指定的目录作为context。context过大会造成docker build很耗时,镜像过大则会造成docker pull/push性能变差以及运行时容器体积过大浪费空间资源。

对于Docker17.05及以上版本,有一个remote context的特性,即可以将远程资源作为context,如下所示:

$ docker build -t nginx:v1 https://gitlab.com/fuhui/docker-lab.git
Sending build context to Docker daemon  50.18kB
Step 1/1 : FROM nginx:latest
 ---> f895b3fb9e30
Successfully built f895b3fb9e30
Successfully tagged nginx:v1

02 分阶段构建

构建镜像最大的挑战莫过于防止镜像过大,造成实际运行时由于并发而导致拉取性能问题。为了应对这个挑战,很多转型到容器的团队采用两个Dockerfile,一个负责开发环境的镜像构建,一个负责生产环境的镜像构建。开发镜像包含了代码构建所需要的环境,镜像大小自然比较大,生产镜像仅包含应用运行所需要的内容,是很精简的体积很小的镜像。

一个开发镜像Dockerfile示例如下:

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
COPY app.go .
RUN go get -d -v golang.org/x/net/html \
  && CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

一个生产镜像Dockerfile示例如下:

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY app .
CMD ["./app"] 

这时候整个过程分为三步:1.根据开发镜像启动一个容器来构建app 2. 构建结束后的app二进制拷贝到主机 3. 根据生产镜像启动一个容器,将主机上的app二进制copy到生产镜像中。如下脚本可自动化执行该过程。

#!/bin/sh
echo Building alexellis2/href-counter:build

docker build --build-arg https_proxy=$https_proxy --build-arg http_proxy=$http_proxy \  
    -t alexellis2/href-counter:build . -f Dockerfile.build

docker container create --name extract alexellis2/href-counter:build  
docker container cp extract:/go/src/github.com/alexellis/href-counter/app ./app  
docker container rm -f extract

echo Building alexellis2/href-counter:latest

docker build --no-cache -t alexellis2/href-counter:latest .
rm ./app

这么做会大量占用主机的空间资源,并且运行一段时间后,遗留很多二进制app文件在主机上,后期清理还需要额外的维护工作,显然不是一个很好的实践。

Docker分阶段构建就可以很好地解决这个问题,使用如下的Dockerfile即可:

FROM golang:1.7.3 as builder
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go    .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]  

整个Dockerfile流程很清晰,也不在需要额外的shell脚本来支持整个流程,并且我们可以指定执行的stage,具体命令如下:

$ docker build --target builder -t alexellis2/href-counter:latest .

03 使用构建缓存

构建映像时,Docker会逐步按指定的顺序执行Dockerfile中的每个指令。在检查每条指令时,Docker会在其缓存中查找可以重用的现有镜像,而不是重复创建新的镜像。

如果不想使用缓存,可以在docker build时加上--no-cache=true参数。然后,使用缓存会使得整个构建过程更高效,因此了解什么样的情形下可以利用缓存来提升效率很重要。具体来说有下面几个情形需要了解:

  • 从已经在缓存中的父镜像开始,将下一条指令与从该基本镜像导出的所有子镜像进行比较,以查看它们中的一个是否使用完全相同的指令构建。如果不是,则缓存无效。

  • 在大多数情况下,只需将Dockerfile中的指令与其中一个子镜像进行比较即可。但是,某些Dockerfile命令需要更深入的检查。对于ADD和COPY指令,将检查镜像中文件的内容,并为每个文件计算校验和。在这些校验和中不考虑文件的最后修改时间和最后访问时间。在缓存查找期间,将校验和与现有映像中的校验和进行比较。如果文件中有任何更改(例如内容和元数据),则缓存无效。

  • 除了ADD和COPY命令之外,缓存检查不会查看容器中的文件以确定缓存匹配。例如,在处理RUN apt-get -y update命令时,不检查容器中更新的文件以确定是否存在缓存命中。在这种情况下,只需使用命令字符串本身来查找匹配项。

04 给镜像设置标签(Label)

每一个对象都包含相应的元数据信息,比如Docker镜像就包含作者、大小等等元数据信息。在使用镜像的时候,往往会通过这些元数据信息来查找适合的镜像来用于开发或测试,而不单单只是通过名字去检索。

在Dockerfile中可以使用Label命令来为镜像增加Label,示例如下:

FROM nginx:latest
LABEL version=2.0

我们可以查看到Label及使用Label进行筛选:

$ docker build -t nginx:2.0 https://gitlab.com/fuhui/docker-lab.git
Sending build context to Docker daemon  50.18kB
Step 1/2 : FROM nginx:latest
 ---> f895b3fb9e30
Step 2/2 : LABEL version 2.0
 ---> Running in 721d056eec21
 ---> 5af7bc144cb6
Removing intermediate container 721d056eec21
Successfully built 5af7bc144cb6
Successfully tagged nginx:2.0
$ docker inspect 5af7bc144cb6
...
    "Labels": {
        "maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>",
        "version": "2.0"
    },
...
$ docker images --filter "label=version=2.0"
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               2.0                 5af7bc144cb6        3 minutes ago       108MB

05 CMD和ENTRYPOINT指令结合

官方关于CMD和ENTRYPOINT指令的说明如下

CMD
The main purpose of a CMD is to provide defaults for an executing container.
ENTRYPOINT
An ENTRYPOINT helps you to configure a container that you can run as an executable.

简而言之,就是CMD提供运行时的动态覆盖参数机制,而ENTRYPOINT只是容器启动时的执行入口。

假设有如下Dockerfile:

FROM debian
ENTRYPOINT ["/bin/ping"]
CMD ["localhost"]

当不指定任何参数时,情形如下:

$ docker run -it ping-test
PING localhost (127.0.0.1): 48 data bytes
56 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.096 ms
56 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.088 ms
56 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.088 ms

当指定一个ip地址,如192.168.137.4时,情况如下:

$ docker run -it ping-test 192.168.137.4
56 bytes from 192.168.137.4: icmp_seq=0 ttl=55 time=32.583 ms
56 bytes from 192.168.137.4: icmp_seq=2 ttl=55 time=30.327 ms
56 bytes from 192.168.137.4: icmp_seq=4 ttl=55 time=46.379 ms

这种机制意味着更好的可移植性,用户可在执行时动态注入变量,如当前环境类型、认证信息等等,便于服务的迁移、扩容等场景。

总结

Dockerfile 在实际基于docker的开发中使用非常普遍,很多开发者都掌握了基本的编写技巧,但对于一些优化的策略、方法掌握比较少,那么以上这些实践能够帮助大家节省时间、提升效率和性能,甚至提升应用的移植灵活性等。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页