Infrastructure/Puppet

Puppet

NOTE: Puppet is on the way out. Ansible is now what should be used for new infrastructure. Current puppet nodes are in the process of being migrated.

Introduction

Puppet is a configuration management system currently being evaluated by Fedora for its infrastructure. This page describes its implementation and while it is specific to Fedora it is a fairly standard setup and should be applicable to most environments.

Also see SOP

Important Files / Locations

Puppet Master (server):

• /etc/puppet - Basic puppet configuration information
• /etc/puppet/manifests - node config mappings
• /etc/puppet/manifests/filetypes/* - Various filetype definitions
• /etc/puppet/manifests/nodes/* - Server lists and what classes[1] they use
• /etc/puppet/manifests/server-groups - Maps services with a server type
• /etc/puppet/manifests/service-types - Contains each service and whats required for that service
• /etc/puppet/manifests/site.pp - Contains the 'root' config file which includes other config files
• /var/lib/puppet/ - Puppet files
• /var/lib/puppet/config - Config files for our actual nodes (eg httpd.conf)
• /etc/lib/puppet/bucket - Backup of overwritten config files

Puppet client

• /etc/puppet - Basic configuration information
• /etc/sysconfig/puppet - Puppet startup definitions

Puppet CVS

• /cvs/puppet - puppet cvs
• /cvs/private - Private information (keys, passwords, etc)

[1] In puppet classes are similar to templates. A class can contain another class. In our case, for example, we'll take the account system. On the proxy servers we require a config section to ProxyPass /accounts/ to the app servers. This account system is in a class which inherits properties from the http class. The http class requires that httpd be installed and the config file type we're using, apacheconfig, requires httpd to be restarted whenever a config file is deployed. This account system class is, in turn, placed in the proxy class. Then proxy1 and proxy2 use the "proxy" class, which contains the account class, which contains the httpd class. Take a look at the config files to see this in action.

Node Setup

Node in this context refers to a server we wish to manage with puppet not the puppet master server. For the purposes of this example we'll use a new server "proxy3".

1. Build proxy3
2. Install ruby
3. Install facter and puppet from EPEL
4. Alter /etc/sysconfig/puppet: PUPPET_SERVER=puppet
5. chkconfig puppet on
6. /etc/init.d/puppet start

This will cause puppet to start up and contact puppet1 for a list of files. This will also send a certificate request to the server. At this point in time NO CONFIG FILES ARE CHANGED. This is because puppet1 has to give access to proxy 3.

To allow the server log in to puppet1 and run puppetca:

proxy3.fedora.phx.redhat.com
Signed: proxy3.fedora.phx.redhat.com

Next log in to puppet1 and add proxy3 to /etc/puppet/manifests/nodes/proxy3.fedora.phx.redhat.com.pp

Once this is done communcation between the node and the server should be ready.

Server Side

The server side of things is already configured. Please see the Important Files / Locations above for more details about where configuration files are. In our setup we have changed from a server centric management model to a service centric model. This was done for ease of management. For example, the Fedora Account System contains a few needs on multiple servers. It has proxy pass on the front servers, applications on the app server and a database to poll. In the previous configuration system this ment multiple files in multiple server groups and the relationship between them was unclear. In this new setup we have one file in the service-groups directory which contains the proxy configs, app configs and db configs.

Adding a file

There's a few steps to actually adding a file to puppet.

1. Check out the current configuration
2. Add configuation file
3. Add the manifest config (tell puppet where your file should end up and what type of file it is)
4. commit the files
5. Run "make install" in the config directory and "make install" in the manifests directory.
6. Verify new file on the client

Adding new files is easy, stick them in /var/lib/puppet/config/ somewhere that makes sense, for example all the web files are in ./web/ Once that is done you need to add your file to /etc/puppet/manifests/service-groups/. In this example we'll be discussing nagios (not yet implemented but will be soon).

class nagios {
package { nagios:
}

nagiosfile { '/etc/nagios/':
source => "nagios/",
ensure => directory,
recurse => true


service { nagios:
ensure => true,
subscribe => [ package["nagios"]   
}
}

class nagios-proxy inherits httpd {
apachefile { "/etc/httpd/conf.d/admin.fedoraproject.org/nagios.conf":
source => "web/nagios-proxy.conf"
}
}

There are 3 classes here. The first one defines a generic nagios class. It's used to make sure that anything that inherits it requires nagios to be installed and so it restarts nagios when a config file is changed. Next is the nagios-proxy file which inherits httpd (defined in a different config file). By inheriting httpd we're saying that wherever the nagios-proxy files get installed, that box will also need to have http. By specifying apachefile, we're telling puppet to restart httpd if the config has changed. We do the same thing with "nagiosfile" which is defined in /etc/puppet/manifests/filetypes. An example would be:

define nagiosfile(owner = root, group = nagios, mode = 664, source,
backup = main, recurse = false, ensure = file) {
file { $name:
mode => $mode,
owner => $owner,
group => $group,
backup => $backup,
recurse => $recurse,
notify => service[nagios] ,
ensure => $ensure,
source => "puppet://$server/config/$source"
}
}

The notify=>service[nagios] means that whenever a configfile of type "nagiosfile" is deployed, the service nagios is restarted.

From this point on you can specify which nodes include which classes. The proxy servers would include "nagios-proxy" where the actual nagios server would include "nagios".

To check if your changes are syntatically correct you can restart puppet master with:

service puppetmaster restart

The client checks in every half hour. If you want to immediately check your changes just run:

/etc/init.d/puppet restart; tail -f /var/log/messages