In this video, learn about Chef and why it has become a very popular configuration management platform.
- [Narrator] With a basic understanding of configuration management principles, we're now ready to talk about how Chef describes your infrastructure as code. Chef as a platform allows you to manage any server component. We describe these server components, such as packages, files, services, users, and groups, as system resources. These system resources are going to be represented as code components. Because we're able to represent infrastructure configurations as code, our infrastructure itself becomes versionable, testable, and repeatable.
I want to give you an overview of some of the components we'll be working with in this class. We should understand the Workstation, the Chef Server, and any of its managed nodes. Looking at an overview of the Chef Architecture, essentially, I want you to understand that a Workstation is where we'll actually be developing and testing our Chef code. Later on in the class, we'll be working with a Chef Server. We will upload all of our code to the Chef Server.
It will store all of our Chef code and then distribute it to any various managed nodes. Nodes themselves are what run our Chef code. So, let's look at an overview of each of these components. The Workstation, again, is where you will develop and test your code. Essentially, the Workstation is going to be configured with all the command-line Chef tools you might need to get started developing Chef code.
This is where we'll author and test our recipes and cookbooks for Chef. And we can interact with the Chef Server and managed nodes from a Workstation. We'll set up a Workstation in a moment, but essentially, all you have to do is install the Chef Development Kit. The Chef Server itself is going to be a hub for all of our policy that describes how we should configure our infrastructure. It's going to store some of the topics we'll talk about in this class: cookbooks, roles, environments, and some other policies themselves that you might need to configure your nodes.
Essentially, it can index information about your nodes as metadata, and it acts as a pull server for all of your nodes. It will store all of our policy, and all of our nodes will pull it from the Chef Server. In principle, this means that all of the nodes, the Chef Server clients, actually configure themselves, meaning that the nodes do all the heavy lifting. This makes the Chef Server highly scalable.
If the term node is confusing to you at all, understand that a node is just a generic term for any machine that we actually manage with Chef. These nodes can be physical, virtual, cloud instances, or even network devices, containers, et cetera. They use the chef-client, a service we'll talk about later on, to pull and apply policy from the Chef Server. When a node pulls policy from the Chef Server, it's called the process of convergence.
Convergence is a term we'll use to actually describe applying our Chef code. The node itself actually has a method to gather details about it that the Chef Server will store to make it easy to tell all of our nodes apart. We'll talk about the Ohai tool later in class. Now that we understand the components that we'll be working with, the Workstation, the Chef Server, and Nodes, we should also understand some basic concepts and terms we'll be covering in this class.
By the end of it, I hope you'll be very familiar with the terms resource, recipe, cookbook, and node attributes. We'll be talking about these topics in some depth. To review, the Chef Ecosystem itself consists of the primary components called Workstation, Chef Server, and any managed nodes. Again, the Workstation is where we'll actually develop Chef code. And then, we'll upload it from a Workstation to a Chef Server.
The Chef Server itself will then distribute your cookbooks to the nodes that it's managing. A node is something that can run our Chef code, and when a node converges, it's the process of pulling any information it needs from the Chef Server and applying those policies. With this overview in place, let's jump in to actually understanding how the Chef model works.
- Configuration management
- Using Chef
- Installing the Chef development kit (ChefDK)
- Provisioning a CentOS instance
- Using recipes and the Apache cookbook
- Working with nodes and node objects
- Using templates and embedded Ruby
- Hosting a Chef server
- Provisioning nodes with AWS
- Testing deployments with Kitchen
- Exploring the Chef Supermarket
- Resolving dependencies with Berkshelf
- Working with server roles, environments, and data bags