(For more resources related to this topic, see here.)
First, let’s talk about the terminology used in the Chef universe.
A cookbook is a collection of recipes – codifying the actual resources, which should be installed and configured on your node – and the files and configuration templates needed.
Once you’ve written your cookbooks, you need a way to deploy them to the nodes you want to provision. Chef offers multiple ways for this task. The most widely used way is to use a central Chef Server. You can either run your own or sign up for Opscode’s Hosted Chef.
The Chef Server is the central registry where each node needs to get registered. The Chef Server distributes the cookbooks to the nodes based on their configuration settings.
Knife is Chef’s command-line tool called to interact with the Chef Server. You use it for uploading cookbooks and managing other aspects of Chef.
On your nodes, you need to install Chef Client – the part that retrieves the cookbooks from the Chef Server and executes them on the node.
In this article, we’ll see the basic infrastructure components of your Chef setup at work and learn how to use the basic tools. Let’s get started with having a look at how to use Git as a version control system for your cookbooks.
Do you manually back up every file before you change it? And do you invent creative filename extensions like _me and _you when you try to collaborate on a file? If you answer yes to any of the preceding questions, it’s time to rethink your process.
A version control system (VCS) helps you stay sane when dealing with important files and collaborating on them.
Using version control is a fundamental part of any infrastructure automation. There are multiple solutions (some free, some paid) for managing source version control including Git, SVN, Mercurial, and Perforce. Due to its popularity among the Chef community, we will be using Git. However, you could easily use any other version control system with Chef.
You’ll need Git installed on your box. Either use your operating system’s package manager (such as Apt on Ubuntu or Homebrew on OS X), or simply download the installer from www.git-scm.org.
Git is a distributed version control system. This means that you don’t necessarily need a central host for storing your repositories. But in practice, using GitHub as your central repository has proven to be very helpful. In this article, I’ll assume that you’re using GitHub. Therefore, you need to go to github.com and create a (free) account to follow the instructions given in this article. Make sure that you upload your SSH key following the instructions at https://help.github.com/articles/generating-ssh-keys, so that you’re able to use the SSH protocol to interact with your GitHub account.
As soon as you’ve created your GitHub account, you should create your repository by visiting https://github.com/new and using chef-repo as the repository name.
Before you can write any cookbooks, you need to set up your initial Git repository on your development box. Opscode provides an empty Chef repository to get you started. Let’s see how you can set up your own Chef repository with Git using Opscode’s skeleton.
mma@laptop $ wget http://github.com/opscode/chef-repo/tarball/
master
...TRUNCATED OUTPUT...
2013-07-05 20:54:24 (125 MB/s) - 'master' saved [9302/9302]
mma@laptop $ tar zvf master
mma@laptop $ mv opscode-chef-repo-2c42c6a/ chef-repo
mma@laptop $ cd chef-repo/
mma@laptop:~/chef-repo $ git init .
Initialized empty Git repository in /Users/mma/work/chef-repo/.
git/
mma@laptop:~/chef-repo $ git remote add origin git@github.
com:mmarschall/chef-repo.git
mma@laptop:~/chef-repo $ git add .
mma@laptop:~/chef-repo $ git commit -m "initial commit"
[master (root-commit) 6148b20] initial commit
10 files changed, 339 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
...TRUNCATED OUTPUT...
create mode 100644 roles/README.md
mma@laptop:~/chef-repo $ git push -u origin master
...TRUNCATED OUTPUT...
To git@github.com:mmarschall/chef-repo.git
* [new branch] master -> master
You’ve downloaded a tarball containing Opscode’s skeleton repository. Then, you’ve initialized your chef-repo and connected it to your own repository on GitHub.
After that, you’ve added all the files from the tarball to your repository and committed them. This makes Git track your files and the changes you make later.
As a last step, you’ve pushed your repository to GitHub, so that your co-workers can use your code too.
Let’s assume you’re working on the same chef-repo repository together with your co-workers. They cloned your repository, added a new cookbook called other_cookbook, committed their changes locally, and pushed their changes back to GitHub. Now it’s time for you to get the new cookbook down to your own laptop.
Pull your co-workers, changes from GitHub. This will merge their changes into your local copy of the repository.
mma@laptop:~/chef-repo $ git pull From github.com:mmarschall/chef-repo * branch master -> FETCH_HEAD ...TRUNCATED OUTPUT... create mode 100644 cookbooks/other_cookbook/recipes/default.rb
In the case of any conflicting changes, Git will help you merge and resolve them.
If you want to use Chef, you’ll need to install it on your local workstation first. You’ll have to develop your configurations locally and use Chef to distribute them to your Chef Server.
Opscode provides a fully packaged version, which does not have any external prerequisites. This fully packaged Chef is called the Omnibus Installer. We’ll see how to use it in this section.
Make sure you’ve curl installed on your box by following the instructions available at http://curl.haxx.se/download.html.
Let’s see how to install Chef on your local workstation using Opscode’s Omnibus Chef installer:
mma@laptop:~/chef-repo $ curl -L https://www.opscode.com/chef/
install.sh | sudo bash
Downloading Chef...
...TRUNCATED OUTPUT...
Thank you for installing Chef!
mma@laptop:~ $ echo 'export PATH="/opt/chef/embedded/bin:$PATH"'
>> ~/.bash_profile && source ~/.bash_profile
The Omnibus Installer will download Ruby and all the required Ruby gems into /opt/chef/embedded. By adding the /opt/chef/embedded/bin directory to your .bash_profile, the Chef command-line tools will be available in your shell.
If you already have Ruby installed in your box, you can simply install the Chef Ruby gem by running mma@laptop:~ $ gem install chef.
If you want to get started with Chef right away (without the need to install your own Chef Server) or want a third party to give you an Service Level Agreement (SLA) for your Chef Server, you can sign up for Hosted Chef by Opscode. Opscode operates Chef as a cloud service. It’s quick to set up and gives you full control, using users and groups to control the access permissions to your Chef setup. We’ll configure Knife, Chef’s command-line tool to interact with Hosted Chef, so that you can start managing your nodes.
Before being able to use Hosted Chef, you need to sign up for the service. There is a free account for up to five nodes.
Visit http://www.opscode.com/hosted-chef and register for a free trial or the free account.
I registered as the user webops with an organization short-name of awo.
After registering your account, it is time to prepare your organization to be used with your chef-repo repository.
Carry out the following steps to interact with the Hosted Chef:
current_dir = File.dirname(__FILE__)
log_level :info
log_location STDOUT
node_name "webops"
client_key "#{current_dir}/webops.pem"
validation_client_name "awo-validator"
validation_key "#{current_dir}/awo-validator.pem"
chef_server_url "https://api.opscode.com/organizations/
awo"
cache_type 'BasicFile'
cache_options( :path => "#{ENV['HOME']}/.chef/checksums" )
cookbook_path ["#{current_dir}/../cookbooks"]
mma@laptop:~/chef-repo $ knife client list
awo-validator
Hosted Chef uses two private keys (called validators): one for the organization and the other for every user. You need to tell Knife where it can find these two keys in your knife.rb file.
The following two lines of code in your knife.rb file tells Knife about which organization to use and where to find its private key:
validation_client_name "awo-validator"
validation_key "#{current_dir}/awo-validator.pem"
The following line of code in your knife.rb file tells Knife about where to find your users’ private key:
client_key "#{current_dir}/webops.pem"
And the following line of code in your knife.rb file tells Knife that you’re using Hosted Chef. You will find your organization name as the last part of the URL:
chef_server_url "https://api.opscode.com/organizations/awo"
Using the knife.rb file and your two validators Knife can now connect to your organization hosted by Opscode.
You do not need your own, self-hosted Chef Server, nor do you need to use Chef Solo in this setup.
This setup is good for you if you do not want to worry about running, scaling, and updating your own Chef Server and if you’re happy with saving all your configuration data in the cloud (under Opscode’s control).
If you need to have all your configuration data within your own network boundaries, you might sign up for Private Chef, which is a fully supported and enterprise-ready version of Chef Server.
If you don’t need any advanced enterprise features like role-based access control or multi-tenancy, then the open source version of Chef Server might be just right for you.
In this article, we learned about key concepts such as cookbooks, roles, and environments and how to use some basic tools such as Git, Knife, Chef Shell, Vagrant, and Berkshelf.
Further resources on this subject:
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…