Changes between Version 8 and Version 9 of how-to/puppet


Ignore:
Timestamp:
Apr 6, 2011, 12:07:18 AM (13 years ago)
Author:
Jamie McClelland
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • how-to/puppet

    v8 v9  
    22= Puppet =
    33
    4 MF/PL is moving toward puppet as a system administration infrastructure.
     4May First/People Link uses [http://www.puppetlabs.com/ puppet] to manage our network of servers. With puppet, we describe how our servers should be configured in an easy to read and maintain way and puppet ensures that all of our servers implement the configuration we describe. Using puppet, we can easily setup new servers and ensure that our existing servers are all configured in standard and predictable way.
    55
    6 == administering puppet ==
    7 
    8 puppet can be intimidating.  If you want to help with the administration, here's instructions to get started.
     6puppet has a steep learning curve. This page provides links to all MF/PL documentation on our puppet setup
    97
    108=== checking out the code ===
    119
    12 For read-only access (available to the public):
     10Anyone can [wiki:puppet/checkout checkout our puppet files] read-only. Members of the [wiki:support-team support team] can checkout read/write copies. Checking out the code is the first step to familiarizing yourself with our puppet setup.
    1311
    14 {{{
    15 git clone git://git.mayfirst.org/mfpl/puppet
    16 }}}
     12== understanding the code ==
    1713
    18 For write access (MFPL admins only):
     14We have taken a non-traditional approach deploying puppet. You will need to read our [wiki:puppet/layout explanation of how our puppet code is organized and deployed].
    1915
    20 {{{
    21 git clone gitosis@git.mayfirst.org:mfpl/puppet
    22 }}}
     16== setting up a development environment ==
    2317
    24 Then...
     18If you'd like to test changes, follow our [wiki:puppet/dev-env directions for setting up a puppet development environment].
    2519
    26 {{{
    27 cd puppet
    28 git submodule init
    29 git submodule update
    30 }}}
     20== workflow ==
    3121
    32 To get the most recent code after you've already checked out the repository:
     22A [wiki:puppet/workflow few simple tips on workflow] will make developing MF/PL's puppet setup much easier.
    3323
    34 {{{
    35 git remote update
    36 # to review changes:
    37 git diff origin/master
    38 git merge origin/master
    39 # to pull in any updates to the submodules
    40 git submodule update
    41 }}}
    4224
    43 === setting up a development environment ===
    44 
    45 And as the superuser, install the tools:
    46 {{{
    47 apt-get install puppet-common
    48 }}}
    49 
    50 then copy and update the sample configs to refer to your current environment:
    51 {{{
    52 cp puppet.conf.sample puppet.conf
    53 cp fileserver.conf.sample fileserver.conf
    54 $EDITOR puppet.conf fileserver.conf
    55 }}}
    56 
    57 some important changes to consider:
    58 
    59  * repoint `[files] path` in `fileserver.conf`
    60  * make a simple `var` dir for your dev puppetmaster to stash its data
    61  * repoint all the explicit dirs in `puppet.conf` to the `var` dir
    62 
    63 Then you can launch the puppet master as a non-privileged user from the checked-out directory:
    64 
    65 {{{
    66 puppet master --confdir=$(pwd) --no-daemonize --verbose
    67 }}}
    68 
    69 The next step is to create a virtual machine that will run puppet and connect to the master. This virtual machine will be your test puppet node.
    70 
    71 You will need to minimally install the following packages:
    72 
    73 {{{
    74 aptitude install puppet lsb-release
    75 }}}
    76 
    77 Then, edit /etc/puppet/puppet.conf adding the following line:
    78 
    79 {{{
    80 server=HOSTNAME-OF-MASTER
    81 }}}
    82 
    83 Replace HOSTNAME-OF-MASTER with the hostname of the machine from which yo uare running the puppet master command.
    84 
    85 Then, run the following command on your test puppet node:
    86 
    87 {{{
    88 puppet agent --verbose --waitforcert 60 --onetime
    89 }}}
    90 
    91 This step will generate a new certificate.
    92 
    93 It should output the fingerprint. If you want it to output the fingerprint again, run:
    94 
    95 {{{
    96 puppet agent --verbose --no-daemonie --fingerprint
    97 }}}
    98 
    99 On your master run:
    100 
    101 {{{
    102 puppet cert --list
    103 }}}
    104 
    105 And you should see the hostname of your puppet node.
    106 
    107 To see if it has the same fingerprint, run:
    108 {{{
    109 puppet cert --list --fingerprint  OUTPUT-OF-LIST-COMMAND-ABOVE
    110 }}}
    111 
    112 If they are the same...
    113 
    114 {{{
    115 puppet cert --confdir=$(pwd) --no-daemonize --sign HOSTNAME
    116 }}}
    117 
    118 Replace HOSTNAME with the listed hostname from the previous command.
    119 
    120 Once the cert is verified, you can run the following on your test puppet node to test changes to the manifests and modules:
    121 
    122 {{{
    123 puppet agent --no-daemonize --verbose
    124 }}}
    125 
    126 === Making changes to MFPL's puppet files ===
    127 
    128 There are three main directories:
    129 
    130  * files: used to store files that are copied to our servers as is
    131  * manifests: the place where May First/People Link specific documentation is kept
    132  * modules: generic modules used to help define configurations that are shared with others
    133 
    134 Edits to any file in the files or manifests directories can be changed, committed and pushed like in any other git repo.
    135 
    136 However, changes to the modules directory require more careful attention since thay are stored as git submodules.
    137 
    138 ==== Editing a puppet module (git submodule) ====
    139 
    140  * For every submodule, you need to add a writable remote (by default, you will pulling these in read-only). You can do that with:
    141 {{{
    142 git remote add mfpl-write gitosis@git.mayfirst.org:mfpl/puppet-modules/MODULENAME
    143 }}}
    144  * When you push your changes, you need to specify with:
    145 {{{
    146 git push mfpl-write +HEAD:master
    147 }}}
    148 
    149 If you want, you can edit the .git/config file in each submodule, adding the following line under your mfpl-write stanza:
    150 
    151 {{{
    152 push = +HEAD:master
    153 }}}
    154 
    155 Then, you only need to type:
    156 
    157 {{{
    158 git push mfpl-write
    159 }}}
    160 
    161 After you have made changes to a module (for example the mayfirst module), you need to add it with:
    162 
    163 {{{
    164 git add modules/mayfirst
    165 }}}
    166 
    167 Be sure ''not'' to include the trailing slash (thanks [https://we.riseup.net/riseup+tech/puppet-git-submodules Riseup for that and other tips on git submodules]).
    168 
    169 ==== Adding a new puppet module as a gitsubmodule ====
    170 
    171 To add a new puppet module, first [wiki:git publish the module via git].
    172 
    173 Next, add it to our puppet git repo with:
    174 
    175 {{{
    176 git submodule add git://git.mayfirst.org/mfpl/puppet-modules/MODULE
    177 git submodule init
    178 git commit
    179 }}}
    180 
    181 === Pulling in changes to the master repo ===
    182 
    183 May First/People Link's Puppet Master server is on `rustin.mayfirst.org` which is aliased to puppetmaster.mayfirst.org.
    184 
    185 As root on rustin:
    186 
    187 {{{
    188 cd /etc/puppet
    189 git remote update
    190 }}}
    191 
    192 Next, check the last commit to make sure it matches the last commit you made (and want live):
    193 
    194 On your local machine:
    195 
    196 {{{
    197 git log -n1
    198 }}}
    199 
    200 Compared with, on rustin:
    201 
    202 {{{
    203 git log -n1 mfpl/master
    204 }}}
    205 
    206 If they match, then rebase (we rebase to ensure that our local changes to files on rustin are not merged):
    207 
    208 {{{
    209 git rebase mfpl/master
    210 }}}
    211 
    212 And lastly, restart puppetmaster:
    213 
    214 {{{
    215 /etc/init.d/puppetmaster restart
    216 }}}
    217 
    218 Now, if puppet is running as a daemon on the nodes, the changes will eventually propagate. If you are running puppet manually on a node, you can test manually with:
    219 
    220 {{{
    221 puppet agent --verbose --no-daemonize --onetime
    222 }}}