Skip to content
This repository has been archived by the owner on Jun 11, 2019. It is now read-only.

Commit

Permalink
Updated layout and documentation
Browse files Browse the repository at this point in the history
  • Loading branch information
root committed Aug 12, 2012
1 parent 81a8519 commit 8e2850e
Show file tree
Hide file tree
Showing 2 changed files with 129 additions and 132 deletions.
56 changes: 42 additions & 14 deletions README.rdoc
View file
@@ -1,13 +1,11 @@
= EXAMPLE 42 PUPPET MODULES
= EXAMPLE 42 PUPPET INFRASTRUCTURE EXAMPLES

Example42 is a set of Puppet Modules that provides an integrated and coherent Puppet setup to manage many common applications.

Each module contains at least one class having its same name, which can be used by nodes.

Official site is http://www.example42.com

Continuous integration tests are public: http://www.example42.com/jenkins

Git repositories are on GitHub: http://github.com/example42

Currently (02/2012) the module set is composed of 2 generation of modules:
Expand All @@ -18,7 +16,7 @@ Currently (02/2012) the module set is composed of 2 generation of modules:

The intention is to move the whole module set to NextGen modules by the end of 2012.

== Installation
== Installation of Modules
You can retrieve the Example42 modules Version 1.0 with:

git clone --recursive -b 1.0 git://github.com/example42/puppet-modules.git
Expand All @@ -39,10 +37,9 @@ If you want to get the very latest version of each submodule, even the ones not

git submodule foreach git pull origin master

From time to time you may need to resync the submodules URLs:

git submodule sync
The above commands (excluded the first cd and included the last) are done by the script:

Example42-tools/sync.sh

== General note on Puppet nodes

Expand All @@ -52,18 +49,49 @@ You have at least two ways to define nodes in Puppet:

* Via an External Node Classifier (ENC), such as Dashboard, Puppet Enterprise Console or Foreman or whatever custom source, where you may have a GUI that helps in setting nodes and their variables.

The general logic is that for each node you may have to set variables (eventually using different methods) thand include or call classes that make use of these variables.
The general logic is that for each node you may have to set variables (eventually using different methods) and include or call classes that make use of these variables.
You can eventually decide to set all your variables using and external datastore, such as Hiera or Extlookup.

If you choose the approach based on site.pp, (which is the default when you install Puppet) you can find here some sample infrastructure layouts.
Look in 10_archive/2010 and 10_archive/2011 of the 2011 branch for alternative approaches on how to define nodes using the nodes' inheritance approach (note that this will not work on Puppet Etsy).
In the toasters/ directory (or the 2011 branch) you find examples of master-less setups that can be used to quickly configure an appliance.

== Example42 sample infrastructures

This repository contains some sample layouts of nodes organization in Puppet ( what is placed in /etc/puppet/manifests when you don't use an ENC ).

The samples have followed Puppet's evolution and what we considered a good approach in the past (setting and overriding variables using nodes' inheritance) is no longer possible in Puppet 3.0.

For this reason you might explore, in different branches, different alternative infrastructures

=== Branch master

The current branch proposes a minimal approach which does not even use nodes' definitions.

General variables are set at top scope, and variables that are considered necessary (role and env) are defined in a switch based on regular expressions of the hostname.

Then is simply included the example42 class (which will become you own project class) where general classes are set and where different role classes are included according to the value of $role.

Note that this "nodeless" setup is something far from being common, but it's the only approch we could conceive to set variables such as $role and $env at the top scope without using facts or an ENC.

=== Branch 2011

This is a branch useful if you don't intend to use Puppet 3.0 soon.

Look in 10_archive/2010 and 10_archive/2011 of the 2011 branch for alternative approaches on how to define nodes using the nodes' inheritance approach.

In the toasters/ directory you find examples of master-less setups that can be used to quickly configure an appliance.

Note that these sample layouts of /etc/puppet/manifests were done with the old Example42 modules' set (branch 1.0 of Example42 puppet-modules) so they won't work perfectly with NextGen modules.

== The example42 module
The approach used here is minimal since in site.pp are defined only some general variables and nodes.
In the Example42 puppet-modules set there's a special "project" module, called example42 which contains site specific customizations of the general modules.

Here is defined the common baseline of all the nodes (example42/manifests/init.pp), "role" classes (where classes are included for different purposes) and the custom templates and files used for the "example42" project.

The example42 module is presented as just another module in the Example42 modules set but is provided are an example on how you can create a custom project module with all the customizations your site needs.

Use the script (provided by the Example42 modules git repo)

Most of the logic on what is placed in every node is moved in a "project" module, here called example42 where are defined custom classes, "role" classes (where classes are included for different purposes) and the custom templates and files used for the "example42" project.
Example42-tools/project_rename.sh

This is easily reproducible by an ENC (just redefine the nodes used here and the relevant variables).
The example42 module is presented as just another module in the Example42 modules set
to create a new project module based on the example42 sample.

205 changes: 87 additions & 118 deletions site.pp
View file
@@ -1,132 +1,101 @@
# INTRODUCTION
# /etc/manifest/site.pp is the first file that, by default, the PuppetMaster
# loads if you don't use an ENC.
# loads if you don't use an External Node Classifier (ENC)
#
# Here you find a sample layout of a Puppet infrastructure based on the Example42 modules
# We import explicitely various manifests classes placed in /etc/manifests/
# and modules that can't be autoloaded from your modulepath ( /etc/puppet/modules )

