1.2.2 Chef,Puppet,etc

对于使用Chef、Puppet或其它配置管理工具的人来说，构建服务发现机制是很常见的。这通常通过在一个周期收敛运行的阶段内，查询全局状态来构建每个节点上的配置文件来实现。

但是这种方式是有一些缺陷的。配置信息是静态的，无法比运行更频繁的更新。通常来讲，这是分钟或小时量级的间隔。此外，在配置过程中也没有将系统状态纳入的逻辑：异常的节点可能或接收到流量从而加剧问题。而且使用这种方法也使得对多数据中心的支持成为挑战，因为需要一组核心的机器来管理所有的数据中心。

Consul是专门设计来作为服务发现工具的。它本身对于集群的状态更动态化、响应更快。节点可以注册或下线它们提供的服务，使得独立的应用可以快速的发现所有服务提供者。通过使用内部集成的错误检测，Consul可以避免将流量导向失效节点，从而使得系统和服务可以优雅的恢复。可能通过配置管理工具提供的静态配置可以转移到动态的K/V存储中。这使得应用的配置无需周期运行即可更新。最后，因为每个数据中心都是独立运行的，支持多个数据中心与支持一个数据中心差异不大。

即便如此，Consul也无法取代配置管理工具。这些工具对于启动应用包括Consul自己，仍然是很重要的。静态的编排最好由已有的根据管理，而动态的状态和发现最好由Consul接管。而对于配置管理和几圈管理的分离同时带来了一些的好的“副作用”：因为没有了全局状态，Chef的recipe和Puppet的manifest变得更简单；服务和配置的修改无需再进行周期性的运行；而基础设施变得不可改变，因为配置管理不再需要全局状态。