Consul vs. Chef, Puppet, etc.

通常使用Chef，Puppet和其他配置管理工具來構建服務發現機制的情況並不少見。這通常通過在週期性收斂執行期間查詢全域性狀態以在每個節點上構造配置檔案來完成。

不幸的是，這種方法存在許多缺陷。配置資訊是靜態的，並且不能比收斂執行更頻繁地更新。通常這是在幾分鐘或幾小時的間隔。此外，沒有機制將系統狀態合併到配置中：不健康的節點可能會進一步加劇流量加劇問題。使用此方法還可以支援多個數據中心，因為中央伺服器組必須管理所有資料中心。

Consul專門設計為服務發現工具。因此，它更加動態並且響應於群集的狀態。節點可以註冊和登出它們提供的服務，使相關的應用程式和服務能夠快速發現所有提供者。通過使用整合的執行狀況檢查，Consul可以將流量路由遠離不健康的節點，從而使系統和服務能夠正常恢復。可以將配置管理工具提供的靜態配置移動到動態金鑰/值儲存中。這允許在沒有慢收斂執行的情況下更新應用程式配置。最後，由於每個資料中心都是獨立執行的，因此支援多個數據中心與單個數據中心沒有什麼不同。

也就是說，Consul不是配置管理工具的替代品。這些工具對於設定應用程式仍然至關重要，包括Consul本身。靜態配置最好由現有工具管理，而Consul可以更好地管理動態狀態和發現。配置管理和叢集管理的分離也有許多有利的副作用：沒有全域性狀態，Chef配方和Puppet清單變得更簡單，服務或配置更改不再需要定期執行，並且由於配置管理執行，基礎結構可以變為不可變的，因為不需要全球狀態。