When Amazon announced it’s Authoritative DNS service, cheekily named Route 53 a few things popped into my head immediately. First, this should be a much easier way to get the effects of Dynamic DNS which we were currently leveraging DNS Made Easy for. Secondly, I wonder how much of a performance boost using it might provide.

Amazon’s entire model for providing services through AWS is predicated on the idea of distributing load. They have several availability zones for computing and storage, they have a Content Delivery Network (CDN) which will deliver your static web content to users at blazing speeds because it’s coming from a data center as close to them as possible.

So why wouldn’t that persist to their new DNS offering?

Turns out I wasn’t the only one wondering this. Brant recently revealed some performance and stability findings in a blog post about Route 53.

How does it improve speed?

With the increasing focus on the speed of websites, everything is getting optimized. Image sizes, whitespace in your CSS and JS files, the number of additional files you load, etc. Each of these techniques strips a millisecond or two off of the time it takes your browser to find and download all of the components which make up the page you’re looking at.

But there is another facet of browsing the web which takes time, the DNS lookup. See, your browser has no idea which server to send the request for “www.google.com” to, since servers are identified not by their domain or hostnames, but by their IP address. DNS is used to translate the hostname you enter into your browser, into an IP address which can be used to actually locate the server.

Of course, this lookup takes time, and if you have lots of components on your page, perhaps even some from other servers, this time could add up.

Google launched a recursive DNS service for this some time back. By using the recursive (think “cached”) servers you could drastically improve your DNS lookup times which is demonstrated quite well in this FAQ for the service.

The downside of course is that you only get the benefit if you change your computers network settings to use the Google DNS servers, and since the DNS data is cached it can lag behind when changes are made to the authoritative DNS records.

On the other hand, if you use Route 53 as the authority for your DNS records, every internet user will benefit from the performance boost of making a DNS request to a much closer (and faster) DNS server. Sweet!

Last week, I told you how you can use Amazon’s Identity and Access Management (IAM) offering to better secure the services and tools you use to manage your AWS environment with service accounts. Well on February 14th IAM got that much sweeter when they opened up the ability for IAM users to login to the AWS Console.

In the previous blog post we covered how to create users and get an AWS Access Key ID and AWS Secret Access Key to use with the AWS API. Well the IAM also offers the ability to allow those users to log into the AWS console.

This is significant because it allows you to give restricted access to users through the AWS console. So you could have a user who is only able to launch new EC2 instances, but can not stop or terminate them. You can have another user who can create EBS snapshots, but can not delete them or do anything with EC2 instances. You can officially delegate a lot of responsibilities to other users who do not have to know anything about the AWS API in order to manage objects in your AWS environment.

Naming your AWS account

The first step to allowing IAM users to login is setting an alias for your AWS account. Technically, this step is optional since you can use your account number to access the AWS console login for your account, but by providing a nickname for your account, you’ll make it much easier for your users to remember. It’s the difference between https://123456789012.signin.aws.amazon.com/console/ec2/ and https://nickname.signin.aws.amazon.com/console/ec2/. Best of all, it’s just a simple oneliner if you already have the IAM CLI tools installed.

$ iam-accountaliascreate -a nickname

Enabling login for a user

Once you’ve created the account alias to make logging in much easier for your users, you’ll want to grant them login permissions. In this example, we’re making the assumption there is already a user named ryan.geyer.

$ iam-useraddloginprofile -u ryan.geyer -p supersecretpassword

That’s it, now you can direct the user to https://nickname.signin.aws.amazon.com/console/ec2/ and they can login with their own username and password. Once they’re logged in, they will only be able to access the AWS objects defined by the IAM policies for the groups to which they are assigned.

I’ve been making use of Amazon Web Services (AWS) quite a lot lately. In order to really enjoy the benefits of Cloud Computing (automation, agility, etc) I’ve had to use a number of tools to interact with AWS on my behalf.

