The course is part of this learning path
Getting Started With Chef
If you were working in IT even ten years ago, then unless you were working for a large company, you probably didn’t need to think about how to manage infrastructure in a scalable way. Back then servers were often on-premises, or in some nearby co-location data center; deployments were infrequent and were kind of like a section of chain, with each link made of a different material, with no consideration of how that link fit into the chain as a whole. At any moment one or more links were bound to break, leaving the deployment is some unforeseen state, that could at best, be described as “broken.”
Luckily for all of us, tools started to evolve out of primordial ooze that was, a random collection of Perl, Python, Ruby, and VBScript, among the other, more esoteric languages. Among those tools was Chef. It not only was among the earliest to evolve, but it has continued to evolve even today.
Chef helps companies around the world manage their infrastructure, in a scalable way. What makes Chef such a useful tool is that it provides a consistent way to interact with nodes, across your entire infrastructure. It also provides a way to test the infrastructure code, which allows you to apply years of software engineering best practices to your infrastructure.
In this course you’ll learn how to use Chef to manage your servers. You’ll learn about how to create your own recipes to configure a server to meet your desired state. You’ll also learn about using community created cookbooks from the Chef Supermarket. By the end of this course you’ll have a solid foundation, to get you started working with Chef.
Getting Started With Chef: What You'll Learn
Lecture | What you'll learn |
---|---|
Intro | What will be covered in this course |
Overview | What is Chef and who uses it? |
A High Level Architecture | A 30,000 foot view |
The Anatomy of a Cookbook | How cookbooks are structured |
The Recipe DSL | How recipes work |
Setup | Setting up the workstation |
Your First Recipe | Creating a recipe |
Refactoring Your Recipe | Making the recipe cross-platform friendly |
Deploying a Web Application | Deploying a LAMP based application |
Setting Up The Chef Server | Preparing a Chef Server |
Setting Up Nodes | Preparing some nodes to configure |
Configuring The Nodes | Configuring The Nodes |
Roles and Data Bags | Managing nodes with roles and accessing global data with data bags |
Next Steps | How to keep learning |
GitHub - Chef Code
The code used in the course can be found here on GitHub:
https://github.com/cloudacademy/chef-intro
If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.
Welcome back! In the previous lesson I wrapped up the creation of the lean_chef_cookbook. And with everything working locally, it’s now time to setup a Chef Server so that I can run this cookbook code on actual servers.
When it comes to setting up the Chef Server, there are options. You can install and configure it all for yourself, or you can use one of the cloud hosted options. Because the goal of this course is to teach to you use Chef from more of a development perspective, I’m going to use on of the hosted options. In particular I’m using the AWS option. Once the server is setup it won’t matter where it lives, because the important part is to have a Chef Server.
By clicking on the button titled “Launch Chef Server on AWS Marketplace” it’ll open up the page to see the Chef Server Amazon machine image. If you’re going to use this option, then you probably already know that this is going to cost you money to run this on AWS. And in addition to that, it’ll also add a slight hourly markup. If you intend on using this for yourself, make sure you read up on the cost, and details.
I already know what I need to know, so I’ll just change the region in this drop down, to use US West, and then click continue.
Here’s some version info, and some buttons to launch the virtual machine. And then at the bottom there’s some details about the requirements for the AWS Security group. In particular it lists the ports that I need to make sure are open. The Chef Server uses ports 22, 443 and 8443.
Okay, so I’ll launch this inside of US West Oregon. And from here the process is just like setting up an Amazon VM. I’ll select the machine type, and click next.
And here you’ll notice that is expects and IAM role to use for metered billing. So I’ll provide a role name and have the role created for me. And then I’ll click next.
I’ll increase the storage just so that I have it available, and click next. I’ll set the Name to Chef Server, and click next again. Then I need to configure the security group to allow for ports 22, 443 and 8443. I’m going to change the name and description of the security group. And that’s it. I’ll click launch and review. Since everything looks good, I can launch it.
The VM itself may take a little while to start up. And that’s normal. And behind the scenes, the VM is also configuring the Chef Server for you. Ths part can take 10 minutes or more, so I’m going to go get some coffee, and then come back to run through the setup.
Okay, so I’ve waited the 10 minutes and now, I can copy the public DNS value here on the AWS console for the Chef Server VM, and paste it into a browser. If you recall Chef Server isn’t listening on port 80, it’s listening on 443. So I need to prepend https:// to the URL. If you have the correct URL and it’s not connecting, then you may need to wait a little longer for the Chef Server to finish getting everything up and running. Remember, just because the VM is up and running doesn’t mean the Chef Server software has finished installing.
Since this is a self signed certificate your browser may warn you about the security of the site. It’s okay to proceed, and ignore any warnings.
As a security mechanism to make sure people aren’t abusing your newly created Chef Server, you’ll need to provide the EC2 instance ID as a sort of password. That can be obtained inside of the AWS console, on the description tab of the instance. So I’ll just copy that and paste it into this field and submit.
The next page is a login page. And since this is the first time connecting in, I don’t have an account. So I need to click here to create one. Since I’ve already used the instance ID as the sort of password, the Chef Server assumes have permission to create an initial user. However the Chef server only allows you 1 hour after creating the Chef Server to get this account created. If you don’t get it done in that window you’ll have to SSH into the Chef Server reconfigure the Chef Server to reset the window. Don’t worry there will be information here in this box that will instruct you how.
So, I’ll use my pre-populated form, and agree to the license and I’ll submit this.
It’ll take just a moment, and when it’s complete it’ll require that I setup an Organization. An organization is the top of a hierarchy for managing role based access to the Chef Server. I’ll give it a name and an abbreviation. And then I’ll submit it.
The landing page here gives you a chance to download a starter kit. The starter kit takes a basic cookbook and bundles it with a newly generated SSH key for the logged in user
I don’t need a cookbook, since I have one already, so I’m not going to use that option. Instead I’ll go to the users option on the left side nav for the Administration tab. From here, I’ll click the Reset Key option. If you already have an existing key, doing this removes it. Once this generates the key, I can use the download button to download the key. Perfect, it’s now downloaded to my Downloads directory.
The reason for this key is so tools such as knife and berkshelf know how to interact with the server. This will allow them to push cookbooks to the server, among other things. Chef expects this key to be found inside the .chef directory inside your Chef Repo. So, I’ll move this file on the command line. With it moved, I can see that it exists if I look in my text editor under the .chef directory.
So what I’ve basically done is give Chef the keys to the house where the Chef Server lives, however I never told Chef where the house is located. For that I need edit the knife file in the .chef directory. If you don’t have a knife file, or even a .chef directory, you can create them manually.
Here’s what the knife file looks like, it has some properties and some generic info about cookbook paths, and log levels. However the property I care about at the moment are the client_key which wants to know the path and filename of the SSH key that I just downloaded. Mine is named ben.pem and it’s in the same directory as this file, so I’ve set the path to use the current directory/ben.pem. And then I also need to change the chef_server_url. This expects the URL to the server as well as the organization. The pattern is https://URL/organizations/abbreviation and the abbreviation is that short version of the organization name that I filled out just after creating the Chef Server account. Now I need to save this file.
With all of this done, if everything was done right, I can now have Chef download the trusted certs. The command is “knife ssl fetch” and it will add the Chef Server’s SSL cert as trusted cert.
Now, if all went well I can start using knife to interact with the Chef Server. I’ll start issuing the list command, and this will show the different components that I can list off. And I’ll add the clients to the end of this command and it returns one result, the ca-validator. The results are less important than the fact that it’s all running without error.
Okay, the goal for this lesson was to get a Chef Server up and running, and using the AWS hosted option from the AWS Marketplace, I’ve done that.
Let’s see how much recall from the lesson.
What’s the name of the directory that the SSH key, and knife.rb reside in?
…..
Chef will look in the .chef directory of the Chef Repository for the knife.rb file, and SSH key. And if any of those don’t exist you can manually create them. Keep in mind if you’re new to Linux a directory name starts with a period, it’s a hidden directory, so some user interfaces and text editors may hide it on you.
The next question is: which command was used to download the SSL certs from the Chef Server?
…..
The answer is the knife command with “ssl” subcommand and the “fetch” argument.
The final question is: Why is setting up knife so that it can connect to the Chef Server required?
….
The answer is that the knife command is going to be how you’ll interact with the Chef Server from your Workstation. It’ll allow you to upload cookbooks, bootstrap nodes, and tell nodes to run their cookbooks. So it’s kind of going to be your way of interacting with the Chef Server.
If I jump back to the Chef Server management UI you can see that there aren’t any Cookbooks. And there aren’t any nodes. And I need both. So in the next lesson I’ll create some nodes and the bootstrap Chef by using knife. So if you’re ready to keep learning, then let’s create some nodes in the next lesson.
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.