# GENERAL IMPORTS AND RESOURCE DEFAULTS
# Example42 common module (contains defines used by other modules that can't autoload)
# This is kept for backwards compatibility with some modules
import "common"

# This is the module that contains our customizations:
# - Our custom roles and baselines, included by the nodes
# - Our custom classes, autoloaded in $myproject is set to lab42
# - Our templates and configuration files
import "example42"

# General settings for standard types
Exec { path => "/bin:/sbin:/usr/bin:/usr/sbin" }

# TOP SCOPE VARIABLES
# Here are valuated all the variables you may want to use to affect module's behaviour

node basenode {
# If you define $my_project , custom $project.pp classes are autoloaded
$my_project = "example42"

# Activate Automatic monitoring
$monitor = "yes"
# Define what are the monitoring tools to use (can be an array)
# NOTE: Some of the tools (such as nagios) require storeconfigs
# The usage on an ENC is in many cases recommended, consider the variables
# defined here as a sample of the general variables that affect all
# Example42 modules.
#
# This sample site.pp is intended to be used with Example42 Puppet Modules

# Activate automatic monitoring
$monitor = true
$monitor_tool = [ "nagios" , "puppi" ]

# Activate Automatic firewalling
# $firewall = "yes"
# $firewall = true
# $firewall_tool = "iptables"
# $firewall_destination = "0/0" # Default is $ip_address
# $iptables_block_policy = "accept"
$iptables_config = "file"

# Activate modules debugging (not too resource intensive and useful)
# $debug = "yes"

# Some general variables used by modules
$puppet_server = "foreman.lab42.it"
$dns_servers = [ "10.42.20.1" , "8.8.8.8" ]
$smtp_server = [ "mail.example42.com" ]

# Local root mail is forwarded to $root_email - CHANGE IT!
$root_email = "roots@example42.com"

# Syslog servers. Can be an array.
$syslog_server = ["10.42.42.15"]

# Set proxy, if needed
# $proxy_server = "proxy.example42.com:8080"

# Set your timezone
$timezone = "Europe/Rome"
# $ntp_server = "ntp.example42.com"

$update = "no" # Auto Update packages (yes|no)

# Munin central server
$munin_server = "10.42.42.12"
# Add extra custom plugins
$munin_plugins = "yes"

# Collectd Central server (here we use unicast networking)
# Define the server IP (not the hostname)
$collectd_server = "10.42.42.16"

# NRPE ACCESS
$nrpe_allowed_hosts = "10.42.42.11,10.42.42.36"
$nrpe_dont_blame_nrpe = "1"
$nrpe_use_ssl = "yes"
# Nagios servers grouping logic
# $nagios_grouplogic = "zone"

# MCollective
$mcollective_psk = "42324bws!988!"
$mcollective_stomp_host = "mq1.example42.com"
$mcollective_stomp_user = "mcollective"
$mcollective_stomp_password = "Unf0rg3tt4bl3!"

# Ldap Authentication
# $users_auth = "ldap" # By default we want ldap auth
# $users_ldap_servers = ["ldap1.example42.com","ldap2.example42.com"]
# $users_ldap_basedn = "dc=example42,dc=com"
## $users_ldap_ssl = "yes"
## $users_automount = "yes"

# Yum repos (for Rhel)
$yum_extrarepo = [ "epel" , "puppetlabs" ]
$yum_update = "updatesd"
$yum_clean_repos = true

# Use puppi and activate puppi subclasses in modules
$puppi = "yes"
}

# NODES DEFINITIONS
# Can be splitted in different files to be imported here
node 'puppet.example42.com' inherits basenode {
include example42::role::puppet
}

node /^foreman\.*/ inherits basenode {
include example42::role::foreman
}

node /^web\d+$/ inherits basenode {
include example42::role::web
}

node /^test\.*/ inherits basenode {
include example42::role::test
}

node /^rspec\.*/ inherits basenode {
include example42::role::rspec
}


node /^moon\.*/ inherits basenode {
include example42::role::ci
}
# $debug = true

# Activate Puppi integration in modules
$puppi = true

# PER NODE EXTRA VARIABLES
# This is a "nodeless configuration example": no nodes are defined.
# Some variables are set according to the hostnames
# and a "project" class where all the customizations are placed
# is included at the end (here is example42, change it for your setup)

# This approach may work if you have a strict naming convention
# Use is as a refrence on the variables to use in an ENC

case $::hostname {
# Web Servers
/^test-web-/: {
$role = 'web'
$env = 'test'
}

/^web-/: {
$role = 'web'
$env = 'prod'
}

# Application Servers
/^test-as-/: {
$role = 'as'
$env = 'test'
}

/^as-/: {
$role = 'as'
$env = 'prod'
}

# Mysql
/^test-mysql-/: {
$role = 'mysql'
$env = 'test'
}

/^mysql-/: {
$role = 'mysql'
$env = 'prod'
}

# PuppetMaster
/^puppet/: {
$role = 'puppet'
$env = 'prod'
}

/^jenkins/: {
$role = 'jenkins'
$env = 'prod'
}

/^icinga/: {
$role = 'icinga'
$env = 'prod'
}

/^munin/: {
$role = 'munin'
$env = 'prod'
}

default: {
$role = 'default'
$env = 'prod'
}

}

include example42

# :include:README.rdoc
# :main:__site__::readme
Expand Down

0 comments on commit 8e2850e

Please sign in to comment.