Archive for the ‘Puppet’ Category
I love reading articles like these, mostly because they deal with issues that I see almost every day in my day job. Adding a new server to your deployment should be as simple as doing a base install and then pointing your configuration management system at it. The hard work should be done once, defining services, their configuration and their relationships.
The operational efficiencies gained from an automated configuration management system should extend beyond growing your current server farm. The time taken to track down bugs and reproduce problems should fall substantially when you know all your servers have the correct configuration. No more diff’ing the config across multiple servers to figure out why one is behaving different to another. No more checking software version numbers across hosts, because sometimes, a host is missed during an upgrade. No more wondering if apache is supposed to be installed on one of your mail servers.
Once your operational staff are relieved of these tedious tasks, their time can be used more effectively in improving aspects of your service. All those tasks that should be done “one day” such as implementing or improving backups, capacity planning or monitoring and reporting of the service can finally get some love.
As we move towards a virtualisation of hardware, automation of provisioning, building and management of servers will become ever more critical. Businesses with advanced operational practices will gain a competitive edge over those organisations who still manually build, configure and maintain their hosts.
The truth is, the state of computing is absolutely pitiful. There are essentially no good tools for sysadmins, and the practice of system administration relies almost entirely on hand-building and hand-maintaining operating systems; those who aren’t doing things by hand are almost exclusively using tools they built themselves and will never publish, including places like Google.
It’s so true, but as with many truths, sometimes it takes someone to say it plainly. We system admins ( at least the ones I work with ) dislike the tedious work — the typing monkey work, but love the challenge of a new problem to solve. When the tedium becomes too strong, we write scripts to do the typing monkey work for us. This can be as enjoyable as solving problems. This is probably the point where non-geeks are scratching their heads saying “Did he just say enjoyable?”.
Some parts of the interview give my sense of humour a wry poke:
sure, you can tell Apache is running, but is it supposed to be running or did someone just start it while testing something six months ago?
Ha. So true. We see this kind of thing all the time — especially with boxes which have been running for a while. ( I was sad to have to update the kernel on some machines a few weeks ago — 522 days of uptime ). “Is apache supposed to be installed on this box??” The more I get to know puppet, the more I think it’s got a place in the toolbox of the sys admin.
I had trouble finding clear instructions on installing Puppet onto Debian Sarge, so I thought I’d document how I did it.
First, install all the Ruby stuff:
aptitude install irb1.8 libreadline-ruby1.8 libruby libruby1.8 rdoc1.8 ruby ruby1.8 ruby1.8-dev libopenssl-ruby1.8
Then, install RubyGems. The latest version can be found here: http://rubyforge.org/frs/?group_id=126
Set an environment variable for your proxy ( if required ):
Next, download and install RubyGems:
wget http://rubyforge.org/frs/download.php/20989/rubygems-0.9.4.tgz tar xzf rubygems-0.9.4.tgz cd rubygems-0.9.4 ruby setup.rb
Finally, we can install puppet (after updating RubyGems):
gem update gem install -b puppet
It’s pretty straight forward really. Although it would be easier with aptitude install puppet, but hey, you can’t have everything.