Puppet Practitioner Course - Day 1

Notes from the Puppet Practitioner training course

Refresher - a puppet run

1. Puppet Agent will run a facter collection
2. Puppet Agent will request a catalog from the master
3. Puppet Master will generate a catalog using the code on the master
4. Puppet Master will send the catalog (JSON format) back to the agent
5. Puppet Agent will cache the catalog
6. Puppet Agent will apply the catalog
7. Puppet Agent will send a completion report back to the master

Puppet uses port 8140
Mcollective (if used) uses port 61613

Puppet code best managed using source control (e.g. git or subversion)
One large git repo is easiest for configuring, but can get quite large.
Puppet best practice is to use one git repo for each module, this however means large complexity in managing a lot of repos.
R10K is a synchrinisation platform which can "glue" together multiple repos on the master

• course doesn't go into much detail on R10K, an option to research later

Functions
only on the master - be careful as functions will work well for puppet master resources, but may cause problems with agents.

Deployments

The puppetlabs website has scripts for agent deployment available. Could be run as
curl -k http://puppetmaster.company.com/script | bash

External Facts

Create a file in /etc/puppet/facts.d
containing

fact=blah
location=hawaii
provider=telecom1
adminteam=green-team

https://puppetlabs.com/blog/facter-1-7-introduces-external-facts

Custom Facts

facts conditional on certain environment data, such as location. Can be generated by scripts. more details in

https://docs.puppetlabs.com/facter/2.4/custom_facts.html

Resources

Abstraction layer which uses providers to enforce a desired state regardless of the type of system we are deploying. For instance, ensure "apache" package exists, would use MSI for Windows, YUM for redhat, apt-get for debian, etc.

Driven by providers (ruby scripts) on the puppet master

Resource types include

• users
• packages
• groups
• services

"puppet resource" can be used to query or manage resources. e.g.

puppet resource user

will list all puppet managed user records

Idempotency

Puppet only runs something if a change is required

• note "exec" may be an exception to this. it may still be run each time the puppet run occurs.

Lint Checks

puppet-lint 

You can also disable specific lint checks (e.g. if you've intentionally decided to ignore certain best practices)

puppet-lint --no-single_quote_string_with_variables-check

Class Naming conventions

If declaring a class

class system::dbadmins {
  require mysql::server
  mysql_user { 'zack@localhost':
  ensure => present,
  password_hash => mysql_password('puppetlabs'),
}

The class will be defined in
modules/system/manifests/dbadmins.pp

The first section of the class name refers to modules/{module_name}
the second section (after double colon) refers to the pp file in modules/{module_name}/manifests/{class_name}.pp

Smoke Tests

Create a modules/{module_name}/tests/init.pp file containing
include module::class

Then run

puppet apply ./modules/{module\_name}/tests/init.pp

This will apply it to your local system.

Virtual resources

If you want to declare a resource in multiple locations, use

Mark resources in the catalog as virtual
@package { 'gcc': ensure => present }
This doesn't affect configuration until it is "realized"

Realize Package['gcc']
Realize Package['gcc']   # this doesn't result in duplicate declarations
Realize Package['gcc']

Any resource in the catalog can be realised

metaparameters

Ordering

These parameters are

• require
• before

Resource ordering can also be defined with -> or -<
e.g. Package['httpd'] -> File['/etc/httpd/conf/httpd.conf']

Would execute from left to right (install package, retrieve config file)

Refresh

• notify
• subscribe

Refresh relationships can also be defined using
~> and ~<

e.g. Package['httpd'] -> File['/etc/httpd/conf/httpd.conf'] ~> Service['httpd']
Would execute from left to right (install package, retrieve config file, start service)