All of these external tools ask for the same thing to enable them to make AWS API calls, your AWS Access Key ID, and your AWS Secret Access Key. Common practice is usually to just hand over the main set of these credentials, but there is a better (more secure) way, using Amazon Identity and Access Management (IAM).

What is IAM?

In September 2010, amidst very little fanfare (as is the Amazon way) Amazon released their Identity and Access Management offering. To this day, the IAM is still technically in Beta, but it is stable tested offering.

As of this writing, you can only interact with the IAM via the API. Amazon also makes a nice set of command line tools available which work equally well in Windows or *nix (including mac OSX) environments.

IAM is a set of tools which allow you to create user groups with defined security policies, as well as unique AWS users with their own credentials who can be assigned to those groups.

This is an extraordinarily powerful tool for managing your use of AWS. No longer is every request to AWS made as your super user account, but you can assign particular users their own credentials to more easily control and audit what they’re doing in your AWS environment.

This concept extends to services and tools you might use to manage your AWS environment as well. Rather than handing over your super user credentials, you can create a unique key and secret pair for each management tool you use, effectively isolating that service.

Now it’s true that you can already create many sets of credentials, and invalidate old ones using the Security Credentials link off of your account management in AWS, but these are all still super user credentials. They still have the same level of access (full control) and any audit information for objects created by those keys show up as the super user.

With IAM you can restrict a set of credentials using an AWS policy, to only the specific AWS API calls you want to allow that user to make, and the objects they create or interact with get audit data showing their username. This makes it possible to know who (or which service) did what to objects inside your AWS environment.

Do you use a tool like S3 Fox to manage the contents of your S3 buckets? You can create a unique user and policy which allows access only to S3 calls, or even narrow it to a particular bucket, or filenames!

So, how exactly do you do that? To best explain it, I’m going to walk through the steps necessary to create a new group and user, and then use those new credentials with RightScale my favorite tool for automating AWS.

Prerequisites

Before we get started, you’ll need to go ahead and download the IAM Command Line Toolkit (IAM CLI) and add the bin directory to your PATH environment variable. Once you’ve done that, you’re ready to follow the steps below.

Creating a Service Account

The first thing we’ll want to do is create a security policy which we will apply to the service account. Since RightScale helps to manage nearly every aspect of the AWS, the policy document is going to be quite simple, and will grant full access to all services.

Don’t be too intimidated by the creating policies for more restrictive cases though, the Policy Generator makes it easy.

So lets write out our full control policy somewhere to disk so that we can use it later.

