Book Image

Mastering Puppet 5

By : Ryan Russell-Yates, Jason Southgate
Book Image

Mastering Puppet 5

By: Ryan Russell-Yates, Jason Southgate

Overview of this book

Puppet is a configuration management system and a language written for and by system administrators to manage a large number of systems efficiently and prevent configuration drift. The core topics this book addresses are Puppet's latest features and mastering Puppet Enterprise. You will begin by writing a new Puppet module, gaining an understanding of the guidelines and style of the Puppet community. Following on from this, you will take advantage of the roles and profiles pattern, and you will learn how to structure your code. Next, you will learn how to extend Puppet and write custom facts, functions, types, and providers in Ruby, and also use the new features of Hiera 5. You will also learn how to configure the new Code Manager component, and how to ensure code is automatically deployed to (multiple) Puppet servers. Next, you will learn how to integrate Puppet with Jenkins and Git to build an effective workflow for multiple teams, and use the new Puppet Tasks feature and the latest Puppet Orchestrator language extensions. Finally, you will learn how to scale and troubleshoot Puppet. By the end of the book, you will be able to deal with problems of scale and exceptions in your code, automate workflows, and support multiple developers working simultaneously.
Table of Contents (19 chapters)
Title Page
Dedication
Packt Upsell
Contributors
Preface
Index

Global, environment, and module layers


The earlier incarnations of Hiera (version 3 or earlier) used a single, entirely global hiera.yaml. Since its hierarchy is entirely global, it's not actually possible to change it without changing all environments simultaneously. Environments are usually used to control code changes, so this really makes a single hiera.yaml file quite inappropriate. Hiera 5 uses three layers of configuration and data: 

  • Global layer:
    • In Hiera 3, this was the only layer
    • Useful for very temporary overrides, for example, when your operations team must bypass regular change processes
    • The legacy Hiera 3 backends are still supported—so it can be used while migrating to Hiera 5
    • This layer should generally now be avoided. All regular data should now be specified in the environment layer
  • Environment layer:
    • The environment layer is now where most of the Hiera data definition happens
    • Available across all modules in the environment
    • Overrides the module layer
  • Module layer:
    • As we discussed...