Changes between Version 1 and Version 2 of how-to/puppet/layout

Timestamp:

Apr 6, 2011, 12:29:56 AM (14 years ago)

Author:

Jamie McClelland

Comment:

--

how-to/puppet/layout

@@ -3 +3 @@
 == Deployment ==
 
-Traditionally, puppet uses a puppet master. Each node runs a puppet process as root that contacts the master, receives changes to the manifest, and then executes those changes on the node.
+Traditionally, puppet uses a puppet master, which is a dedicated server that has a copy of the puppet configuration files. Each node runs a puppet process as root that contacts the master, receives the catalog specific to the server they are running, and then executes the catalog.
 
-MF/PL does not use a puppet master. 
+MF/PL does not use a puppet master. Instead of having a single server with the puppet configuration files, we have distributed the configuration files to every server (aka node) on our network via git, placing the files in /etc/puppet. 
 
+Each node runs a cron job that does a `git remote update` against git://git.mayfirst.org/. It checks for the most recent git tag that is signed by a member of the MFPL support team, merges that tag, and then runs puppet.
+
+Alternatively, MFPL admins can push changes into a puppet bare repo on each node, which will run a post-update hook that pulls the changes into /etc/puppet and runs puppet.
+
+== Layout ==
+
+ * manifests
+        * globals.pp: global variables specific to May First/People Link, used throughout
+        * modules.pp: one line to import every puppet module that we use
+        * site.pp: this is the file that boostraps all other files
+  * nodes
+         * production: one file for every production server in our network
+         * dev: place test and dev server definitions here 
+ * modules: modules are abstracted collections of manifests, templates and files. They are intended to be re-usable by others. In addition to several modules that we have borrowed from others and written ourselves, our modules directory contains a module called "mayfirst" which contains our collection of configurations that specific to us. Most development work will happen in this module.