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


Ignore:
Timestamp:
Apr 21, 2011, 10:51:39 PM (14 years ago)
Author:
Jamie McClelland
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • how-to/puppet/layout

    v2 v3  
    77MF/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.
    88
    9 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.
     9Each 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.
    1010
    1111Alternatively, 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.
    … …  
    1313== Layout ==
    1414
    15  * manifests
     15Below is the layout of our [https://git.mayfirst.org/?p=mfpl/puppet.git;a=summary git repository].
     16
     17 * manifests: this is where information about each MFPL server is stored, plus some general information specific to our servers
     18        * site.pp: this is the file that boostraps all other files
    1619        * globals.pp: global variables specific to May First/People Link, used throughout
    1720        * modules.pp: one line to import every puppet module that we use
    18         * site.pp: this is the file that boostraps all other files
    19   * nodes
     21  * nodes: this directory contains the files for each server in our network
    2022         * production: one file for every production server in our network
    21          * dev: place test and dev server definitions here
    22  * 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.
     23         * dev:  one file for every test/dev server
     24 * 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.