Showing posts with label Systems Administration. Show all posts
Showing posts with label Systems Administration. Show all posts

Thursday, November 20, 2008

Puppet and Ralsh

I wrote about puppet and how we're starting to look into it at work a couple of days ago. Yesterday, I learned about an awesome little tool that puppet provides — ralsh, the Ruby Abstraction Layer SHell. To understand just how cool ralsh is, you need to know a little bit more about how puppet works. puppet allows you to describe how a server should 'look' using a declarative language (this is a hurdle a lot of people have problems with, but it's too big to go into here). It then provides the plumbing to enact those declarations on different kinds of servers (OS X, Solaris, Linux, etc.) using its 'Ruby Abstraction Layer'. This allows you to define something like:

user { 'postfix':
    ensure => 'present',
    uid => '51',
    comment => 'Postfix Daemon',
    gid => '51',
    home => '/var/spool/postfix',
    shell => '/bin/false'
}
Which says that you should have a user called postfix, defined as listed. If that user doesn't exist on a system where this is defined, puppet will do the right thing to add them for that kind of box. ralsh provides commandline access to this abstraction layer so that you can query the current configuration of the system, or modify that configuration. When used to query a system ralsh dumps out the current configuration in puppet's declarative language. For example:

$ ralsh service apache2
service { 'apache2':
    ensure => 'running',
    enable => 'false'
}
$
If you think about this for a minute, you'll see that it's a lot cooler than it first appears. Let's say you've got 15 servers that have been 'built' piecemeal. You're really not sure what's installed on them, or what's running there. Now, let's make a bad situation even worse, you need to build out a duplicate set of servers, only you're going to migrate from SLES to debian. ralsh suddenly looks like a great way to audit those servers and to provide a basic puppet configuration to build out the new ones. Don't expect this process to be perfect — debian and SLES name their packages differently enough, for example, that you're going to have to sort some things out by hand. It's a great way to start though. puppet and ralsh look like great tools to help you get out the door before five.

Tuesday, February 12, 2008

Book Review: Pulling Strings with Puppet

Puppet is a great looking configuration management tool written in Ruby, from Luke Kanies at Reductive Labs. Recently, James Turnbull has written a book, Pulling Strings with Puppet, about it.

I’ve interviewed both Luke and James about Ruby, Puppet, and James’ book. So, it’s only fair that I turn an eye to the book as well. In the interest of full disclosure I should mention that Apress gave me a PDF of this book for review purposes.

Pulling Strings with Puppet was published as an eBook, through Apress’ imprint firstPress. It’s a really big book to see published this way, coming in at 187 pages, two or three times the size of a lot of ebooks. Like other books in the firstPress line, this one is also available in print (the amazon links in this review point to the paper copy, if you want the PDF, look here and follow the link).

James is an accomplished Apress author, having also published Pro Nagios 2.0 and Hardening Linux (both of which come highly regarded). As such, he’s certainly proven his chops in the sysadmin world, so his book on Puppet can be seen as something of a vote of confidence in the system.

The book contains seven chapters, as follows:
  1. Introducing Puppet
  2. Installing and Running Puppet
  3. Speaking Puppet
  4. Using Puppet
  5. Reporting on Puppet
  6. Advanced Puppet
  7. Extending Puppet

The first chapter should whet your appetite for the rest of the book, chapters three and four will get you running along smoothly, but I think it’s the last three chapters that really make this book worthwhile. In chapter five the discussion of the built in report tools and the mechanism for building custom reporting will be of interest. I really liked chapter six’s coverage of scalability (both the admission that Puppet still needs work and the workarounds that can help scale it until the work gets done). All of chapter seven was interesting reading, and shows the ease of extending Puppet and Facter (one of the underlying libraries that makes Puppet work).

This book is filled with helpful code samples and pointers to external resources that look very useful. It’s well written and easy to understand. As good a tool as Puppet looks to be, this looks like an equally good book to get you going. If you’re doing configuration management for anything more than a box or two, run, don’t walk, and pick up your copy of Pulling Strings with Puppet.

Monday, February 11, 2008

Puppet Interview with James Turnbull

Recently, I’ve been reading about Puppet because of James Turnbull’s excellent Pulling Strings with Puppet. James has been good enough to do a short interview with me as well. I hope you enjoy reading it as much as I enjoyed chatting with James (you might want to check out my interview with Luke Kanies too).


I normally think of you as a Pythonista, yet Puppet comes from the land of Ruby. How much does that matter to you? How much should it matter to an end user?

Actually I’d probably be classed a Perl Monger rather than a Pythonista. Either way I am a “hack & slash” programmer in both languages – functionality over elegance.

I took my first serious look at Ruby about the same time I found Puppet. I initially thought that the language wouldn’t matter to me at all but I confess Ruby has sucked me in a great deal more than I had anticipated. It is a very elegant language and one well suited to beginners and system administrators. I find Ruby’s syntax and flow control very easy to grasp and yet a few simple extensions and you are doing some very powerful things. I think when more system administrators discover Ruby we’ll see a slow movement away from Perl and Python as the core “sysadmin scripting” languages.

As a Puppet end user Ruby almost shouldn’t matter to you though. The “almost” relates to exactly where Puppet is in its life cycle. Puppet is still a young product. It is highly flexible and featured and if you’re using Puppet in serious anger about 80% of what you need is there. But there are still some resources you can’t manage. The fastest way to fix that? Develop these resources yourself. Luke Kanies, Puppet’s author, has built a very simple framework that with some Ruby knowledge allows you to do this. We are also seeing more development input as the community expands and people are starting to get more involved. This may provide most of the additional resource types needed right now.

How did you discover Puppet?

By accident mostly. I was researching configuration management tools and I was reading a blog post and someone had commented on this upstart new tool called Puppet. I went over to the Reductive Labs site and downloaded it. Fifteen minutes later I had a master and 5 clients running managing my DMZ servers. Two days after that I was starting to think – “Gee it’d be nice if Puppet did…” And then I was hooked.

Any recommendations on books, blogs, or websites for sysadmins who want to learn more about Ruby?

I like Apress' (disclosure – I am obviously an Apress author) Beginning Ruby. I it found a very useful book – easy to use as a reference and easy to read through. I also found that the Ruby documentation and the basic tutorial at tryruby.hobix.com are good places to start.

Why not CFEngine, one of the other systems management tools, or even a roll-your-own solution?

I have used CFEngine in the past and I know CFEngine has a very loyal user base. It’s a solid tool for many purposes but it has weaknesses and a lot of things that I personally don’t like about it. It also has a long development cycle and a limited number of people contributing to its development. Alternatively I see Puppet as having a quite dynamic community with developers who are responsive to community requirements. ~ Hence for me Puppet is a better choice of tool and one I felt it was important to support and develop.

Using “roll-your-own” tools I think defeats the whole purpose of configuration management. The scripts usually require trees of case statements to cater for varying operating systems and platforms, they usually aren’t portable and they require a communications mechanism that usually defaults to ssh and a for loop. Puppet makes all of that go away – it is a configuration management abstraction language combined with a secure client-server mechanism to configure your hosts. It takes all the pain out of systematically and efficiently managing your hosts.

Puppet seems like a good answer on the configuration management end of the sysadmin house. Is there room for a Ruby solution on the monitoring side as well? Or do you think nagios, mon, or some other solution have that all sewn up? (If so, which one?)

There is a Ruby solution that I quite like for monitoring called “god”. It is very immature compared to Nagios or others of that ilk but it has some interesting concepts. You can see it at god.rubyforge.org. I think there is always room for new ideas and new approaches in system administration tools.

Since you were learning Ruby and Puppet at the same time, what kinds of things did Puppet teach you about the language?

Well I had little understanding of classes, modules and related concepts—actually very little OO experience. Understanding Puppet required gaining an understanding of Ruby’s OO nature. That has also made a big difference to how I code overall.

What kinds of things did writing the book teach you about Ruby and Puppet?

Well I hadn’t looked at storing hosts in LDAP or had much experience with Mongrel. Writing the book meant I had to delve quite deeply into both. Also explaining to people how to create your own extensions to Puppet to manage other resources also meant I had to ensure I learnt enough Ruby to comfortably explain the concepts involved.

Can you show us a little bit of Puppet in action?

Well I can show you a very simple example of managing a resource. Let’s say you wanted to ensure the sshd service was enabled and running on hosts. In Puppet you would define the following resource:

service { "sshd":
~  enable => true,
~  ensure => running,
}
>

And that’s it! You can then assign this resource to the hosts which need it and Puppet will automatically ensure that the service is enabled and started. The best thing is that this same resource definition will work on Red Hat, Debian, Solaris, BSD and others. This is the magic of Puppet’s configuration abstraction – you only need to define what the resource should look like. Puppet takes cares of the how.

What’s the coolest thing you’ve done (or seen someone else do) with Puppet?

That is a hard choice because lots of people are doing lots of cool things. There is a large multi-coloured search engine company who are managing many thousands of OS X desktops with Puppet and the Fedora Project who use it to manage all of their infrastructure.

Probably the coolest thing I see is how people use Puppet in ways I hadn’t considered. I regularly see people on the mailing list and IRC channel say “Wow – I just found out the syntax can do x”. I look at what they have posted and they have often found some new way to take advantage of the language to configure hosts. It is being part of this sort of community that makes working with Puppet very cool.

What non-Puppet Ruby projects are you watching/using?

I’ve recently started playing with rbot—an IRC bot written in Ruby. That also led me to another IRC bot framework called Autumn Leaves. But generally due to a distinct lack of time most of my focus is on Puppet and Facter.

Who gets the credit (Or is it blame?) for the title of your book, “Pulling Strings with Puppet”?

That’d be my editor and the marketing guys at Apress. Do you know how excited marketing people are when a product allows amusing alliteration and puns? :) But I like it – it’s both kitsch and catchy.