17

At my current workplace, I look after two VMware host machines, an OpenBSD physical machine, three Debian VM's, and six Windows Server VM's (2008/2012).

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? Where is the tipping point between manageability & implementation cost?

Rhyven
  • 183
  • 8
  • 1
    It's "appropriate" as soon as you ever need to manage a configuration - need to recover from a disaster? Need to move to a new data center? Need to expand horizontally? If you're doing by hand, you're doing it [wrong](http://antipaucity.com/2013/05/11/automating-or-automation/#.VSwoyBPF8nR). "[Doing it twice? Write it down.](http://buildacloud.org/blog/257-doing-it-twice-write-it-down.html)" – warren Apr 13 '15 at 20:37
  • 1
    It depends on what you need to do to/with these systems. – ewwhite Apr 15 '15 at 13:21

5 Answers5

25

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

EEAA
  • 108,414
  • 18
  • 172
  • 242
  • 5
    Well said. I end up using Ansible on trivial things like setting up a raspberry pi at home because it's a convenient way for me to document the process. – tedder42 Apr 07 '15 at 05:41
  • 2
    Absolutely! Getting into Chef has been a huge career win for me. Here's the real thing: in a couple years CM will be just about required/expected for all but junior SysAd jobs. – gWaldo Apr 08 '15 at 16:40
  • 2
    Totally agreed. Too much focus is on automation of install which is only one part of CM systems. People forget what M stands for - management. How do you keep track of the various configuration changes you make to 1 server. The number of servers does not matter. When that 1 server dies, you're happy to be able to rebuild it exactly without a doubt. – ETL Apr 09 '15 at 17:54
5

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.

Vasili Syrakis
  • 4,435
  • 3
  • 21
  • 29
4

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.

Droopy4096
  • 670
  • 3
  • 7
3

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.

Edheldil
  • 127
  • 3
1

Puppet or any other management system bring great benefits which have all been highlighted by other answers here, but there is no silver bullet when it comes to management.

For example creating puppet classes for complex systems cost much time and effort and sometimes tears as there are many pitfalls, and error messages are not always 100% clear, and when the software upgrades you must invest time to adapt your puppetclasses to match any new specification or procedure and figure out which approach is best suited for this (puppet for example declarative and an upgrade is typically procedural)

Also you need to figure out how you plan to roll out changes made to your classes in a controlled manner, and how to maintain the different versions of your manifests.

You should also consider how to go about upgrading your management solution when the time comes for that.

If you spend a significant amount of time writing for example puppet classes then you'd have to perform a lot of one-click installs to reap any real benefits.

I recommend exploring still and where appropriate, ie distribution of config files can be a good place to start, and take it from there.

Petter H
  • 3,383
  • 1
  • 14
  • 18