Home / server / Questions / 414758
Accepted
Luke404
Asked: 2012-08-07 08:42:34 +0800 CST

What should NOT be managed by puppet?

  • 772

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?

linux

6 Answers

  1. Best Answer

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

    • 26

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

    • 11
    • 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.

    • 8

  4. 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.
    • 2

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

    • 2

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

    • 0