1

Does either Puppet or Chef support replicated puppetmasterd/Chef servers? It seems very surprising to me that these tools would force a single point of failure, but I haven't been able to find any mention of this in their docs or Google.

I know Puppet and Chef can be run without a server (possibly updated with, e.g., git as described in http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control), but this seems like a second-class citizen, and presumably loses some monitoring ability.

Improve this question

3 Answers 3

Reset to default
5

For puppet you would need

  1. Identical manifests. This can be accomplished by keeping your manifests in version control and checking them out on each server, which you should be doing anyway.
  2. A single database for stored configuration, if you using it. This is as simple as switching from the default of sqlite to MySQL or PostgreSQL. You could then use those database's tools to replicate the database if desired.
  3. Certificates from the same certificate authority on all puppetmasters. Dan Bode has the best explanation I've seen. However, it may not work the way you expect. Also, I'm not sure how this works with client certificates (i.e. /var/lib/puppet/ssl/ca/signed/*). Maybe their verification is always handled by the single CA (introducing a single point of failure), or maybe the the pem files be distributed to each puppetmaster after they're signed by the CA.
Improve this answer
1
  • 2
    The signed directory doesn't much matter; as long as the cert presented by the client chains up to the CA cert each master uses, you'll be fine. The tricky thing about multiple hosts running a single CA certificate is that they can issue duplicate serial numbers so revocation (puppet cert --clean myhost1.my.com) will also revoke myhost2.my.com if they were issued with the same serial by different masters. Bad news. To get around it use --ca_server master1.my.com on the clients and set ca = false on your non-signing puppetmasters.
    – eric sorenson
    Mar 16, 2011 at 1:36
2

Chef was designed from the ground up to be run with multiple servers, for all its backend component, as this is a core feature of the Opscode Platform - a highly scalable hosted Chef Server.

The various core components of the Chef Server:

  • API server
  • Data Store (CouchDB)
  • Search Engine (SOLR)

As such, each of these components is capable of running on separate servers, and Chef can be configured to use separate servers for each component. For configuration information, see the Chef Configuration Settings page. Primarily, couchdb_url and solr_url settings can point to either a separate server (or servers) running those components, or a load balancer sitting in front of them.

The Chef Server API will also need access to the cookbooks, which could be in a shared filesystem.

Improve this answer
1

If you are concerned about a single point of failure, create a puppet cluster :)

  1. Create a cluster with corosync/pacemaker (or old school heartbeat), make it active/passive or even active/active
  2. Get the two (or more) server's important data duplicated with DRBD or other method
  3. Profit!

Puppet clients get their manifests from the puppet server identified by DNS (unless you specify a server on the client, but that's not very good), so you have many ways to guarantee that you will never be without a server, be it an active/passive cluster where the passive gets the IP address if the active fails or even changing the DNS entry to a new server in case of failure (the first option being the most elegant).

A great resource for clusters those days is the Cluster from Scratch document from clusterlabs. The guide includes DRBD configuration examples so it's very through.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .