Why Puppet Should Manage Your Infrastructure

Re:Why Puppet Should Manage Your Infrastructure by _b8r0 on Tuesday March 08, 2011 @03:07AM (#2300236)

Puppet is one of those things I like in principle but is too much of a PITA to set up. Take for example the class definitions, the class definitions don't appear to offer a great deal more than a shell script, but in the example shown in TFA for the price of about 6 lines of puppet code we could've just run rsync -e ssh -avz ntpd.conf puppet@server:/etc/ntpd.conf && chown root:root /etc/ntpd.conf && chmod 644 /etc/ntpd.conf.

Of course in the real world you'd have a tarball you'd rsync over, then use SSH to extract and run the base script and robert's your father's brother. A lot simpler and the way I'd automated Solaris admin years ago. Puppet's drawback is that it doesn't offer anything sufficiently compelling for people to change from what they use, and presents an awful lot of work in it's syntax for people getting started. Once it's up and running it's brilliant, I've seen it. But it just seems like so much hard work to get there it's like a barrier to entry.

[ Parent | on HN ]

Re:Why Puppet Should Manage Your Infrastructure by Goladus on Tuesday March 08, 2011 @03:31PM (#2302481)

The original example is actually kind of bad and doesn't demonstrate puppet's abstraction facilities.

You can define a custom resource, for example "system_file" that provides a default "root:root, mask 444" permissions such that you just have to define a source and destination for every file, overriding the default permissions when you want.

define system_file($mode = 444, $owner = root, $group = root, $content = '', $source = '', $ensure = 'present') {

        file { $name:
                owner => $owner,
                group => $group,
                mode => $mode,
                ensure => $ensure
        }

        if $source != '' { File[$name] { source => $source } }
        if $content != '' { File[$name] { content => $content } }

 }

So in the article's example, it would look like this:

        system_file { "/etc/ntp.conf":
            source => "puppet:///ntpd/ntp.conf",
            require => Package["ntp"]
        }

Or even

        system_file { "/etc/ntp.conf":
            source => "$configfiles/ntpd/ntp.conf",
            require => Package["ntp"]
        }

Where $configfiles might be the puppet server or some other location. One of the things you get with puppet is access to any of the local host properties that can be discovered with facter, so you can dynamically configure something like a source file.

[ Parent | on HN ]

Re:Why Puppet Should Manage Your Infrastructure by uggedal on Saturday March 12, 2011 @07:10AM (#2316675)

Or you could override the default file resource attributes in sites.pp:

  File {
    owner => root,
    group => root,
    mode => 644,
  }

Then you could override that again in individual file resources. If you need several file resources with the same attributes you can override them within the scope of a class:

  class postgresql {
    File {
      owner => "postgres",
      group => "postgres",
      mode => 640,
    }
  
    $pgsql_root = "/etc/postgresql/8.4/main"
    file { "$pgsql_root/postgresql.conf":
      content => template("postgresql/postgresql.conf.erb"),
      require => Package["postgresql"],
    }
  
    file { "$pgsql_root/pg_hba.conf":
      content => template("postgresql/pg_hba.conf.erb"),
      require => Package["postgresql"],
    }
  }

[ Parent | on HN ]

Re:Why Puppet Should Manage Your Infrastructure by vacri on Tuesday March 08, 2011 @08:39AM (#2300779)

"price of 6 lines of puppet code" = 90 characters

price of your example = 105 characters

[ Parent | on HN ]