1. Home
  2. Training Library
  3. DevOps
  4. Courses
  5. Getting Started With Chef

Setting Up Nodes

Developed with
Start course
Duration2h 12m


In this lesson, we will configure some missing nodes for the cookbooks.

We will begin by turning to AWS to create three virtual machines: Ubuntu 16.04 and 14.04, and one for CentOS 7. We will verify that all three of these are accessible via ports 22 for SSH and port 80 for HTTP.

First we will click Launch Instance, and select Ubuntu 16.04 LTS. Then we give the instance a name to make it easier to recognize. We will verify that ports 22 and 80 are open, and name the security group. Finally, we will launch the instance, and repeat the process for Ubuntu 14.04.

For the CentOS instance, we will navigate to centos.org and install the most recent version. Then you will follow the process for the steps used for Ubuntu.

You will install the chef-client software for the server to see these nodes, and learn what bootstrapping is. We will walk through the installation process using the knife command to install the chef-client on all three nodes.

Finally, we will perform a recap of the lesson.


Welcome back! In the previous lesson I setup the Chef Server. And since I created a cookbook before that, the only thing that’s missing are some nodes to configure.

So that’s what I’ll do in this lesson, so that in the next lesson I can run the cookbook on the nodes I create right now.

Just as I did with the Chef Server, I’m going to turn to AWS. I’m going to create three virtual machines. I’m going to create VMs for Ubuntu 16.04 and 14.04, and then one for CentOS 7.
You can create yours anywhere you like, including local VMs. So I’m not going to go in depth on the settings for this. The important part is that I’m going to make sure that all three of these are accessible via ports 22 for SSH and port 80 for HTTP. And that’s because I’m going to use knife to connect to these via SSH, and to test that things worked I need port 80 open so I can see the web app.

To start, I’ll click Launch Instance, and click the select button for Ubuntu 16.04 LTS. And I’ll just keep clicking next until I get to the tags, where I’ll give the instance a name; this is to make it easier to recognize them at a glance. Next I need to make sure ports 22 and 80 are open, and I’ll name the security group so I can reuse it for the other instances. And then I’ll click next until the instance is launched. And then I’ll repeat the process for Ubuntu 14.04. Again, it’s a lot of clicking next through all of the prompts. And then selecting the security group I created a moment ago, and then more clicking next until it’s launched.

And with that done, I’ll launch a CentOS which comes from the Marketplace, though it doesn’t add any additional cost to use it, at least as far as I can tell.

So I’ll filter for CentOS, and the first option is put out by centos.org, and it’s version 7, so that’s the option I’ll select. The next screen shows some information about the image I’ve selected including pricing, so I need to scroll down to the bottom to continue. And from here on out, it’s the same mashing of the next button that you saw twice before. And when this is complete, I’ll have a CentOS VM.

If I go back to the EC2 instances, filtered by the state of “Running” you can see that there are 2 Ubuntu VMs, a CentOS VM and the Chef Server.

Okay, the Chef Server has no idea that these nodes even exist. And since I want to manage these nodes with Chef, I need to install the chef-client software on these nodes. This process of installing the initial Chef software on a node is referred to as bootstrapping the node. And just like any other software installation, it could be done in different ways.

There are a couple methods that are commonly used, which are to use knife connect in via SSH and install the chef-client, and the unattended mode, which is a common method when dealing with VMs that are dynamically created and destroyed, often via auto scaling.

The way I’m going to show you is to use the knife command to install the chef-client on these nodes.
The knife executable has a bootstrap subcommand with a lot of options for how to connect, to a node. The documentation covers each of the arguments, so if you want to skim through that, I’d recommend it.

I’m going to switch back to my terminal so I can run the bootstrap process. I’m in the working directory for the Chef repo that I’ve named ca_repo.
And from here, I’ll issue the knife command, followed by the bootstrap subcommand.
Next I need to set the fully qualified domain name, which I can take from inside the AWS console. I’ll start with the Ubuntu 16.04 instance.
I’m going to connect to the nodes via SSH key, so I need to specify the path to the key. This is the key that Amazon added to these nodes for me during the VM creation process.
So, I’ll specify the with to the key with the minus “i” flag, followed by the path and name of the key. And the next flag I’ll add is the minus capital “N” flag followed by the name for this node. I’m going to just combine the name of the particular Linux distribution and the version to form the node name. You can choose your own names, if you want something that’s more descriptive. Next I’ll specify the name of the SSH user with the minus “x” flag. And then I’ll pass the minus minus sudo flag to tell kitchen to run the bootstrap command as sudo.

And now I’ll run this, and it’ll take a moment…..and there it is. To see if it worked I can issue the knife client list command and see that the node I just bootstrapped is in that list. Which is perfect. That was pretty easy. So now I just need to repeat the process for the other two nodes.

Next up I’ll bootstrap the Ubuntu 14.04 instance. So I need to get the fully qualified domain name from the AWS console, and I’ll paste it here. Then I’ll set the SSH key path, just as before. And then the name which will be ubuntu1404. And this will take several seconds to run, and once it’s complete I can use knife to see if the node is all set. And it looks like it is. So it’s time to do the same thing for the CentOS instance.

Again, I’ll type out “knife bootstrap” and then grab the domain name from the AWS console. And I’ll set the SSH path, and then give the node a name of “centos7,” which kind of sounds like some far off nebula.

Now if I run the “knife list nodes” it returns all of my nodes. And if I switch over to the Chef Server management UI, I can see the nodes there too. However there are still no cookbooks, so there’s still some work to do, however I’ll save that for the next lesson.

For now, let’s see how much you remember from this lesson.

What’s the purpose of bootstrapping a node?
By bootstrapping a node you install the chef-client on the node, as well as register the node with the Chef Server. And that allows you to manage that node with Chef.

The next question is: I mentioned two common methods for bootstrapping a node. What are the two methods?
There’s the method I showed you, which is to use the knife command to bootstrap the nodes. And there’s also an unattended mode, which is very useful when dealing with dynamic servers. Since cloud providers allow you to dynamically create and destroy virtual machines, having a method to bootstrap the node without requiring human intervention is essential. There are a lot of ways to handle this sort of thing, across the different cloud platforms. And while it’s outside the scope of this course to cover them, if you’re planning on using Chef with dynamic servers I recommend you do some research to find a bootstrapping method that works for you and your platform.

Okay, let’s wrap up this lesson here. In the next lesson I’m going to show you how to get your cookbooks onto the Chef Server, and then I’ll configure the nodes that I just created. So if you’re ready to keep learning, then let’s get started in the next lesson!

About the Author
Learning paths15

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