WARNING: This article can be outdated. Better read my book about Chef: Cooking Infrastructure by Chef
Hello my dear friends. Today we will continue talk about Chef Server. All example code you can find here: github.com/le0pard/chef-server-example/tree/1.0.
In this article we will learn what is Chef Server and how to setup it.
Before reading this article, I recommend reading a series of articles about the Chef Solo. In this series of articles I will explain only what I hasn’t already been covered in this Chef Solo series of articles.
What is 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 (24x7/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 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 useful for small infrastructure (several servers), but if your you have huge amount of server - you must use Chef Server.
As you remember, Chef Solo have 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)
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? :). Chef Solo will help us quickly deploy Chef Server on a new server, if with it 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 will create kitchen for Chef:
As you remember, to manage cookbooks for Chef Solo we used librarian gem. For this tutorial I selected another good gem for manage a cookbooks dependencies - berkshelf. You can use any which 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 a groups (like have bundler)
Let’s create Berksfile file and add to it “chef-server” cookbook (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”:
But right now we don’t need this.
Configure Chef Server node
After this we should configure for Chef Solo node for our Chef Server. I will do this by using role. First of all, we should create “chef.json” in folder role with content:
By “configuration” key you can change settings for Chef Server. All available setting, which is possible to redefined, you can find here.
Next we should create node “vagrant.json” with content:
We are ready for testing this Chef Server kitchen.
For testing Chef Server by vagrant we need download vagrant box. List of boxes you can find at www.vagrantbox.es.
Next we need modeling a cluster of machines by vagrant. Let’s modify Vagrantfile:
We set two nodes by this configuration: chef (Chef Server) and chef_client (client of Chef Server). We use “hostonly” network for this servers. In this case both of this servers will be available by IPs: 10.33.33.33 and 10.33.33.50. Also doesn’t need to do forward ports, because services on this servers will be available by this IPs. More about “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:
After login by “admin/p@ssw0rd1” you must change admin password to some secure password.
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 server. We should copy its from our Chef Server to “.chef” directory in project:
On prodution you can use scp command for this.
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 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 new client “web.dev”.
You also can see this client in Chef Server web interface:
And new registered node:
In the current article we have learn what is Chef Server and how to setup it. In next article I will cover how to work with Chef Server.
All example code you can find here: github.com/le0pard/chef-server-example/tree/1.0.
That’s all folks! Thank you for reading till the end.