在应用容器前考虑运维的挑战

容器使快速开发应用成为可能。Keith Townsend强调了在部署应用之前监控是运维的挑战

快速把概念从想法转为产品的愿望驱动了原生云（cloud-native）的开发工具的采用。容器的趋势就是一项允许快速开发的技术的例子。

使用如Docker这样的平台，在发布产品的时候，一个开发者在产品主机上和在他们的笔记本电脑上使用相同的Docker镜像。那么在管理产品应用的时候，容器和微服务的使用有什么影响呢？组织和公司可以使用相同的工具，还是需要利用新的途径？

微服务和容器
为了理解容器的影响，考虑微服务这个和容器伴生的概念是重要的。微服务是把应用开发分解为小的分布式的进程的方法。一个典型的微服务的例子是web服务器。随着对应用的需求的增加，一个应用可以产生一系列另外的Apache web服务器，每个都运行在各自的容器中。当对应用的需求减少，之前生成的微服务实例所消耗的资源可以被释放。

容器的生存期是短暂的。数据和系统设置只有在每个容器的运行生命期内才存在。容器的这个短暂的生命期的属性使他适合微服务架构。每当一个应用需要产生一个新的微服务的时候，应用向容器管理器发送服务请求。

一个应用或者应用系统可以产生几十乃至上千的容器，他们可能只持续几秒钟，也可能永远保持。

一个受到挑战的例子：监控
从技术角度来看，应用的监控传统上存在于服务端。服务端团队为监控一个操作系统实例提供一系列缺省的统计指标和告警。随着运维年份的增加，除了对操作系统的监控，监控团队也会为应用服务添加一些监控能力。然而这些监控目标是有状态的。产品的虚拟机通常是使用静态的配置项，传统的应用也不会产生只持续几秒钟的微型的虚拟机。

这类环境的静态属性使服务与虚拟机之间是一对一或多对一的映射。如果一个虚拟机罢工，那么服务就罢工。服务端团队就可以仅依靠虚拟机的状态来警告应用团队服务是否可用。微服务的架构打破了这种关系。容器和虚拟机采用不同的体检表。

DevOps（开发运维模式）来拯救

容器监控是一个对DevOps有现实需求的领域。然而DevOps是一个被用滥了的概念。在一些场景，DevOps指像Puppet和 Chef这样的工具。而在其他一些场景，它又是融合开发和基础设施运行的概念。

在一个完美的世界，应用监控应该是应用设计的一部分。虽然数据中心管理器可以继续上报一个容器的主机的整体健康状况，但开发和运维团队需要合力来实现应用层面的监控。

本文作者：Keith Townsend

原文链接：Consider this operational challenge before implementing containers

责编：魏伟，欢迎投稿，邮箱weiwei@csdn.net