Chef is an indispensable tool to manage your infrastructure. It consists of a set of tools that are designed to work together to enable you to model and manage your systems. This is a large space to fill, and Chef provides you with the tools to do this in a very flexible and powerful way. It achieves this through a combination of services, end host agents, a web interface, and command-line tools that work in unison to deliver an incredible suite of tools.
Chef's services are responsible for storing, managing, and distributing data about your infrastructure through an API. Endhost software agents that run on nodes (managed systems) are responsible for performing updates to systems, and the web interface, along with command-line tools, allows an administrator to edit and consume information that is vended by the API service.
One of the most attractive features of Chef is that you can leverage its API to easily integrate existing tools, or you can develop new tools to meet specific needs. Any organization with a moderate number of developer resources can harness the power of Chef to manage their systems. For example, one can easily build software to import data from Chef into a reporting tool of some form and dynamically reconfigure infrastructure based on a third-party tool's output—the sky's the limit. This is incredibly valuable to anybody who has an existing infrastructure because it provides a convenient path to integrate Chef into their environment.
There are a number of ways to access Chef. The quickest way for a single user to manage his/her infrastructure (virtual machines, a handful of hosts, and so on) is to use Chef-solo, a product geared towards single-user environments. In a small environment, setting up a hosted server is a good way to manage infrastructure automation among team members. If you need to, you can configure the hosted environment as a highly available system using load balancers and other technologies. Alternatively, if hosting the service yourself is not an option, you can use hosted Chef, a software-as-a-service (SaaS) model, thus paying for access to a hosted service.
Configuration management software was created to fill a need—managing infrastructure is a challenging task. Regardless of the scale you operate on, keeping track of software versions, upgrading systems, and generating consistent configuration data is a lot of work. It is tempting to update a configuration file on one system, only to forget to commit those changes somewhere, or to apply them to existing or future hosts. This is very convenient, but it quickly leads to inconsistency between hosts. When you are working with only one or two hosts, this may be acceptable. As such, a system grows from a few servers to dozens, hundreds, or possibly thousands—this type of system management does not scale due to time requirements and configuration errors that result from size and complexity.
Consider a scenario where you are migrating a database server to a new host. This would involve: bringing up a new host, installing all of the required software on your list to ensure it has parity with the old server (you did keep a list, right?), ensuring that your database server was configured with the same options, putting the correct firewall rules in place, tuning the filesystem, setting up monitoring tools, updating DNS records or changing web application configurations to point to the new host, and so on. Now imagine that, instead of one server in one data center, you have 10 database servers in 10 data centers, each with their own IP ranges, hardware configurations, and networking rules. Situations such as this are exactly why system configuration management software packages were developed: to make the lives of system administrators and engineers much easier.
This scenario, and many others like it, is where Chef is indispensable. Having the ability to describe your hosts, configuration data, and roles, and then apply that across as many hosts as you like means that you can manage large fleets of hosts just as easily as you can manage one or two.
Chapter 1, Installing Chef, introduces you to the architecture of Chef, various installation methods, and a guide to setting up Chef (solo and self-hosted). It includes information on using hosted Chef (and what that means for your team) and Vagrant with Chef-solo.
Chapter 2, Modeling Your Infrastructure, introduces how to model your infrastructure with Chef using your newly installed system. This chapter will cover modeling environments, small and large, as well as how to integrate with cloud technologies using Chef (AWS, Rackspace Cloud, and so on).
Chapter 3, Integrating with the Cloud, covers how Chef helps you scale your infrastructure using any combination of physical, virtual, and cloud-hosted systems. This chapter discusses how to use Chef to provision and manage hosts using cloud providers as easily as your local systems including AWS and Rackspace Cloud.
Chapter 4, Working with Cookbooks, covers how every Chef needs cookbooks—once your systems are part of your Chef-managed fleet, you can begin collecting, developing, and applying recipes to your hosts. It includes in-depth explanations of the structure and development of cookbooks and recipes, as well as how to test, publish, and share them.
Chapter 5, Testing Your Recipes, focuses on one compelling reason to use Chef to configure your infrastructure, that is, recipes are written in Ruby code and can be tested as any program would be tested. Here, you will learn how to test your recipes through a variety of testing mechanisms.
Chapter 6, From Development to Deployment, covers how to take a custom application from development to a production deployment with Chef. It contains a complete example that includes provisioning a web server, database server, and users as well as deploying code from source control.
Chapter 7, Beyond Basic Recipes and Cookbooks, delves into developing extensions to Chef through advanced concepts, including custom providers and resource types, using the Chef search engine, advanced scripting, and more.
Chapter 8, Extras You Need to Know, expands your knowledge of how to leverage Chef for infrastructure automation, complex systems integration, and securely storing and distributing sensitive data with Chef.
This book assumes that you are familiar with at least one programming language (it does not need to be a compiled language, and knowledge of an interpreted language will be suitable. Chef uses Ruby for its dynamic, scriptable components and any experience with Ruby will be valuable. However, having a strong understanding of program logic will provide you with the background to be productive with Chef.
For those who are not experts with Ruby, there will be a wide array of example listings that can be copied directly and executed as part of the book's offerings. This will enable you to use the examples without any previous Ruby experience. However, a working knowledge of Ruby will be needed in order to expand on the book's code examples or while writing your own recipes from scratch.
You will be walked through the steps required to install Chef on a Linux-based host. In order to be immediately successful, you will need administrative access to a host that runs a modern version of Linux; Ubuntu 13.10 is what will be used for demonstration purposes. If you are a more experienced reader, then a recent release of almost any distribution will work just as well (but you may be required to do a little bit of extra work that is not outlined in the book). If you do not have access to a dedicated Linux host, a virtual host (or hosts), running inside of virtualization software, such as VirtualBox will work.
Additionally, you will need access to the Internet to download software packages that you do not already have, as well as an installation of the Ruby programming language Version 1.9 or higher.
This book targets developers and system administrators who need to manage infrastructure and are looking to automate their system management. This includes infrastructure ranging in size from small-scale installations with a handful of hosts to multicontinent corporate IT systems with hundreds or even thousands of hosts. Anybody whose job involves maintaining systems will benefit from the concepts being covered.
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: "The search method has a similar format to the knife command."
A block of code is set as follows:
all_users = search(:users, 'id:*') users_s = search(:users, 'id:s*') all_nodes = search(:node, '*')
Any command-line input or output is written as follows:
$ knife data bag show credentials aws
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 there, a tab labeled Chef Server will be present at the top of the page."
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 <[email protected]>, 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.
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 <[email protected]> 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 <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.