consul/website/pages/intro/vs/chef-puppet.mdx

48 lines
2.6 KiB
Plaintext
Raw Normal View History

2014-02-08 00:41:03 +00:00
---
2020-04-07 18:55:19 +00:00
layout: intro
2020-04-06 20:27:35 +00:00
page_title: 'Consul vs. Chef, Puppet, etc.'
2020-04-07 18:55:19 +00:00
sidebar_title: 'Chef, Puppet, etc.'
sidebar_current: vs-other-chef
description: >-
It is not uncommon to find people using Chef, Puppet, and other configuration
management tools to build service discovery mechanisms. This is usually done
by querying global state to construct configuration files on each node during
a periodic convergence run.
2014-02-08 00:41:03 +00:00
---
2014-04-10 20:51:08 +00:00
# Consul vs. Chef, Puppet, etc.
2014-02-08 00:41:03 +00:00
2014-04-10 20:51:08 +00:00
It is not uncommon to find people using Chef, Puppet, and other configuration
management tools to build service discovery mechanisms. This is usually
done by querying global state to construct configuration files on each
2014-04-14 18:53:29 +00:00
node during a periodic convergence run.
Unfortunately, this approach has
a number of pitfalls. The configuration information is static
2014-04-10 20:51:08 +00:00
and cannot update any more frequently than convergence runs. Generally this
is on the interval of many minutes or hours. Additionally, there is no
mechanism to incorporate the system state in the configuration: nodes which
2014-04-10 20:51:08 +00:00
are unhealthy may receive traffic exacerbating issues further. Using this
approach also makes supporting multiple datacenters challenging as a central
group of servers must manage all datacenters.
2014-02-08 00:41:03 +00:00
2014-04-10 20:51:08 +00:00
Consul is designed specifically as a service discovery tool. As such,
it is much more dynamic and responsive to the state of the cluster. Nodes
can register and deregister the services they provide, enabling dependent
applications and services to rapidly discover all providers. By using the
integrated health checking, Consul can route traffic away from unhealthy
nodes, allowing systems and services to gracefully recover. Static configuration
2014-04-17 20:18:16 +00:00
that may be provided by configuration management tools can be moved into the
2014-04-10 20:51:08 +00:00
dynamic key/value store. This allows application configuration to be updated
2014-11-05 04:01:45 +00:00
without a slow convergence run. Lastly, because each datacenter runs independently,
2014-04-10 20:51:08 +00:00
supporting multiple datacenters is no different than a single datacenter.
2014-02-08 00:41:03 +00:00
2014-04-10 20:51:08 +00:00
That said, Consul is not a replacement for configuration management tools.
These tools are still critical to set up applications, including Consul itself.
Static provisioning is best managed by existing tools while dynamic state and
discovery is better managed by Consul. The separation of configuration management
and cluster management also has a number of advantageous side effects: Chef recipes
and Puppet manifests become simpler without global state, periodic runs are no longer
required for service or configuration changes, and the infrastructure can become
immutable since config management runs require no global state.