Book Image

Puppet 5 Beginner's Guide - Third Edition

By : John Arundel
Book Image

Puppet 5 Beginner's Guide - Third Edition

By: John Arundel

Overview of this book

Puppet 5 Beginner’s Guide, Third Edition gets you up and running with the very latest features of Puppet 5, including Docker containers, Hiera data, and Amazon AWS cloud orchestration. Go from beginner to confident Puppet user with a series of clear, practical examples to help you manage every aspect of your server setup. Whether you’re a developer, a system administrator, or you are simply curious about Puppet, you’ll learn Puppet skills that you can put into practice right away. With practical steps giving you the key concepts you need, this book teaches you how to install packages and config files, create users, set up scheduled jobs, provision cloud instances, build containers, and so much more. Every example in this book deals with something real and practical that you’re likely to need in your work, and you’ll see the complete Puppet code that makes it happen, along with step-by-step instructions for what to type and what output you’ll see. All the examples are available in a GitHub repo for you to download and adapt for your own server setup.
Table of Contents (21 chapters)
Puppet 5 Beginner's Guide Third Edition
Credits
About the Author
Acknowledgments
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface
Index

The hierarchy


So far, we've only used a single Hiera data source (common.yaml). Actually, you can have as many data sources as you like. Each usually corresponds to a YAML file, and they are listed in the hierarchy section of the hiera.yaml file, with the highest-priority source first and the lowest last:

hierarchy:
  ...
  - name: "Host-specific data"
    path: "nodes/%{facts.hostname}.yaml"
  - name: "OS release-specific data"
    path: "os/%{facts.os.release.major}.yaml"
  - name: "OS distro-specific data"
    path: "os/%{facts.os.distro.codename}.yaml"
  - name: "Common defaults"
    path: "common.yaml"

In general, though, you should keep as much data as possible in the common.yaml file, simply because it's easier to find and maintain data if it's in one place, rather than scattered through several files.

For example, if you have some Hiera data which is only used on the monitor node, you might be tempted to put it in a nodes/monitor.yaml file. But, unless it has to override some settings...