canmove, Confirmed users
1,394
edits
ReleaseEngineering/PuppetAgain: Difference between revisions
Jump to navigation
Jump to search
reorg useful docs near the top; add a link to ReleaseEngineering/HowTo/Hack on PuppetAgain
(→Action) |
(reorg useful docs near the top; add a link to ReleaseEngineering/HowTo/Hack on PuppetAgain) |
||
| Line 1: | Line 1: | ||
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. | 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. | The Puppet manifests themselves are documented here. Any new modules should be added to the proper list below. | ||
| Line 123: | Line 73: | ||
* [[ReleaseEngineering/PuppetAgain/HowTo/Change secrets]] | * [[ReleaseEngineering/PuppetAgain/HowTo/Change secrets]] | ||
* [[ReleaseEngineering/PuppetAgain/HowTo/Modify a Custom RPM]] | * [[ReleaseEngineering/PuppetAgain/HowTo/Modify a Custom RPM]] | ||
* [[ReleaseEngineering/PuppetAgain/HowTo/Hack on PuppetAgain]] (patch/review guidelines) | |||
= System Description = | |||
== The Goals == | |||
* 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 <tt>toplevel::*</tt> classes. | |||
* Include all necessary dependencies. Use [http://bitfieldconsulting.com/puppet-dependency-graphs 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 [[ReleaseEngineering/Puppet|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. | |||