为什么说容器和DevOps不分彼此？

容器和到底什么关系?如果你没办法理解，可以把他们想象成是“一对好伙伴”，浑然天成，不分彼此。

容器应用之所以发展为一种生态，和快速增长的实践，密不可分。当容器和开始齐头并进，当越来越多的容器应用开始投入生产环境，我们也越来越深刻地理解什么是，实现有哪些方式和方法。

容器，更像是“管道式”应用，能直接将一个应用程序所需的相关程序代码、函式库、环境配置文件都打包起来，建立沙盒执行环境。从内部结构来看，隔离性强、可移植性高、资源占用少，操作者可以不用考虑主机节点、集群和底层基础设施等问题。但是从外部应用来看，容器中的程序又是整体生态系统中最重要的部分，包括：web API、用户界面、数据库、工作流、缓存和垃圾收集器等。技术团队要给容器设置规则，限制容器对基础设施的性能影响。另外，还要评估容器自身的性能。因为，超负荷工作负载，可能会给业务部门带来负面影响。

理念给容器开发上了深深的一课。对于开发人员来说，无论是代码发布，还是基础架构构建，每一个过程都要遵循从概念到实现的线性路径。从开发到测试、再到上线发布，理论上没什么问题，但是如果某一个团队因为某项工作陷入瓶颈，那么整个环节都会受到影响。

有两个重要方法：

第一，先解决流程问题。通过技术手段实现协同工作，实现持续的过程管理;通过过程管理的可预见性，不断发现和调整问题点，进而提高工作效率。

第二，坚持反馈原则。反馈，就是快速获取相关信息。有了即时的、有用的反馈，很多问题就可以在未发生时被识别出来，在整个开发过程未受影响之前解决掉。团队不仅注重“上游管理”，而且更专注于“优化下游”，重点着手解决可能影响后续团队的问题点。与流程管理一样，反馈也是一个持续过程，找到快速获取重要数据的方法，并在问题出现时及时采取行动。在技术开发流程中，能否创建快速的反馈机制，决定了后期质量实现，及时反馈和产品可靠性、安全性等，一样重要。

容器应用也一样，也要建立反馈价值。除了防止容器自身出现问题，还要通过很多监控产品建立监督机制，实时了解容器动态。比如：，就是最流行的一个监控告警工具，它能主动收集数据指标，并检查是否触发告警规则。

容器为服务器上运行的每个应用程序提供了独自、隔离的环境来运行，使得你可以在一瞬间为虚拟机建立容器，而不用依赖于操作系统。但是，这种便捷有时是以信息不透明为代价，所以必须建立快速反馈机制，以便快速解决问题。