The Chef Supermarket is a publically available repository for community code that can help with building instructions for specific infrastructure.
- [Instructor] Returning back to the infrastructure we're concerned with building in this class, we've been talking about adding a load balancer to our Chef server. This load balancer is going to allow us to expand or scale our infrastructure. When it receives requests from the internet, it will relay those requests to an available web server. It's a great way to see how we can actually work with some more complex cookbooks. Now what needs to be done to actually set up this new load balancer? Well we have to write a cookbook that's full of the load balancer instructions.
Here you see that I'm actually going to talk about using a protocol called haproxy. Haproxy is an easy way to set up a software-based load balancer. Now to run out new load balancer cookbook, I'll also need a new note, which you saw me managing in EWS earlier in the class. But do we really want to reinvent the wheel? You should understand that there's a lot of code out there that people have already pulled apart and turned into community cookbooks.
Someone may have already written the cookbook that you need to get started configuring a particular piece of infrastructure. The community cookbook site is called the Supermarket and is available at supermarket.Chef.io You can think of the Supermarket as the GitHub of all things Chef. With community code you should always understand that community code is managed by individuals, whether it's on GitHub or on the Supermarket.
This means that Chef does not verify or approve cookbooks that are in the Supermarket, and therefore they may not work for your specific situation. However there's still a huge benefit to using community code to get started, building more complex pieces of infrastructure. Let's take a short tour of the Supermarket. At supermarket.chef.io you can actually search through all the community code that's available. For example, I'm interested in building a software-based load balancer.
In the search bar on the home page, I'm going to type in haproxy. You'll see that a number of cookbooks actually pop up that may be related to configuring a software-based load balancer. Let's take a look at the first result. Some things to look for here are: what version is it? When was it last updated? And also, who's responsible for maintaining this cookbook? You should always be aware of who build the cookbook that you're considering using.
In addition to this you want to make sure it supports the platform you're trying to configure. In particular, the first one listed is CentOS, so I feel pretty comfortable investigating the first result. Heading into the haproxy page on the Supermarket, you're confronted with the Readme. The Readme lists important details about versions of this cookbook, who's responsible for maintaining it, the last time it was updated, and licensing information. Scrolling through the Readme page, the first thing you're presented with after platform support are attributes.
Now this is quite interesting, and it reveals something that I haven't told you yet. Remember Ohai? Ohai collects host-specific details and build the node object. Well we don't just have to rely on attributes gathered by Ohai. We can also create our own. And what you're seeing here on the Readme is actually a list of attributes that can be used to configure the haproxy cookbook. For example, here we see that if we want to use this cookbook, we can define a node attribute called haproxy members.
This will be used by the default recipe to specify any members to add to our load balancer. What are members? Members are going to be the web servers that our load balancer redirects traffic to. What this means is we can use this configuration to actually set up a basic software-based load balancer. Now with this in mind I want you to be aware, I don't want you to actually go through and simply download this cookbook.
I'm going to show you another method of working with community code in the next section. Before we wrap up our tour of the Supermarket, a couple things. First, before you build any piece of infrastructure from scratch, always come to the Supermarket and see if someone's done that hard work for you. Second, I want to show you what the Supermarket actually is by clicking on the blue "view source" button. And you'll notice the supermarket is nothing more than a front for GitHub.
GitHub is where most of this code is actually stored. However, you should also be aware that the Supermarket itself is available as a GitHub project itself. If you were to search GitHub for the Supermarket, you'll find that the chef/supermarket itself is actually a community project. This means that you can clone the entire Supermarket and run it behind your firewall if you want a safe place to grab community code from.
- 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