目录:
1.dockerfile实战
2.dockerfile最佳实践
3.dockerfile的编写
4.dockerfile示例
5.dockerfile部署
6.docker使用dockerfile
7.dockerfile命令详解
8.dockerfile构建
9.docker执行dockerfile
10.dockerfile执行
1.dockerfile实战
字节三面远程,Java+Redis+网络+数据库+算法,轻松反杀面试官?2020年后想跳槽?MQ、ZK、Nginx、Kafk等分布式技术你都掌握了?2020“闭关”跳槽季,啃透分布式三大技术:限流、缓存、通讯
2.dockerfile最佳实践
疫情期间“闭关修炼”,吃透这本Java核心知识,跳槽面试不心慌虽然 Dockerfile 简化了镜像构建的过程,并且把这个过程可以进行版本控制,但是很多人构建镜像的时候,都有一种冲动——把可能用到的东西都打包到镜像中。
3.dockerfile的编写
这种不正当的 Dockerfile 使用也会导致很多问题:docker 镜像太大如果你经常使用镜像或者构建镜像,一定会遇到那种很大的镜像,甚至有些能达到 2G 以上docker 镜像的构建时间过长每个 build 都会耗费很长时间,对于需要经常构建镜像(比如单元测试)的地方这可能是个大问题。
4.dockerfile示例
重复劳动。多次镜像构建之间大部分内容都是完全一样而且重复的,但是每次都要做一遍,浪费时间和资源
5.dockerfile部署
希望读者能够对 docker 镜像有一定的了解,阅读这篇文章至少需要一下前提知识:了解 docker 的基础概念,运行过容器熟悉 docker 镜像的基础知识,知道镜像的分层结构最好是负责过某个 docker 镜像的构建(使用 docker build 命令创建过自己的镜像)
6.docker使用dockerfile
Dockerfile 和镜像构建Dockerfile 是由一个个指令组成的,每个指令都对应着最终镜像的一层每行的第一个单词就是命令,后面所有的字符串是这个命令的参数,关于 Dockerfile 支持的命令以及它们的用法,可以参考官方文档,这里不再赘述。
7.dockerfile命令详解
当运行 docker build 命令的时候,整个的构建过程是这样的:读取 Dockerfile 文件发送到 docker daemon读取当前目录的所有文件(context),发送到 docker daemon
8.dockerfile构建
对 Dockerfile 进行解析,处理成命令加上对应参数的结构按照顺序循环遍历所有的命令,对每个命令调用对应的处理函数进行处理每个命令(除了 FROM)都会在一个容器执行,执行的结果会生成一个新的镜像
9.docker执行dockerfile
为最后生成的镜像打上标签编写 Dockerfile 的一些最佳实践1. 使用统一的 base 镜像有些文章讲优化镜像会提倡使用尽量小的基础镜像,比如 busybox 或者 alpine 等我更推荐使用统一的大家比较熟悉的基础镜像,比如 ubuntu,centos 等,因为基础镜像只需要下载一次可以共享,并不会造成太多的存储空间浪费。
10.dockerfile执行
它的好处是这些镜像的生态比较完整,方便我们安装软件,除了问题进行调试2. 动静分离经常变化的内容和基本不会变化的内容要分开,把不怎么变化的内容放在下层,创建出来不同基础镜像供上层使用比如可以创建各种语言的基础镜像,python2.7、python3.4、go1.7、java7等等,这些镜像包含了最基本的语言库,每个组可以在上面继续构建应用级别的镜像。
3. 最小原则:只安装必需的东西很多人构建镜像的时候,都有一种冲动——把可能用到的东西都打包到镜像中要遏制这种想法,镜像中应该只包含必需的东西,任何可以有也可以没有的东西都不要放到里面因为镜像的扩展很容易,而且运行容器的时候也很方便地对其进行修改。
这样可以保证镜像尽可能小,构建的时候尽可能快,也保证未来的更快传输、更省网络资源4. 一个原则:每个镜像只有一个功能不要在容器里运行多个不同功能的进程,每个镜像中只安装一个应用的软件包和文件,需要交互的程序通过 pod(kubernetes 提供的特性) 或者容器之间的网络进行交流。
这样可以保证模块化,不同的应用可以分开维护和升级,也能减小单个镜像的大小5. 使用更少的层虽然看起来把不同的命令尽量分开来,写在多个命令中容易阅读和理解但是这样会导致出现太多的镜像层,而不好管理和分析镜像,而且镜像的层是有限的。
尽量把相关的内容放到同一个层,使用换行符进行分割,这样可以进一步减小镜像大小,并且方便查看镜像历史RUNapt-get update\ && apt-get install -y –no-install-recommends \ bzr \ cvs \ git \ mercurial \ subversion \ && apt get clean
6. 减少每层的内容尽管只安装必须的内容,在这个过程中也可能会产生额外的内容或者临时文件,我们要尽量让每层安装的东西保持最小比如使用 –no-install-recommends 参数告诉 apt-get 不要安装推荐的软件包。
安装完软件包,清楚 /var/lib/apt/list/ 缓存删除中间文件:比如下载的压缩包删除临时文件:如果命令产生了临时文件,也要及时删除7. 不要在 Dockerfile 中单独修改文件的权限因为 docker 镜像是分层的,任何修改都会新增一个层,修改文件或者目录权限也是如此。
如果有一个命令单独修改大文件或者目录的权限,会把这些文件复制一份,这样很容易导致镜像很大解决方案也很简单,要么在添加到 Dockerfile 之前就把文件的权限和用户设置好,要么在容器启动脚本(entrypoint)做这些修改,或者拷贝文件和修改权限放在一起做(这样最终也只是增加一层)。
8. 利用 cache 来加快构建速度如果 Docker 发现某个层已经存在了,它会直接使用已经存在的层,而不会重新运行一次如果你连续运行 docker build 多次,会发现第二次运行很快就结束了不过从 1.10 版本开始,Content Addressable Storage 的引入导致缓存功能的实效,目前引入了 –cache-from 参数可以手动指定一个镜像来使用它的缓存。
9. 版本控制和自动构建最好把 Dockerfile 和对应的应用代码一起放到版本控制中,然后能够自动构建镜像这样的好处是可以追踪各个版本镜像的内容,方便了解不同镜像有什么区别,对于调试和回滚都有好处另外,如果运行镜像的参数或者环境变量很多,也要有对应的文档给予说明,并且文档要随着 Dockerfile 变化而更新,这样任何人都能参考着文档很容易地使用镜像,而不是下载了镜像不知道怎么用。
作者:kevinyan原文链接:https://juejin.im/post/5e574bf8f265da575209418d
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需!
7. 如遇到加密压缩包,请使用WINRAR解压,如遇到无法解压的请联系管理员!
8. 精力有限,不少源码未能详细测试(解密),不能分辨部分源码是病毒还是误报,所以没有进行任何修改,大家使用前请进行甄别
丞旭猿论坛
暂无评论内容