back to article If you like slipping your hand into Puppets, look for these certified types

Puppet Labs is rolling out what it calls the Puppet Supported Program, which pushes gear that's been tested and certified to work with its automation software Puppet. Swift uptake by many big-name vendors in the program comes on the heels of a $40m funding announcement. If you had any remaining doubts that DevOps is a thing, …


This topic is closed for new posts.
  1. Peter Gathercole Silver badge

    The future of Sysadmining.

    Do other people worry like me, that tools like this relegate Sysadmins to GUI drivers, with no knowledge of how it all hangs together?

    I'm not criticising tools like this, because they are necessary to run large environments like we have now, but making it easier also degrades the required skill. And my constant worry is that when it goes wrong, organisations who have de-skilled their sysadmins will no longer have the skills necessary to diagnose the problems.

    Looks to me like we need to re-instate the System Programmer job discipline as the next tier up.

    1. Trevor_Pott Gold badge

      Re: The future of Sysadmining.

      Puppet. GUI. Wha?

      1. Peter Gathercole Silver badge

        Re: The future of Sysadmining.

        OK, I take the point that it has no GUI, but the whole point of this certification is that the devices will work out of the box without the admins having to understand how to actually configure and manage the devices.

        At least in the past when admins had to write their own 'scripts', they dug in to the device to work out what is necessary. If the scripts are already written, they may never read the manuals!

        1. Trevor_Pott Gold badge

          Re: The future of Sysadmining.

          Why is that a bad thing? Why should systems administrators have to know how infrastructure works, if the infrastructure is cheap enough to be disposable and there are things that easily configure it? Ideological purity?

          Look, the point of IT is to make money. Your switch and your storage array don't make money. The applications they support do. If you can reduce the cost of managing and maintaining those switches, storage arrays, operating systems and so forth then you make more money from the use of the applications in question. If you are more efficient than your competitors, you win. That's business.

          I could build you a car from scratch right up to the point that we stopped using carburetors. After fuel injection came in, I can't build you a car anymore, or even fix it. But I can still drive one. I've been driving one for a decade or more and I'll be driving for decades to come. The inability to repair all aspects of the car doesn't prevent me from using it and gaining value from it.

          Systems administrators no longer need to know the sorted details of their disk arrays or how to futz with a switches command line. If push comes to shove on that, they can always bust out the manual, and that's available online. And we all have many ways of getting online.

          I learned Cisco switches back in the early Catalyst 2600 days. Have I played with a Nexus from the command line level? No. Could I work it out after only a few minutes? Yes! The internet is full of knowledge and I only need to grok the basics before I'm off to the races.

          Meanwhile, could I get 15 years of productivity out of that Nexus without ever dropping to it's command line? With Puppet, you're goddamned rights I could.

          So on the one hand, I can orchestrate a delicate ballet of hundreds of thousands of devices using a tool called Puppet. I can be a highly efficient administrator that provides a good return on investment for my employer, but I fail in some ideologically "pure" fashion because I am not infinitely familiar with the details of how every single device works.

          On the other hand, I could learn every single detail of every single device I use and configure each and every one of them from the lowest level interface available, with zero orchestration across the entire estate. I will likely need 5x as many administrators to run that estate. I don't provide efficient IT services for my employer, but I meet an arbitrary "pureness" of philosophy.

          If you view the second option as the desirable one, you are bad at business.

    2. Goat Jam

      Re: The future of Sysadmining.

      Puppet doesn't have gui (that I know of) it is essentially a centralised bunch of scripts that hosts on your network pull down and configure themselves with.

      That is an overly simplistic description of course but it will do.

      1. Billy 8

        Re: The future of Sysadmining.

        There are web-based interfaces that work with it thought - like foreman for instance. Which I've been meaning to try out for a while. Just as soon as I get to the end of my infinite to-do list... :-/

  2. Captain DaFt

    Missed it by one letter!

    If this was from Muppet Labs, I'd be more interested... Just to see what it does to hapless beaker!

    1. Trevor_Pott Gold badge

      Re: Missed it by one letter!

      Mahna Mahna.

  3. Anonymous Coward
    Anonymous Coward

    Got introduced to Puppet by a consultant sysadmin that we brought in to give us some advice. I'm actually a programmer, but along with the DBA had become the de-facto sysadmin. All our development and production systems ran Linux, but our Ops guys were Windows only and snowed under with running the internal systems.

    Prior to Puppet, we had muddled through with a bunch of shell scripts that would strip down and add a few packages to a minimal CentOS install, preparing it for the intended usage (DB server, HTTP server, etc). They took parameters or prompted for various things like IP address and so on. These went into Subversion, but were getting a bit awkward as we tuned more and more things. Puppet replaced most of those ad-hoc scripts with something much better.

    We later moved from dedicated hardware to a mostly virtualised environment. Even with templates made from snapshots of each system type, we still needed Puppet to set up the system specific bits. An alternative that I've since looked at is Chef, which also looks pretty good.

  4. Alistair

    automate automate automate automate.

    just get it done. You have a project to build 4 systems - start there - eventually you'll have a flow that works - once it works, it *will* demonstrate efficiencies and stabilities - which makes it easier sell to the app folks to butter the (non equipped) systems with the tasty tasty automation tool(s).

    I've been using cfengine for this on linux with viperl to blow out vms from a linux command line. I still have to fight fires, but the **great thing** is that an edge case detected on one host in a corner of the datacenter that *does* cause a problem can be fixed across the environement fairly quickly - - despite the presence of burdensome paperwork, with automation. Yes I test things. Yes we have a few boxes that once were decommissioned that were pushed into a corner and hidden so we have test fleet. I had a huge advantage in that linux was a "new" operating system here once. AND I had the foresight to say "its going to spread like a weed" and plan for it.

    Three aquisitions along the way and cfengine went on those systems too.

    The biggest change I have to teach SA's coming in is to toss out the idea that "but the user says it has to be this way" is an acceptable reason to change a standard. There's always a way to get the standard and "what the user wants" to agree.

This topic is closed for new posts.