Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm learning my way through configuration management in general and using puppet to implement it in particular, and I'm wondering what aspects of a system, if any, should not be managed with puppet?

As an example we usually take for granted that hostnames are already set up before lending the system to puppet's management. Basic IP connectivity, at least on the network used to reach the puppetmaster, has to be working. Using puppet to automatically create dns zone files is tempting, but DNS reverse pointers ought to be already in place before starting up the thing or certificates are going to be funny.

So should I leave out IP configuration from puppet? Or should I set it up prior to starting puppet for the first time but manage ip addresses with puppet nonetheless? What about systems with multiple IPs (eg. for WAN, LAN and SAN)?

What about IPMI? You can configure most, if not all, of it with ipmitool, saving you from getting console access (physical, serial-over-lan, remote KVM, whatever) so it could be automated with puppet. But re-checking its state at every puppet agent run doesn't sound cool to me, and basic lights out access to the system is something I'd like to have before doing anything else.

Another whole story is about installing updates. I'm not going in this specific point, there are already many questions on SF and many different philosophies between different sysadmins. Myself, I decided to not let puppet update things (eg. only ensure => installed) and do updates manually as we are already used to, leaving the automation of this task to a later day when we are more confident with puppet (eg. by adding MCollective to the mix).

Those were just a couple of examples I got right now on my mind. Is there any aspect of the system that should be left out of reach from puppet? Or, said another way, where is the line between what should be set up at provisioning time and "statically" configured in the system, and what is handled through centralized configuration management?

share|improve this question
    
Nice question. I'm curious myself if there's anything other than machine-specific configs you shouldn't use puppet for. Well, that and Windows machines. –  HopelessN00b Aug 6 '12 at 17:07
4  
<vague>You should not manage things in puppet when it is better/easier to manage them some other way.</vague> :p –  Zoredache Aug 6 '12 at 17:24
1  
With the prevalence of companies using Puppet these days, I can see this question garnering much attention over the next few years –  Daniel Li Aug 29 '12 at 15:12
add comment

6 Answers

up vote 16 down vote accepted

General rule: If you're using configuration management, manage every aspect of the configuration that you can. The more you centralize the easier it will be to scale your environment out.

Specific examples (cribbed from the question, all "This is why you want to manage it" narratives):


IP Network configuration

OK, sure, you configured an address/gateway/NS on the machine before you dropped it in the rack. I mean if you didn't how would you run puppet to do the rest of the config?

But say now you add another nameserver to your environment and you need to update all your machines -- Don't you want your configuration management system to do that for you?

Or say your company gets acquired, and your new parent company demands that you change from your 192.168.0.0/24 addressing to 10.11.12.0/24 to fit into their numbering system.

Or you suddenly get a massive government contract -- Only catch is you have to turn up IPv6 RIGHT FREAKIN' NOW or the deal is blown....

Looks like network configuration is something we'd like to manage...


IPMI Configuration

Just like with IP addresses, I'm sure you set this up before you put the machine in the rack -- It's just good common sense to enable IPMI, remote console, etc. on any machine that has the capability, and those configurations don't change much...

... Until that hypothetical acquisition I mentioned in IP Configuration above -- The reason you were forced to vacate those 192.168-net addresses is because that's IPMI-land according to your new corporate overlords, and you need to go update all your IPMI cards NOW because they're gonna be trampling on someone's reserved IP space.

OK, it's a bit of a stretch here, but like you said - all of it can be managed with ipmitool, so why not have Puppet run the tool and confirm the configuration while it's doing all of its other stuff? I mean it's not going to hurt anything, so we may as well include IPMI too...


Updates

Software updates are more of a gray area -- In my organization we evaluated puppet for this and found it "sorely lacking", so we use radmind for this purpose. There's no reason Puppet can't call radmind though -- In fact if/when we migrate to Puppet for configuration management that's exactly what's going to happen!

The important thing here is to have all your updates installed in a standard way (either standard across the organization, or standard within platforms) -- There's no reason Puppet shouldn't be launching your update process, as long as you've thoroughly tested everything to ensure that Puppet won't mess up anything.
There's also no reason why Puppet can't call out to a tool that's better suited for this task if you've determined that Puppet can't do a good job on its own...

