Posts tagged ‘hosting provisioning’

Configuration Management: Jump into the Kitchen

Configuration Management is an old horse that rarely gets any loving outside of the Microsoft environment.

Generally it’s a mechanism that allows you to control the configuration and software available on machine but it’s usually clunky, brutally inefficient on the network and generally requires total control of the target machines.

Then along comes Opscode and opens up their Configuration Management Kitchen with Chef.  Chef is a lightweight approach to Systems Integration & Configuration Management (SI & CM for the light-hearted) built on Ruby/Rails/Gems that allows you to quickly deploy and configure software and services without requiring total domination.

I’ve had my eye on it for a while and with the Virtual Machine environments I’ve been working on for Symfony and Zend – I decided to dig in and give it a spin and I’m impressed; almost beyond words.

Chef depends on having Fully Qualified Domain Names up and running and can be a little quirky without them.

The installation instructions for the Chef-Server and Chef-Client are clear and concise and can be found here.

You start by installing the Chef-Server which provides the core back-bone to support your environment.  Once it’s up and running you have Chef running on Rails under Apache providing a web and REST interface for clients (or nodes in the Chef parlance).  Here you can view and control the attributes of a node, examine your configuration scripts (Recipes)  and authorise clients.  The GUI tools in the current (6.2) release are a little raw but functional and the coming 6.4 Release sharpens up the Web UI a lot (and brings with it a whole host of exciting features).  I setup the chef server on a stand-alone VirtualBox machine with 256 MB memory and a 3GB disk – which is working well for everything I’ve thrown at it so far.  You’ll need to login to the Web UI using OpenID and ensure you use the appropriate domain appended to your login – full details of the OpenID providers and their naming schemes can be found on the OpenID site here.

It can take a few minutes for the registrations to appear in the Chef Web UI.

Once you have the server up and running you’ll need to install the chef-client on a host.  Once up and running the client will connect to the server and register itself.  You’ll need to fire-up the Web UI on the server and authorise the client before you’ll be able to do anything more with the client.

Once it’s been authorised just run the chef-client again with:

sudo chef-client

When it completes you’ll see the information about the client in the Web UI in the nodes and status panels.

If you don’t authorise a client on the server then you’ll see a HTTP 403 error when you run the chef-client.

Now you have both the client and server up and running – you can get down to the real business of deploying something.

Open 2 SSH connections – one on the chef-server and another on the chef-client and start simply by following their quick-start guide on the chef-server and in a couple of minutes you’ll have your first chef-recipe complete.  Now just drop into the cookbooks folder and copy the quick_start cookbook to /srv/chef/site-cookbooks:

cd cookbooks
cp –R ./quick_start /srv/chef/site-cookbooks/

Now refresh the Web UI and open the Recipes Panel and you’ll see the quick_start recipe that you just created listed.

To apply the recipe to a node (your client) open up the nodes panel in the Web UI and double click on Recipes for it.  In Chef 6.2 you’ll get an awful textbox with the information for the node in JSON format.  Scroll down to the bottom and you’ll find the recipes entry – inside the [] put “quick_start” (include the “”) and hit save.

The end result should look something like:

“recipes”: [
” quick_start”
],

If you did it right you’ll see the page update.  Another minor issue in the 6.2 release is that if you didn’t update the JSON correctly you’ll see saving that’ll never complete.

All that’s left is to switch to the chef-client SSH terminal and get the client to update itself now with:

sudo chef-client

A few seconds later the client will find that it has a new recipe and install it.  On the client go to the /tmp folder and you’ll see deep_thought.txt from the chef-run J

Now this seems like a lot of effort to get a text file to appear in a folder – but it’s just as simple writing a recipe that installs MySQL, PHP, Redmine, Symfony or Zend Server.  But it’s not just about installing packages that’s already pretty simple using bash with apt or yum.  Using a recipe allows you to ensure that the installs are idempotent or transactional.  If one part fails – then you can ensure that the machine is left in a known reliable state.  If you have a failure in a script then you can be left with partial installs or worse – the machine in an unreliable or unworkable state.

One of the exciting aspects to all of this is that it’s very easy to hook things together – not just on one machine but all machines in your environment – regardless of what OS they’re running.  A recipe to install Zend Server, Symfony, MySQL or as a single package will work on Ubuntu, Redhat, CentOS or most other variants.

Hooking into the infrastructure allows very simple approaches to things like provisioning, deployment and configuration of environments – in my case this allows:

  • Automated creation of a virtual machine instance
  • Automatic provisioning of the instance
  • Dynamic allocation & changing of the resources available to the instance (Memory, Disk, Drives, etc) although with VirtualBox a reboot is needed for memory changes to take effect.
  • Dynamic package and configuration – allowing me (from within the VM instance) to switch it’s mode of operation and determine its role.  So within minutes it changes from all in one (complete LAMP on the instance) to the DB Server role
Advertisements

Friday 29th May, 2009 at 1:48 pm 1 comment


Recent Posts