Consul vs. Chef, Puppet, etc.
通常使用Chef，Puppet和其他配置管理工具来构建服务发现机制的情况并不少见。这通常通过在周期性收敛运行期间查询全局状态以在每个节点上构造配置文件来完成。
不幸的是，这种方法存在许多缺陷。配置信息是静态的，并且不能比收敛运行更频繁地更新。通常这是在几分钟或几小时的间隔。此外，没有机制将系统状态合并到配置中：不健康的节点可能会进一步加剧流量加剧问题。使用此方法还可以支持多个数据中心，因为中央服务器组必须管理所有数据中心。
Consul专门设计为服务发现工具。因此，它更加动态并且响应于群集的状态。节点可以注册和注销它们提供的服务，使相关的应用程序和服务能够快速发现所有提供者。通过使用集成的运行状况检查，Consul可以将流量路由远离不健康的节点，从而使系统和服务能够正常恢复。可以将配置管理工具提供的静态配置移动到动态密钥/值存储中。这允许在没有慢收敛运行的情况下更新应用程序配置。最后，由于每个数据中心都是独立运行的，因此支持多个数据中心与单个数据中心没有什么不同。
也就是说，Consul不是配置管理工具的替代品。这些工具对于设置应用程序仍然至关重要，包括Consul本身。静态配置最好由现有工具管理，而Consul可以更好地管理动态状态和发现。配置管理和集群管理的分离也有许多有利的副作用：没有全局状态，Chef配方和Puppet清单变得更简单，服务或配置更改不再需要定期运行，并且由于配置管理运行，基础结构可以变为不可变的，因为不需要全球状态。