The core philosophy behind configuration management systems has its roots in the US Department of Defense, where it was adopted as a technical management discipline. Today, the philosophy has been adopted by many other disciplines, including systems and software engineering. The basic idea behind a configuration management system is to establish and maintain the consistency of a system or product throughout its lifetime. The following are the fundamental activities associated with any configuration management system:
The purpose of configuration management systems is to ensure that the state of the system isn't residing in the minds of people, but inside a revision control system, from which it's easy to figure out the current state of the system along with the changes that have been made to the underlying system over the course of time. It not only allows to record "what" changes were made, but also "why" the changes were made.
With a phenomenal increase in the usage of cloud platforms, new challenges have emerged for system architects, as they now need to design systems that are able to scale up the size of the infrastructure upon the demands laid down by the application's needs, and the manual configuration of systems in such a dynamic environment is just not possible.
Chef is a configuration management system developed by Opscode and is one of the most widely used systems in its category. It allows you to define the infrastructure as a code, and it can be used to build, deploy, and automate your infrastructure. With Chef, the infrastructure becomes as versionable, testable, and repeatable as an application code.
Mastering Chef is an attempt to provide in-depth knowledge of the underlying system. It provides users with insights into different components of the underlying system and also provides users with insight into the APIs that can be used to either extend Chef, or build toolsets around the ecosystem.
Chapter 1, Introduction to the Chef Ecosystem, serves as a reference to new users of Chef. After a brief introduction, we jump into the anatomy of a chef-client run and at the end, we'll see how to go about setting up our workstation for the development of a Chef code that is thoroughly tested before being pushed to the production environment.
Chapter 2, Knife and Its Associated Plugins, introduces the reader to one of the most widely used tools in the Chef ecosystem, called Knife. We will learn to use Knife to bootstrap instances and also learn about different plugins that can be used to accomplish daily routine tasks in a more efficient way.
Chapter 3, Chef and Ruby, brings a user up to speed with the required Ruby knowledge, thereby allowing them to write a more efficient infrastructure code. By the end of this chapter, the user will be equipped with enough knowledge of Ruby to extend the code for infrastructure provisioning, beyond what can be accomplished by merely using the DSL provided by Chef.
Chapter 4, Controlling Access to Resources, introduces the concept of organization, groups, and users, and explains how you can allow fine-grained access to different types of objects residing on the Chef server.
Chapter 5, Starting the Journey to the World of Recipes, introduces the reader to the most fundamental unit of code written by Chef developers—"recipes". We'll learn about the different components of a recipe and get an understanding of the different resources that can be used to manage our infrastructure.
Chapter 6, Cookbooks and LWRPs, introduces users to cookbooks and how you can extend chef-client through the use of lightweight resource/provider. Readers will also learn how to create their own custom LWRPs by the end of this chapter.
Chapter 7, Roles and Environments, explains that, most of the time, a server is not just associated with one particular task and can perform many different operations. For example, you might have a web server that is also performing the role of an application server and a proxy. Roles allow users to attach multiple recipes to a server. Also, in most organizations, infrastructure is classified into different environments depending upon the use. For example, an organization might have a dev, QA, staging, and production environment. The configuration of applications running across these environments will be different to some extent. This chapter will explain what a role is, how we can group multiple recipes in a role, and how to use roles inside a recipe to do things conditionally. We'll also learn how you can manage different environments in your infrastructure using Chef.
Chapter 8, Attributes and Their Uses, explains that every service and a server can be identified with a role and set of properties associated with it. Some properties are system specific, such as the IP address, kernel, hostname, and so on. While they are necessary, an effective infrastructure code always needs more properties that can define the services and the server itself in a more precise manner. In this chapter, we'll see what the different types of attributes are and how to override values of the attributes.
Chapter 9, Ohai and Its Plugin Ecosystem, explains that as part of a chef-client run, many details related to the underlying system, such as architecture, operating system, network details, filesystem, and so on, are required to be collected by Chef. Ohai is a tool that allows for this. In this chapter, we'll learn about Ohai and its plugin-based architecture and associated plugins. We'll also learn how to write our own custom Ohai plugins.
Chapter 10, Data Bags and Templates, explains that in highly dynamic environments such as cloud, a configuration management system is only as good as its support for allowing the specification of the configuration in a form that is dynamic. Templates are just what the doctor ordered for this use case. Data bags, on the other hand, are data stores containing the data stored in a JSON format. In this chapter, we'll learn how to make effective use of databags and templates to define our infrastructure.
Chapter 11, Chef API and Search, explains that the Chef API is perhaps one of the most powerful features of Chef. Chef has a really wonderful API and its search facility is what makes it really fun to use. There are lots of cases where you can make use of Chef's API to build tools that can help in the efficient automation of the tasks. In this chapter, we'll look at Chef's API, using search in a recipe using Chef API, and also using a search through Knife.
Chapter 12, Extending Chef, covers the writing of a custom code suited for our requirements that will help us to extend the functionality of Chef. We'll learn how to write custom Knife plugins and custom Chef handlers.
Chapter 13, (Ab)Using Chef, explores some fun uses of Chef, which will allow an increase in productivity, while managing a large scale infrastructure. We'll see how we can extend tools such as Capistrano by using Chef API. We'll also learn how to manage large distributed clusters using an extension of Chef called Ironfan. We will also look at tools such as the Push Job server, which can be used for the orchestration of chef-client runs across a set of instances.
All the code in this book is written/tested against Chef 12.x. A basic list of software required to run the code in this book is as follows:
Operating system: Mac OS X/Linux/Windows
Ruby: 1.9.3+
Chef: 12.x
Git
Editor: Atom/Sublime/Vi/Emacs/TextMate
This is a book for anyone who is interested in learning about Chef. You are not required to have any prior experience with the use of Chef or any configuration management system. You aren't expected to have experience with programming in Ruby; however, some experience with the fundamentals of programming will definitely be helpful.
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "Let's see what the knife command has to offer to us."
A block of code is set as follows:
knife[:aws_access_key_id] = "AWS_ACCESS_KEY" knife[:aws_secret_access_key] = "AWS_SECRET_KEY"
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
node_name 'mayank'
client_key '~/keys/chef/mayank.pem'
validation_client_name 'chef-validator'Any command-line input or output is written as follows:
$ knife search '*:*'
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "Once you are done with it, click on the Create Role button."
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <feedback@packtpub.com>, and mention the book title via the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the errata submission form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <copyright@packtpub.com> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
You can contact us at <questions@packtpub.com> if you are having a problem with any aspect of the book, and we will do our best to address it.
