ReleaseEngineering/PuppetAgain/Modules/puppet: Difference between revisions
No edit summary |
|||
| Line 2: | Line 2: | ||
The puppet class is imported in toplevel::base, and takes care of installing and configuring puppet. Releng uses two modes of puppet startup, so there are two classes that must *also* be included to make sure puppet actually runs. | The puppet class is imported in toplevel::base, and takes care of installing and configuring puppet. Releng uses two modes of puppet startup, so there are two classes that must *also* be included to make sure puppet actually runs. | ||
= How puppet clients use puppet masters = | |||
There are some ways to specify which puppet master clients should talk to: | |||
* Single puppet master. Used by <tt>puppet::periodic</tt> (usually for masters). Random puppet master can be choosen by setting <tt>puppet_server</tt> CSV variable (usually in <tt>manifests/extlookup/local-config.csv</tt>) to <tt><<RANDOM>></tt>. | |||
* Multiple puppet masters. Used by <tt>puppet::atboot</tt> (usually for slaves). If <tt>puppet_server</tt> CSV variable set to <tt><<RANDOM>></tt>, then <tt>/etc/puppet/puppetmasters.txt</tt> file will be populated with a shuffled list of <tt>puppet_servers</tt> (from CSV files). Otherwise, <tt>puppet_server</tt> will be the top entry in <tt>/etc/puppet/puppetmasters.txt</tt>; other puppet masters from <tt>puppet_servers</tt> will be appended in random order. | |||
* No masters (standalone). Used by <tt>puppetmaster::standalone</tt>. A cronjob runs "puppet apply" if there are changes in the puppetagain repo to keep the master up to date. | |||
= puppet::periodic = | = puppet::periodic = | ||
Latest revision as of 17:06, 22 August 2012
This module handles installing, updating, and running puppet.
The puppet class is imported in toplevel::base, and takes care of installing and configuring puppet. Releng uses two modes of puppet startup, so there are two classes that must *also* be included to make sure puppet actually runs.
How puppet clients use puppet masters
There are some ways to specify which puppet master clients should talk to:
- Single puppet master. Used by puppet::periodic (usually for masters). Random puppet master can be choosen by setting puppet_server CSV variable (usually in manifests/extlookup/local-config.csv) to <<RANDOM>>.
- Multiple puppet masters. Used by puppet::atboot (usually for slaves). If puppet_server CSV variable set to <<RANDOM>>, then /etc/puppet/puppetmasters.txt file will be populated with a shuffled list of puppet_servers (from CSV files). Otherwise, puppet_server will be the top entry in /etc/puppet/puppetmasters.txt; other puppet masters from puppet_servers will be appended in random order.
- No masters (standalone). Used by puppetmaster::standalone. A cronjob runs "puppet apply" if there are changes in the puppetagain repo to keep the master up to date.
puppet::periodic
If /etc/puppet/standalone file exists it runs puppet in "apply" (standalone) mode by running /etc/puppet/update.sh. Otherwise this runs puppet the "normal" way - puppet consults the puppetmaster every 30m or so. It is used for any subclass of toplevel::server.
At the moment "standalone" method is iused by toplevel::server::puppetmaster::standalone.
puppet::atboot
This runs puppet at boot. It is used for any subclass of toplevel::slave. On Linux, the startup process blocks until puppet has run successfully, and reboots after a number of unsuccessful runs. On OS X, launchd does not allow one process to block another, so the puppet process runs puppet (as root) repeatedly until it is successful, and then touches a sentinel file that indicates to the buildslave process that it is safe to start. See ReleaseEngineering/Buildslave Startup Process for more details.