ReleaseEngineering/PuppetAgain
PuppetAgain is an implementation of configuration management with puppet for Mozilla release engineering. It is intended to make machine management easier and more flexible for release engineering, while also making that management transparent enough that it can be reliably duplicated by users outside of the company.
Documentation - Manifests & Modules
The Puppet manifests themselves are documented here. Any new modules should be added to the proper list below.
Stages
Stages need to be defined globally in Puppet manifests, and this is done in manifests/stages.pp. The following stages are available, aside from 'main', the default stage.
- packagesetup - This stage should handle any preliminaries required for package installations, so that subsequent package installations do not need to require them explicitly.
Nodes
manifests/nodes.pp defines all of the nodes the puppet masters recognize. Note that all nodes are defined for all masters.
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 toplevel module.
If the need arises to set host-specific values for classes, we will need to carefully consider whether to set variables in the node scope, or to use parameterized classes, based on the capabilities of an ENC.
extlookup/
We store csv files pertaining to the Config module here (under manifests/extlookup/). Expect to find the local secrets details and possibly a symlink to a local-config in this dir.
Modules
All substantial configuration is done with puppet modules, in the modules directory. Each should have its own page describing both how to use the module, and how the module works, below:
Infrastructure
These modules are part of the puppet system itself, and provide support to other modules as needed
- ReleaseEngineering/PuppetAgain/Modules/config - global configuration
- ReleaseEngineering/PuppetAgain/Modules/dirs - Common directories
- ReleaseEngineering/PuppetAgain/Modules/packages - install packages generically
- ReleaseEngineering/PuppetAgain/Modules/puppet - install, upgrade, and run puppet (including custom facts, etc.)
- ReleaseEngineering/PuppetAgain/Modules/toplevel - top-level classes for node types, included from node definitions
- ReleaseEngineering/PuppetAgain/Modules/shared - shared calculated values, functions, facts, etc.
- ReleaseEngineering/PuppetAgain/Modules/users - user account management
Action
These modules actually get stuff done.
- ReleaseEngineering/PuppetAgain/Modules/buildslave - buildslave (buildbot) installation and startup
- ReleaseEngineering/PuppetAgain/Modules/network - configure host networking parameters
- ReleaseEngineering/PuppetAgain/Modules/nrpe - NRPE support
- ReleaseEngineering/PuppetAgain/Modules/ntp - NTP support
- ReleaseEngineering/PuppetAgain/Modules/tweaks - small, one-off classes (aka "miscellaneous")
- ReleaseEngineering/PuppetAgain/Modules/ccache - ccache directory management
- ReleaseEngineering/PuppetAgain/Modules/disableservices - disable unneeded services
- ReleaseEngineering/PuppetAgain/Modules/smarthost - configure a mail relay
- ReleaseEngineering/PuppetAgain/Modules/powermanagement - configure power management
- ReleaseEngineering/PuppetAgain/Modules/mockbuild - manage mock build environments
- ReleaseEngineering/PuppetAgain/Modules/ssh - manage ssh configuration (server, global, and user)
Utility
These modules are more generic, and probably useful outside of PuppetAgain.
- ReleaseEngineering/PuppetAgain/Modules/motd - edit the contents of /etc/motd
- ReleaseEngineering/PuppetAgain/Modules/osxutils - utility for reading and writing configuration using defaults and system setup on MacOSx
- ReleaseEngineering/PuppetAgain/Modules/python - support for installing python virtualenvs and packages
- ReleaseEngineering/PuppetAgain/Modules/sudoers - manage sudo permissions
- ReleaseEngineering/PuppetAgain/Modules/supervisord - supervise processes
Third-Party
These are modules taken from elsewhere. When adding, remember to verify license compatibility and ensure proper credit.
- sysctl - from https://github.com/duritong/puppet-sysctl
- concat - from https://github.com/ripienaar/puppet-concat (modified to not use a fact, although this should probably be reverted)
Custom Facts
We have a single custom fact defined:
- $puppetizing - 'true' if being run from puppetize.sh, empty otherwise
How To
- ReleaseEngineering/PuppetAgain/HowTo/Re-issue Certificates for a host
- ReleaseEngineering/PuppetAgain/HowTo/Set up a user environment
- ReleaseEngineering/PuppetAgain/HowTo/Change secrets
- ReleaseEngineering/PuppetAgain/HowTo/Build RPMs
- ReleaseEngineering/PuppetAgain/HowTo/Build DMGs
- ReleaseEngineering/PuppetAgain/HowTo/Hack on PuppetAgain (patch/review guidelines)
System Description
This section describes how PuppetAgain is built at Mozilla. External implementations may not have all of these bells and whistles. This link contains details oriented toward Mozilla IT and ops folks.
The Goals
- PuppetAgain should be usable as a whole for folks outside of Mozilla, Inc. who want to build similar systems
- Client images should proceed automatically from base image install to a fully-operational state. While refimages may be employed, this is done only as an optimization.
- We do not keep distinct reference images. When a new refimage snapshot needs to be made, a machine is rebuilt from scratch, snapshotted, and then returned to service.
- OS does not imply role. Roles are defined in node declarations, by including toplevel::* classes.
- Include all necessary dependencies. Use dependency graphs. Debugging dependency errors when building a new reference system is no fun.
- Documentation (here) is a part of the patch.
See ReleaseEngineering/PuppetAgain/HowTo/Hack on PuppetAgain for more detail
Puppetmasters
Releng puppet masters are managed by IT (in fact, managed by IT's puppet infrastructure, which can lead to some confusion). There will be as many puppet masters as required, attempting to minimize the need for communication across WAN links. The puppet masters do not permit root logins by non-sysadmins, but automatically update from the manifest repository using a crontask. As described below, masters also allow user logins for a limited set of people, who can set up puppet environments.
See the following for more details, noting that most of this is not required for an external PuppetAgain implementation.
- ReleaseEngineering/PuppetAgain/Puppetmasters
- ReleaseEngineering/PuppetAgain/Puppetization Process
- ReleaseEngineering/PuppetAgain/Base Images
- ReleaseEngineering/PuppetAgain/Certificate Chaining
Puppet Versions
The releng puppet infrastructure will be using the same puppet versions as the rest of Mozilla. This generally tracks the latest puppet release. As IT upgrades, the masters will be upgraded; releng can then upgrade the clients using puppet itself.
Base Images
The base images for this infrastructure are barely-modified OS installs. They have just enough installed that they can connect to a puppet server, get certificates, and puppetize on boot.
See ReleaseEngineering/PuppetAgain/Base Images for more on the base images and the deployment process. 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.
Data
Puppet deals with a lot of big files - packages, mostly. We don't want these in hg! They are instead managed as data. This means several big file trees available at http://repos/$treename and, from puppet, at puppet://$treename. See ReleaseEngineering/PuppetAgain/Data for details on what's available, how it is implemented, and some how-tos.
Pending bug 757285, this data is available outside of Mozilla via HTTP and rsync at http://puppetagain.pub.build.mozilla.org/data and rsync://puppetagain.pub.build.mozilla.org/data.
Manifests
Manifests are at http://hg.mozilla.org/build/puppet.
History
Releng once used a puppet infrastructure based on Puppet-0.24.8, and manifests at http://hg.mozilla.org/build/puppet-manifests/. This had a few weaknesses:
- lots of assumptions and fragile dependencies based on bugs in 0.24.8
- very few modules - mostly manifest files, organized per slave type, rather than per service/purpose
- many references to external files which are not as available as the repo itself
- puppet manifests assume some manual ref-image steps; external exact reproduction is extremely difficult
Dustin started work on a new puppet deployment - chronicled at User:Djmitche/New Releng Puppet Infrastructure. That's this puppet.