Before I could enter the world of Chef I needed to at least get a handle on Ruby which is the language used to write the recipes needed (I’ll explain a little about how Chef hangs together later in this post).
If you’re used to C# or Java then Ruby shouldn’t be that scary as it’s an OO language and treats everything as an object and is very familiar i.e. there are classes, constructs and the usual OO suspects.
If you are going to get to grips with Chef then it helps to have some OO programming skills. Powershell is a good starting point though for those starting from windows systems management as it treats everything as objects so the concepts should not be that hard to get used to. The good news is that it is possible to use Powershell with Chef which I will cover in a later post in this series (you still need to have a basic familiarity with ruby though sorry about that J ).
I found reading Ruby was all about getting my head round the semantics of the language.
Ruby does seem to be a handy language to have a smattering of familiarity with as it seems to pop up all over the place these days so the effort involved in getting to a basic level of understanding is not wasted whether you’re going to use Chef or not. I would suggest having a read of The little Book of Ruby to get a basic familiarisation. Needless to say there is a bigger more extensive version of this e-book J
The other concept I needed to get my head around was RubyGems . This is a package manager for Ruby. It provides a way to manage Ruby libraries and applications. I haven’t really had time to really get to grips with this aspect beyond what I needed to install chef but it’s on my list of things to do.
There are also Language specific versions of Ruby JRuby for Java and IronRuby for .NET but for this exercise I decided to stick to vanilla Ruby. I had enough new things to learn without getting distracted and I do really want to get to the end of this series of posts in the near future.
I had to prepare my workstation for Ruby use and thus chef use as ideally I wanted to use it to write any recipes and upload changes to the Chef Server repository from there.
The first thing you need to accept is that window is a second class citizen so I anticipated getting my workstation (windows 7 pro) configured properly was not going to be trouble free (plus I’m just getting to grips with ruby) .The description below of how I got to a working workstation has admittedly missed out some of my pain and blind alleys I went down but will mean anyone else following along will have an easy time of it .
To prepare my workstation I first installed Ruby 1.9.2-p0 from the Ruby Installer for Windows Download page
I then had to install the DevKit from the same location following the instructions from here to install it.
I am going to be using the OpsCode platform for my Chef server (see later in this post) I thus followed the instructions from chef installation on windows with slight modifications.
| Modifications: Make sure you install rdp-ruby-wmi not ruby-wmi and you do not need the win32-open gem if you are using the same version of ruby as I am. gem install rdp-ruby-wmi windows-api windows-pr You also need to modify the file : C:\Ruby192\lib\ruby\gems\1.9.1\gems\chef-0.9.12\lib\chef\mixin\command\windows.rb so it doesn’t barf as it will be trying to include the win32/open3 gem rather than the open3 gem #require 'win32/open3' require 'open3' |
I verified that the Chef Client had installed successfully by running chef-client –v
Then I created my first chef client using the last step from chef installation on windows
chef-client -c c:\chef\client.rb
I then installed & configured git as described in the Setting Up your User environment . If using the OpsCode platform it’s optimised to use git. Even if you decide not to use the OpsCode platform having an appropriate repository is a must have anyway (Luckily I had git on my list of things to look at, this just means I’m looking at it a bit earlier than anticipated).
I checked I could connect to the OpsCode Platform using knife
C:\Users\grace\chef-repo>knife node list
[
"GraceDev"
]
And my first node can now be seen from the opsCode Console
Now is a good point to have quick look at the chef architecture:
Chef itself consists of a number of components a high level overview provided by Opscode is shown below. The individual components are described on the OpsCode site (I would suggest having at least a quick scan of this page as I reference some of the definitions later on)
Chef comes in several flavours:
Chef-solo is a standalone version of Chef that runs locally on your node. All the information and cookbooks required to configure the node have to be present on the local disk.
Chef-client is a Chef agent that, like Chef-solo, runs locally on your nodes. But it connects to a Chef Server to be told what to do on the local node.
The Opscode Platform is a highly available, scalable Chef Server in the cloud .This is the flavour I’ll be using in conjunction with Chef-client.
The diagram below pulls out some of the components that we will be getting used to if you stick with me and the journey.
Nodes are the systems you are managing with Chef and the Opscode Platform. Nodes are typically single servers or VMs.
Anyway back to finishing of preparing my workstation for using the OpsCode platform. From the console you can see my workstation as I showed above, but when you click on it you can see that there is the fun stuff to be getting on with next.
This sets the scene for the next posts in this series where I hope I’ll be able to describe how I used Chef to manage an ec2 estate by exploring the use of cookbooks, instantiating nodes etc.