Puppet Overview

Configuration management is an attempt to manage hundreds or thousands of hosts with as little human attention as possible, striking a balance between flexibility, functionality, speed and accountability.

This section covers the steps you need to provision a host quickly and easily, without diving into the gory details.

Puppet

The easiest way to get started is to use the provided NCSU puppet roles and profiles. With these you can quickly create a system that will use Wolftech for authentication and have access to campus AFS resources.

Details on how to classify nodes with NCSU default roles

Write your own Puppet classes

The first thing you’ll need to begin creating your own Puppet roles is Git. You can access the NCSU campus github here

Getting Started

If you want to jump straight in see Starting with Puppet for information about how to configure your workstation to work with Puppet.

Roles, Profiles, and Repos

To simplify the management of large number of hosts, you classify hosts into “roles.” A Role can describe a single system, for example, “Library Master Database Server” or many systems, for example “ECE Graduate Student Loaner Chromebooks.” Both Roles and Profiles are implemented as Puppet Classes, and are stored in git repos.

Profiles perform apply specific configurations to a box. For example we have a profile that configure authentication sources. Another installs the afs client. A role will call any number of profiles to configure the machine to meet the role requirements.

The ncsu:: class

The ncsu:: class is a parent class, owned by the campus and supported by the RLSC/OIT/Other? that contains roles and profiles tested and recommended for general use on campus. It’s kept in a github.ncsu.edu repo named oit-csu/ncsu

“Supported” means that if you encounter a bug or have a problem implementing a class in the ncsu:: name-space on a supported operating system you can get assistance using the LINUX workgroup in ServiceNow. We intend this class to be reliable and trustworthy for all who use it.

If you prefer and have the in-house expertise, you can set up your own Puppet Control Repo, and ignore the classes here.

The NCSU class is already available on the Foreman server. If you wish to build a box using only the ncsu:: class you can do that immediately. See the Foreman docs for more detail.

Your organizations class

Your organization also has at least one git repo that you control for your own roles and profiles. If OIT hosts your repo, it generally has the name YourOrg_puppet and it has been populated with a directory structure to help you get started.

Unless you are managing your own Puppet Control repo, your organizations repo is tied in to the campus Puppet Master server(s) so that whenever you change the git repo, it automatically updates the Puppet Masters.

Puppet Environments

Puppet environments map directly to branches within git. This allows us to test code without impacting production. We support several pre-built puppet environments with Foreman.

  • Production: Any code committed to this branch will be deployed into production.
  • NCSU-Test: This environment allows you to test your Puppet code against the most recent proposed changes to the production environment.
  • ForgeLatest: This branch allows you to test your puppet code against the latest module changes from the Forge. The list of modules in this environment is copied daily from the Production environment.

Hiera

Hiera is where we will store data to be used by Puppet when building systems. For example we use hiera to store the names of AD groups we want to have access to our systems.

Tags: puppet
Edit me