For some time now I’ve been thinking about and reading about tools like Chef and Puppet. A couple of years ago a got a couple of small projects off the ground with Puppet for a job I was working as well. But, with the way the cloud is developing and my general belief that if you are really deploying a cloud computing application but then you find yourself logging into a server command prompt for some reason during normal operations then something has either gone wrong or you are doing something wrong.
The issue of scripted server build and configuration management is hardly new. There are numerous other resources I’m sure you can search to learn the history of configuration management tools both commercial and open source. For my part, I’ve been doing a number of experiments and have chosen to work with the Opscode Chef platform. What follows in this article are a few of the things I’ve learned along the way.
Knowing some ruby helps a LOT! Opscode chef is going to be challenging to get the hang of if you do not know the first thing about the ruby programming language. If you are in that camp, you might just want to invest a bit of time w/ a good basic ruby programming language tutorial first. A great deal of the flexibility and power of the chef tools is about being able to use ruby effectively. This is not a major barrier because you do not need to be a l33t hax0r by any means. But, it will help a great deal if you know how variables work, how to do a loop, case statements, and other basic constructs of the language.
I have been used to building and deploying things with push methods a lot in the past. With a tool like chef things are kind of turned around the other way. You need to put yourself the the shoes of the server you are trying to configure and think more about pulling data to yourself. This is essentially what happens after you bootstrap a chef configured server. It pulls a lot of data to it after it registers itself with a chef server somewhere. It then uses this data(recipes and roles) to turn itself into the server it is told it should be more or less.
Why would I bother with all this you might be thinking!? Well, assuming I have set up my environment properly, defined my roles, created the proper recipes assigned to that role, then with a command that looks a bit like the following:
knife rackspace server create 'role[serverrole]' --server-name myawesomeserver --image 49 --flavor 1
NOTE: This example uses the knife tools to interact w/ chef. Knife is a command-line utility used to interact with a Chef server directly through the RESTful API.
I can start a server (a node) running the software I want running on the rackspace cloud with the code I want on it in about 4-5 minutes. That’s 4-5 minutes from the time I hit the <enter> key on my keyboard! Race ya!
Now, if I’m building one server, this might not seem very worthwhile. But, if I am building 100 or 1000... or if I’m going to be building them and tearing them down constantly by the dozens or hundreds per day then yes, this makes ALL THE SENSE IN THE WORLD! But WAIT! It gets better.
With this command I can launch THE SAME server on a different cloud in 4-5 minutes (AWS US-East-1c in this case)
knife ec2 server create -G WebServers,default --flavor m1.small -i ami-2d4aa444 -I /Users/me/Downloads/mykey.pem -S servername -x ubuntu 'role[serverrole]' -Z us-east-1c
Just think about this for a moment. From my laptop (macbookpro in this case) I can launch a server that is exactly the same on two different cloud computing providers in well under 10 minutes without ever touching a cloud GUI like the AWS console or the Rackspace Cloud console (which would only slow me down).
Now, it wasn’t exactly trivial to set all this up so that it works. But, the fact is, it wasn’t that bad either and I learned a TON along the way.
So, this was just a little intro article. There are LOADS of great resources about chef out there. I will warn you about one other thing I learned. It’s a bit hard to search for information about this software because it’s called “chef” and it has “recipes” which means a lot of the time you’ll end up with search results from FoodTV network. I like food so I don’t mind sometimes but it can be annoying.
The issue of scripted server build and configuration management is hardly new. There are numerous other resources I’m sure you can search to learn the history of configuration management tools both commercial and open source. For my part, I’ve been doing a number of experiments and have chosen to work with the Opscode Chef platform. What follows in this article are a few of the things I’ve learned along the way.
Knowing some ruby helps a LOT! Opscode chef is going to be challenging to get the hang of if you do not know the first thing about the ruby programming language. If you are in that camp, you might just want to invest a bit of time w/ a good basic ruby programming language tutorial first. A great deal of the flexibility and power of the chef tools is about being able to use ruby effectively. This is not a major barrier because you do not need to be a l33t hax0r by any means. But, it will help a great deal if you know how variables work, how to do a loop, case statements, and other basic constructs of the language.
I have been used to building and deploying things with push methods a lot in the past. With a tool like chef things are kind of turned around the other way. You need to put yourself the the shoes of the server you are trying to configure and think more about pulling data to yourself. This is essentially what happens after you bootstrap a chef configured server. It pulls a lot of data to it after it registers itself with a chef server somewhere. It then uses this data(recipes and roles) to turn itself into the server it is told it should be more or less.
Why would I bother with all this you might be thinking!? Well, assuming I have set up my environment properly, defined my roles, created the proper recipes assigned to that role, then with a command that looks a bit like the following:
knife rackspace server create 'role[serverrole]' --server-name myawesomeserver --image 49 --flavor 1
NOTE: This example uses the knife tools to interact w/ chef. Knife is a command-line utility used to interact with a Chef server directly through the RESTful API.
I can start a server (a node) running the software I want running on the rackspace cloud with the code I want on it in about 4-5 minutes. That’s 4-5 minutes from the time I hit the <enter> key on my keyboard! Race ya!
Now, if I’m building one server, this might not seem very worthwhile. But, if I am building 100 or 1000... or if I’m going to be building them and tearing them down constantly by the dozens or hundreds per day then yes, this makes ALL THE SENSE IN THE WORLD! But WAIT! It gets better.
With this command I can launch THE SAME server on a different cloud in 4-5 minutes (AWS US-East-1c in this case)
knife ec2 server create -G WebServers,default --flavor m1.small -i ami-2d4aa444 -I /Users/me/Downloads/mykey.pem -S servername -x ubuntu 'role[serverrole]' -Z us-east-1c
Just think about this for a moment. From my laptop (macbookpro in this case) I can launch a server that is exactly the same on two different cloud computing providers in well under 10 minutes without ever touching a cloud GUI like the AWS console or the Rackspace Cloud console (which would only slow me down).
Now, it wasn’t exactly trivial to set all this up so that it works. But, the fact is, it wasn’t that bad either and I learned a TON along the way.
So, this was just a little intro article. There are LOADS of great resources about chef out there. I will warn you about one other thing I learned. It’s a bit hard to search for information about this software because it’s called “chef” and it has “recipes” which means a lot of the time you’ll end up with search results from FoodTV network. I like food so I don’t mind sometimes but it can be annoying.
I've worked with Puppet in the past, love it. I'm working with Chef now, love it. I'll almost certainly be using both for projects where they are best appropriate in the future.
Have good configurating and I'm sure I'll be writing more about this in the near future.
Have good configurating and I'm sure I'll be writing more about this in the near future.