share|improve this answer
add comment
  • Puppet is not an orchestration system. In particular:
    • Puppet is not well suited to VM orchestration, as VMs have a lifecycle of their own which should be respected.
    • Puppet is not well suited to application release management/complex upgrades. Standalone puppet runs could be exploited for this, but then at least it's not Puppet in control, instead it's your wrapper scripts or a human robot, which is fine.
  • Puppet is not a good user management system (It has to manage every user entry, even deleted users, to be effective. So find another solution)
  • Puppet is not a good configuration database (look at using an external database of some sort, and an ENC, Hiera, or some similar glue)

Of course you can do all of these things with Puppet.. but it’s just not the best solution for them. Sometimes you should put down the hammer, and go look for a wrench.

Puppet is however exceedingly good at maintaining the base configuration for a machine, and installing the tools that let you do VM and release orchestration, user management etc.

share|improve this answer
add comment

I mostly agree with voretaq7, but with a couple of caveats.

  • I rarely ever configure the IP addressing in puppet, unless the system uses DHCP (i assume most large "cloud" providers do this). I've had situations where i broke network configurations with puppet, but couldn't correct them with puppet because the node didn't have any way to contact the puppetmaster.

  • I'm quite firm in my belief that update management belongs in the hands of the system tools, and i don't see using puppet as a glorified cron to be an improvement.

share|improve this answer
add comment

Don't reinvent the wheel.

Yes, you can have 50 puppet virtual user resources and realize them as needed in your modules... but if you can, use LDAP.

I speak from bitter experience. Although ldap isn't an option here, yet.

Anouther example is pushing out hosts files, rather than just using DNS.

share|improve this answer
2  
I recognize all those words, but I'm still not sure what you're trying to say. –  Chris S Aug 7 '12 at 0:18
    
I'm trying to say; puppet is a central place for "information". So are DNS and LDAP. Don't try to do their jobs with puppet, it's rubbish at it.... I say this having seen giant /etc/hosts files being pushed out with puppet every time a new host joins the network. –  Sirex Aug 7 '12 at 0:24
2  
Do people really use Puppet instead of LDAP to manage user accounts?? –  Joel E Salas Aug 8 '12 at 0:30
    
Yes. We do... politics. Believe me, I'm working on it. –  Sirex Aug 8 '12 at 1:00
    
Every tool has its place, but using puppet for user account management or LDAP for file storage is abuse. –  Hubert Kario Dec 13 '12 at 23:35
show 3 more comments

Think you don't need use puppet for network configuration. It is once configured thing usually. Also you can get some crap if you will have a mistake(s) with IP or MAC or something similar that will brings by puppet.

share|improve this answer
1  
Never had to change default gateway on 100+ server by hand? Lucky you ;) –  Eric DANNIELOU Aug 6 '12 at 21:36
    
@EricDANNIELOU I suppose that could be taken as a +1 for letting puppet manage IP configuration of network interfaces ;) –  Luke404 Aug 6 '12 at 23:01
    
@EricDANNIELOU Try to do this with bash, "for" cycle and appropriate user permissions (sudo to root or root directly) and sed/perl/etc. :) –  Evgeniy Aug 7 '12 at 4:37
1  
I don't think bash "for" cycle and dirty sed/awk/vi scripts are safer than scm for network configuration. And once you have puppet set up for everything else, it's not very convenient to have ssh "for" loop only for network configuration. –  Eric DANNIELOU Aug 7 '12 at 10:38
add comment

In my case, I have a bootstrap script which loads the minimal system config (Ubuntu): Ruby, Rubygems, build-essential, git, etc. My Puppet manifests are kept under version control, and I simply clone the repository. From there, my bootstrap script makes an assumption that hostname --short is valid, and attempts to puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

To answer your question:

  • My scripts assume basic network connectivity (DNS, IP), and don't manage or change it;
  • My scripts assume the machine's identity is correct, and don't change it;
  • My scripts assume Ruby / Rubygems / Git is present, but do manage it afterwards.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.