Dissection of a Chef Recipe or two for windows

Working with chef one of the first things I needed to do was get to grips with the semantics of ruby.  I did a bit of speed reading, did a few simple ruby programs and I keep a copy of the little book of ruby handy for reference purposes so am becoming more comfortable with that.

What I found though is that it wasn’t problems with getting to grips with ruby and I’m definitely a newbie there but the actual understanding of the Chef recipe DSL. I had a look at the wiki and although it does give some guidance I was thinking that the best way to help someone get started quickly was to walk through a couple of example recipes.

There is a fair amount of information on using Chef with Linux targets so I’ll focus on using Windows as the target as I believe Chef has as much to offer the windows system administrator as it does for Linux sysadmins.

Before you start writing recipes the first thing you need to understand is the anatomy of a cookbook

Taking the definitions from the Opscode Wiki:

Cookbooks contain:

  • Attributes that are values on Node to set default values used elsewhere in the cookbook.
  • Definitions that allow you to create reusable collections of one or more Resources.
  • Files that are transferred to your Chef-administered machines via Cookbook File resource.
  • Libraries that extend Chef or provide helpers with Ruby code.
  • Recipes that specify Resources to manage, in the order they should be managed.
  • Lightweight Resources and Providers (LWRP) that allow you to create your own custom resources and providers.
  • Templates that are rendered on Chef-configured machines with your dynamically substituted values. Think config files on steroids, then read ERB templates.
  • Metadata that tells Chef about your recipes, including dependencies, supported platforms and more.

Cookbooks are arranged in the following folder structure:

attributes/

defintions/

files/

libraries/

metadata.rb

providers/

README.rdoc

recipes/

resources/

templates/


Well I don’t know about you but as a newbie based on the above it’s a bit daunting to try and understand how it all fits together and hunting through the various pages on the Opscode wiki to understand can be slightly frustrating to say the least so I hope a walkthrough of a few simple recipes will help you get started.

Example 1:

#

# Cookbook Name:: myapp

# Recipe:: deploymsi

#

# Copyright 2011, @devopscloud

#

# All rights reserved – Do Not Redistribute

#

msifile = File.basename(“myapp.msi”)

dir = “buildoutput”

drive=”c:”

msifiledst = “#{drive}\\#{dir}\\#{msifile}”

execute “install #{msifiledst}” do

command “msiexec /qn /i #{msifiledst} TARGETENV=DEV”

only_if { File.exists?(msifiledst) }

end

This example does what you think it does it installs an MSI on the target node.

How does it work:

Firstly we define a number of variables to allow us to identify the msi.

All the grunt work is defined in the execute resource:

execute “install #{msifiledst}” do

command “msiexec /qn /i #{msifiledst} TARGETENV=DEV”

only_if { File.exists?(msifiledst) }

end

The resource  type is: execute.

The resource name is : install #{msifiledst} = Install c:\buildoutput\myapp.msi

It calls the command prompt and then runs msiexec but only if the msi actually exists which is what the only_if (File.exists?..  bit of the recipe does.

Tip  the ‘\\’ to allow you to  use ‘\’  not an issue with Linux nodes but useful when working with windows nodes.

Building upon the above simple example we’ll now introduce something new in the next example:

Example 2:

#

# Cookbook Name:: myapp

# Recipe:: deploywebapp

#

# Copyright 2011,  @devopscloud

#

# All rights reserved – Do Not Redistribute

#

msi = File.basename(“myWebapp.msi”)

dir = “buildoutput”

drive=”c:”

dst = “#{drive}\\#{dir}\\#{msi}”

template “C:/chef/tmp/appool.ps1″ do

source “appool.ps1.erb”

end

execute “install #{dst}” do

command “msiexec /qn /i #{dst} TARGETENV=DEV”

only_if { File.exists?(dst) }

end

execute “updateappool” do

command “c:\\Windows\\System32\\WindowsPowerShell\\V1.0\\powershell.exe c:\\chef\\tmp\\appool.ps1\””

action :run

cwd “c:/chef/tmp”

end

This recipe installs an MSI as in example 1 but it then runs a powershell script that makes modifications to the appool. This recipe introduces the concept of templates. Templates are stored in the templates folder of your cookbook and stored as .erb files. In this example the erb file contains powershell script. So what does these two line mean?

template “C:/chef/tmp/appool.ps1″ do

source “appool.ps1.erb”

This essentially equates to the following:  copy the   file appool.ps1.erb  to target node to the folder c:/chef/tmp  and name accordingly.

Later on in the recipe we actually run the powershell script. Easy huh   Smile

The key thing here really is that all the Powershell you inevitably use as a windows administrator is still reusable and I haven’t even started talking about providers as yet.

The examples above are simple and not exactly robust but they do stuff which is all we want chef recipes to do really.

Recipes are quite a huge topic and I have barely  scraped the surface with these two  simple examples.

About Grace Mollison
Photography, diving, archery, films, theatre, travel and Technology are my main passions plus basically being a decent human being just because it's the right thing to do

3 Responses to Dissection of a Chef Recipe or two for windows

  1. jimmyp83 says:

    So I’m just getting into trying to configure servers for my web apps solely through powershell, and being new to powershell it’s certainly tricky….

    But I don’t see how this is going to help? I’ll still need to write the powershell right?

    What are some possible advantages of chef on Windows?

    • Hi ,
      I’ll do a post detailing why you should use configuration management tools so keep an eye out for that. I suggest using power shell because it makes sense for managing windows servers you could stick purely to using the Chef Ruby DSL but why waste an awesome scripting tool like powershell? If you decide to go down a managed route like RightScale they have ready made Windows recipes anyway so it may be worth exploring what they have to offer.

  2. Pingback: Top 10 reasons for having a Configuration management solution « Devops and the Public cloud

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: