chef_not

Getting Started with Chef Server. Part 1

| 2 Comments

Hello my dear friends. Today we will continue talking about a Chef Server. All the code examples you can find here: github.com/le0pard/chef-server-example/tree/1.0.

In this article we will learn what is the Chef Server and how to setup it up.

Before reading this article, it’s better to read my articles about Chef Solo. Here, in this series of articles, I’ll explain only those things that hasn’t already been covered in those Chef Solo series of articles.

What is the Chef Server?

Chef is a Ruby-based configuration management engine.

The Chef Server acts as a hub, ensuring that the right cookbooks are used, that the right policies are applied, that all of the node objects are up-to-date, and that all of the nodes that will be maintained are registered and known to the Chef Server. The Chef Server distributes configuration details (such as recipes, templates, and file distributions) to every node within the organization. Chef then does as much of the configuration work as possible on the nodes themselves (and not on the Chef Server). This scalable approach distributes the configuration effort throughout the organization.

There are three types of Chef Servers:

  • Hosted Chef is a version of a Chef Server that is hosted by Opscode. Hosted Chef is cloud-based, scalable, and available (24×7/365), with resource-based access control. Hosted Chef has all of the automation capabilities of Chef, but without requiring it to be set up and managed from behind the firewall.
  • Private Chef is a version of a Chef Server that is designed to provide all of the infrastructure automation capabilities of Chef, set up and managed from within the organization.
  • Open Source Chef is an open source version of the Chef Server that contains much of the same functionality as Hosted Chef, but requires that each instance be configured and managed locally, including performing data migrations, applying updates to the Open Source Chef server, and ensuring that the Open Source Chef server scales as the local infrastructure it is supporting grows. Open Source Chef includes support from the Chef community but does not include support directly from Opscode.

In the series of articles we will work with Open Source Chef.

What is the difference between Chef Solo and Chef Server?

Chef Solo does not provide:

  • Node data storage or search indexes.
  • Centralized cookbook distribution.
  • Environments, for setting policy of cookbook versions.
  • A central API to interact with and use to integrate infrastructure components.
  • Bulk operations with nodes.

As you can see, Chef Solo is useful for small infrastructure (several servers), but if you have a huge amount of server – you must use Chef Server.

Environments

As you remember, Chef Solo has nodes, roles and data bags. Chef Server have additional policy: environments. An environment is a way to map an organization’s real-life workflow to what can be configured and managed when using Chef Server. Every Chef organization begins with a single environment called the “_default” environment, which cannot be modified (or deleted). Additional environments can be created, such as production, staging, testing, and development. Generally, an environment is also associated with one (or more) cookbook versions. An environment attribute can only be set to be a default attribute or an override attribute.

Attributes for recipes can be redefined in this way (except “override attributes”):

Defaults (lowest precedence) -> Environments -> Roles -> Nodes (highest precedence)

Chef version

In this series of articles we will work with Chef 11. You can read about changes in this Chef version by this link.

Initialize Chef Server project

To setup and configure Chef Server we will use Chef Solo (really? :). This is because this component of the system also should be quickly deployed to the new server, if something happened with Chef Server something happens (crash file system of server, etc.). Do not forget to make a backups of Chef Server (because compared with Chef Solo, Chef Server will be the point of failure in your configuration management system).

Let’s create our folder, which will contain all our Chef kitchen:

Next I will use bundler to get some useful gems:

And create a kitchen for the Chef:

Berkshelf

As you remember, we used librarian gem to manage cookbooks for Chef Solo we used librarian gem. For this tutorial, I selected another good gem to manage a cookbooks dependencies – berkshelf. You can use anyone you like, but compared to the “librarian” the “berkshelf” has several pros:

  • By default, berkshelf stores every version of a cookbook that you have ever installed in one folder on your local machine (the same workflow as for rubybems)
  • Flexible configuring
  • Build-in integration with Vagrant and Thor
  • Adding sources of cookbooks to groups (like have bundler)

Let’s create the Berksfile file and add the “chef-server” cookbook “chef-server” cookbook (this cookbook supported by Opscode):

Let’s create the Berksfile file and add the “chef-server” cookbook to it (this cookbook supported by Opscode):

After launch of command “berks install” your cookbooks directory will be clear, because by default “berkshelf” install cookbooks into “~/.berkshelf” location. You can easily install your Cookbooks and their dependencies to a location other than default by argument “–path”:

After the launch of the “berks install” command, your cookbooks directory will be clear, because, by default, “berkshelf” installs cookbooks into “~/.berkshelf” location. You can easily install your Cookbooks and their dependencies to a location other than the default by the argument “–path” argument:

But right now we don’t need this.

Configure Chef Server node

After this, we should configure the Chef Solo node for our Chef Server. I will do this by using a role. First of all, we should create “chef.json” in the role folder with content:

By the “configuration” key you can change settings for Chef Server. All available settings, which is possible to redefined, you can find here.

Next, we should create the “vagrant.json” node with the following content:

We are ready for testing this Chef Server kitchen.

Vagrant

For testing Chef Server by vagrant, we need to download the vagrant box. List of boxes you can find at www.vagrantbox.es.

Next, we need to model a cluster of machines by vagrant. Let’s modify the Vagrantfile:

We set two nodes: chef (Chef Server) and chef\_client (client of Chef Server). We use the “hostonly” network for these servers. In this case, both of these servers will be available by IPs: 10.33.33.33 and 10.33.33.50. Also, there’s no need to forward ports because services on these servers can be available by this IPs. To find more, read “Multi-VM Environments” and “Chef Solo Provisioning” you can find by this links.

Let’s create our nodes:

Our Chef Server by default takes your systems FQDN as Chef Server url. We can check Chef Server web interface by “https://10.33.33.33″ and info about versions by “https://10.33.33.33/version” url. It should looks like this:

chef_server_versions

After login by “admin/p@ssw0rd1″ you must change admin password to some secure password.

SSH keys

After installation Chef Server with default settings, Chef will generate pem keys, which will be used for knife (command line tool for Chef) and Chef clients for authentication with the server. We should copy them from our Chef Server to “.chef” directory in the project:

On prodution you can use scp command for this.

Knife configuration

Next we should create for knife configuration file (knife should know how to communicate with Chef Server):

If you have such error:

This mean, what you are using chef version 11.0.0. This bug fixed in version 11.4.0.

As a result, you should have a file “.chef/knife.rb” with similar content:

Let’s check knife configuration:

If you see an error on command “knife client list” – check you knife configuration, you pem keys and availability of Chef server.

Bootstrap first node

Once the Chef Server workstation is configured, it can be used to install Chef on one (or more) nodes across the organization using a Knife bootstrap operation. The “knife bootstrap” command is used to SSH into the target machine, and then do what is needed to allow the chef-client to run on the node. It will install the chef-client executable (if necessary), generate keys, and register the node with the Chef Server. The bootstrap operation requires the IP address or FQDN of the target system, the SSH credentials (username, password or identity file) for an account that has root access to the node, and (if the operating system is not Ubuntu, which is the default distribution used by knife bootstrap) the operating system running on the target system.

So let’s do this:

Let’s check clients on Chef Server:

As you can see we get a new client “precise64″.

You can also see this client in Chef Server web interface:

precise64

And new registered node:

precise64_2

Summary

In the current article, we have learned what Chef Server is and how to setup it up. In the next article, I will cover how to work with Chef Server.

All the code examples you can find here: github.com/le0pard/chef-server-example/tree/1.0.

That’s all folks! Thank you for reading till the end.

This post is crossposting from my blog.

UPDATE: There’s now a Getting Started with Chef Server. Part 2 blog post released!

Share
* Railsware is a premium software development consulting company, focused on delivering great web and mobile applications. Learn more about us.
  • Pingback: Chef Server. Part 2 | Railsware Blog()

  • matthew day

    crappy article, for many reasons, has no bearing on setting up a real production chef server, this is all for testing and local stuff

Want to get more of Railsware blog?

RSS FEED

We're always ready to help!

CONTACT US