Book Overview & Buying
Table Of Contents

Puppet 5 Essentials Third Edition - Third Edition

By : Felix Frank, Martin Alfke

1 (1)

Buy this Book

Puppet 5 Essentials Third Edition

1 (1)

By: Felix Frank, Martin Alfke

Buy this Book

Overview of this book

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 scaleable and portable solutions, not only in terms of software, but also the system that runs it. This book gets you started quickly with Puppet and its tools in the right way. It highlights improvements in Puppet and provides solutions for upgrading. It starts with a quick introduction to Puppet in order to quickly get your IT automation platform in place. Then you learn about the Puppet Agent and its installation and configuration along with Puppet Server and its scaling options. The book adopts an innovative structure and approach, and Puppet is explained with flexible use cases that empower you to manage complex infrastructures easily. Finally, the book will take readers through Puppet and its companion tools such as Facter, Hiera, and R10k and how to make use of tool chains.

Preface

What this book covers

What you need for this book

Who this book is for

Conventions

Reader feedback

Customer support

Free Chapter

Writing Your First Manifests

Getting started

Introducing resources, parameters, and properties

Interpreting output of the puppet apply command

Using variables

Adding control structures in manifests

Controlling the order of execution

Implementing resource interaction

Examining Puppet core resource types

Summary

Puppet Server and Agents

The Puppet server

Setting up the Puppet agent

Performance optimizations

Completing the stack with PuppetDB

The Puppet CA

Summary

A Peek into the Ruby Part of Puppet - Facts, Types, and Providers

Putting it all together - collecting system information with Facter

Accessing and using fact values

Extending Facter with custom facts

Simplifying things using external facts

Goals of Facter

The resource type's life cycle on the agent side

Command execution control with providers

Summarizing types and providers

Summary

Combining Resources in Classes and Defined Types

Introducing classes and defined types

Design patterns

Including classes from defined types

Ordering and events among classes

Ordering containers

Limitations

Making classes more flexible through parameters

Summary

Combining Classes, Configuration Files, and Extensions into Modules

The contents of Puppet's modules

Managing environments

Building a component module

Replacing a defined type with a native type

Enhancing Puppet's system knowledge through facts

Refining the interface of your module through custom functions

Making your module portable across platforms

Finding helpful Forge modules

Summary

The Puppet Beginners Advanced Parts

Building dynamic configuration files

Managing file snippets

Using virtual resources

Cross-node configuration with exported resources

Setting defaults for resource parameters

Avoiding antipatterns

Summary

New Features from Puppet 4 and 5

Upgrading to Puppet 4

Learning lambdas and functions

Creating Puppet 4 functions

Leveraging the new template engine

Handling multiline with HEREDOC

Using Puppet 5 server metrics

Breaking old practices

Summary

Separation of Code and Data with Hiera

Understanding the need for separate data storage

Building hierarchical data structures

Fetching data from classes

Debugging data lookups

Managing resources from data

Summary

Puppet Roles and Profiles

Technical component modules

Implementing components in profiles

The business use case and node classification

Building roles from profiles

Placing code on the Puppet server

Summary

Technical component modules

Until now, we have referred to modules as a strict directory structure containing classes, static files, templates, and extensions. We now must differentiate between upstream or generic modules and our platform implementation modules.

Modules that take care of a specific technical component are now referred to as technical component modules. Technical components themselves are a set of configurations for a certain software running on a system, such as Nginx, Postgres, or LDAP.

There has always been the problem of whether a module is a technical component module or not. There are some patterns that allow you to identify technical component modules: