34,79 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Puppet is a configuration management tool that allows you to automate all your IT configurations, giving you control over what you do to each Puppet Agent in a network, and when and how you do it. In this age of digital delivery and ubiquitous Internet presence, it's becoming increasingly important to implement scalable and portable solutions, not only in terms of software, but also the systems that run it. The free Ruby-based tool Puppet has established itself as the most successful solution to manage any IT infrastructure. Ranging from local development environments through complex data center setups to scalable cloud implementations, Puppet allows you to handle them all with a unified approach.
Puppet 4 Essentials, Second Edition gets you started rapidly and intuitively as you’ll put Puppet’s tools to work right away. It will also highlight the changes associated with performance improvements as well as the new language features in Puppet 4.
We’ll start with a quick introduction to Puppet to get you managing your IT systems quickly. You will then learn about the Puppet Agent that comes with an all-in-one (AIO) package and can run on multiple systems. Next, we’ll show you the Puppet Server for high-performance communication and passenger packages. As you progress through the book, the innovative structure and approach of Puppet will be explained with powerful use cases. The difficulties that are inherent to a complex and powerful tool will no longer be a problem for you as you discover Puppet's fascinating intricacies.
By the end of the book, you will not only know how to use Puppet, but also its companion tools Facter and Hiera, and will be able to leverage the flexibility and expressive power implemented by their tool chain.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 305
Veröffentlichungsjahr: 2015
Ähnliche
Table of Contents
Puppet 4 Essentials Second Edition
Puppet 4 Essentials Second Edition
Copyright © 2015 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: November 2014
Second edition: December 2015
Production reference: 1071215
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78588-110-7
www.packtpub.com
Credits
Authors
Felix Frank
Martin Alfke
Reviewer
Ger Apeldoorn
Acquisition Editor
Nadeem Bagban
Content Development Editor
Sumeet Sawant
Technical Editor
Menza Mathew
Copy Editors
Angad Singh
Alpha Singh
Project Coordinator
Shweta H Birwatkar
Proofreader
Safis Editing
Indexer
Tejal Daruwale Soni
Production Coordinator
Melwyn Dsa
Cover Work
Melwyn Dsa
About the Authors
Felix Frank has used and programmed computers for most of his life. During and after working on his computer science diploma, he gained experience on the job as a systems administrator, server operator, and open source software developer. He spent 6 years of his 11-year career as a Puppet power user. In parallel, he spent about two years intensifying his studies through ongoing source code contributions and active participation in several conferences.
For making this title possible in the first place, and for their ongoing support, I'd like to thank my editors, Nadeem Bagban and Arwa Manasawala. Also, this book would not be what it is without the amazing feedback from my reviewers.
For their kind feedback and ongoing support, I'd also like to thank a number of Puppet Labs employees: Michael Smith, Peter Huene, Josh Cooper, Andrew Parker, Adrien Thebo, Dawn Foster, Kara Sowles, Joshua Partlow, Henrik Lindberg, Charlie Sharpsteen, Nigel Kersten, Kylo Ginsberg, Ethan Brown, Rob Reynolds, Jeff McCune, and Eric Sorenson. Special thanks to Luke Kanies for creating Puppet and dedicating so many resources to this amazing community.
Further thanks go to Waltraut Niepraschk and the whole datacenter staff at DESY Zeuthen for getting me on track with the central management of UNIX servers. Thanks also to mpex for giving me the opportunity to learn a lot about Puppet, and ultimately, write this very book.
Martin Alfke is co-founder and CEO of example42 GmbH. He is a Puppet and automation enthusiast since 2007. In the past, he would have said he is a "system administrator". Nowadays, he likes the term "infrastructure engineer". The big difference is that system administrators sshs into systems to fix them, whereas infrastructure engineers fix their automation.
Martin is serving as a Puppet Labs' training partner in Germany since 2011, conducting official Puppet training. In his spare time, he likes reading books and visiting interesting locations.
About the Reviewer
Ger Apeldoorn is a freelance Puppet consultant and teaches official Puppet Labs courses in the Netherlands. He has helped many companies implement Puppet (both Open Source and Enterprise), and has conducted talks at PuppetConf, PuppetCamps, FOSDEM, and other conferences. You can go through his official website at http://puppetspecialist.nl.
www.PacktPub.com
Support files, eBooks, discount offers, and more
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why subscribe?
Free access for Packt account holders
If you have an account with Packt atwww.PacktPub.com, you can use this to access PacktLib today and view 9entirely free books. Simply use your login credentials for immediate access.
Preface
The software industry is changing and so are the related fields. Old paradigms are slowly giving way to new roles and shifting views on what the different professions should bring to the table. The DevOps trend pervades more and more workflows. Developers set up and maintain their own environments. Operations raise automation to new levels and translate whole infrastructures to code.
A steady stream of new technologies allows for ever-evolving, more efficient organizational principles. One of these is Puppet. Its fresh take on server configuration management caused a rapid adoption and distribution throughout the industry. In the few years of its existence, Puppet has managed to rally thousands of users who employ it in numerous contexts to achieve manifold results. While it is not the only configuration management system available, it is certainly the most widespread by now.
From its specialized language, to the system that makes it work, Puppet has innovated and rapidly conquered. Its extendible structure, paired with a large and helpful community, has made Puppet a powerhouse of easy configuration. The more well known a software is, the greater the chance that Puppet will deploy and configure it out of the box.
Puppet's own learning curve is not sharp, and the available documentation is not only extensive, but also of high quality. Nevertheless, even experienced programmers and administrators can face difficulties at some point. Advanced use may require the navigation of some intricacies that stem from Puppet's unique modeling approach.
This book aims to impart all the knowledge required to tap into not only the basics of Puppet, but also its core. The very ideas and principles of Puppet-based designs are explored and explained. Sophisticated tooling is presented to enable efficient and productive use. The reader is rapidly introduced to and familiarized with a whole range of Puppet-centric technology.
What this book covers
Chapter 1, Writing Your First Manifests, is an introduction to the core concepts of Puppet, including a syntax tutorial. You will learn to write and use Puppet manifests within a few pages.
Chapter 2, The Master and Its Agents, is a quick how-to guide to setting up all the required components for a distributed Puppet infrastructure. In this chapter, you will learn to create the master and an agent, and set up puppetserver.
Chapter 3, A Peek under the Hood Facts, Types, and Providers, covers a summary of the core components that give Puppet its flexibility, as well as its ease of use and extension. You will also be able to understand the principles of Puppet's function.
Chapter 4, Modularizing Manifests with Classes and Defined Types, helps you learn the most important structural elements of Puppet manifests. Find out how to use them for best results.
Chapter 5, Extending Your Puppet Infrastructure with Modules, takes you on a tour of downloadable extensions, with a guide to making your own. Extend Puppet to your specific needs.
Chapter 6, Leveraging the Full Toolset of the Language, teaches you to interpret and use language features beyond the basics.
Chapter 7, New Features from Puppet 4 helps you learn about the new Type system and data processing features. It also helps you to understand the deprecations and what to change to make use of the new features.
Chapter 8, Separating Data from Code Using Hiera, gives you an introduction to the powerful configuration data storage that comes with Puppet. In this chapter, you will learn to model your infrastructure naturally in a hierarchy.
What you need for this book
To follow the examples, it is enough to use a computer with sufficient resources to run two or more virtual machine instances. The virtualization guests should have a connection to the internet and each other. The configuration examples are tailored to the Debian GNU/Linux operating system in version 7, code name "Wheezy".
Who this book is for
This book assumes that the reader possesses no prior Puppet knowledge. Readers should have a sound technical background though. Experience with the GNU/Linux command line is required. Existing programming skills are recommended.
This book is also suitable for beginner or intermediate level Puppet users who wish to expand their knowledge of the software. It can serve as a guide for veteran users who wish to learn about the new features in the Puppet 4.x series of releases.
Conventions
In this book, you will find a number of text styles 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: "With all your Hiera data in place, you can now include the demo class from your site.pp (or an equivalent) file indiscriminately."
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "The ability to enumerate classes for each node to include is what Puppet's External Node Classifiers (ENCs) had originally been conceived for."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in 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 at www.packtpub.com/authors.
Customer support
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.
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. 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.
Errata
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 could 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 to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted 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.
Questions
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.
Chapter 1. Writing Your First Manifests
Over the last few years, configuration management has become increasingly significant to the IT world. Server operations in particular is hardly even feasible without a robust management infrastructure. Among the available tools, Puppet has established itself as one of the most popular and widespread solutions. Originally written by Luke Kanies, the tool is now distributed under the terms of Apache License 2.0 and maintained by Luke's company, Puppet Labs. It boasts a large and bustling community, rich APIs for plugins and supporting tools, outstanding online documentation, and a great security model based on SSL authentication.
Like all configuration management systems, Puppet allows you to maintain a central repository of infrastructure definitions, along with a toolchain to enforce the desired state on the systems under management. The whole feature set is quite impressive. This book will guide you through some steps to quickly grasp the most important aspects and principles of Puppet.
In this chapter, we will cover the following topics:
Getting started
Installing Puppet is easy. On large Linux distributions, you can just install the Puppet package via apt-get or yum.
The installation of Puppet can be done in the following ways:
The former way is generally simpler. Chapter 2, The Master and Its Agents, provides simple instructions to install the Puppet Labs packages. A platform-independent way to install Puppet is to get the puppet Ruby gem. This is fine for testing and managing single systems, but is not recommended for production use.
After installing Puppet, you can use it to do something for you right away. Puppet is driven by manifests, the equivalent of scripts or programs, written in Puppet'sdomain-specific language (DSL). Let's start with the obligatory Hello, world! manifest:
Tip
Downloading the example code
You can download the example code files for all the Packt Publishing 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 yourself to have the files e-mailed directly to you.
To put the manifest to work, use the following command. (We avoided the term "execute" on purpose—manifests cannot be executed. More details will follow around the middle of this chapter.):
Before we take a look at the structure of the manifest and the output from the puppet apply command, let's do something useful, just as an example. Puppet comes with its own background service. Let's assume that you want to learn the basics before letting it mess with your system. You can write a manifest to have Puppet make sure that the service is not currently running and will not be started at system boot:
To control system processes, boot options, and the like, Puppet needs to be run with root privileges. This is the most common way to invoke the tool, because Puppet will often manage OS-level facilities. Apply your new manifest with root access, either through sudo, or from a root shell, as shown in the following transcript:
Now, Puppet has disabled the automatic startup of its background service for you. Applying the same manifest again has no effect, because the necessary steps are already complete:
This reflects a standard behavior in Puppet: Puppet resources are idempotent—which means that every resource first compares the actual (system) with the desired (puppet) state and only initiates actions in case there is a difference (configuration drift).
You will often get this output, as shown previously, from Puppet. It tells you that everything is as it should be. As such, this is a desirable outcome, like the all clean output from git status.
Introducing resources and properties
Each of the manifests you wrote in the previous section declared one respective resource. Resources are the elementary building blocks of manifests. Each has a type (in this case, notify and service, respectively) and a name or title (Hello, world! and puppet). Each resource is unique to a manifest, and can be referenced by the combination of its type and name, such as Service["puppet"]. Finally, a resource also comprises a list of zero or more attributes. An attribute is a key-value pair, such as "enable => false".
Attribute names cannot be chosen arbitrarily. Each resource type supports a specific set of attributes. Certain parameters are available for all resource types (metaparameters), and some names are just very common, such as ensure. The service type supports the ensure property, which represents the status of the managed process. Its enabled property, on the other hand, relates to the system boot configuration (with respect to the service in question).
Note that we have used the terms attribute, property, and parameter in a seemingly interchangeable fashion. Don't be deceived—there are important distinctions. Property and parameter are the two different kinds of attributes that Puppet uses. You have already seen two properties in action. Let's look at a parameter:
The provider parameter tells Puppet that it needs to interact with the upstart subsystem to control its background service, as opposed to systemd or init. If you don't specify this parameter, Puppet makes a well-educated guess. There is quite a multitude of supported facilities to manage services on a system. You will learn more about providers and their automatic choosing later on.
The difference between parameters and properties is that the parameter merely indicates how Puppet should manage the resource, not what a desired state is. Puppet will only take action on property values. In this example, these are ensure => 'stopped' and enable => false. For each such property, Puppet will perform the following tasks:
A property is considered to be in sync when the system entity that is managed by the given resource (in this case, the upstart service configuration for Puppet) is in the state that is described by the property value in the manifest. In this example, the ensure property will be in sync only if the puppet service is not running. The enable property is in sync if upstart is not configured to launch Puppet at system start.
As a mnemonic concerning parameters versus properties, just remember that properties can be out of sync, whereas parameters cannot.
Puppet also allows you to read your existing system state by using the puppet resource command:
Please note that some resource types will return read-only attributes (for example, the file resource type will return mtime and ctime). Refer to the appropriate type documentation.
Interpreting the output of the puppet apply command
As you have already witnessed, the output presented by Puppet is rather verbose. As you get more experienced with the tool, you will quickly learn to spot the crucial pieces of information. Let's first take a look at the informational messages though. Apply the service.pp manifest once more:
Puppet took no particular action. You only get two timings: one, from the compiling phase of the manifest, and the other, from the catalog application phase. The catalog is a comprehensive representation of a compiled manifest. Puppet bases all its efforts concerning the evaluation and syncing of resources on the content of its current catalog.
Now, to quickly force Puppet to show you some more interesting output, pass it a one-line manifest directly from the shell. Regular users of Ruby or Perl will recognize the call syntax:
Note
We prefer double quotes in manifests that get passed as command-line arguments, because on the shell, the manifest should be enclosed in single quotes as a whole.
You instructed Puppet to perform yet another change on the Puppet service. The output reflects the exact change that was performed. Let's analyze this log message:
Dry-testing your manifest
Another useful command-line switch for puppet apply is the --noop option. It instructs Puppet to refrain from taking any action on unsynced resources. Instead, you only get a log output that indicates what will change without the switch. This is useful in determining whether a manifest would possibly break anything on your system:
Note that the output format is the same as before, with a (noop) marker trailing the notice about the sync action. This log can be considered a preview of what will happen when the manifest is applied without the --noop switch.
The additional notices about triggered refreshes will be described later and can be ignored for the moment. You will have a better understanding of their significance after finishing this chapter and Chapter 4, Modularizing Manifests with Classes and Defined Types.
Adding control structures in manifests
You have written three simple manifests while following the instructions in this chapter so far. Each comprised only one resource, and one of them was given on the command line using the -e option. Of course, you would not want to write distinct manifests for each possible circumstance. Instead, just as how Ruby or Perl scripts branch out into different code paths, there are structures that make your Puppet code flexible and reusable for different circumstances.
The most common control element is the if/else block. It is quite similar to its equivalents in many programming languages:
The Puppet DSL also has a case statement, which is reminiscent of its counterparts in other languages as well:
A variation of the case statement is the selector. It's an expression, not a statement, and can be used in a fashion similar to the ternary if/else operator found in C-like languages:
It should be used with caution, because in more complex manifests, this syntax will impede readability.
