Confirmed users
3,104
edits
ReleaseEngineering/PuppetAgain/Modules/puppet: Difference between revisions
ReleaseEngineering/PuppetAgain/Modules/puppet (view source)
Revision as of 17:06, 22 August 2012
, 22 August 2012no edit summary
(Created page with "This module handles installing, updating, and running puppet. It has two modes: = puppet::periodic = This runs puppet the "normal" way - puppet consults the puppetmaster every ...") |
No edit summary |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
This module handles installing, updating, and running puppet. | 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 <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 = | ||
If <tt>/etc/puppet/standalone</tt> file exists it runs puppet in "apply" (standalone) mode by running <tt>/etc/puppet/update.sh</tt>. Otherwise this runs puppet the "normal" way - puppet consults the puppetmaster every 30m or so. It is used for any subclass of <tt>toplevel::server</tt>. | |||
At the moment "standalone" method is iused by <tt>toplevel::server::puppetmaster::standalone</tt>. | |||
= puppet::atboot = | = puppet::atboot = | ||
This runs puppet at boot. | This runs puppet at boot. It is used for any subclass of <tt>toplevel::slave</tt>. 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. | ||