设为首页 收藏本站
查看: 940|回复: 0

[经验分享] Docker镜像构建的优化总结

[复制链接]

尚未签到

发表于 2019-2-21 10:41:42 | 显示全部楼层 |阅读模式
Docker镜像构建的优化总结

随着我们对docker镜像的持续使用,在此过程中如果不加以注意并且优化,镜像的体积会越来越多。很多时候我们在使用docker部署应用时,会发现镜像的体积至少有1G以上。镜像体积的增大,不单单会增加磁盘资源与网络资源的开销,也会影响应用的部署效率,使得应用的部署时间会越来越长。因此我们需要减少部署镜像的体积以加快部署效率,降低资源的开销。而对于镜像的优化,可以通过对dockerfile的优化来实现。
一、镜像最小化

1、选择最精简的基础镜像

选择体积最小的基础镜像可有效降低镜像体积。如:alpine、busybox等
2、清理镜像构建的中间产物。

构建镜像的过程中,当dockerfile的指令执行完成后,删除镜像不需要用的的文件。如使用yum安装组件,最后可使用yum clean all镜像清理不需要的文件或者使用系统rm命令删除不需要的源文件等。
3、减少镜像的层数

镜像是一个分层存储的文件,并且镜像对层数也是有一定数量的限制,当前镜像的层数最高是127层,如果不多加注意,将会导致镜像越来越臃肿。在使用dockerfile构建镜像时,dockerfile中的每一条指令都会生成一个层,因此可以通过合并dockerfile中可合并的指令,减少最终生成镜像的层数。例如:在dockerfile中使用RUN执行shell命令是,可以用"&&"将多条命令连接起来。
二、构建速度最快化

1、充分利用镜像构建缓存

我们可以利用构建的缓存来加快镜像构建速度,Docker构建默认会开启缓存,缓存生效有三个关键点,镜像父层没有发生变化,构建指令不变,添加文件校验和一致。只要一个构建指令满足这三个条件,这一层镜像构建就不会再执行,它会直接利用之前构建的结果。某一层的镜像缓存失效之后,它之后的镜像层缓存都会失效。我们应该把变化最少的部分放在Dockerfile的前面,这样可以充分利用镜像缓存。dockerfile中有可能导致缓存失效的命令WORKDIR、CMD、ENV、ADD等,像这些命令最好放到dockerfile底部,以便在构建镜像过程中最大限度使用缓存。
2、删除构建目录中(默认:Dockerfile所在目录)不需要用的的文件。

编写.dockerignore文件过滤构建过程中不必要的文件或者创建单独的目录,并且目录中仅存在镜像构建过程中需要使用的文件。
Docker 在运行时分为 Docker 引擎(也就是服务端守护进程)和客户端工具。Docker 的引擎提供了一组 REST API,被称为 Docker Remote API,而如 docker 命令这样的客户端工具,则是通过这组 API 与 Docker 引擎交互,从而完成各种功能。因此,虽然表面上我们好像是在本机执行各种 docker 功能,但实际上,一切都是使用的远程调用形式在服务端(Docker 引擎)完成。docker build 命令构建镜像,其实并非在本地构建,而是在服务端,也就是 Docker 引擎中构建的。
构建镜像时,Docker需要先准备context ,将所有需要的文件收集到进程中。默认的context包含Dockerfile目录中的所有文件。如果目录中的存在大量不相关的文件,不仅会导致构建缓慢,而且还会导致镜像体积增大。
.dockerignore示例如下:
在一个git项目中,我们并不需要.git目录等内容。可以在.dockerignore文件中加入以下内容:
.git/
.dockerignore 的作用和语法类似于 .gitignore,可以忽略一些不需要的文件,这样可以有效加快镜像构建时间,同时减少Docker镜像的大小。
3、注意优化网络请求

我们使用一些镜像源或者在dockerfile中使用互联网上的url时,去用一些网络比较好的开源站点,这样可以节约时间、减少失败率
三、dockerfile指令优化

1、COPY指令和ADD指令的区别

