luxolus/open-consul
2
0
Fork 0
Code Issues 1 Pull requests Packages Releases Wiki Activity

website: Update Chef comparison

Browse source
This commit is contained in:
Armon Dadgar 2014-04-10 13:51:08 -07:00
parent 81abe725f9
commit 39b28dadd7
1 changed files with 32 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

55
website/source/intro/vs/chef-puppet.html.markdown
View file

@ -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.