Pro Puppet (2011).pdf

The eXPeRT’s VOIce ® In OPen sOuRce

Pro

Puppet

Maximize and customize Puppet’s

capabilities for your environment

James Turnbull and Jeffrey McCune

For your convenience Apress has placed some of the front

matter material after the index. Please use the Bookmarks

and Contents at a Glance links to access them.

 CONTENTS AT A GLANCE

Contents at a Glance

 About the Authors ................................................................................................ xiii

 About the Technical Reviewer ............................................................................. xiv

 Acknowledgments ................................................................................................ xv

 Introduction ......................................................................................................... xvi

 Chapter 1: Getting Started with Puppet .................................................................. 1

 Chapter 2: Building Hosts with Puppet ................................................................. 29

 Chapter 3: Working with Environments ................................................................ 65

 Chapter 4: Puppet Scalability ............................................................................... 89

 Chapter 5: Externalizing Puppet Configuration................................................... 119

 Chapter 6: Exporting and Storing Configuration ................................................. 133

 Chapter 7: Puppet Consoles: Puppet Dashboard and The Foreman.................... 159

 Chapter 8: Tools and Integration ........................................................................ 189

 Chapter 9: Reporting with Puppet ...................................................................... 231

 Chapter 10: Extending Facter and Puppet .......................................................... 241

 Chapter 11: Marionette Collective ...................................................................... 265

 Appendix A: Working with Puppet ...................................................................... 289

 Index ................................................................................................................... 293

 INTRODUCTION

Introduction

“ssh in a for loop is not a solution” – Luke Kanies, Puppet developer

The lives of system administrators and operations staff often revolve around a series of repetitive tasks:

configuring hosts, creating users, and managing applications, daemons, and services. Often these tasks

are repeated many times in the life cycle of one host, from building to decommissioning, and as new

configuration is added or corrected for error or entropy.

The usual response to these repetitive tasks is to try to automate them with scripts and tools. This

leads to the development of custom-built scripts and applications. In my first role as a systems

administrator, I remember creating a collection of Control Language (CL) and Rexx scripts that I

subsequently used to manage and operate a variety of infrastructure. The scripts were complex, poorly

documented and completely customized to my environment.

My experience is not unique, and this sort of development is a common response to the desire to

make life easier, automate boring, manual tasks and give you a few more minutes in the day for the more

interesting projects and tasks (or to get to the pub earlier).

Very few of the scripts developed in this ad hoc manner are ever published, documented, or reused.

Indeed, copyright for most custom material rests with the operator or system administrator’s

organization and is usually left behind when they move on. This leads to the same tool being developed

over and over again. Sometimes they are even developed over and over again in the same company if

previous incarnations don’t suit a new incumbent (or occasionally, if they are indecipherable to a new

incumbent!).

These custom scripts and applications rarely scale to suit large environments, and they often have

issues of stability, flexibility, and functionality. In multi-platform environments, such scripts also tend to

suit only one target platform, resulting in situations such as the need to create a user creation script for

BSD, another one for Linux, and still another for Solaris. This increases the time and effort required to

develop and maintain the very tools you are hoping to use to reduce administrative efforts.

Other approaches include the purchase of operations and configuration management tools like

HP’s Opsware, BMC’s CONTROL-M, IBM’s Tivoli suite, and CA’s Unicenter products. But commercial

tools generally suffer from two key issues: price and flexibility. Price, especially, can quickly become an

issue: The more platforms and hosts that you are managing, the greater the price. In large

environments, licensing for such tools can run to millions of dollars.

Flexibility is also a key concern. Commercial tools are usually closed source and are limited to the

features available to them, meaning that if you want to extend them to do something custom or specific

to your environment, you need to request a new feature, potentially with a waiting period and associated

cost. Given the huge varieties of deployments, platforms, configurations and applications in

organizations, it is rare to discover any tool that provides the ability to completely customize to suit your

environment.

There is an alternative to both in-house development and commercial products: Free and Open

Source Software (FOSS). Free and open source configuration management tools offer two key benefits

for organizations:

xvi

 INTRODUCTION

•

They are open and extensible.

•

They are free!

With FOSS products, the tool’s source code is at your fingertips, allowing you to develop your own

enhancements or adjustments. You don’t need to wait for the vendor to implement the required

functionality or pay for new features or changes. You are also part of a community of users and

developers who share a vision for the development of the tool. You and your organization can in turn

contribute to that vision. In combination, you can shape the direction of the tools you are using, giving

you a more flexible outcome for your organization.

The price tag is another important consideration for acquisition of any tool. With free and open

source software, it isn’t an issue. You don’t pay anything for the software, and you get the source code

with it.

Of course, we all know there is no such thing as a free lunch, so what’s the catch? Well unlike

commercial software, open source software doesn’t come with any guaranteed support. This is not to

say there is no support available: Many open source tools have large and active communities where

members answer questions and provide assistance via mechanisms like email lists, forums, Wikis and

IRC.

 Note Many open source tools, including Puppet, also have organizations that provide commercial editions or

support for these tools. For full disclosure, both the author James Turnbull and co-author Jeff McCune work at

Puppet Labs, the organization that supports the development of Puppet.

Puppet ( http://www.puppetlabs.com/puppet ) is a reaction to these gaps in the tools available to

SysAdmins, Operators and Developers. It is designed to make their lives easier by making infrastructure

easy, simple and cheap to manage. This book will introduce you to Puppet, an open source

configuration management tool, and take you through installation, configuration and integration of

Puppet into your environment.

xvii

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: