Lab42 Puppet Infrastructure
A complete set of modules for puppet configurations
Lab42 Puppet Infrastructure provides:
- Dozens (and growing) of modules for different applications,more or less common
- Cross Operating System approach
- Infrastructural module logic in order to adapt to different IT architectures
Download and "install"
You can browse it here (most of the stuff is in the modules directory) or you can download it via anonymous git:
git clone git://live.lab42.it/puppetinfrastructure
The repository contains the whole /etc/puppet directory:
- Edit /etc/puppet/puppet.conf with your server name
- Edit /etc/puppet/manifests/site.pp and include a different project class (import project_mycompany)
In /etc/puppet/modules you find all the modules so far:
- A module (recipe?) for each supported application (apache, nagios, postfix, lighttpd ..).
- A special module for your own site infrastructure (default is project_lab42 which is a working infrastructure (not particularly complex) but you can start from project_general and build your setup from there.
Customize
Note that what is written here could not have been standardized in all the modules, at the moment.
Each module is organized according to Reductive Labs suggested Module organization.
In module_name/manifests/init.pp there is the starting manifest.
Here you find a class (with the same name of the module) and possible subclasses for specific functions of the same applications (ex: cobbler and cobbler::full).
Generally in module_name/manifests/lab42.pp there are lab42 specific sub classes (ex: cobbler::lab42), they are strictly related to Lab42 infrastructure but can be easily adapted to custom needs.
The primary class (ex: samba) should not overwrite configuration files but only define the general types, whose properties can be modified by subclasses that inherit tha main one (ex: samba::pcd)
In module_name/files/ you can find the files provided by puppet. Lab42 specific configurations and files are in the module_name/files/lab42/ subdirectory.
At the moment there is few use of templates, since it has been considered that it might be easier to adapt and convert to puppet an existing infrastructure, using custom configurations provided as static files.
Project organization
The project_yourprojectname module is the key to the organization of puppet layout you your own infrastructure design.
In the future various examples of different typical projects will be provided, for the moment project_lab42 is used on a simple infrastructure with few nodes but can scale extremely well.
Here are the basic principles or a project layout:
- project_general/manifests/init.pp is the starting manifest, it includes the others, written below (note that you can organize files and classes as you wish)
- project_general/manifests/infrastructure.pp defines the infrastructure logic: from the default basenode you can inherit different environment related subnodes (it's good idea to consider an environment as a dedicated IP network or as a specific functional area (ex: dmz1, dmz2, frontend, backend, intranet, devel etc). You can have more than one inheritance step (ex: servers inherits intranet inherit basenode).
It'a good idea to define the variable $env with the name of the environment (you can use it to differentiate configuration sourcing accordind to the environment).
- project_general/manifests/nodes.pp contains the nodes list (the hosts of your infrastructure), they inherit a previously defined environment and include a single role (ex: webservers, load balancers ecc.)
- project_general/manifests/roles.pp has the lists of used roles and the classes they use. General roles can be defined to summarize common includes.
It'a good idea to define the variable $role with the name of the role (you can use it to differentiate configuration sourcing according to the node's role).
Note that according to this design a node inherits an environment and includes a role:
- Only ONE inheritance tree for nodes: general node - [zone/network/environment] - [ subzone ] - node
- Each node may include a SINGLE specific role, where you define what modules to use
Now, how to organize your own infrastructure actually depends only on its complexity and specificity.
What must be respected is the use of few specific variables:
- $os defines the operating system or linux distribution (redhat, debian..),
- $osver defines the version of the operating system (4, 5 ...),
- $update defines if packages must be automatically updates (yes/no becomes ensure => latest/present in packages definitions),
- $env defines the environment inherited by the host node (devel, test, prod..),
- $role defines the role of the host node (webserver, proxy, mail... )
More information on how to use Lab42 Puppet Infrastructure is here.