配置管理在容器化世界中的角色

Docker 已经作为基础自动化工具被广泛使用，越来越多的开发者开始争论 Docker 是否将最终替代配置管理工具这一问题。随着多数配置管理工具为 Docker提供支持，以上争论的结论似乎是二者将在使用中共存，而不是其中一个代替另一个。

配置管理工具需要确保一组服务器全部成员的初始状态与其所发生的结构变化都是一致的。配置管理所解决的问题还包括结构变化，即运行中的服务器结构变得与初始状态不一致。但前提条件是，每一项变化都必须通过配置管理工具实现。现代应用拥有成百上千的服务器，配置管理工具使得批量管理变得更便捷。

然而，在最近几年，开发者的工作变得更加灵活，应用结构中也引入了 API 主导的服务导向架构。服务配置从整体到局部转化、及时发现实时的服务需求、规模变化速度加快等特性，使得开发者开始面对一个新问题，即配置管理的边界问题。

容器技术使得根据配置需求建立稳定服务器的过程更加快捷，同时使得每次更改中放弃旧版本、重建一个新版本的过程更加方便。对比配置管理，容器看上去更贴近工作实际需求

——只需要将镜像与需求中的依赖关系相结合，输出服务节点。Netflix 早在其Amazon EC2 系统的AMI 中就应用了这个模型，其中， AMI 系统（Amazon 机器镜像）是一个可以启动服务器的镜像，通常被称作“金色镜像”。

容器技术使得子服务的体系架构工作更为便捷。任何服务导向的应用架构都将包含内部的服务依赖关系——多服务的复杂依赖关系。在这些服务的业务流程的设计中，拓扑结构与依赖关系同样重要。Docker 就能够很方便地对这种服务进行建模。 Ernest Mueller ，DevOps 运动的长期成员、敏捷管理博客的合著者，说：

在服务依赖关系建立完成后，随之出现的是对子服务进行调整的需求。一些工具，如 Etcd 和 Docker ，是通过将子服务紧密整合在容器环境中，来实现对其动态性的调整。在这些工具中，你可以定义一个多服务的环境，进而注册并通过编程来控制那些正在运行中的服务。

这是与纯配置管理相比较而言的，他还补充道：

你只需要改变软件程序，其余大部分工作就可以通过推动完成了，不需要直接建模。

那么金色镜像是否是一种“万金油”？容器是否将最终代替配置管理？

Ben Schwartz ，BancVue 的设计师、博客主，并没有认为这是个值得争辩的问题。他认为配置管理与容器所解决的根本问题是不同的。

对“容器与配置管理”的不休争论本质上就是错误的。我们从没有试图只通过使用一种技术就能解决全部的问题（你不会为了使用 Puppet 而放弃全部的 Java 库，也不会将负载平衡器设置在 Maven Central 中）。那么为什么我们要讨论容器与配置管理的问题呢？我建议我们应该集中精力去做我们经常做的事：选择正确的工具去做正确的事。

配置管理的目的是部署和变化管理。容器是虚拟机的轻量版，相比虚拟机，容器能更容易地连接现代应用中松散的子服务结构。这是容器的一个很明确的优势，但那并不意味着配置管理在这样的架构中没有价值。

配置管理能够用于集成环境下的很多工作：

• 基础镜像创建和配置，比如 Chef 与 Docker ， Ansible 与 Docker ；
• 管理运行中的容器配置

Diego Zamboni 在 2014 年 UNIX 用户协会配置管理峰会的发言中总结了二者的共存性：

在容器的时代，配置管理未来将是在那些小碎片中进行配置管理。

这里的“小碎片”指的是在容器化的系统中所构建的模块——应用、容器镜像与容器本身。他也提出警示，我们应该跳出“不变的基础服务”这个思维定式。他希望容器中配置管理系统的属性列表包括轻量化、分布式和弹性化，并牢记容器生命的短暂性。

查看英文原文： The Role of Configuration Management in a Containerized World

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。