= Puppet layout and deployment = == Deployment == 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. 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/mfpl/puppet. 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 == Below is the layout of our [https://git.mayfirst.org/?p=mfpl/puppet.git;a=summary git repository]. * [wiki:puppet/fabric fabric] - fabfile.py holds code for running operations on our servers from the command line using [http://fabfile.org fabric]. Our fabfile.y is [wiki:puppet/fabric documented]. * manifests: this is where information about each MFPL server is stored, plus some general information specific to our servers * site.pp: this is the file that boostraps all other files * globals.pp: global variables specific to May First/People Link, used throughout * modules.pp: one line to import every puppet module that we use * nodes: this directory contains the files for each server in our network * production: one file for every production server in our network * dev: one file for every test/dev server * modules: modules are abstracted collections of manifests, templates and files. Usually, they are intended to be re-usable by others (we have one exception, the mayfirst module, which contains most code specific to us.