When is it appropriate to use a configuration manager (eg Puppet / Chef / Ansible)?

Solution 1:

IMHO it's worth learning even if you're only managing a single server,

Yes, there will be a learning curve. Yes, you will get frustrated. For those costs, though, you will be paid back in multiples through reliable, consistent, one-click deployments, version-controlled server configuration, ease of setting up test/dev environments, etc.

In addition to the benefits to your current job, being able to add a CM system to your resume is a big win. Modern sysadmins are now expected to have at least exposure to a config management system, if not proficiency.

(Sidenote: consider Ansible as well. It's my preferred CM, and is very easy to get up and running with - much easier than either Puppet or Chef. Additionally, windows support in Ansible is coming along nicely.)

Solution 2:

I'm considering implementing a configuration management tool such as Puppet or Chef. Is this reasonable, or will the overhead of learning the tool outweigh the benefits?

It is reasonable depending on how much time and money you have to burn, and whether or not it's your money that you are burning.

A configuration management tool (any of them) is becoming a valuable skill in todays market.

Spending the time to learn and implement a CM tool may not be the most efficient thing to do from the perspective of your business or environment, but from your skillset it may be worthwhile.

Where is the tipping point between manageability & implementation cost?

Most configuration management tools are available for free with the caveat that they are harder to install and get going.

This question is a little hard to answer since it really depends on what you are doing on a day to day basis to manage these servers. If you aren't required to do much at all, then a configuration management tool may be total overkill.

If you only really need to enforce your infrastructure into a predictable and basic state, then it may not do much harm to pick up the very basics of something like SaltStack or Ansible.

In my personal experience, Salt is very easy to get going and bootstrap onto servers, and can be used for very basic remote execution and reporting, which may come in handy if you don't have it already implemented in your environment.

Keep in mind, I am biased. You should evaluate each CM tool by yourself.

Solution 3:

Just like @EEAA said - number of servers is irrelevant. You can reap benefits of using configuration management with a single machine:

• documented setup (documented via CM scripts)
• reliable deployment (you can [re]deploy youre setup over and over again
• resilience of setup (current server croaks - spin up a new one)
• reuse (when you get to a point of having a second server - you already have CM scripts you can recycle from first one)
• upgrades (it's kind of like a new setup, just atop a different platform)

I can say that I had to implement CM for all my personal servers as I work there infrequently and forget all of the little details. Having CM scripts while may seem to be time-consuming (it is) the payback is well worth it. Long term you'll save much more time that you'll spend setting things up.

Solution 4:

I have experience with Puppet and Ansible. Ansible is IMO simpler, as it's procedural, while Puppet is declarative. There are pros and cons to both, but I have pulled enough hair due to Puppet's cryptic errors.

Both require a lot of work if you want to create clean and reusable configuration. The costs start to really pay off if you have at least two very similar servers, e.g. clouds or clusters.

However, it has some use even for standalone servers - you can setup admin users, standard (with local variations) sshd, postfix or snmpd configs and also use them for a simple information gathering, like adherence to policy or test for shellshock vulnerability.

Also, as mentioned by EEAA, it has a value for documenting the setup if you verify that it really brings a server from base state to running state. It's good to combine it with version control system (git), so that the changes you make are versioned and documented. That is very valuable if you have a team of admins.