Configuring The Nodes

Developed with
Start course
2h 12m

This lesson will teach you how to configure the nodes created in the previous lesson.

We will start by uploading the cookbooks to the Chef Server to begin configuring the nodes.

You will upload your cookbook and also the community cookbooks to the test virtual machines using Berkshelf.

You will perform hands-on practice to change directories, download the dependencies, and issue the berks install command to download the cookbooks.

Next, we will explain how to upload the cookbooks to the Chef Server using the Berkshelf berks upload command.

After all the cookbooks have been uploaded, we will discuss how to configure the nodes. You will see how all of the components of Chef work together to configure the nodes.

We will tell the nodes what recipes they should run using several knife and Chef commands. You will test the nodes afterward to be sure they are working as expected.

Finally, we will recap what you have just learned in the lesson.


Welcome back! In the previous lesson I bootstrapped the nodes with the chef-client. Before that I setup the server, and before that I created a cookbook that will configure a node to install Apache, MySQL and then deploy a Python based web application.

So I have all of the components required to configure the nodes. And that’s what I’ll show in this lesson. I’ll upload the cookbooks to the Chef Server and then configure the nodes.

So let’s start with uploading the bookbooks. If you recall that when I created the cookbook, I used several community cookbooks, and I added them to my metadata.rb file. That means that my cookbook isn’t going to run without them, so I need to upload not only my cookbook, but also the community cookbooks. Kitchen used Berkshelf to install the cookbooks on the test VMs, and so will I.

I need to change directories into the learn_chef_coobook directory to start. Before I use Berkshelf to download the dependencies, here’s a look at the Berksfile. Remember that the Berksfile is how Berkshelf knows which cookbooks to download. The Berksfile is looking in the metatdata.rb file for the dependencies. Notice at the bottom I have several specified. These are the cookbooks that I need to download locally, so that I can upload the to the Chef Server.

So now I need to issue the “berks install” command in order to download the cookbooks. It runs pretty quickly because they were already downloaded by Kitchen earlier in the course. So it doesn’t need to do anything now. If the files didn’t already exist, it’d take a moment to download them all.

The cookbooks will be download into a cookbooks directory inside a hidden directory named .berkshelf in your home directory. So, if I list off the contents of that hidden directory, you can see all of the cookbooks.

With those all downloaded, it’s time to get them uploaded to the Chef Server. For this, I could use Knife or Berkshelf. Since I’m using Berkshelf to manage the dependencies, I’ll use it to upload the cookbooks too. And to do that I simply issue the berks upload command. And it’ll run for a second, and then throw an error.
This isn’t entirely unexpected. This is happening because the SSL cert that was downloaded earlier by knife, is a self signed cert and Berkshelf isn’t happy about it. In production you should have a signed cert that’s installed on your workstation. So I’m going to resolve the symptom and not the problem.
And I’ll do that by adding a setting to the berkshelf.config file that resides in that hidden .berkshelf directory. Optionally you could use the --no-ssl-verify command line flag for the upload command. I’ll use the config file option so I don’t need to type that out every time I want to upload. That setting is the only thing in that file.

Now with that done, if I run the berks upload command again, it’ll work. This is going to take about a minute. So I’ll fast forward to once it’s complete. So now you can see here in the web UI that all the cookbooks are uploaded.

So, that’s the first objective for this lesson completed. That leaves configuring the nodes. Managing your infrastructure with Chef is the reason to learn Chef. So this next part is the culmination of all of the work throughout the course so far. This is where you get to see the how all of the components work together to configure the nodes.

The first thing that I need to do is to tell the nodes what recipes they should run, by setting a runlist for the nodes. And I can do that with the “knife node run_list set” command, followed by the name of the node and the runlist. And the runlist is going to be the default recipe for the learn_chef_cookbook. So, I’ll run this command, and it returns pretty quickly. And then I’ll run it again, and change the node name. And then once more for the final node. Okay perfect!

Now that the nodes all know what recipes they should run, I need to tell them to actually run them. And that’s done by running the chef-client command on the nodes. Since it’s just a matter of running an executable, I could have it set to run as cron tab job, or some other scheduled task. I could run it manually from a shell running on the node. Or I can use the knife command to use SSH to run it for me. And that’s the option I’ll use.

I’ll start with the Ubuntu 14.04 instance. This command here will instruct knife to run a command on whatever nodes I specify. I’m going to use the node’s name to reference the node that I want to run code against. This is a special search syntax that allows you to specify a key and some value, and the value can use wildcard characters, allowing you to target multiple nodes. This is the same syntax that the knife search command uses, so if you want to learn more about it, check out the documentation.
The next argument is the command I want to run, which is “sudo chef-client.” Next is the minus x flag, which specifies the SSH user, followed by the minus “a” which tells knife which attribute to use to as the host or IP address when connecting in. This is the attribute that kitchen will take and use as the location of node when it tries to connect via SSH.

In this case I’m going to use the attribute named ec2.public_address. There are a lot of possible attributes that are fetched by knife, from the Chef Server. If you look in the web UI on the attributes tab for a node you can see the list of attributes. Most of these were collected by Ohai automatically. If I expand the ec2 attributes you can see the public hostname is the same value that I’ve been using as the fully qualified domain name whenever I referenced the different EC2 instances.
Back to the terminal, I also need to specify the SSH key that will be used to authenticate. And with that set, I can run this, and it’ll look very familiar, because it’s basically what Kitchen has been doing. I’m going to fast forward to when it’s complete…

It ended up taking about a minute and a half. Now, if everything went well, I should be able to use the web app. So if I load the page in the browser it should load...there it is!
And if I add some values, it looks like they save to the database. So this is great!

I want to do the same thing for the CentOS instance before celebrating. So, I’ll again use knife to run the chef-client via the knife ssh command.

And I’ll fast forward to when it’s complete. And this one ended up being slightly faster. So I now if I load the page in the browser, it should load the app...and there it is. And if I add some values...I’ll just type “test” and submit that, and it seems to work. I’ll add one more value for the fun of it, and it works! With that done I’ve accomplished the second objective for the lesson, which was to configure the nodes.

A lot of work went into getting this working. So let’s recap how it’s all working.

By running the chef-client executable on the nodes, it told them to check with the Chef Server and make sure they have everything they need. And that includes their runlist. Once they have everything they can run through the recipes in the runlist, and then the node can report back the state of the node and some stats about how things went to the Chef Server.

Okay, after all of that work it’s time to wrap up this lesson. Let’s see how much you recall from this lesson.

Which command was used to upload the Cookbooks?
While you do have options, the method I showed was to use Berkshelf to upload the files. And for that the command is “berks upload.” It’s worth mentioning that if you make a change to a cookbook, and you don’t change the version in the metadata.rb file, berks will skip uploading the cookbook. However you can force it to with the minus minus force flag.

The next question is: How do you specify what recipes are supposed to be run on a node?
The answer is that you need to set the run list. And the way I showed how to do that is the “knife node run_list set” command. And then you can specify the recipes you want to have run.

The final question is: Which command did I use to run the chef-client on the nodes?
In the demo I used the knife ssh command to run “sudo chef-client” on the nodes. And you’re not limited to just running that one command, as you probably guessed.

You may have noticed that I didn’t configure that Ubuntu 16.04 instance. And that’s because I’ll use it in a later lesson.

In the next lesson I’ll cover roles and data bags. So if you’re ready to keep learning, then let’s get started in the next lesson!

About the Author
Learning Paths

Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.

Covered Topics