Changes

Jump to: navigation, search

ReleaseEngineering/PuppetAgain

66 bytes added, 18:09, 7 November 2013
no edit summary
* stdlib - from https://github.com/puppetlabs/puppetlabs-stdlib/
* vmwaretools - from https://github.com/craigwatson/puppet-vmwaretools
 
== Custom Facts ==
 
Custom facts are described in [[ReleaseEngineering/PuppetAgain/facts]].
 
Custom functions, types, and providers are documented in the modules that implement them. Most are in [[ReleaseEngineering/PuppetAgain/Modules/shared|shared]].
 
== Stages ==
Stages need to be defined globally in Puppet manifests, and this is done in <tt>manifests/stages.pp</tt>. The following stages are available, aside from 'main', the default stage.
 
* network - This stage should handle any network related configurations for some specific cases (like AWS)
* packagesetup - This stage should handle any preliminaries required for package installations, so that subsequent package installations do not need to require them explicitly.
* users - This stage creates user accounts; while this is normally automatically required, the requirement doesn't work with the temporary 'darwinuser' type.
 
== Nodes ==
 
<tt>manifests/nodes.pp</tt> defines all of the nodes the puppet masters recognize. Note that all nodes are defined for all masters. This file is a symlink to <tt>$org-nodes.pp</tt>, e.g., <tt>moco-nodes.pp</tt>. With this arrangement, each organization can make node changes without any risk to other organizations.
 
In anticipation of using an external node classifier (ENC), node definitions should only include classes - do not define any resources within nodes. In general, the included classes should be in the [[ReleaseEngineering/Puppet/Modules/toplevel|toplevel]] module.
 
Host-specific values are specified as node-scope variables, as these are easier to represent in an ENC. Such variables (including some Puppet gotchas) are described in [[ReleaseEngineering/PuppetAgain/node-scope variables|node-scope variables]].
 
Node definitions also specify a host's [[ReleaseEngineering/PuppetAgain/Aspects|aspects]], e.g., <tt>$aspects = [ 'staging' ]</tt>.
 
== Configuration ==
 
Per-organization configuration is read from <tt>manifests/config.pp</tt>, which is a symlink to <tt>$org-config.pp</tt>, similar to that for nodes. The <tt>config.pp</tt> file defines a "config" class that inherits from "config::base". It is free to express the configuration using any mechanism available to puppet. For some organizations, simple puppet literals will do, while more complex organizations will want to perform some more sophisticated automatic generation of configuration. See [[ReleaseEngineering/PuppetAgain/Modules/config|config]] for more.
 
== Secrets ==
See [[ReleaseEngineering/PuppetAgain/Secrets]]
== Bugs ==
Note that, while most of PuppetAgain is intended to be easily replicated, the deployment system is probably not easily replicated, and is best left out of any external implementations.
 
== Custom Facts ==
 
Custom facts are described in [[ReleaseEngineering/PuppetAgain/facts]].
 
Custom functions, types, and providers are documented in the modules that implement them. Most are in [[ReleaseEngineering/PuppetAgain/Modules/shared|shared]].
 
== Stages ==
Stages need to be defined globally in Puppet manifests, and this is done in <tt>manifests/stages.pp</tt>. The following stages are available, aside from 'main', the default stage.
 
* network - This stage should handle any network related configurations for some specific cases (like AWS)
* packagesetup - This stage should handle any preliminaries required for package installations, so that subsequent package installations do not need to require them explicitly.
* users - This stage creates user accounts; while this is normally automatically required, the requirement doesn't work with the temporary 'darwinuser' type.
 
== Nodes ==
 
<tt>manifests/nodes.pp</tt> defines all of the nodes the puppet masters recognize. Note that all nodes are defined for all masters. This file is a symlink to <tt>$org-nodes.pp</tt>, e.g., <tt>moco-nodes.pp</tt>. With this arrangement, each organization can make node changes without any risk to other organizations.
 
In anticipation of using an external node classifier (ENC), node definitions should only include classes - do not define any resources within nodes. In general, the included classes should be in the [[ReleaseEngineering/Puppet/Modules/toplevel|toplevel]] module.
 
Host-specific values are specified as node-scope variables, as these are easier to represent in an ENC. Such variables (including some Puppet gotchas) are described in [[ReleaseEngineering/PuppetAgain/node-scope variables|node-scope variables]].
 
Node definitions also specify a host's [[ReleaseEngineering/PuppetAgain/Aspects|aspects]], e.g., <tt>$aspects = [ 'staging' ]</tt>.
 
== Configuration ==
 
Per-organization configuration is read from <tt>manifests/config.pp</tt>, which is a symlink to <tt>$org-config.pp</tt>, similar to that for nodes. The <tt>config.pp</tt> file defines a "config" class that inherits from "config::base". It is free to express the configuration using any mechanism available to puppet. For some organizations, simple puppet literals will do, while more complex organizations will want to perform some more sophisticated automatic generation of configuration. See [[ReleaseEngineering/PuppetAgain/Modules/config|config]] for more.
 
== Secrets and External Data ==
See [[ReleaseEngineering/PuppetAgain/Secrets]] and [[ReleaseEngineering/PuppetAgain/Extsync]].
== Data ==
Canmove, confirm
1,394
edits

Navigation menu