In my last post I covered the basic concepts in chef. This post should get you up and running with chef so you can start learning. (This post is not about setting up chef for production use.)
In part 1, I talked about how chef is file-based and how there are a bunch of Ruby and json files. These files are stored in the “chef repository” or just “repo”. Really it’s just a directory. The chef repo contains cookbooks — both those you download and those you create yourself.
Opscode provides a git repo containing the basic file structure. If you use git, you get started by cloning that repo. If you don’t use git, you can download it as a tarball. I’m going to use git.
You don’t have to use git. You can use whatever source control you want (or none if you are insane). Using git just makes things a bit easier. Some of the knife commands we’ll use in the next post are git-aware and will do more for you if you are using git. But you can do all those steps yourself with your own source control if you really don’t like git.
You also don’t have to use a VM, as I describe below. But you really should. Chef is a tool for configuring a machine and deploying things to it. You don’t really want to be learning about that on your primary machine, do you? (Um, that was rhetorical. You don’t.)
So here we go:
- Set up the OS
- Set up a VM with a clean install of the OS that is running on the machines you want to use chef to manage. I’m using Windows Server 2008 R2, running in VMWare Fusion on my MacBook Pro.
- Optional: Run Windows Update. I do this, so that when I take a snapshot of the VM (below), it includes all the updates.
- Install Chef
- Chef client, chef solo, and knife are all in in a single MSI. The MSI also includes all the dependencies, like ruby and all the required gems. You can find that at http://opscode.com/chef/install (if you add “.msi” to that, you can skip the web page and download directly.
- Run the installer and accept the defaults. Chef will be installed to c:\opscode\chef
- Install git
- Any git will do. I use GitHub for Windows: http://windows.github.com/
- I launch the GitHub app once to enter my github.com credentials and my name/email for git config (they will appear in your commits). From then on, GitHub generates keys and configures things so you don’t have to enter credentials over and over.
We have arrived at the first pain point with Chef on Windows: For some knife commands to work, you must use bash, not cmd or powershell. I’ll explain why in my next post.
GitHub for Windows includes several shell configurations. I really like Powershell with posh-git, which is the default, but for working with knife, you’ll avoid some headaches by using bash.
To do so: open the GitHub app, click Tools -> Options, and under “default shell” select “Git Bash”. Then launch Git Shell from the desktop icon or Start menu. While in bash, Windows paths that would normally look like c:\foo\bar can be specified as /c/foo/bar. Relative paths work also, just use forward slashes for everything.
Time for chef!
- Launch bash (Git Shell from the desktop shortcut or the Start menu).
- Figure out where you want your chef repo to be. I want mine in c:\dev\chef-repo, so I’ll enter these commands:
mkdir /c/dev cd /c/dev
- Clone the opscode git repo that contains the standard folder structure for a chef repo.
git clone https://github.com/opscode/chef-repo.git
- Change to that directory and create the .chef directory (with the leading dot) where the config will live.
cd chef-repo mkdir .chef
- Configure knife (the chef tool for managing things) by entering:
knife configure -i
Chef will ask you a bunch of questions. The first one and the last are important, the rest you can just hit enter to accept the defaults. The screenshot shows my answers outlined in red. Ignore the error about the private key. You need a key when you work with a chef server, but we won’t be for now.
All that did was create the file .chef\knife.rb, which sets some default values while using knife within this repo. Feel free to open that file in a text editor if you’re curious.
Take a snapshot of the VM at this point. This is your clean starting state for developing cookbooks. You can play around and totally muck things up, then restore this snapshot to start again fresh as many times as you want.
Next time we’ll download some cookbooks and create one of our own.