COPY 复制文件
格式:
COPY ...
COPY ["",... ""]
COPY 指令将从构建上下文目录中  的文件/目录复制到新的一层的镜像内的  位置。比如:
COPY package.json /usr/src/app/
可以是多个,甚至可以是通配符,其通配符规则要满足 Go 的 filepath.Match 规则,如:
COPY hom* /mydir/
COPY hom?.txt /mydir/
可以是容器内的绝对路径,也可以是相对于工作目录的相对路径(工作目录可以用 WORKDIR 指令来指定)。目标路径不需要事先创建,如果目录不存在会在复制文件前先行创建缺失目录。
此外,还需要注意一点,使用 COPY 指令,源文件的各种元数据都会保留。比如读、写、执行权限、文件变更时间等。这个特性对于镜像定制很有用。特别是构建相关文件都在使用 Git 进行管理的时候。
ADD 更高级的复制文件
ADD 指令和 COPY 的格式和性质基本一致。但是在 COPY 基础上增加了一些功能。
比如  可以是一个 URL,这种情况下,Docker 引擎会试图去下载这个链接的文件放到  去。下载后的文件权限自动设置为 600,如果这并不是想要的权限,那么还需要增加额外的一层 RUN进行权限调整,另外,如果下载的是个压缩包,需要解压缩,也一样还需要额外的一层 RUN 指令进行解压缩。所以不如直接使用 RUN 指令,然后使用 wget 或者 curl 工具下载,处理权限、解压缩、然后清理无用文件更合理。因此,这个功能其实并不实用,而且不推荐使用。
如果  为一个 tar 压缩文件的话,压缩格式为 gzip, bzip2 以及 xz 的情况下,ADD 指令将会自动解压缩这个压缩文件到  去。
在某些情况下,这个自动解压缩的功能非常有用,比如官方镜像 ubuntu 中:
FROM scratch
ADD ubuntu-xenial-core-cloudimg-amd64-root.tar.gz /
...
但在某些情况下,如果我们真的是希望复制个压缩文件进去,而不解压缩,这时就不可以使用 ADD 命令了。
在 Docker 官方的最佳实践文档中要求,尽可能的使用 COPY,因为 COPY 的语义很明确,就是复制文件而已,而 ADD 则包含了更复杂的功能,其行为也不一定很清晰。最适合使用 ADD 的场合,就是所提及的需要自动解压缩的场合。
另外需要注意的是,ADD 指令会令镜像构建缓存失效,从而可能会令镜像构建变得比较缓慢。
因此在 COPY 和 ADD 指令中选择的时候,可以遵循这样的原则,所有的文件复制均使用 COPY 指令,仅在需要自动解压缩的场合使用 ADD。
2、CMD 与 ENTRYPOINT的区别

CMD
CMD 指令设置镜像中的默认启动命令和参数. 容器启动之后, 如果没有加入任何启动命令(也就是在镜像参数之后没有添加任何内容) 则默认执行镜像中 CMD 设置的默认的启动命令
设置启动命令时, 应该尽量使用 JSON 格式 CMD ["command", "arg1", "arg2"]
例如 nginx 的启动方式: CMD ["nginx", "-D"]
如果开发者和使用者都不是很熟悉 CMD 和 ENTRYPOINT 的工作原理的情况下, 尽量避免这两个指令配合使用
例如 Django 的启动方式: CMD ["python", "manage.py", "runserver", "0.0.0.0:8989"]
相反, 如果开发者和使用者都很熟悉 CMD 和 ENTRYPOINT 的工作原理, 推荐 CMD 作为 ENTRYPOINT 的参数来配套使用
ENTRYPOINT
当需要把容器当做一个命令行工具使用时, 推荐通过 ENTRYPOINT 指令设置镜像的入口程序
当启动主程序之前还需要执行大量的前置操作时, 可以将 ENTRYPOINT 的入口指令设置为一个脚本 start.sh
当 dockerfile 中指定了 ENTRYPOINT 的时候, docker run 如果在镜像之后添加的指令, 那么这些指令将被当做 ENTRYPOINT 的参数执行
如果 dockerfile 中同时有 CMD 和 ENTRYPOINT 指令, 当 CMD 指令可执行时, 它将在 ENTRYPOINT 之前运行; 如果 CMD 不是可执行的命令, 则将作为 ENTRYPOINT 的命令参数追加
3、WORKDIR

尽量使用绝对路径
切换目录的时候尽量使用 WORKDIR, 而不是使用 RUN cd /data
4、USER

如果容器中的应用程序运行时不需要特殊的权限, 可以通过 USER 指令把应用程序的所有者设置为非 root 用户. 如果该用户不存在, 首先需要使用 RUN 命令在镜像中创建用户.
如果在每次编译镜像时, 对用户的 UID/GID 有要求需要保持一致, 应该在新建用户和组的时候指定 UID和 GID
在镜像中避免使用sudo 命令. 应为该命令使用的 TTY 不确定, 对接收信号量也会造成影响. 如果确实需要使用 sudo 功能, 则可是使用 gosu 命令替代
可以用 root 用户初始化一个 daemon, 然后用非 root 用户启动这个 daemon
为了减少镜像体积, 应该避免不必要的用户切换
5、EXPOSE

EXPOSE 用来声明未来容器内需要监听的端口, 在 bridge 模式下, 这些容器内部的端口会映射到宿主机的端口上, 建议在容器内部不要更改应用原生的端口号
EXPOSE 中只能指定未来容器内部需要暴露的端口, 不能指定未来容器外部与内部端口之间的映射关系, 比如设置 EXPOSE 80:80 是没有任何意义的



运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-675241-1-1.html 上篇帖子: Mesos+Marathon+zk+docker构建PaaS平台 下篇帖子: 50+ 实用的 Docker 工具推荐
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表