Puppet
What is Puppet
A Configuration Management Tool
A framework for Systems Automation
A Declarative Domain Specific Language (DSL) ), a mixte between JSON and Ruby.
Used by sysadmins and easier to adapt as human readable.
Determines installation based on defined dependencies, could give surprises.
Puppet keeps the configuration of the hosts under check.
An OpenSource software in written Ruby
Works on Linux, Unix (Solaris, AIX, *BSD), MacOS, Windows (Supported Platforms)
Developed by Puppet Labs
Used by http://puppetlabs.com/customers/companies/ ... ... and many others
Configuration Management Advantage
Infrastructure as Code: Track, Test, Deploy, Reproduce, Scale
Code commits log shows the history of change on the infrastructure
Reproducible setups: Do once, repeat forever
Scale quickly: Done for one, use on many
Coherent and consistent server setups
Aligned Environments for devel, test, qa, prod nodes
Alternatives to Puppet: Chef, Salt, Ansible
References and Ecosystem
Puppet Labs - The Company behind Puppet
Puppet - The OpenSource version
Puppet Enterprise - The commercial version
The Community - Active and vibrant
Puppet Documentation - Main and Official reference
Puppet Modules on: Module Forge and GitHub
Software Related to Puppet
Facter - Complementary tool to retrieve system's data
MCollective - Infrastructure Orchestration framework
Hiera - Key-value lookup tool where Puppet data can be placed
PuppetDB - Stores all the data generated by Puppet
Puppet DashBoard - A Puppet Web frontend and External Node Classifier (ENC)
The Foreman - A well-known third party provisioning tool and Puppet ENC
Geppetto - A Puppet IDE based on Eclipse
Puppet Versions
From version 2 Puppet follows Semantic Versioning standards to manage versioning, with a pattern like: MAJOR.MINOR.PATCH
This implies that MAYOR versions might not be backwards compatible, MINOR versions may introduce new features keeping compatibility and PATCHes are for backwards compatible bug fixes.
This is the history of the main Puppet versions and some relevant changes
Check also Puppet Language History for a more complete review:
0.9.x - First public beta
0.10.x - 0.21.x - Various "early" versions
0.22.x - 0.25.x - Improvements and OS wider support
2.6.x - Many changes. Parametrized classes
2.7.x - Windows support
3.0.x - Many changes. Disabled dynamic variables scope. Data bindings
3.2.x - Future parser (experimental, will be default in Puppet 4)
4.x.x - Release in early 2015. New parser, new type system and lot of changes, some backwards incompatibilities
Puppet Advantages
Normally most of the configuration management tool, deploy the required configuration on a machine, and leave them as it is. But puppet keeps on verifying the configuration at a specified interval(which you can modify as per requirement).
Puppet defines the configurations for a host with the help of a language which is very easy to learn and is only used for that purpose.
Puppet is used by major players in the industry like Google,red hat etc.
Larger open-source developer base.
Wide number of platforms are supported in puppet.
Its works very smooth, even when deployed in a large infrastructure (thousands of hosts to manage).
Puppet Design
Puppet consists of a server (Puppet Master) and a client(Puppet agent).
Puppet Master: This machine contains all the configuration for different hosts. Puppet master will run as a daemon on this master server.
Puppet Agent: This is the daemon that will run on all the servers, which are to be managed using puppet. Puppet agent will go and ask the configuration for itself from the puppet master server at a specific time interval.
The puppet master package always needs to be a greater version than the puppet agent.
Puppet has pull based model from Agent. The default is 30 min runtime for Agent.
Puppet has dry-run --noop mode for simulation, helpful for trading business to dry run in peak time.
Step 1: Whenever a client node connects to the master, the master server analyzes the configuration to be applied to the node, and how to apply that configs on the node.
Step 2:Puppet master server Takes and collects all the resources and configurations to be applied to the node, and compiles it and make it a catalog. This catalog is given to the puppet agent of the node.
Step 3: Puppet agent will apply the configuration on the node, according to the catalog, and then reply back, and submit the report of the configuration applied to the puppet master server.
Facter tool is used to give the complete details about the node(agent) to the puppet master. The details make puppet master take decision w.r.t. different platforms or logic involved.
For example if suppose the node is debian then to install a package puppet will use apt-get instead of yum.
Facter tool is required to be installed on all the nodes, where you want to apply configuration using puppet.
Puppet Install
Download Fedora 21 Iso : https://getfedora.org/en/workstation/download/
Download\Install Virtualbox : https://www.virtualbox.org/wiki/Downloads
Install Fedora 21 to create VM on Virtualbox : https://www.youtube.com/watch?v=tKPCOTtMbdI
Create VM - Puppet-Master : IP 192.168.1.8
Create VM - Puppet-Agent 1: IP 192.168.1.9
Enable ssh
Start : systemctl start sshd.service
Stop : systemctl stop sshd.service
Start at Boot : systemctl enable sshd.service
Prerequisites - Ruby Language, Ruby Libraries, Shadow Ruby Libraries
VM : Puppet-Master : Install Puppet, Puppet-server, facter
sudo yum install ruby-shadow ruby ruby-libs
sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm
- sudo yum install puppet puppet-server facter
VM : Puppet-Agent 1: Install Puppet, facter
sudo yum install ruby-shadow ruby ruby-libs
sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm
- sudo yum install puppet facter
Puppet - Configuring Puppet Master
Edit /etc/hosts, add VM ip/dns
- 192.168.1.8 master.cmdemo.in puppet puppet.cmdemo.in
- 192.168.1.9 agent1.cmdemo.in
Puppet.conf - /etc/puppet/
If not present, create by –
- # puppetmasterd --genconfig > /etc/puppet/puppet.conf
Puppet conf file has 3 sections:
- [agent] -- this section is for mentioning agent specific parameters.
- [master] -- this section is for specifying options for puppet master.
- [main] -- this section will contain all global configuration options.
Configure the [master] section
[master]
certname=master.cmdemo.in
manifest (.pp ext) is nothing but a name that puppet calls those files which contain the configuration options for the agents.
site.pp : Tells what configurations needs to be applied to the clients (agents)
Create empty /etc/puppet/manifests/site.pp , touch /etc/puppet/manifests/site.pp
You can alter the location of manifests and site.pp file with the help of manifestdir and manifestoptions in puppet.conf file.
The default directory for SSL certificates is /var/lib/puppet.
Starting puppet master server will also create a self signed certificate for the master server.
Start Puppet Master - sudo puppet master [--verbose] [--no-daemonize]
# sudo puppet master --verbose --no-daemonize
Notice: Starting Puppet master version 3.7.1
# ls /var/lib/puppet/ssl/ca/signed/
- master.cmdemo.in.pem
# lsof -i :8140
- COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
- ruby-mri 3368 puppet 9u IPv4 41742 0t0 TCP *:8140 (LISTEN)
Puppet - Configuring Puppet Agent
Edit /etc/hosts, add VM ip/dns
192.168.1.8 master.cmdemo.in puppet puppet.cmdemo.in
192.168.1.9 agent1.cmdemo.in
Configure the [agent] section in /etc/puppet/puppet.conf
[agent]
certname=agent1.cmdemo.in
1. Start Puppet Agent
# sudo puppet agent --server puppet --no-daemonize --verbose
- Info: Creating a new SSL key for agent1.cmdemo.in
- Info: Caching certificate for ca
- Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml
- Info: Creating a new SSL certificate request for agent1.cmdemo.in
- Info: Certificate Request fingerprint (SHA256): 3B:B7:0C:3F:2E:17:05:EE:B8:D7:4A:63:F8:00:A1:F1:B2:54:F4:11:34:16:0F:2E:EA:56:13:5C:4C:30:FE:88
2. Puppet-Master : Verbose Logs
Info: Not Found: Could not find certificate agent1.cmdemo.in
Info: Not Found: Could not find certificate_request agent1.cmdemo.in
Notice: agent1.cmdemo.in has a waiting certificate request
Info: Not Found: Could not find certificate agent1.cmdemo.in
3. Puppet-Master : Add certificate for Agent
# puppet cert --sign agent1.cmdemo.in
- Notice: Signed certificate request for agent1.cmdemo.in
- Notice: Removing file Puppet::SSL::CertificateRequest agent1.cmdemo.in at '/var/lib/puppet/ssl/ca/requests/agent1.cmdemo.in.pem'
4. Puppet-Master : Verify ceritificates
# ls /var/lib/puppet/ssl/ca/signed/
- agent1.cmdemo.in.pem master.cmdemo.in.pem
5. Puppet-Master : Verbose Logs
- Info: Caching node for agent1.cmdemo.in
6. Puppet-Agent: Got certificate for Master
- Info: Caching certificate for agent1.cmdemo.in
- Notice: Starting Puppet client version 3.7.1
- Info: Caching certificate_revocation_list for ca
- Info: Retrieving pluginfacts
- Info: Retrieving plugin
- Info: Caching catalog for agent1.cmdemo.in
- Info: Applying configuration version '1430857769'
- Notice: Finished catalog run in 0.18 seconds
At Puppet Agent, add runinterval to /etc/puppet/puppet.conf
runinterval = 30s
At Puppet Master, update /etc/puppet/manifests/site.pp
node default {
package { ‘ftp' :
ensure => installed,
allow_virtual => false,
}
}
At Puppet Master, apply - # puppet apply /etc/puppet/manifests/site.pp
At Puppet Agent, fetch the updates automatically as per runinterval timing
- Info: Applying configuration version '1430854856'
- Notice: /Stage[main]/Main/Node[default]/Package[ftp]/ensure: created
- Notice: Finished catalog run in 2.21 seconds
(Verified by running ftp on Puppet Agent)
Puppet Language Basics
Puppet Language
A Declarative Domain Specific Language (DSL)
It defines STATES (Not procedures)
Puppet code is written in manifests (files with .pp extension)
In the code we declare resources that affect elements of the system (files, packages, services ...)
Resources are grouped in classes which may expose parameters that affect their behavior.
Classes and configuration files are organized in modules.
Consult the official glossary to give the correct meaning to Puppet terms
Node classification
When clients connect, the Puppet Master generates a catalog with the list of of the resources that clients have to apply locally.
The Puppet Master has to classify nodes and define for each of them:
The classes to include
The parameters to pass
The Puppet environment to use
The catalog is generated by the Master according to the logic of our Puppet code and data.
In our code we can define our variables and use other ones that may come from different sources:
facts generated directly by the client
parameters obtained from node's classification
Puppet internal variables
Resource Types
Resource Types are single units of configuration composed by:
A type (package, service, file, user, mount, exec ...)
A title (how is called and referred)
Zero or more arguments
type { 'title':
argument => value,
other_arg => value,
}
Example for a file resource type:
file { 'motd':
path => '/etc/motd',
content => 'Tomorrow is another day',
}
Resource Types Reference
Find online the complete Type Reference for the latest or earlier versions.
From the shell the command line interface:
puppet describe file
For the full list of available descriptions try:
puppet describe --list
Give a glance to Puppet code for the list of native resource types:
ls $(facter rubysitedir)/puppet/type
Simple samples of resources
Installation of OpenSSH package
package { 'openssh':
ensure => present,
}
Creation of /etc/motd file
file { 'motd':
path => '/etc/motd',
}
Start of httpd service
service { 'httpd':
ensure => running,
enable => true,
}
More complex sample of resources
Management of nginx service with parameters defined in module's variables
service { 'nginx':
ensure => $::nginx::manage_service_ensure,
name => $::nginx::service_name,
enable => $::nginx::manage_service_enable,
}
Creation of nginx.conf with content retrieved from different sources (first found is served)
file { 'nginx.conf':
ensure => present,
path => '/etc/nginx/nginx.conf',
source => [
"puppet:///modules/site/nginx.conf--${::fqdn}",
"puppet:///modules/site/nginx.conf" ],
}
Classes Definition
Classes are containers of different resources. Since Puppet 2.6 they can have parameters
Example of a class definition:
class mysql (
root_password => 'default_value',
port => '3306',
) {
package { 'mysql-server':
ensure => present,
}
service { 'mysql':
ensure => running,
}
[...]
}
Note that when we define a class we just describe what it does and what parameters it has, we don't actually add it and its resources to the catalog.
Classes Declaration
When we have to use a class previously defined, we declare it.
This can be done in 2 different ways:
"Old style" class declaration, without parameters:
include mysql
(Inside a catalog we can have multiple includes of the same class but that class it's applied only once.)
"New style" (from Puppet 2.6) class declaration with explicit parameters:
class { 'mysql':
root_password => 'my_value',
port => '3307',
}
(Syntax is the same of normal resources and the same class can be declared, in this way, only once inside the same catalog)
Variables
We need them to provide different configurations for different kind of servers.
They can be defined in different places and by different actors:
Can be provided by client nodes as facts
Can be defined by users in Puppet code, on Hiera on in the ENC
Can be built-in and be provided directly by Puppet
Facts
Facter runs on clients and collects facts that the server can use as variables
al$ facter
architecture => x86_64
fqdn => Macante.example42.com
hostname => Macante
interfaces => lo0,eth0
ipaddress => 10.42.42.98
ipaddress_eth0 => 10.42.42.98
kernel => Linux
macaddress => 20:c9:d0:44:61:57
macaddress_eth0 => 20:c9:d0:44:61:57
memorytotal => 16.00 GB
netmask => 255.255.255.0
operatingsystem => Centos
operatingsystemrelease => 6.3
osfamily => RedHat
virtual => physical
User Variables
We can define custom variables in different ways:
In Puppet manifests:
$role = 'mail'
$package = $::operatingsystem ? {
/(?i:Ubuntu|Debian|Mint)/ => 'apache2',
default => 'httpd',
}
In an External Node Classifier (ENC)
Commonly used ENC are Puppet DashBoard, the Foreman, Puppet Enterprise.
In an Hiera backend
$syslog_server = hiera(syslog_server)
Nodes - Default Classification
A node is identified by the PuppetMaster by its certname, which defaults to the node's fqdn
In the first manifest file parsed by the Master, site.pp, we can define nodes with a syntax like:
node 'web01' {
include apache
}
We can also define a list of matching names:
node 'web01' , 'web02' , 'web03' {
include apache
}
or use a regular expression:
node /^www\d+$/ {
include apache
}
A node can inherit another node and include all the classes and variables defined for it, this feature is now deprecated and is not supported anymore on Puppet 4.
The Catalog
The catalog is the complete list of resources, and their relationships, that the Puppet Master generates for the client.
It's the result of all the puppet code and logic that we define for a given node in our manifests and is applied on the client after it has been received from the master.
The client uses the RAL (Resource Abstraction Layer) to execute the actual system's commands that convert abstract resources like
package { 'openssh': }
to their actual fullfillment on the system (apt-get install openssh , yum install openssh ...).
The catalog is saved by the client in /var/lib/puppet/client_data/catalog/$certname.json
Certificates Management
On the Master we can use puppet cert to manage certificates
List the (client) certificates to sign:
puppet cert list
List all certificates: signed (+), revoked (-), to sign ( ):
puppet cert list --all
Sign a client certificate:
puppet cert sign <certname>
Remove a client certificate:
puppet cert clean <certname>
Client stores its certificates and the server's public one in $vardir/ssl** (/var/lib/puppet/ssl on Puppet OpenSource)
Server stores clients public certificates and in $vardir/ssl/ca (/var/lib/puppet/ssl/ca). DO NOT remove this directory.
Useful paths
/var/log/puppet contains logs (but also on normal syslog files, with facility daemon), both for agents and master
/var/lib/puppet contains Puppet operational data (catalog, certs, backup of files...)
/var/lib/puppet/ssl contains SSL certificate
/var/lib/puppet/clientbucket contains backup copies of the files changed by Puppet
/etc/puppet/manifests/site.pp (On Master) The first manifest that the master parses when a client connects in order to produce the configuration to apply to it (Default on Puppet < 3.6 where are used config-file environments)
/etc/puppet/environments/production/manifests/site.pp (On Master) The first manifest that the master parses when using directory environments (recommended from Puppet 3.6 and default on Puppt >= 4)
/etc/puppet/modules and /usr/share/puppet/modules (On Master) The default directories where modules are searched
/etc/puppet/environments/production/modules (On Master) An extra place where modules are looked for when using directory environments
Anatomy of a Puppet Run - Part 1: Catalog compilation
Execute Puppet on the client
Client shell # puppet agent -t
If pluginsync = true (default from Puppet 3.0) the client retrieves all extra plugins (facts, types and providers) present in modules on the server's $modulepath
Client output # Info: Retrieving plugin
The client runs facter and send its facts to the server
Client output # Info: Loading facts in /var/lib/puppet/lib/facter/... [...]
The server looks for the client's hostname (or certname, if different from the hostname) and looks into its nodes list
The server compiles the catalog for the client using also client's facts
Server's logs # Compiled catalog for in environment production in 8.22 seconds
If there are not syntax errors in the processed Puppet code, the server sends the catalog to the client, in PSON format.
Anatomy of a Puppet Run - Part 2: Catalog application
Client output # Info: Caching catalog for
The client receives the catalog and starts to apply it locally
If there are dependency loops the catalog can't be applied and the whole tun fails.
Client output # Info: Applying configuration version '1355353107'
All changes to the system are shown here. If there are errors (in red or pink, according to Puppet versions) they are relevant to specific resources but do not block the application of the other resources (unless they depend on the failed ones).
At the end ot the Puppet run the client sends to the server a report of what has been changed
Client output # Finished catalog run in 13.78 seconds
The server eventually sends the report to a Report Collector
Managing packages
Installation of packages is managed by the package type.
The main arguments:
package { 'apache':
name => 'httpd', # (namevar)
ensure => 'present' # Values: 'absent', 'latest', '2.2.1'
provider => undef, # Force an explicit provider
}
Managing services
Management of services is via the service type.
The main arguments:
service { 'apache':
name => 'httpd', # (namevar)
ensure => 'running' # Values: 'stopped', 'running'
enable => true, # Define if to enable service at boot (true|false)
hasstatus => true, # Whether to use the init script' status to check
# if the service is running.
pattern => 'httpd', # Name of the process to look for when hasstatus=false
}
Managing files
Files are the most configured resources on a system, we manage them with the file type:
file { 'httpd.conf':
# (namevar) The file path
path => '/etc/httpd/conf/httpd.conf',
# Define the file type and if it should exist:
# 'present','absent','directory','link'
ensure => 'present',
# Url from where to retrieve the file content
source => 'puppet://[puppetfileserver]/<share>/path',
# Actual content of the file, alternative to source
# Typically it contains a reference to the template function
content => 'My content',
# Typical file's attributes
owner => 'root',
group => 'root',
mode => '0644',
# The sylink target, when ensure => link
target => '/etc/httpd/httpd.conf',
# Whether to recursively manage a directory (when ensure => directory)
recurse => true,
}
Executing commands
We can run plain commands using Puppet's exec type. Since Puppet applies it at every run, either the command can be safely run multiple times or we have to use one of the creates, unless, onlyif, refreshonly arguments to manage when to execute it.
exec { 'get_my_file':
# (namevar) The command to execute
command => "wget http://mysite/myfile.tar.gz -O /tmp/myfile.tar.gz',
# The search path for the command. Must exist when command is not absolute
# Often set in Exec resource defaults
path => '/sbin:/bin:/usr/sbin:/usr/bin',
# A file created by the command. It if exists, the command is not executed
creates => '/tmp/myfile.tar.gz',
# A command or an array of commands, if any of them returns an error
# the command is not executed
onlyif => 'ls /tmp/myfile.tar.gz && false',
# A command or an array of commands, if any of them returns an error
# the command IS executed
unless => 'ls /tmp/myfile.tar.gz',
}
Managing users
Puppet has native types to manage users and groups, allowing easy addition, modification and removal. Here are the main arguments of the user type:
user { 'joe':
# (namevar) The user name
name => 'joe',
# The user's status: 'present','absent','role'
ensure => 'present',
# The user's id
uid => '1001',
# The user's primary group id
gid => '1001',
# Eventual user's secondary groups (use array for many)
groups => [ 'admins' , 'developers' ],
# The user's password. As it appears in /etc/shadow
# Use single quotes to avoid unanted evaluation of $* as variables
password => '$6$ZFS5JFFRZc$FFDSvPZSSFGVdXDlHe�',
# Typical users' attributes
shell => '/bin/bash',
home => '/home/joe',
mode => '0644',
}
Puppet language style
Puppet language as an official Style Guide which defines recommended rules on how to write the code.
The standard de facto tool to check the code style is puppet-lint.
Badly formatted example:
file {
"/etc/issue":
content => "Welcome to $fqdn",
ensure => present,
mode => 644,
group => "root",
path => "${issue_file_path}",
}
Corrected style:
file { '/etc/issue':
ensure => present,
content => "Welcome to ${fqdn}",
mode => 0644,
group => 'root',
path => $issue_file_path,
}
Resource references
In Puppet any resource is uniquely identified by its type and its name.
We can't have 2 resources of the same type with the same name in a catalog.
We have seen that we declare resources with a syntax like:
type { 'name':
arguments => values,
}
When we need to reference to them in our code the syntax is like:
Type['name']
Some examples:
file { 'motd': ... }
apache::virtualhost { 'example42.com': .... }
exec { 'download_myapp': .... }
are referenced, respectively, with
File['motd']
Apache::Virtualhost['example42.com']
Exec['download_myapp']
Resource defaults
It's possible to set default argument values for a resource in order to reduce code duplication. The syntax is:
Type {
argument => value,
}
Common examples:
Exec {
path => '/sbin:/bin:/usr/sbin:/usr/bin',
}
File {
mode => 0644,
owner => 'root',
group => 'root',
}
Resource defaults can be overriden when declaring a specific resource of the same type.
Note that the "Area of Effect" of resource defaults might bring unexpected results. The general suggestion is:
Place global resource defaults in /etc/pupept/manifests/site.pp outside any node definition.
Place local resource defaults at the beginning of a class that uses them (mostly for clarity sake, as they are parse-order independent).
Nodes inheritance
On the PuppetMaster we can define with the node definition the resources to apply to any node.
It is possible to have an inheritance structure for nodes, so that resources defined for a node are automatically included in an inheriting node.
An example:
node 'general' { ... }
node 'www01' inherits general { ... }
In Puppet versions prior to 3, it was possible to use nodes inheritance also to set variables and override them at different inheritance levels, and refer to these variables with their "short" name (not fully qualified).
When using this approach it was important to avoid the inclusion on classes in the inheritance tree, since some variables could be evaluated in an unexpected way.
This is no more possible because variables are not more dynamically scoped, and generally speaking nodes inheritance has been deprecated.
Class inheritance
In Puppet classes are just containers of resources and have nothing to do with OOP classes. Therefore the meaning of class inheritance is somehow limited to few specific cases.
When using class inheritance, the main class ('puppet' in the sample below) is always evaluated first and all the variables and resource defaults it sets are available in the scope of the child class ('puppet::server').
Moreover the child class can override the arguments of a resource defined in the main class. Note the syntax used when referring to the existing resource File['/etc/puppet/puppet.conf']:
class puppet {
file { '/etc/puppet/puppet.conf':
content => template('puppet/client/puppet.conf'),
}
}
class puppet::server inherits puppet {
File['/etc/puppet/puppet.conf'] {
content => template('puppet/server/puppet.conf'),
}
}
Metaparameters
Metaparameters are parameters available to any resource type, they can be used for different purposes:
Manage dependencies (before, require, subscribe, notify, stage)
Manage resources' application policies (audit, noop, schedule, loglevel)
Add information to a resource (alias, tag)
Official documentation on Metaparameters
Managing dependencies
Puppet language is declarative and not procedural: it defines states, the order in which resources are written in manifests does not affect the order in which they are applied to the desired state.
To manage resources ordering, there are 3 different methods, which can cohexist:
1 - Use the metaparameters before, require, notify, subscribe
2 - Use the Chaining arrows (compared to the above metaparamers: -> , <- , <~ , ~>)
3 - Use run stages
Managing dependencies - before | notify
In a typical Package/Service/Configuration file example we want the package to be installed first, configure it and then start the service, eventually managing its restart if the config file changes.
This can be expressed with metaparameters:
package { 'exim':
before => File['exim.conf'],
}
file { 'exim.conf':
notify => Service['exim'],
}
service { 'exim':
}
which is equivalent to
Package['exim'] -> File['exim.conf'] ~> Service['exim']
Managing dependencies - require | subscribe
The previous example can be expressed using the alternative reverse metaparameters:
package { 'exim':
}
file { 'exim.conf':
require => Package['exim'],
}
service { 'exim':
subscribe => File['exim.conf'],
}
which can also be expressed like:
Service['exim'] <~ File['exim.conf'] <- Package['exim']
Sample: Assign a variable value
Selector for variable's assignement
$package_name = $osfamily ? {
'RedHat' => 'httpd',
'Debian' => 'apache2',
default => undef,
}
case
case $::osfamily {
'Debian': { $package_name = 'apache2' }
'RedHat': { $package_name = 'httpd' }
default: { notify { "Operating system $::operatingsystem not supported" } }
}
if elsif else
if $::osfamily == 'Debian' {
$package_name = 'apache2'
} elsif $::osfamily == 'RedHat' {
$package_name = 'httpd'
} else {
notify { "Operating system $::operatingsystem not supported" }
}
Puppet Codebook
Packages
Installing Packages
Package install options
Removing a package
Tracking newer package versions
Install multiple packages
Per distro package names
Installing a RubyGem
Add a Yum repository
Remove Yum repo config setting
Change Package Providers
Files
Create a directory
Create a symlink
Create a directory tree
Select a file based on a fact
Only manage absent files
Restart service when config changes
Reduce Duplicated File Attributes
Avoid hard coding file paths
Host files
Add a host entry
Remove a host entry
Remove all unmanaged host entries
Localise service host entries
Exec
Execute commands from Puppet Manifests
Globally Set Exec Paths
Nicer Exec Names
Run exec if file is missing
Control when an exec should run
Control Execs output
Services
Ensure service is running
Start service on boot
Restart stopped service
Ensure service is stopped
Don't start service on boot
Restart service when config changes
Facts and Facter
Show all facter facts
See all client variables
Enable LSB facts
Override a Facter fact
Display fact resolution timings
Enable the Facts hash
Using the Facts hash
Deploy a custom fact
Deploy an External fact
Modules
Deploy a custom fact
Deploy an External fact
Users
Create home directories
Managing User Password Fails
Groups
Add a Unix group
Remove a Unix group
Change a groups group ID
Debugging
Adding Debug Messages
View puppet variables for this client
Show Puppet Config Settings
Display fact resolution timings
Misc
Why the trailing commas?
Autosigning Client Certificates
View existing resources
Command Line
Adhoc Puppetry with puppet apply execute
Syntax Check Manifests
Which files are puppet managed?
Testing
Test Manifest Syntax
Override a Facter fact
Cron
Managing /etc/cron.d Entries
Errors
Managing User Password Fails
Fileserver Path Specified In Template call
Files found without specifying 'modules'
Chef
Similar to Puppet, used pull method and master-agent structure.
Chef also use a D.S.L but based on the Ruby syntax.
Used by DevOps
Procedure based approach with ruby, takes initial time but code management easy and no surprises.
Salt
Salt is a python based tool.
Salt is similar to Ansible in that it's a CLI-based tool that utilizes a push method of client communication.
Salt can communicate with clients through general SSH, but the scalability is greatly enhanced through the use of client agents called minions.
Also, Salt includes an asynchronous file server to speed up file serving to minions, which is all part of Salt's focus on high scalability.
Custom modules can be written in Python or PyDSL.
Ansible
Similar to Salt, utilizes a push method of client communication.
The focus is to be streamlined and fast, and to require no node agent installation. Thus, Ansible performs all functions over SSH.
Ansible is built on Python, in contrast to the Ruby foundation of Puppet and Chef.
Ansible master server can communicate with the node via SSH and perform all required tasks.
Ansible can use Paramiko, a Python SSH2 implementation, or standard SSH for communications.
Puppet ENterprise Master
Introduction
Automation is critical to the success of any cloud initiative, to manage dynamic infrastructure at scale.
It's easy to spin up new machines in AWS, but a lot harder to ensure those machines are correctly configured.
Puppet Enterprise makes it easy to automate the provisioning, configuration and ongoing management of your machines and the software running on them.
Make rapid, repeatable changes and automatically enforce the consistency of systems and devices – across physical and virtual machines, on premise or in the cloud.
Installation
The installer tar could be downloaded for free trail (upto 10 nodes).
Download the tar from download or get
Create a VM over AWS EC2. Allow traffic via port
8140 - Puppet communication
443 - https for Puppet Entrise Console
61613 - the Puppet Enterprise orchestration engine (MCollective)
Untar the puppet-enterprise
ls
Run Installer
sudo ./puppet-enterprise-installer
Goto Browser and open puppet enterprise installer web
Puppet aws module
Puppet aws module : https://github.com/puppetlabs/puppetlabs-aws
Installation with github ReadMe steps
Viewing existing EC2 instances
Puppet aws module
Creating EC2 instances
Node_aws help
Setup an EC2 instances
Setup up a security group
References
Chef Vs Puppet :
https://pierrerambaud.com/blog/devops/chef-vs-puppet- http://www.scriptrock.com/blog/puppet-vs-chef-battle-wages
Moving away from Puppet to Salt
http://ryandlane.com/blog/2014/08/04/moving-away-from-puppet-saltstack-or-ansible/
Puppet or Chef
http://www.infoworld.com/article/2614204/data-center/puppet-or-chef--the-configuration-management-dilemma.html
Puppet wins
http://bitfieldconsulting.com/puppet-vs-chef
Puppet Vs Salt
http://www.scriptrock.com/articles/puppet-vs-salt
Puppet Tutorial
http://www.example42.com/tutorials/PuppetTutorial/
Puppet Releases : http://docs.puppetlabs.com/release_notes/#current-release
Type References : http://docs.puppetlabs.com/references/latest/type.html
Puppet Codebook : http://www.puppetcookbook.com/
References - Puppet Enterprise
Download : https://puppetlabs.com/download-puppet-enterprise.Get : https://puppetlabs.com/download-puppet-enterprise-get
Install Answer : http://docs.puppetlabs.com/pe/3.0/install_answer_file_reference.html