modules
CHAPTER 4
TOPICS
-
modules
-
classes
-
ordering
-
node classification
-
notification and handlers
modules
-
modules are the packages with manifests and supporting files
-
have 1:1 mapping with the applications
-
let you create a library of reusable code
anatomy
manifests
files
templates
data
spec
examples
metadata.json
README.MD
modulepath
- Modules are stored on Puppet Master
- Puppet Master has a code directory to store modules and rest of the configurations
- The default code dir needs to be changed in case want to point to a custom path.
master-code-dir: /etc/puppetlabs/code
master-code-dir: /workspace/code
cp -r /etc/puppetlabs/code /workspace/code
master-code-dir: /etc/puppetlabs/code
master-code-dir: /workspace/code
service puppetserver restart
Edit File : /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf
Copy existing structure to our workspace
Change from
Change to
Restart Puppet Master
Group exercise
You have been asked to deploy a java application server with tomcat. You have been tasked to create automation code with puppet to set it up.
Problem Statement
APP server
modules
Group exercise
- We would create a module to setup tomcat server and apply it to automate the task
- As a prerequisite, we also need to install Java. We will create a module to install openjdk.
Solution:
tasks
Group exercise
-
Generate modules for java and tomcat
-
Create class to install java and
-
Create a node definition to apply the classes
-
Create classes to install tomcat and start the service, apply
-
Write classes to manage configuration files
auto generating modules
-
puppet module is a utility which comes with code generator -
it can let you create, search install, upload modules (to and from puppet forge)
root@puppet:/workspace# puppet help module
USAGE: puppet module <action> [--environment production ] [--modulepath ]
ACTIONS:
build Build a module release package.
changes Show modified files of an installed module.
generate Generate boilerplate for a new module.
install Install a module from the Puppet Forge or a release archive.
list List installed modules
search Search the Puppet Forge for a module.
uninstall Uninstall a puppet module.
upgrade Upgrade a puppet module. generating modules Skeleton
Group exercise
cd /workspace/code/environments/production/modules
puppet module generate --skip-interview user-java
puppet module generate --skip-interview user-tomcat
|-- java
| |-- Gemfile
| |-- README.md
| |-- Rakefile
| |-- examples
| | `-- init.pp
| |-- manifests
| | `-- init.pp
| |-- metadata.json
| `-- spec
| |-- classes
| | `-- init_spec.rb
| `-- spec_helper.rb -- java
| |-- Gemfile
| |-- README.md
| |-- Rakefile
| |-- examples
| | `-- init.pp
| |-- manifests
| | `-- init.pp
| |-- metadata.json
| `-- spec
| |-- classes
| | `-- init_spec.rb
| `-- spec_helper.rb 
modules
tomcat
manifests
init.pp
- puppet module generator creates a scaffolding required to write manifests
- it also generates the default manifest (init.pp)
- additional manifests can be added to modules/xxx/manifest directory
????
????
writing manifests
modules
tomcat
manifests
init.pp
- each manifest contains a class, a named container, which encompasses one or more resources
- "::" is added to class names to separate the namespaces
- namespaces must map to the module structure
abc.pp
xyz.pp
classes
class tomcat::abc
class tomcat::xyz
subdir
pqr.pp
class tomcat::subdir::pqr
modules
tomcat
manifests
init.pp
- every feature gets its own class, and in turns a manifest
- create a separate classes for each phase of application lifecycle. This provides more granular control
install.pp
config.pp
strategies
service.pp
deploy.pp
ssl.pp
tomcat
example
Group exercise
- install packages to setup web server application and pre requisites
- manage configurations for web servers
- start/stop service
phases
tomcat::service
tomcat::config
tomcat::install
classes
java
module
Group exercise
- install packages to setup openjdk
phases
java::install
classes
java manifest
Group exercise
class java::install {
package { [ 'epel-release', 'java-1.7.0-openjdk'] :
ensure => installed,
}
}file: modules/java/manifests/install.pp
tasks
-
Generate modules for java and tomcat
-
Create class to install java and
-
Create a node definition to apply the classes
-
Create classes to install tomcat and start the service, apply
-
Write classes to manage configuration files
now that we have written the class, lets learn how to apply it, in a client server model
node definition
node
list of classes
node 'nodename' {
include class1
include class2
include class3, class4
class { 'class3':
param1 => val1,
param2 => val2,
param3 => val3,
}
}
node 'app1.example.io', 'app2.example.io', 'app3.example.io' {
include class1
include class2
}
node /^(app|web)\.blr\d+\.example\.io$/ {
include class1
include class2
}node definition
groups
regex
simple
classifying nodes
-
node definition provides a mapping between nodes and a list of classes to apply
-
node definition resides on the puppet master
-
its the simplest way of classifying nodes
-
there are more options available for node classification
ENC
Puppet Entperprise
node definition territory
code
environments
xxx
manifests
xxx.pp
webservers.pp
db.pp
modules
code
environments
production
manifests
app.pp
node definition territory
create a node definition
node 'node1' {
include java::install
}
file: environments/production/manifests/app.pp
Group exercise
pull and apply from node 1
ssh devops@node1
sudo su
puppet agent -t
Group exercise
ssh devops@node2
sudo su
puppet agent -t
apply on node 2
Group exercise
app.codespace.io
app.codespace
app
default
default block
DEFAULT BLOCK
node default {
notify{'checkpoint_1':
message => '
CHECKPOINT_1
DEFAULT BLOCK APPLIED
Looks like there is no node definition for this host
'
}
}
Group exercise
file: production/manifests/site.pp
PRO TIP
notify{'checkpoint_1':
message => '
CHECKPOINT_1
DEFAULT BLOCK APPLIED
Looks like there is no node definition for this host
'
}notify
- notify is a resource and a metaparameter (will talk about this later)
- as a resource, can be used for checkpointing
- prints a message in the run log
- useful to check if a particular block of code is being called or not
pro tip
notify{'checkpoint_1':}- Create a node definition for node2
- Include the same java class that you applied earlier for node1
- Apply and validate on node2
LAB exercise
discussion
package { 'httpd':
ensure => absent,
}
package {'nginx':
ensure => $nginx_version,
require => Package['httpd'],
}
What would this code do?
why ?
how ?
ordering
A
B
->
package
service
before B
require A
ordering
C
D
~>
file
service
notify D
subscribe C
ordering with
notification
package { 'nginx':
ensure => installed,
before => Service["nginx"],
}
file { 'nginx.conf':
ensure => file,
mode => '0644',
notify => Service["nginx"],
}
service { 'nginx':
ensure => running,
enable => true,
hasrestart => true,
hasstatus => true,
require => [ Package["nginx"], File["nginx.conf"] ]
subscribe => File["nginx.conf"],
}
Package["nginx"] -> File["nginx.conf"] ~> Service["nginx"]sample ordering.pp
sample
Type['title']
CAPS
before
require
notify
subscribe
PARAMETERS
meta -
Meta Parameters
---------------
alias, audit, before, consume, export,
loglevel, noop, notify, require,
schedule, stage, subscribe, tag
puppet describe -sm packagetasks
-
Generate modules for java and tomcat
-
Create class to install java and
-
Create a node definition to apply the classes
-
Create classes to install tomcat and start the service, apply
-
Write classes to manage configuration files
lab exercise
LAB exercise
create a tomcat::service recipe to start and enable tomcat service
Service should depends on package tomcat
create a tomcat::install recipe to install tomcat along with example apps. Packages to install are
- tomcat
- tomcat-webapps
Install
Service
Create and apply the following recipes for tomcat
lab
Expected Output
- You should be able to browse to http://ipaddress:8081 port in the browser
- Tomcat home page is the expected output
http://IPADDR:8081
LAB exercise
simplify node definition
Group exercise
class tomcat {
include java::install
include tomcat::install
include tomcat::service
}
Lets call all other manifests from init.pp
node 'node1' {
include tomcat
}
node 'node2' {
include tomcat
}Group exercise
- we included java cookbook in tomcat init.pp
- We would also add dependency in metadata.json of tomcat module that depends on java
{
"name": "user-tomcat",
"version": "0.1.0",
"author": "user",
"summary": null,
"license": "Apache-2.0",
"source": "",
"project_page": null,
"issues_url": null,
"dependencies": [
{"name":"puppetlabs-stdlib","version_requirement":">= 1.0.0"}
],
"data_provider": null
}
DEPENDENCIES
tasks
-
Generate modules for java and tomcat
-
Create class to install java and
-
Create a node definition to apply the classes
-
Create classes to install tomcat and start the service, apply
-
Write classes to manage configuration files
manging files
-
We will need to manage configurations eg. tomcat.conf -
since chef is a centralized configuration management system, we will keep the files centrally in cookbooks, which will then be copied to all managed nodes
manging files
-
Create tomcat.conf file in tomcat modules' files directory. -
add tomcat::config class to copy these files to the relevant locations on destination hosts
modules
tomcat
manifests
init.pp
install.pp
service.pp
config.pp
files
tomcat.conf
LAB exercise
destination path in nodes: /etc/tomcat/tomcat.conf
manging files
Generate tomcat.conf using chef generate file in tomcat cookbook directory.
add tomcat::config recipe to copy these files to the relevant locations on destination hosts
cookbooks
tomcat
recipes
default.rb
install.rb
service.rb
config.rb
files
tomcat.conf
tomcat-users.xml
LAB exercise
path: /etc/tomcat/tomcat-users.xml
path: /etc/tomcat/tomcat.conf
tomcat.conf
file: cookbooks/tomcat/files/default/tomcat.conf
TOMCAT_CFG_LOADED="1"
JAVA_HOME="/usr/lib/jvm/jre"
JAVA_OPTS="-Xms64m -Xmx128m -XX:MaxPermSize=128M -Djava.security.egd=file:/dev/./urandom"
CATALINA_BASE="/usr/share/tomcat"
CATALINA_HOME="/usr/share/tomcat"
JASPER_HOME="/usr/share/tomcat"
CATALINA_TMPDIR="/var/cache/tomcat/temp"
TOMCAT_USER="tomcat"
SECURITY_MANAGER="false"
SHUTDOWN_WAIT="30"
SHUTDOWN_VERBOSE="false"
CATALINA_PID="/var/run/tomcat.pid"
Group exercise
tomcat::config
class tomcat::config {
file { '/etc/tomcat/tomcat.conf':
source => 'puppet:///modules/tomcat/tomcat.conf',
owner => 'tomcat',
group => 'tomcat',
mode => '0644'
}
}file: modules/tomcat/manifests/config.rb
Group exercise
tomcat::config
cookbook_file '/etc/tomcat/tomcat.conf' do
source 'tomcat.conf'
owner 'tomcat'
group 'tomcat'
mode 0644
action :create
end
cookbook_file '/etc/tomcat/tomcat-users.xml' do
source 'tomcat-users.xml'
owner 'tomcat'
group 'tomcat'
mode 0644
action :create
end
file: cookbooks/tomcat/recipes/config.rb
refreshing service
conf
service
refresh
class tomcat::config {
file { '/etc/tomcat/tomcat.conf':
source => 'puppet:///modules/tomcat/tomcat.conf',
owner => 'tomcat',
group => 'tomcat',
mode => '0644',
notify => Service['tomcat']
}
}file: modules/tomcat/manifests/config.rb
tomcat::config
cookbook_file '/etc/tomcat/tomcat.conf' do
source 'tomcat.conf'
owner 'tomcat'
group 'tomcat'
mode 0644
action :create
notifies :restart, 'service[tomcat]', :delayed
endUpdate file: cookbooks/tomcat/recipes/config.rb
Note: Add config.rb recipe to default.rb
tomcat::config
cookbook_file '/etc/tomcat/tomcat.conf' do
source 'tomcat.conf'
owner 'tomcat'
group 'tomcat'
mode 0644
action :create
notifies :restart, 'service[tomcat]', :delayed
end
cookbook_file '/etc/tomcat/tomcat-users.xml' do
source 'tomcat-users.xml'
owner 'tomcat'
group 'tomcat'
mode 0644
action :create
notifies :restart, 'service[tomcat]', :delayed
end
file: cookbooks/tomcat/recipes/config.rb