1. Puppet for GENI Experiments
Stéphane Blais
GEC22, March 24, 2015

2. Puppet Overview
Centralized configuration system: One puppet master and many clients (aka hosts or nodes)
Exists since 2005
Ruby based
Uses its own declarative language ~ruby
Allow to deploy software and keep machines in an expected state.

3. Puppet Vocabulary Class Templates
See
Class
A collection of related resources, which, once defined, can be declared as a single unit. For example, a class could contain all of the elements (files, settings, modules, scripts, etc) needed to configure Apache on a host.
Templates
A partial document which is filled in with data from variables. Puppet can use Ruby ERB templates to generate configuration files tailored to an individual system.

4. Puppet Vocabulary (Cont’d)
Variables
A named placeholder in a manifest that represents a value. Variables in Puppet are similar to variables in other programming languages, and are indicated with a dollar sign (e.g. $operatingsystem) and assigned with the equals sign (e.g. $myvariable = "something"). Once assigned, variables cannot be reassigned within the same scope
Scope
The area of code where a variable has a given value.
Class definitions and type definitions create local scopes. Variables declared in a local scope are available by their short name (e.g. $my_variable) inside the scope, but are hidden from other scopes unless you refer to them by their fully qualified name (e.g. $my_class::my_variable).

5. Puppet Vocabulary (Cont’d)
Modules
A collection of classes, resource types, files, and templates, organized around a particular purpose. For example, a module could be used to completely configure an Apache instance
Facts
A piece of information about a node, such as its operating system, hostname, or IP address.
Facts are read from the system by Facter, and are made available to Puppet as global variables.

6. Puppet Vocabulary (Cont’d)
Manifest
A file containing code written in the Puppet language, and named with the .pp file extension. 
Catalog
A catalog is a compilation of all the resources that will be applied to a given system and the relationships between those resources. Catalogs are compiled from manifests by a puppet master server and served to agent nodes

7. Puppet Vocabulary (Cont’d)
node (or node statement)
A collection of classes, resources, and variables in a manifest, which will only be applied to a certain agent node. Node definitions begin with the node keyword, and can match a node by full name or by regular expression.
When a managed node retrieves or compiles its catalog, it will receive the contents of a single matching node statement, as well as any classes or resources declared outside any node statement. The classes in every other node statement will be hidden from that node.

8. How it works Client: request catalog applies the parts that are needed
Ends up in the defined state
Server:
Identifies the requesting client
Compiles its specific catalog
Receives report (success / failures, and what was changed)

9. Puppet Setup Setting up a puppet master
Install puppet server, usually using packages for your distribution.
Gather the modules you will need from the puppet forge
The Puppet Forge is a repository of free modules you can install and use. Most of these modules are open source, and you can easily contribute updates and changes to improve or enhance these modules. 
Declare nodes definitions for the machines you want to configure, for example:
node 'agent1.localdomain' {
include apache
class {'ntp':
servers => [ "ntp1.example.com dynamic", "ntp2.example.com dynamic", ], }

10. Puppet Setup (cont’d) Puppet comes with a web server:
Puppet includes a basic puppet master web server based on Ruby’s WEBrick library.You cannot use this default server for real-life loads, as it can’t handle concurrent connections; it is only suitable for small tests with ten nodes or fewer. You must configure a production quality web server before you start managing your nodes with Puppet.
Use Apache and Passenger if you plan to support more than 10 nodes.
Passenger (AKA mod_rails or mod_rack) is an Apache 2.x module which lets you run Rails or Rack applications inside a general purpose web server
First time the puppet master is started, certificates are created for the server.

11. Puppet Setup (cont’d) Set up of a managed node
Install the base OS with the puppet client, usually using packages for you distribution
Configure /etc/puppet/puppet.conf to point to your puppet master
Clock need to be in sync with master (SSL)
Run puppet client once
certificate for your client is created
a certificate signature request is sent to the puppet master
On the puppet master: sign the client certificate
Run puppet client again: the run will now succeed and puppet will configure the node according to the node definition.

12. Puppet Setup (cont’d)
Version control the puppet files (modules, manifests, configurations)
Not a requirement, just good practice

13. Puppet Characteristics
Long and rich history. Well maintained
Lots of documentation
Quite a bit of ramp up
Pseudo ruby declarative language
Ordering.
Puppet applies its catalog in a random order (can be changed in latest version)
When dealing with related resources, Puppet has ways to express those relationships with the before, require, notify, and subscribe metaparameters.

14. Puppet Characteristics (Cont’d)
No separation of code and “data”
Customization of modules (new classes, templates) all go in the existing modules area
Your own module go in the modules folder
Makes it hard and sometimes impossible to know where things came from, after a while.
Makes it hard to upgrade to new versions of modules
Makes it hard to upgrade to new versions of puppet
Once you have it working, does a good job at doing its job, i.e. keeping your machines configured the way you want.

15. Puppet in GENI
Probably does not make sense if you don’t have experience with it and if the slice you’re using is not going to last very long
Makes sense to use if you have some puppet gurus on hands.