容器镜像是一个分发的形式，我们可以把容器镜像分发给别人，或者是让别人继承我们的镜像。同时Docker又提供了Dockerfile。Dockerfile允许我们通过一个文件的形式去描述镜像。一旦能够定义镜像就可以协作了。有了这样的能力以后，容器就很快被大家所接受了。所以容器的接受看起来好像是技术发展的过程，其实是随着云原生、云市场的发展必然带来的结果。
我们很多人认为的“集装箱”就是容器，这个容器很多时候我们都认为是docker容器。在K8s里面支持很多个容器运行，大部分的情况都是用docker容器。docker容器的优势就是刚才说的两点：镜像和Dockerfile。这两点使得docker镜像可以像集装箱一样做分发。
此外，容器还提供了很好的资源隔离，可以在比较小的粒度上进行隔离。虚拟机虽然也做了隔离，但是它的粒度比较大。不仅如此，容器还提供了非常弹性的资源管理方式，这点比虚拟机和物理机都有非常大的改善。本质上它就是物理机上的一个进程，这是它和虚拟机的本质的差别。
了解了软件集装箱是什么后，然后我们再来了解下容器镜像的组成。
如何保证软件制品的一致性
要保证软件制品的一致性，软件制品应该有确定的格式、唯一的版本、能够追溯到源码、能够追溯到生产和消费过程，这样才能使持续交付更好地服务于企业的制品管理与开发。
-
相同的代码
-
相同的构建环境
-
相同的构建脚本
相同的代码
例如程序员开发时，不在依赖描述文件（如go.mod,package-lock.json,pom.xml,requirements.txt等）中指定依赖的版本，则会默认使用最新的版本作为依赖，这样产出的制品会随着依赖的更新而不能保持一致，这将带来完全不在预期内的风险。
对应的，使用相同的，与代码实现无关的构建脚本也是非常重要的，在Dockerfile的环境中必须指定确定的环境依赖版本。
只有在同一份代码（及同一个依赖）、同样构建环境的描述、和同样构建脚本的环境下，所产生的软件制品才是相同的。这里强调的是说所有的东西都要保证一致性，如果说三者是一样的话，那产生出来的制品也是一样的，即使构建时间不同，产出的制品也是相同的。
那我们如何提升构建的效率呢面是我们的一些实践建议：
1个基本原则： 保证构建的准确性，构建的准确性永远优于构建的效率。只有在保证准确性的前提下提升效率才有意义。
5点建议：
-
应用瘦身：检查应用的依赖情况，应用包体积是否过大，依赖项是否过多，能否去除不必要的依赖，能否构建更小的镜像。
-
分层构建：底层的东西先构建出来以后被上层所复用，然后就可以做增量式的了。
-
构建缓存：构建过程中拉取依赖是很耗时的，要避免重复拉取。
-
络优化：主要是保证代码、构建机器和制品库之间的低 络延时。代码和构建机器是否是在同一个低时延链路中。例如代码在Github上而使用云效构建，此时的延时相对于内 会高出许多。
-
仓库镜像：仓库镜像可以极大地减少拉取依赖项的时间。在国内的 络环境下，如果从源仓库获取依赖，可能延时会非常长，这时可以使用镜像 络降低延时。例如nodejs开发者常使用淘宝的npm镜像源，而Python开发者使用清华的镜像源。对于企业来说也可以构建自己的镜像仓库以提升可靠性与降低延时。云效也使用了镜像仓库，来减少拉取的时间。
（小编推荐：云效流水线Flow 是一款云原生时代的流水线工具，通过容器技术让企业摆脱对虚拟机构建环境的依赖。您甚至可以根据您的使用需求，在同一条流水线上使用不同的构建环境。此外，云效流水线Flow 还提供了各种语言的容器环境，满足不同的构建使用场景。点击文末阅读原文，了解详情）
总结
本篇文章，我们从软件交付的终态出发，提出了不可变构建的概念。希望通过:相同的源码+相同的环境+相同的构建脚本=>带来一致的软件制品。而这些东西都是保存在源代码里的，所以源代码的管理非常重要。
下篇文章，我们将分享如何对源代码进行有效管理。
阅读上篇：做到这4点，才是真正的持续交付
点击下方链接立即体验云效持续交付流水线Flow。
https://www.aliyun.com/product/yunxiao/flowhannel=yy_rccb_36
关于我们
ps：本课程将从研发效能的定义和度量着手，逐渐深入解析来自不同业务部门提升持续交付能力的实践、方法和工具，同时还将分享如何基于持续交付能力，切实提升产品和业务创新的效率和效果。
看完觉得对您有所帮助别忘记点赞、收藏和关注呦；
文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树容器编排(生产环境 k8s)kubelet,kubectl,kubeadm三件套8693 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！