{
  "Statement": [
    {
      "Action": "*",
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

/tmp/fullcontrol_iam_policy.json

With that out of the way, lets create a new IAM user group named RightScaleDash and upload our new policy file using the IAM CLI tools.

$ iam-groupcreate -g RightScaleDash
$ iam-groupuploadpolicy -g RightScaleDash -p FullControl -f /tmp/fullcontrol_iam_policy.json

Then, we create a new user named rsdash and assign the new user to the RightScaleDash group. Note the -k parameter, this instructs the IAM CLI tools to create a new AWS key and secret pair.

$ iam-usercreate -u rsdash -g RightScaleDash -k

Some things like signing your custom Amazon Machine Images (AMI’s) require an x.509 certificate, and RightScale has a place for entering this type of “credential” as well, so we’ll create a self signed one for this example.

$ openssl genrsa -out iam.key 1024
$ openssl req -new -key iam.key -out iam.csr
$ openssl x509 -req -in iam.csr -signkey iam.key -out iam.pem
$ iam-useraddcert -u rsdash -f iam.pem

That’s really all there is to creating your service account. Once you’ve set things up you aren’t locked in to your choices either. At any time you can go back and add or remove security policies using the IAM CLI.

So now that we’ve set up our new user, let’s configure RightScale to use it.

RightScale Configuration

These steps are very easy, I’m going to describe how you would change the credentials for an existing RightScale account since adding your credentials for the first time is handled by the RightScale setup wizard.

Once you’ve logged in, hover over the Clouds menu, then under AWS Global click the Credentials link.

On the next page, click Edit then enter the newly created credentials into the appropriate fields.

That’s it, you’ve just configured your RightScale account to use it’s very own AWS credentials!

You may (or may not) have noticed that there has not been much activity here over the past couple months. There are a number of reasons for that, but I’ll spare you the excuses. I’m here to tell you that things are about to change.

There are posts about parenthood and child rearing epiphanies from the lovely Marlena (my wife) scheduled for every Wednesday and Friday from now through just about the end of April.

I’m digging back into my drafts and fleshing out previous trains of through, and starting some new cloud computing projects which I’ll be excited to share. I’m also hope to be finding time to work on, and blog about my Cadillac restoration project.

So, if you were anxiously awaiting every new post here, sorry for the mini hiatus. But we’re getting things back in gear and should be producing some interesting new posts on the regular!

You’ve heard the colloquialism that “Time is Money” right? Perhaps you agree, or perhaps you just scoff at the sentiment.

I, for one, have given this particular little proverb a good amount of though. So much so, that I usually work out how much something will “cost” me for my time before I get serious about diving into it.

See, I’m a DIY kinda guy, I like to work on my own cars, I like to build DIY versions of retail products, etc. But before I take something on I usually try to break down exactly what it’ll cost me both in time and money.

DIY R-Strap

For those of you who may not know, I fancy myself something of an amateur photographer, and I tend to carry my dSLR around with me a lot.

I discovered very quickly that the standard neck camera strap is just downright cumbersome, and it often flops in front of the lens at the most inopportune times.

I could throw it over my neck, and under one arm. But, I’m a bit of a big guy too so that just results in a strap that’s too short for me to get the camera to my eye.

As a result, when I discovered the BlackRapid R-Strap I instantly fell in love.

Of course, being the DIY guy I am, I immediately went looking for DIY instructions for it, and I found plenty without looking too hard.

Now comes the breakdown. An RS-4 (the model that seemed most appropriate for me) costs around $60 all things considered. Most of the DIY instructions show parts lists that add up to less than $10.

Sweet deal right?

Well, not exactly. See, I easily spent two hours looking at all of the different DIY plans and devising my own “best of” from those.

Then, since I didn’t have any of the parts on hand I’d have to go to a home improvement center for the hardware, and possibly a different store to get some nylon strapping or strap from an existing bag. Figure on another hour or so driving to and from, and wandering around.

Then, once I had all the materials together building my strap, testing, adjusting, rebuilding, and cleaning up could easily take another two hours.

Assuming that I don’t have to drive to any other stores to buy materials I forgot, or later decided that I need to improve my design I’ve already spent five hours.

$60 (Price of retail R-Strap) – $10 (Price of DIY parts) = $50 / 5hr = $10/hr

All told, I’d be paying myself $10/hr to build my own R-Strap. Then, what are the chances that I’d end up with a product that is better (or even as good) as the mass produced, tested, and redesigned product?

So.. Not better, not really cheaper..

I bought an RS-4 from a retailer.

Choosing how to spend

Sometimes, you can look at a task and realize that it’d cost you WAY less to pay someone for a particular product or service, but you still choose to do it yourself.

You do this usually for the non monetary benefits you receive.

Or, perhaps you could never hope to spare that much cash, but you’re willing and able to spend the time.

For me, working on cars is where I choose to spend the time, rather than the money.

Sure, most times I probably take two to three times longer to fix or modify my car than a professional would, and I know I earn more hourly than the shop would charge. But I get a sense of satisfaction in my work, the knowledge that it’s done “right”.

Besides, working with my hands is cathartic given that I sit on my duff behind a keyboard all day.

Mind you, there are times that I decide that the cost of time is too great to complete a project, and I’ll gladly pay a professional to take care of it. This is particularly the case for the cars which we depend upon for transportation.

Billable hours

The other thing to consider is. You can’t possibly bill for your every waking hour.

If you’ve got the time to spare, and you can’t monetize it, then you’re wasting a resource if you’re not doing something you enjoy (recreation) or being productive.

If you ask me, time is money in a very tangible way, so make sure you’re making the most of both.

Remember, if you’re going to spend more time on something that it’d be worth monetarily, make sure you’re doing it for the right reasons.

If you’re looking to start a blog to promote your business, or boost your presence on the internet, you’ve probably heard of WordPress.

You may also have heard about the benefits of hosting your own instance of WordPress, but you’re intimidated by the idea of setting up and maintaining your own server, or trusting your business to a shared hosting solution.

What if I told you that I’ve got a solution that’ll let you run your WordPress blog, on your very own server, with automated backups and disaster recover, completely free?

Wait wait! I know it sounds too good to be true, but don’t leave just yet, hear me out…

Amazon AWS Free Tier

First, let me be straight with you. When I say “free” I’m referring to the free tier of Amazon’s virtual computing and storage platform AWS.

This free tier allows you to run their smallest instance free for one year. In practice you actually end up paying them a very small sum (around $0.12 average for me thus far) each month for transfer costs to run a low to medium traffic blog.

After your first year of free usage has expried, it’ll start to cost around $15 per month to keep using the same size instance.

Managed by RightScale

You may be looking at AWS and thinking that setting up your own server, and keeping it running and backed up would be a daunting task, and it can be. That’s where RightScale comes into the picture.

RightScale offers a Free Developer Edition that gives you access to their shared library of ServerTemplates.

In that library is one little gem that I published, expressly for the purpose of running a server that hosts my blog, a few sites for other domains I own, as well as all of the email traffic for my various domains.

In fact, you’re reading this right now from a server running from this ServerTemplate.

Full Disclosure

Before I give you the skinny on how to start using these tools to host a WordPress blog on your own virtual server, a few warnings are in order.

I am using Opscode Chef to configure the server. Chef support is currently in Beta on RightScale, meaning that they do not recommend you use it to configure and manage “Production” servers.

It also means that there can be some hiccups when you’re launching and configuring a server with this ServerTemplate.

So, don’t be surprised if the first time you launch your server, it doesn’t work. Try launching a second time.

Lastly, I can’t take any responsibility for any loss of self esteem, data, productivity, or sanity. You have been warned.

That said, I’m using this server to run the very blog you’re reading, and I haven’t had any significant glitches yet. RightScale is working as we speak to improve their support for Chef and things will only get better from here.

Haven’t scared you off yet? Okay, good.. Here we go..

20 Minute Quickstart

The RightScale management tool, and this ServerTemplate offer all sorts of cool functionality which we can explore later, but if you’re in a hurry to get started here’s all you need to know.

1. Go sign up for an AWS Account
2. Sign up for a RightScale Free Developer Edition
3. Enter your AWS credentials into the RightScale dashboard using these directions
4. Browse to my All-In-One ServerTemplate and click “Import”



5. Click “Add to Deployment”



6. Pick the AWS Cloud closest to you and click “OK”
7. Change the “Instance Type” dropdown to “t1.micro”, and select the “default” Security Group from the dropdown. You can also provide you server a name, then click “Add”



8. Click the “Play” button, provide inputs for the Database Administrator password, Postfix DB password, and EBS volume size, then click “Save and Launch”




And now.. We wait.. Until the instance is up and running..

9. Click on the server’s nickname, then navigate to the “Scripts” tab
10. Run the “rjg_utils::aio_ebs_volume_enable_continuous_backup” operational script to make sure your server is backed up daily
11. Run the “app_wordpress::deploy” operational script to setup WordPress for your domain



12. Navigate to your websites URL (we used http://ec2.ryangeyer.com in this example) and setup your WordPress preferences



13. Start Blogging!

What’s Next?

That’s really all there is to it. As I mentioned the ServerTemplate does a number of other cool things, which you can read about in it’s description.

The best part is that because this ServerTemplate is what I use for my own blog and email hosting duties, you can be sure that I’ll keep it up to date, secure, and be adding features fairly regularly.

Drop me a note

If you followed these directions, or if you’re using this ServerTemplate, or if you’re having trouble, by all means drop me a note in the comments here.

I’ll be happy to answer any questions I can, and I’d love to get a sense for how many people are out there running servers based on this template, it’ll keep me motivated to publish more stuff in the public ServerTemplate library!

If you’re like me, every time you get an invitation for one of the RightScale webinars you’re super excited and sign up right away, anxious to see what they have prepared. Perhaps like me you also manage to forget, and the reminder from your calendar application of choice doesn’t pop up.

Fortunately, for the chronically late but still insatiably curious, RightScale has published all of their public webinars as well as talks from their most recent User Conference on a free iTunes podcast channel!

So to take advantage of the full wealth of information that’s regularly disseminated, point your browser or iTunes here. Then absorb the information at your own pace.

They just wrapped the webinar “Managing RightScale on RightScale” which I caught the last half of. It should be posted on the iTunes channel soon so I can catch the first half that I missed!

It’s been a bit over a year since I dropped my Nikon SB600, rendering it useless. When it happened I was able to disassemble the flash and identify the part which was damaged, but being a relative layman when it comes to circuit board components I didn’t know what to replace it with.

Apparently though, I wasn’t the only person to damage their SB600. Nor was I the only one who popped out the jewelers screwdriver and did a post mortem. David identified the part as a small inductor, and even provided the digikey part number that was the best fit to replace it.

Armed with the knowledge that someone else had repaired their strobe which suffered a similar fate, I felt empowered to take on the project myself. I ordered up half a dozen of the component from DigiKey and started psyching myself up for the project.

The repair

Now, I’m a pretty technically adept dude, and I’m not terrified to use a soldering iron. That said, I’m also not an electronics wizard so I did approach this project with some trepidation.

It took me a while to get the remnants of the old inductor off of the circuit board. The components on this board are all surface mounted, and I do not have a hot air rework station, just a simple soldering iron with a fairly sharp tip. The inductor did finally yield to my persistence and patience though.

Soldering the new one on proved a tad more difficult though. I had only one soldering iron, so I could only heat one of the two contact points at any given moment. As a result the new inductor is connected, but one of the contact pads is actually elevated quite a bit on top of a glob of solder. A little amateurish, but it gets the job done.

Modz

Since I was going to have the flash disassembled again, and since I had recently read this little teaser over on strobist, I decided to improve my strobe at the same time.

My first attempt to complete this mod was a complete failure as I managed to reverse the trigger and quench leads. I should have looked at this and maybe I could have avoided that. The failure was actually fairly hard to detect. See..

Both the trigger and quench signals are just a short to ground, and the both happen in such quick succession (trigger to start the flash, quench to stop it after a specified time) that it all happened well within the sync speeds I was testing at (1/60 if I recall). So it looked like the trigger was working, but the quench was not, when in actual fact the quench signal was triggering the flash and it was just popping at near full power! Oops!

After going back in and connecting the 1/8″ stereo jacks leads to the correct pins, I was still getting the same issue. This time though, it seems I have a problem with continuity between the quench pin and my stereo jack.

Results

At the end of the day, I chose not to try to fix the 1/8″ stereo jack mod since I didn’t want to pop the flash open again. I’m quite happy with the repair, and while my mod wasn’t quite as functional as I had hoped, it does give me the ability to trigger my SB600 using my radio triggers easily.

You just finished adding a shiny new plugin to your Grails project, and build some functionality around it. You excitedly push it out to your deployment site and you’re greeted with a NoClassDefException. If this has happened to you, the complex and murky plugin dependency handling of Grails may be to blame.

The release of Grails 1.2 introduced a DSL for defining your projects external dependencies using Ivy, by convention, in your BuildConfig.groovy file, and the villagers rejoiced. Then, Grails 1.3 expanded on this successful design and allowed you to define your projects plugin dependencies in the BuildConfig.groovy file rather than having to run grails install-plugin. The villagers prepared a sacrificial virgin, declared Grails as their new deity, and began a holy war to convert the nearby settlers.

But things may not be exactly as they appear..

Straight from the Grails documentation we have this.

Grails features 5 dependency resolution configurations (or ‘scopes’) which you can take advantage of:
-build: Dependencies for the build system only
-compile: Dependencies for the compile step
-runtime: Dependencies needed at runtime but not for compilation (see above)
-test: Dependencies needed for testing but not at runtime (see above)
-provided: Dependencies needed at development time, but not during WAR deployment

So based on this you might assume you must specify all dependencies for each configuration individually, I certainly did. Suppose that you’re working on a project that has these plugins installed.

• fixtures-1.0.RC1.SNAPSHOT
• joda-time-1.1
• spock-0.4-groovy-1.7-SNAPSHOT

If you want the fixtures and joda time plugins loaded each time you do a compile, run-app, run-war, or war, and only include the spock plugin when you run test-app, you might assume your BuildConfig should look like this.

grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"

grails.project.dependency.resolution = {
  // inherit Grails' default dependencies
  inherits("global") {
  }
  log "warn" // log level of Ivy resolver, either 'error', 'warn', 'info', 'debug' or 'verbose'
  repositories {
    grailsPlugins()
    grailsHome()
    grailsCentral()
  }
  dependencies {
    // specify dependencies here under either 'build', 'compile', 'runtime', 'test' or 'provided' scopes eg.
  }
  plugins {
    build ':fixtures:1.0.RC1.SNAPSHOT',
      ':joda-time:1.1'
    compile ':fixtures:1.0.RC1.SNAPSHOT',
      ':joda-time:1.1'
    runtime ':fixtures:1.0.RC1.SNAPSHOT',
      ':joda-time:1.1'
    test ':fixtures:1.0.RC1.SNAPSHOT',
      ':joda-time:1.1',
      ':spock:0.4-groovy-1.7-SNAPSHOT'
  }
}

Notice the duplication across all configurations? In fact only the test configuration is different with the addition of the spock plugin. Intuitively this would make sense, even if a particular phase didn’t really require the plugin by including it you make sure all of the dependencies are available; better safe than sorry, right?

The problem is that these configurations interact with one another in subtle, and not clearly documented ways. In actual fact what you’ve done above is excluded all plugins from every phase but test. To achieve the desired result your build config would need to look like this instead.

grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"

grails.project.dependency.resolution = {
  // inherit Grails' default dependencies
  inherits("global") {
  }
  log "warn" // log level of Ivy resolver, either 'error', 'warn', 'info', 'debug' or 'verbose'
  repositories {
    grailsPlugins()
    grailsHome()
    grailsCentral()
  }
  dependencies {
    // specify dependencies here under either 'build', 'compile', 'runtime', 'test' or 'provided' scopes eg.
  }
  plugins {
    build: ':joda-time:1.1'
    test ':fixtures:1.0.RC1.SNAPSHOT',
      ':spock:0.4-groovy-1.7-SNAPSHOT'
  }
}

The scopes are in fact additive, so if you put all of your dependency declarations in the build scope they’re automatically included in all other scopes. In every other scope, by listing a dependency there it effectively adds it to that scope, and removes it from all other scopes. That’s why your deployed war file breaks.

Something else to look out for if you’re working on an older project which used Grails 1.2 or earlier. If you’ve used the grails install-plugin method of including a plugin in your project your application.properties file will list the plugins for your project. This method of listing dependencies, and the “new” dependencies DSL for Grails 1.3+ do not mix well, so be sure to stick to one or the other!

For the past few weeks I have been getting down and dirty writing Chef recipes for use in RightScale.

With Chef support still in beta on RightScale, and me being a complete Chef newbie it’s I’m still on the front side of the learning curve.

If you’re just getting started with Chef for RightScale, you might benefit from this quick start and some of the lessons I learned while getting started.

Mise en place

While you could just open up Notepad or TextEdit and start writing your Chef recipes, there are a few resources that will make the experience much more enjoyable.

Install Chef

The first thing you’re going to want to do is install the Chef Ruby Gem. This will add all of the libraries and binaries for Chef.

While we’re writing our recipes for use with RightScale we won’t need to worry about using the Chef Server, Chef Solo, or Chef Client, so don’t bother configuring any of those.

I’m developing on a Mac and the only suitable installation method seems to be using Ruby Gems to install. This mechanism should also work for most Linux and Debian machines which already have Ruby installed.

sudo gem install chef

Be sure that you run this as root, or with sudo or Chef will get installed at ~/.gem and won’t be in your $PATH or consequently accessible to other users.

Sharpen your knives

Now that you have all of the Chef goodies installed, you’ll have a binary named “knife”. The knife is a utility which we’ll be using as we develop our cookbooks and recipes which you’ll see later.

First though, we need to configure knife. Since we’ll only be using knife to act locally on our recipes and cookbooks we don’t need to give it legit values for a Chef server, but we do need to complete the configuration step to satisfy knife and prevent it from crashing when we use it.

To create a simple configuration file for knife, just run knife config, and accept all of the defaults.

knife configure
No knife configuration file found
Where should I put the config file? [~/.chef/knife.rb]
Please enter the chef server URL: [http://localhost:4000]
Please enter an existing username or clientname for the API: [rgeyer]
Please enter the validation clientname: [chef-validator]
Please enter the location of the validation key: [/etc/chef/validation.pem]
Please enter the path to a chef repository (or leave blank):
WARN: *****
WARN:
WARN: You must place your client key in:
WARN:   /Users/rgeyer/.chef/rgeyer.pem
WARN: Before running commands with Knife!
WARN:
WARN: *****
WARN:
WARN: You must place your validation key in:
WARN:   /etc/chef/validation.pem
WARN: Before generating instance data with Knife!
WARN:
WARN: *****
WARN: Configuration file written to /Users/rgeyer/.chef/knife.rb

You’re safe to ignore the warnings since they only pertain to actually connecting to a Chef server, which we won’t be doing.

That’s it for installing and configuring Chef if you’re using it with RightScale!

Prepare your pantry

Once you get going with Chef you’re going to need to store your cookbooks somewhere for RightScale to find them and run them.

RightScale will use svn or git repositories, as well as simply downloading a tar or zip file, but my personal preference is to use a git repository.

The quickest and easiest way to get started with git is to head over to github and sign up for a free account.

Once you’re setup, go ahead and create the repository we’ll be using for our Chef cookbooks, and note the SSH URL to your new repository. It should look something like git@github.com:<github_username>/<repo_name>.git. Write it down or keep the browser window open so you can reference it later.

Heat things up

Now that you’ve got your mise en place it’s time to get cooking for RightScale with Chef.

Create your repo

The first step is to get the file structure of your Chef repository setup. You could just take a look at an existing repository like the opscode cookbooks, or RightScale’s public repository and replicate it manually, but there is a better way.

Clone the OpsCode repo

OpsCode, (the folks behind Chef) have conveniently provided a public github repository that represents the skeleton of a fully operational Chef repository. You can clone this repository to get you started.

git clone git://github.com/opscode/chef-repo.git

Once you’ve cloned the skeleton repository, you’ll want to configure git to use the new github repository we created earlier. Here’s where you’ll use the SSH URL I told you to take note of. Substitute that URL where you find <ssh_url> below.

cd chef-repo/
git remote rename origin opscode-github
git remote add origin <ssh_url>
git remote rm opscode-github
git push origin master

Create cookbook

With the repository skeleton all ready, we’re going to want to create our first cookbook and add a recipe to it.

Creating a cookbook is our first chance to use our freshly sharpened knife, like so.

knife cookbook create my-first-cookbook -o cookbooks/

This should create a nice new cookbook skeleton directory at <path_to_your_repo>/cookbooks/my-first-cookbook.

With that done, let’s put our first recipe in the cookbook. Using your favorite IDE, create and save a file named helloworld.rb inside the new cookbook directory.

helloworld.rb

log "Hello World"

With the recipe created, we need to add it to our metadata file so that Chef and RightScale can know it’s there. Here’s a copy of our default metadata.rb file. The highlighted line is added to define the recipe we’ve added.

metadata.rb

maintainer       "YOUR_COMPANY_NAME"
maintainer_email "YOUR_EMAIL"
license          "All rights reserved"
description      "Installs/Configures my-first-cookbook"
long_description IO.read(File.join(File.dirname(__FILE__), 'README.rdoc'))
version          "0.0.1"

recipe "my-first-cookbook::helloworld", "My first recipe, prints Hello World to the RightScale dashboard"

We only have one more step before we’re ready to commit our new cookbook and recipe to our new git repository.

RightScale reads the metadata to determine which recipes are available in the repository, and which inputs are available for those recipes. The file that RightScale evaluates though is a json file named metadata.json.

The contents of metadata.json are effectively the same as metadata.rb, but take heart, you only need maintain the metadata.rb file, then convert it using another Chef command. To generate metadata.json from metadata.rb just run the following command.

rake metadata

You can run this command either right at the root of your repository, or inside each cookbook. If you run it from the root directory of your repository, it will convert all the metadata files in all of the cookbooks.

Now we’re ready to commit our repository and try out our new cookbook.

git add cookbooks/
git commit -am "Added my-first-cookbook and helloworld recipe"
git push

RightScale Configuration

I’m going to assume that you already have some familiarity with the RightScale dashboard, and creating things like ServerTemplates and RightScripts.

What I’m going to cover here are steps are necessary to start using Chef with your ServerTemplates.

Tell RightScale about your Repo

The first thing you need to start using your cookbooks in RightScale is to tell the RightScale dashboard where to find your repo. To do that, you need to create a new RepoPath in the designer.

When you’re adding the RepoPath, for the URL field, supply the “Git Read-Only URL” for your repository, and make sure to specify the path to your cookbooks as cookbooks.

Add your RepoPath to a ServerTemplate

Now that you’ve added your repo to the RightScale dashboard, you need to add that RepoPath to a ServerTemplate. To do that, open the ServerTemplate you want to run Chef cookbooks on, and click the edit pencil on the Repos tab.

Then select the RepoPath we just made, and click OK.

Add a recipe to your ServerTemplate

Our very last step is to add our helloworld recipe to a our ServerTemplate so that we can run it on one of our instances. Go back to the Scripts tab, and in the script category of your choosing, click Add Recipe and select the helloworld recipe.

From an instance running with the ServerTemplate we just modified, we can run the recipe, and see “Hello World” appear in the RightScale dashboard.

Tips & Tricks

As stated before, Chef support in RightScale is still in Beta. Because of this there are some gotchas to watch out for.

Sanity Check Recipe

If there are any syntax errors or anything else amiss in your repository, you’ll find that not just the cookbook or recipe which you’re working on is failing, but absolutely every recipe in your repo (or any other repo that’s part of your RepoPath) will fail with this super informative error message.

*ERROR> Chef process failed with return code 1

Of course, you can also get that error message if you have some other problem in the recipe you’re working on.

Because of this I find it useful to keep a “smoke test” recipe in my repo, and assigned to the operational scripts on my ServerTemplate when I’m doing Chef development. This recipe should be something simple that you know will always succeed, assuming that everything else is in order.

The helloworld recipe that we created in this exercise is actually a perfect choice for this purpose.

Taste Test

So there it is, everything you need to know to get started using Chef on RightScale condensed from my few weeks of experience. I hope it helps you get started configuring your server instances with Chef, which brings a whole new dimension of power and flexibility to the RightScale ServerTemplates.

I’m excited to see how Chef support progresses and makes it to production status.

If you’re hungry for more info, check out some of the early documentation available about using Chef in RightScale here.