website: Update Chef comparison
This commit is contained in:
parent
81abe725f9
commit
39b28dadd7
|
@ -1,31 +1,40 @@
|
|||
---
|
||||
layout: "intro"
|
||||
page_title: "Serf vs. Chef, Puppet, etc."
|
||||
page_title: "Consul vs. Chef, Puppet, etc."
|
||||
sidebar_current: "vs-other-chef"
|
||||
---
|
||||
|
||||
# Serf vs. Chef, Puppet, etc.
|
||||
# Consul vs. Chef, Puppet, etc.
|
||||
|
||||
It may seem strange to compare Serf to configuration management tools,
|
||||
but most of them provide mechanisms to incorporate global state into the
|
||||
configuration of a node. For example, Puppet provides exported resources
|
||||
and Chef has node searching. As an example, if you generate a config file
|
||||
for a load balancer to include the web servers, the config management
|
||||
tool is being used to manage membership.
|
||||
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. Unfortunately, this approach has
|
||||
a number of pitfalls. The configuration information is static,
|
||||
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
|
||||
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.
|
||||
|
||||
However, none of these config management tools are designed to perform
|
||||
this task. They are not designed to propagate information quickly,
|
||||
handle failure detection, or tolerate network partitions. Generally,
|
||||
they rely on very infrequent convergence runs to bring things up to date.
|
||||
Lastly, these tools are not friendly for immutable infrastructure as they
|
||||
require constant operation to keep nodes up to date.
|
||||
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
|
||||
integrating health checking, Consul can route traffic away from unhealthy
|
||||
nodes, and allowing systems and services to gracefully recover. Static configuration
|
||||
that may be provided by configuraiton management tools can be moved into the
|
||||
dynamic key/value store. This allows application configuration to be updated
|
||||
without a slow convergence run. Lastly, because each datacenter runs indepedently,
|
||||
supporting multiple datacenters is no different than a single datacenter.
|
||||
|
||||
That said, Serf is designed to be used alongside config management tools.
|
||||
Once configured, Serf can be used to handle changes to the cluster and
|
||||
update configuration files nearly instantly instead of relying on convergence
|
||||
runs. This way, a web server can join a cluster in seconds instead of hours.
|
||||
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
|
||||
membership updates, and the infrastructure can become immutable since
|
||||
config management runs require no global state.
|
||||
That said, Consul is not a replacement for configuration management tools.
|
||||
These tools are still critical to setup setup applications and even to
|
||||
configure 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.
|
||||
|
|
Loading…
Reference in New Issue