Practical Puppet at MWRC March 14, 2009
Posted by stochasticresonance in Puppet.Tags: Awesome, EC2, MWRC, Puppet, Rails, reductive
add a comment
**update** The underlying repos changed so the demo won’t work from the user data. It will still work after running ‘apt-get update’ on the box. If I get bored I might repackaged it.
*update* Confreaks has my MWRC video up. The notes below about launching on EC2 are probably still useful for context.
These are my slides from Mountain West Ruby Conf.
Starts with a little intro about the beginning of computing, before ‘computer science’, driven by desire for computation in math and physics, when there wasn’t a division between the people that program and people that understand how the systems work. (this period probably lasted for about 10 minutes.)
Then some Puppet code…
These modules will build passenger and install rails.
Finishes with a short discussion on the tribes, trading ideas, evolutions, the opportunity of clouds and encouraging people to do something awesome.
The talk was given with a live demo of this code building rails in EC2.
You can do it too if you have an EC2 account.
Start ami-2b10f742 littleidea/mwrcpuppetrailsdemo.manifest.xml sending this as the user data:
#!/usr/bin/env puppet
rails::site{ the_next_big_thing:
servername => "www.tnbt.com",
rails_version => "2.2.2"
}
Set the server name and the rails version to whatever you want.
If you need more gems or packages you can add:
#for gems
package { gemname:
ensure => installed,
provider => gem
}
#for native packages
package { pgkname:
ensure => installed,
}
If you need a certain version of a gem or package, change ‘installed’ to the version you want (the default will install the latest available.)
The image is based on ami-7cfd1a15 Ubuntu Intrepid packaged by Eric Hammond with puppet and facter installed. The puppet manifests from the slides are modules found in /usr/share/puppet/modules.
When the ami starts up it will grab the user data and run it.
You can also ssh to your instance and just put the puppet code in a file (strip the #! /usr/bin/puppet) and run puppet –debug to watch it build.
puppet --debug mysite.pp
Mountain West Ruby Conference February 9, 2009
Posted by stochasticresonance in Puppet, Ruby.Tags: MWRC, Puppet, Ruby, Salt Lake City
add a comment
Rocky Mountain High
I’m definitely looking forward to Mountain West Ruby Conference. Last year was most excellent, and this year I’m presenting. Puppet, clouds, live demo, no net, should be a good time…
MWRC is a single track regional conference, but it brings in some of the biggest names in the Ruby world. (maybe we can get Matz to come next year) Sharing the stage with some of these guys is an honor and a privilege, if not a little intimidating. And if last year was any indication, even the guys you haven’t heard of will be awesome. I can’t recommend this conference highly enough.
Pat Eyler of On Ruby is one of the organizers and just posted an interview with me. He is interviewing other speakers as a lead up to the conference, so keep an eye out.
Use your powers for Awesome!!!
Puppet and Capistrano February 9, 2009
Posted by stochasticresonance in Puppet.Tags: Puppet, reductive
add a comment
Can you smell what the Puppet is cookin’? January 18, 2009
Posted by stochasticresonance in Puppet.Tags: Meatcloud, Puppet
3 comments
Imitation is the highest form of flattery…
Things are getting really interesting in the configuration management space. The confluence of clouds, web 2.0, dev-ministration and chocolate sauce.
Chef is upping the ante, one way or another. I’m a little saddened that the majority of the ideas in Chef were discussed in the context of Puppet and implemented by someone who has made a living off of Puppet… but I’m not totally surprised.
I understand why Adam would do this, and on many levels it parallels Luke’s relationship with cfengine. Adam has probably used Puppet to solve more real problems and build more infrastructure than anyone else, just like Luke had done consulting with cfengine for years before Puppet was born. In a sense, Adam is the embodiment of the future of system administration that Luke had envisioned and hoped to create.
Socrates, Plato, Aristotle… and so it goes.
Adam is a smart guy who thinks clearly about solving problems, had Puppet as an example and data from the front line. He strikes me as a genuine fellow and while we aren’t best friends, I have enjoyed his conversation and insights on more than one occasion. Chef adds some nice functionality that was obvious and some pieces that are differences in philosophy. I’ve done my best to absorb both Luke and Adam’s expressed positions, and paradoxically, in my estimation they are both right, in their context. One way or another, there are still a lot of machines out there being managed by meatclouds, so there is plenty of work to do.
Puppet was first released in 2005 and has grown in functionality and adoption since that time. Puppet is revolutionizing system administration, similarly to how Rails revolutionized web development, and Chef can only accelerate that process, by its own merits and by driving innovations in Puppet. At the heart of the story are many questions about progress, open source, community, technology, obligations and the attributions. The storyline already has mystery, intrigue, tragic heroes, and double agents. There is bound to be some drama, just because there are humans involved, but sometimes nothing motivates like a nice punch in the mouth.
Remember when Nintendo was king of the world then couldn’t sell anything, and now they pwn Playstation and Xbox… Or when apple was awesome and then wasn’t and now we all have iPhones… Innovators innovate, ebb and flow, ebb and flow.
And rails is merb is rails, and you never know what the future holds. Buckle up… I’m just sayin’…
Progress is impossible without change, and those who cannot change their minds cannot change anything.
–George Bernard Shaw
Semantics Matter (or I finally get it…) September 1, 2008
Posted by stochasticresonance in Puppet.Tags: Awesome, Golden Image, Linux Plumbers Conference, Puppet, reductive, Semantics
2 comments
Silence is better than unmeaning words.
-Pythagoras
Over the time I’ve been programming, I’ve come to value certain things in a code base. Without going into too much detail (which will probably be its own post soonish), I value code that is easy to understand and manipulate.
The first level of understanding, which is facilitated by the style and organization in a code base is ‘What’. If I can look at code and mentally map ‘What’ it is doing, I start to get a level of productive joy. I can’t get that if I’m trying to sort out which branch of the if-else plinko, meta-scrambled self.foo or side effect driven development is actually getting executed at any given moment. ‘What’ is really really nice.
A higher level of understanding code is ‘Why’. ‘Why’ is more subtle, but orders of magnitude more powerful than ‘What’. ‘What’ is a technique, ‘Why’ is the purpose, the driving principle. Understanding ‘Why’ gives flexibility and options to ‘What’. (Unfortunately, most code does a poor job of conveying ‘What’, let alone ‘Why’, but that is a topic for another day.)
Which brings me to ’semantics matter’, which is something I’ve heard Luke say over and over when talking about Puppet. When I heard him before, I just nodded and thought he was talking about nifty Puppet language features like ‘after’ and ’subscribe’ for managing relationships between services and the underlying packages and config files, because that was what he was using as the example. I was understanding the ‘What’ level.
You think I would have figured this out faster after listening to Luke rant about it so much, but the whole ’semantics’ thing didn’t click until a discussion with Teyo about preparing for his ‘Golden Images’ talk at Linux Plumbers Conf.
Do not make a golden image...
Puppet let’s one model system configuration with code. Just like any other language, the ‘What’ and especially the ‘Why’ can be made apparent if the code is organized in certain ways and/or if one shares certain metaphors with the original author.
Until quite recently, I was having a hard time understanding why rebuilding virtual images with Puppet was superior to just versioning working images. I mean I heard the words, but in my mind I was questioning the practical difference. In one case you start with a base image, get everything set up and save the working copy, in the other you start with the base image and let puppet build it up. I kept thinking to myself, what is the difference, both solutions end up in the same place, right?
Being afraid to turn off real machines where you have no idea what is running, because there might be some critical cron job that matters on the third Tuesday of the month is one thing… (this happens, for real, some of you know this is true, someone reading this works at places like this right now, guaranteed), but once everything is virtual and running what you want, what’s the harm of just making images?
The difference is the potential to encode ‘What’, and if your code is sensibly organized, ‘Why’.
I was only seeing the static state of the working system. What if you want to change things? If you have working images, you have to reconstruct ‘What’ by discovery, good luck with ‘Why’. If you are lucky, it was you that set up the systems and it wasn’t over 6 months ago. The ‘What’ and ‘Why’ were apparent to someone, potentially you, when the systems were first set up, but now you just have this bucket of bootable bits that ostensibly does something. If it isn’t working, or there is a need to change something significant, the choice is poking around the bucket of bits until the new ‘What’ is in place or starting over with a new ‘Why’ that is lost as soon as the new image is finished.
If Puppet is building your services, ‘What’ and ‘Why’ can be recorded, clarified, recovered and manipulated. Version control becomes straight forward, manageable, and transparent. Services can have clear definitions and relationships. So obvious… can’t believe it took me this long to ‘get it’…
How many 500 MB images do you want to version? Can you make any sense of the diffs? Really? Seriously?
A Joining of the Tribes July 9, 2008
Posted by stochasticresonance in Puppet, ramble.Tags: Developer, Puppet, Sysadmin, Tribes
9 comments
Forgive him, for he believes that the customs of his tribe are the laws of nature!
-George Bernard Shaw
I’ve spent the last decade involved in software development on some level.
During that time, I’ve built things with Fortan, Java, C/C++, and recently Ruby at the core with Tcl, HTML, CSS, Javascript, XSLT, and SQL among other things as adornments. Never really did much Perl and as a result I suck pretty bad at regular expressions, especially by sysadmin standards (which will become more relevant in a minute).
Can I get some WiFi around here?
I was a ‘Developer’. I had a tribe. Not a LISP druid or a kernel hermit, who tend to be solitary creatures, but a ‘yes, I can do that’, Linux-loving, little-bit-of-everything, do-it-for-the-team developer. (I used to think .Net stormtroopers were my natural enemy, but I’ve opened my heart and learned how to love. I digress. . .)
Parallel to the ‘Developer’ tribe in most organizations, often with a semi-antagonistic mutual dependence, there was always another tribe: ‘Sysadmin’. When Developers and Sysadmins got together, it sometimes felt like the dwarfs and high elves forced to work together by necessity. (I’ll let you workout which is which.)
But something is happening, something is changing. Part of the change has to do with clouds and what utility computing enables, part of the change has to do with the scale that successful web applications must account for and perhaps part of it is that it’s just about damn time. Sandwiched between all these forces, and perhaps in part as a catalyst, is a little open source project with big hopes and dreams: Puppet. (Or maybe I just think about Puppet too much)
All evolution in thought and conduct must first appear as heresy and misconduct
- G.B. Shaw (two for two)
Which brings us back to the tribes… One of the recurring themes at the Velocity conference on operations and web performance was that in this world of highly available, scaled and performant web applications, developers have to think about operations and admins have to think about the applications.
Throwing tools like Puppet into the mix (maybe with a little help from kickstart, fai, PXE booting or a request to EC2) where one can express infrastructure as code and the whole thing goes to another level.
A Reductive Labs client (who shall remain nameless, but has a kick ass Indian developer who was born in Canada, sucked at hockey and should probably give it all up to become a comedian) did an on-site Puppet training about a year ago, and Puppet has become such a part of the development culture that the developers are required to write the Puppet classes that will manage their applications. If there is an operational issue with Puppet managing the application, it is opened as a bug against that code. How cool is that?
Operations is development. It’s going to happen. . .
Some lines are being drawn, you can be a ‘Developer’ who understands not only the bits and algorithms but also the way those things need to behave across racks of servers (or virtual machines) or you can work on that little internal business rules engine. Or you can be a ‘Sysadmin’ who can think about what it takes to automagically scale an application to 100s or 1000s of servers, or you can change tape and plug in cable. Which tribe are you going to be in?
Still have I borne it with a patient shrug, for sufferance is the badge of all our tribe.
-William Shakespeare
And when we all get together to build something incredible and amazing, please don’t hold my feeble RegEx fu against me. (you can tease me a little, I deserve it)
Perfunctory Introduction March 23, 2008
Posted by stochasticresonance in Agile, Puppet, Ruby, ramble.Tags: Agile, Programming, Puppet, Ruby, Software
add a comment
I should welcome myself to web 2.0 or something. . .
Some people might consider me somewhat a technologist but that is misleading and superficial, at least in my opinion.
I’m fairly decent with technical things and thankfully that has allowed me play with some really cool stuff and to cash some checks to feed my family, but I have other interests and abilities involving art, communication, culture, athletics, food and the human condition just to start the list that extends into the horizon.
I think that makes me better at technology, but maybe it just keeps me from being bored
Living in Salt Lake City has also given me the opportunity to absorb Agile software development philosophy and practice from close to the source. Alistair Cockburn’s Agile Roundtable is an excellent resource for anyone who wants to drink from a well of creative insight. I’ve also been influenced by the local XP community, specifically Zhon Johansen.
I’ve recently dedicated myself to building a life for my family around an Open Source software project called Puppet. (crazy, I know) Puppet was conceived and written primarily by Luke Kanies, after working for years as an operational sysadmin and then as a system automation consultant. I believe Puppet represents a significant step forward in system management. I am not alone.
Puppet is written in Ruby, which is a pleasure to read and write, at least after years of primarily C++ and Java. (with a smattering of bash, python, perl, tcl, matlab and javascript thrown in for good measure) Ruby (and Puppet) also awoke a latent interest in functional languages and declarative constructs.
This blog will capture my thoughts and observations, my trials and tribulations, both past and present, concerning how technology and people come together to create value and opportunity. Maybe it will be useful or amusing to someone else. . .
Sometimes I might just rant 
