Docker镜像瘦身与优化

栏目: Ruby · 发布时间: 5年前

内容简介:【编者的话】为什么在存储如此便宜的今天我们仍然需要对Docker镜像进行瘦身?加速构建/部署。虽然存储资源较为廉价,但是网络IO是有限的,在带宽有限的情况下,部署一个1G的镜像和10M的镜像带来的时间差距可能就是分钟级和秒级的差距。特别是在出现故障,服务被调度到其他节点时,这个时间尤为宝贵。提高安全性,减少攻击面积。越小的镜像表示无用的程序越少,可以大大的减少被攻击的目标。

【编者的话】为什么在存储如此便宜的今天我们仍然需要对 Docker 镜像进行瘦身?

小镜像的优点

加速构建/部署。虽然存储资源较为廉价,但是网络IO是有限的,在带宽有限的情况下,部署一个1G的镜像和10M的镜像带来的时间差距可能就是分钟级和秒级的差距。特别是在出现故障,服务被调度到其他节点时,这个时间尤为宝贵。

提高安全性,减少攻击面积。越小的镜像表示无用的程序越少,可以大大的减少被攻击的目标。

减少存储开销。

小镜像的制作原则

选用最小的基础镜像

减少层,去除非必要的文件

在实际制作镜像的过程中,一味的合并层不可取,需要学会充分的利用Docker的缓存机制,提取公共层,加速构建。

  • 依赖文件和实际的代码文件单独分层
  • 团队/公司采用公共的基础镜像等

使用多阶段构建

往往我们在构建阶段和实际运行阶段需要的依赖环境是不同的,例如Golang编写的程序实际运行的时候仅仅需要一个二进制文件即可,对于Node来说,可能最后运行的只是一些打包之后的js文件而不需要包含node_modules里成千上万的依赖。

基础镜像

Distroless, https://github.com/GoogleCloudPlatform/distroless

“Distroless” images contain only your application and its runtime dependencies. They do not contain package managers, shells or any other programs you would expect to find in a standard Linux distribution.

Distroless是Google推出的一个仅仅包含运行时环境,不包含包管理器,shell等其他程序。如果你的程序没有其他依赖的话,这是一个不错的选择。

Alpine, https://hub.docker.com/_/alpine

Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.

Alpine 是一个基于MUSL,Busybox的安全的 Linux 发行版。麻雀虽小五脏俱全,虽然不到10M, 但是包含了一个包管理器和 shell 环境,这在我们实际的使用调试当中将非常有用。

但是请注意,由于Alpine使用了更小的muslc替代glibc,会导致某些应用无法使用,需要重新编译

Scratch, https://hub.docker.com/_/scratch

Scratch是空白镜像,一般用于基础镜像构建,例如Alpine镜像的Dockerfile便是从Scratch开始的:

FROM scratch

ADD alpine-minirootfs-20190228-x86_64.tar.gz /

CMD ["/bin/sh"]

Busybox, https://hub.docker.com/_/busybox

一般而言,Distroless相对会更加的安全,但是在实际使用的过程中可能会遇到添加依赖以及调试方面的问题,alpine更小,自带包管理器,更加贴合使用习惯,但是muslc可能会带来兼容性的问题,一般而言我会选择alpine作为基础镜像使用。

除此之外,在Docker Hub当中我们可以发现常用的Debian的镜像也会提供的只包含基础功能的小镜像。

基础镜像对比

此处直接拉取基础镜像,查看镜像大小, 通过观察我们可以发现,alpine只有5M左右为debian的20分之一:

alpine      latest    5cb3aa00f899        3 weeks ago         5.53MB

debian      latest    0af60a5c6dd0        3 weeks ago         101MB

ubuntu      18.04     47b19964fb50        7 weeks ago         88.1MB

ubuntu      latest    47b19964fb50        7 weeks ago         88.1MB

alpine      3.8       3f53bb00af94        3 months ago        4.41MB

似乎从上面看,感觉差距不大,实践中,不同语言的基础镜像都会提供一些采用不同基础镜像制作的tag,下面我们以 Ruby 的镜像为例,查看不同基础镜像的差异。可以看到默认的latest镜像881MB而alpine仅仅只有不到50MB这个差距就十分的可观了:

ruby   latest   a5d26127d8d0        4 weeks ago         881MB

ruby   alpine   8d8f7d19d1fa        4 weeks ago         47.8MB

ruby   slim     58dd4d3c99da        4 weeks ago         125MB

减少层,去除非必要的文件

删除文件不要跨行

# dockerfile 1

FROM alpine



RUN wget https://github.com/mohuishou/scuplus-wechat/archive/1.0.0.zip &&  rm 1.0.0.zip



# dockerfile 2

FROM alpine



RUN wget https://github.com/mohuishou/scuplus-wechat/archive/1.0.0.zip

RUN rm 1.0.0.zip



# dockerfile 3

FROM alpine



RUN wget https://github.com/mohuishou/scuplus-wechat/archive/1.0.0.zip &&  rm 1.0.0.zip
test   3  351a80e99c22        5 seconds ago        5.53MB

