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 















Comments