Notes from the Puppet Practitioner training course
Refresher - a puppet run
- Puppet Agent will run a facter collection
- Puppet Agent will request a catalog from the master
- Puppet Master will generate a catalog using the code on the master
- Puppet Master will send the catalog (JSON format) back to the agent
- Puppet Agent will cache the catalog
- Puppet Agent will apply the catalog
- 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)