test   2  ad27e625b8e5        49 seconds ago       6.1MB

test   1  165e2e0df1d3        About a minute ago   6.1MB

可以发现1,2两个大小一样,但是3小了0.5MB,这是因为Docker几乎每一行命令都会生成一个层,删除文件的时候:因为底下各层都是只读的,当需要删除这些层中的文件时,AUFS 使用whiteout机制,它的实现是通过在上层的可写的目录下建立对应的whiteout隐藏文件来实现的,所以在当前层去删除上一层的文件,只是会把这个文件隐藏掉罢了。

使用单行命令

除了删除语句需要放在一行以外,由于层的机制,我们安装依赖的一些公共的语句最好也使用条RUN命令生成,减少最终的层数。

分离依赖包,以及源代码程序,充分利用层的缓存

这是一个最佳实践,在实际的开发过程中,我们的依赖包往往是变动不大的,但是我们正在开发的源码的变动是较为频繁,如果我们实际的代码只有10M,但是依赖项有1G,如果在COPY的时候直接 COPY . . ,会导致每次修改代码都会使这一层的缓存失效,导致浪费复制以及推送到镜像仓库的时间,将COPY语句分开,每次push就可以只变更我们频繁修改的代码层,而不是连着依赖一起。

使用.dockerignore

在使用Git时,我们可以通过.gitignore忽略文件,在docker build的时候也可以使用.dockerignore在Docker上下文中忽略文件,这样不仅可以减少一些非必要文件的导入,也可以提高安全性,避免将一些配置文件打包到镜像中。

多阶段构建

多阶段构建其实也是减少层的一种,通过多阶段构建,最终镜像可以仅包含最后生成的可执行文件,和必须的运行时依赖,大大减少镜像体积。

Go 语言为例,实际运行的过程中只需要最后编译生成的二进制文件即可,而Go语言本省以及扩展包,代码文件都是不必要的,但是我们在编译的时候这些依赖又是必须的,这时候就可以使用多阶段构建的方式,减少最终生成的镜像体积。

# 使用golang镜像作为builder镜像

FROM golang:1.12 as builder



WORKDIR /go/src/github.com/go/helloworld/



COPY app.go .



RUN go build -o app .



# 编译完成之后使用alpine镜像作为最终的基础镜像

FROM alpine:latest as prod



RUN apk --no-cache add ca-certificates



WORKDIR /root/



# 从builder中复制编译好的二进制文件

COPY --from=builder /go/src/github.com/go/helloworld/app .



CMD ["./app"]

由于本文篇幅较长,这里不对多阶段构建展开讲解,详情可以参考 多阶段构建

奇淫技巧

使用 dive 查看Docker镜像的层,可以帮助你分析减少镜像体积。

使用 docker-slim 可以自动帮助你减少镜像体积,对于Web应用较为有用。

安装软件时去除依赖:

# ubuntu

apt-get install -y — no-install-recommends



#alpine

apk add --no-cache &&  apk del build-dependencies



# centos

yum install -y ... && yum clean all

使用 --flatten 参数,减少层(不推荐)。

使用 docker-squash 压缩层。

不同语言的示例

Ruby(Rails)

只安装生产所需的依赖。

删除不需要的依赖文件:

bundle install --without development:test:assets -j4 --retry 3 --path=vendor/bundle \

   # Remove unneeded files (cached *.gem, *.o, *.c)

   && rm -rf vendor/bundle/ruby/2.5.0/cache/*.gem \

   && find vendor/bundle/ruby/2.5.0/gems/ -name "*.c" -delete \

   && find vendor/bundle/ruby/2.5.0/gems/ -name "*.o" -delete

删除前端的node_modules以及缓存文件:

rm -rf node_modules tmp/cache app/assets vendor/assets spec

上述内容可以结合多阶段构建实现。

Golang

Golang在使用多阶段构建之后,只剩下了一个二进制文件,这时候再要优化,就只有使用npx之类的 工具 压缩二进制文件的体积了。

参考资料

原文链接: docker镜像瘦身&优化


以上所述就是小编给大家介绍的《Docker镜像瘦身与优化》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

敏捷估计与规划

敏捷估计与规划

[美] Mike Cohn / 宋锐 / 清华大学出版社 / 2007-7 / 39.90元

《敏捷估计与规划》一书为对敏捷项目进行估计与规划提供了权威实际的指导方针。在本书中,敏捷联盟的共同创始人Mike Cohn讨论了敏捷估计与规划的思想,并使用现实的例子与案例分析向您详细地展示了如何完成工作。本书清晰地阐述了有关的概念,并引导读者逐步认识到下列一些问题的答案:我们要构建什么?它的规模有多大?需要在什么时候完成?到那个时候我们到底能完成多少?您首先会认识到优秀的计划由哪些东西组成,接着......一起来看看 《敏捷估计与规划》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

SHA 加密
SHA 加密

SHA 加密工具