Puppet

Installing Puppet

Puppet now comes with a new Puppet Master, puppetserver. puppet-server is the older master and runs as a Ruby application whereas puppetserver is the newer application running on JVM and has an inbuilt Jetty Web Server. puppetserver uses a Jruby interpereter to run existing puppet code. We will concentrate on puppetsever here. Installing is very simple with yum.

yum install puppetserver

systemctl enable puppet

systemctl enable puppetserver

Configuration

By default puppetserver allocates 2Gb of memory but this can be changed to as little as 512Mb on a VM.

/etc/sysconfig/puppetserver

# Modify this if you'd like to change the memory allocation, enable JMX, etc

JAVA_ARGS="-Xms2g -Xmx2g"

The main configuration file is puppet.conf. Most settings go in here. Some settings are more complex like authentication or should be in puppet.conf but cannot be added to puppet.conf like puppetdb.

Useful Commands

View a puppet resource

puppet resource user root

View resource types

puppet resource --type

View brief descriptions of resource types.

puppet describe --list

More detailed information about a resource type

puppet describe user

Execute a specific piece of puppet code.

puppet apply -e "user { 'galatea': ensure => present, }"

puppet resource package cowsay ensure=absent provider=gem

Query a resource and write the results to a file. You can then make changes and when you save and exit, the code will be applied.

puppet resource -e user galatea

user { 'galatea':

  ensure           => 'present',

  comment          => 'Galatea of Cyprus',

  gid              => '1002',

  home             => '/home/galatea',

  password         => '!!',

  password_max_age => '99999',

  password_min_age => '0',

  shell            => '/bin/bash',

  uid              => '1002',

}

Validate manifest syntax with puppet parser

puppet parser validate cowsay.pp

Include a class by declaring it.

include cowsayings::cowsay

Test and apply a puppet manifest.

puppet apply --noop cowsay.pp

puppet apply cowsay.pp

Display a puppet graph

puppet apply --noop --graph examples/init.pp

Locate the puppet graph directroy

puppet config print graphdir

Use the dot command to convert a dot file into a png.

dot -Tpng /opt/puppetlabs/puppet/cache/state/graphs/relationships.dot -o /var/www/html/questguide/relationships.png

Puppet Module Path

puppet master --configprint modulepath

/etc/puppetlabs/code/environments/production/modules - Environment specific modules

/etc/puppetlabs/code/modules - Modules available to all environments

/opt/puppetlabs/puppet/modules - Modules required by Puppet Enterprise

Module Structure

vimrc/

├── examples

│ └── init.pp

├── files

│ └── vimrc

└── manifests

└── init.pp

Class defaults and class parameters

node 'learning.puppetlabs.vm' {

  class { 'ntp':

    servers => [

      'nist-time-server.eoni.com',

      'nist1-lv.ustiming.org',

      'ntp-nist.ldsbc.edu'

      ]

  }

}

Variables and Parameters

Puppet variables are as simple as this.

$variable_name = 'variable1'

Use it like this

content => "${variable_name}some more text",

Some things to note about variables.

1. Unlike resource declarations, variable assignments are parse-order dependent. This means that you must assign a variable in your manifest before you can use it.
2. If you try to use a variable that has not been defined, the Puppet parser won't complain. Instead, Puppet will treat the variable as having the special undef value. Though this may cause an error later in the compilation process, in some cases it will pass through and cause unexpected results.
3. You can only assign a variable once within a single scope. Once it's assigned, the value cannot be changed. The value of a Puppet variable may vary across different systems in your infrastructure, but not within them.

Class parameters allow you to set variables within a class as you declare the class.

Define a class with parameters like this

class classname ( $parameter = 'default' ) {

 ... 

}

Declare class with parameters like this

class {'classname':

 parameter => 'value',

}

Resource Ordering

before - Resource must run before specified resource

after - Resource must run after specified resource

notify - Tell the specified resource to refresh

require - Refresh if the specified resource changes

Chain Arrows

Chain arrows do the same as before, after, notify and require but outside of the resources themselves. This allows for one-to-many or many-to-many.

The -> (ordering arrow) operator causes the resource to the left to be applied before the resource to the right.

The ~> (notification arrow) operator causes the resource on the left to be applied before the resource on the right, and sends a refresh event to the resource on the right if the left resource changes.

Autorequires

Puppet knows that certain resources need a relationship and applies them automatically. For instance. If the you configure a user resources with a gid, Puppet knows to create the gid first before the user.

Containment

Containment is all about when a class or resource will run.

• All resources in a class are contained. That is they will all run when the class is run.
• A relationship to a class from another class/resource passes to the resources in the class.
• If a class is included in another class, there is no relationship and therefore unordered.

The include() function can be used multiple times. If the class is already included, it will not be included again.

The resource-like syntax will throw errors. class {'apache':}

Declaring Classes for Ordering

• include - Includes the named class but does not set ordering
• require - Includes the named class and ensures it is enforced before the current one
• contain - Includes the named class and ensures it is contained within the current class

Classes can only be safely contained once.

Contain classes within the same module

Classes included in the contained class are not contained

Run Stages

• Allows ordering during runtime
• Cannot assign class to run stage with include()
• Cannot subscribe or notify across run stage boundary
• Using contain() or anchor() with run stages can behave unpredictably
• Should never use run stages except for maybe mass yum repositories
• Stage main is default for all classes
• Use before and require to order stages

• Only full classes can be assigned to run stage
• Classes must be parameterised

# Define the stages we can use in our manifests

class stages {

  stage { [ 'before', 'after']: }

  Stage['before'] -> Stage['main'] -> Stage['after']

}

# Declare classes and assign them to stages.

class webserver {

  include stages

  include packages # Gets Stage['main'] by default

  class { 'yum':

    stage => 'before',

  }

  class { 'apache':

    stage => 'after',

  }

}

Resource Collectors

Defined Resource Types

Define a defined resource

define web_user::user {

$home_dir = "/home/${title}"

$public_html = "${home_dir}/public_html"

user { $title:

ensure => present,

}

file { [$home_dir, $public_html]:

ensure => directory,

owner => $title,

group => $title,

mode => '0755',

}

file { "${public_html}/index.html":

ensure => file,

owner => $title,

group => $title,

replace => false,

content => "<h1>Welcome to ${title}'s home page!</h1>",

mode => '0644',

}

}

Declare a defined resource

web_user::user { 'shelob': }

web_user::user { 'frodo':

  content  => 'Custom Content!',

  password => pw_hash('sting', 'SHA-512', 'mysalt'),

}

Git and r10k

In order to use r10k with Git you must have a Production branch and it must be the default. Other environments will be based on the Production branch.

**Note**

Enabling code management means Puppet will manage environment directories and any existing environment directories will be not be preserved.

Set up your control repo

The control-repo will have files in it to control environments. Basically files that don't belong to modules like the Puppetfile, the environments environment.conf file, etc. Modules will be installed per environment using the Puppetfile.

**CHECK**Create ssh keys for the puppet user and yourself. For the puppet user, make the saved file be /etc/puppetlabs/puppetserver/ssh/id_rsa. Follow the process for each user requiring ssh keys.

## On the Puppet server

ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa): /etc/puppetlabs/puppetserver/ssh/id_rsa

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /etc/puppetlabs/puppetserver/ssh/id_rsa.

Your public key has been saved in /etc/puppetlabs/puppetserver/ssh/id_rsa.pub.

The key fingerprint is:

86:a7:8a:b9:60:21:54:92:69:ec:09:b5:5e:f3:36:2b root@server1.grow4.co.uk

The key's randomart image is:

+--[ RSA 2048]----+

|.o+. |

|.=o. |

|+.o o |

|.+ . o . |

|... = S |

|. . . * |

|.. E o |

|.. o o |

| +.. |

+-----------------+

[root@server1 ~]#

Amend the permissions of the public key and directory so that the pe-puppet user can access they key.

chown -R pe-puppet:pe-puppet /etc/puppetlabs/puppetserver/ssh

chmod 700 /etc/puppetlabs/puppetserver/ssh

chmod 600 /etc/puppetlabs/puppetserver/ssh/*

On the Git server create the users and groups who will access Git and copy their ssh keys.

groupadd puppet-git

useradd -G puppet-git puppet-git

useradd -G puppet-git pe-puppet

On the Git server create the control-repo. This will have any config to setup puppet. r10k for example.

Example- On server create the repo - No HEAD refs will exist

mkdir /git

cd /git

git init --bare --shared=group control-repo.git

Clone repo to the local development machine. We will do this on the same server.

git clone /git/control-repo.git

There are no refs set

git show-ref --heads

Create a blank file, add to repo and do an initial commit. For me couldn't do anything on the repo until I did an initial commit.

touch Puppetfile

git add .

git commit -m "Initial Commit"

There are now some refs

git show-ref --heads

425fdaa57c62bfef2f76b55debdc04214f793745 refs/heads/master

Now push to the remote

git push origin master

Now we need to rename master to production.

So go directly to the remote git repository and rename the master

cd /git/control-repo.git

git branch -m master production

Now you can either remove your cloned repo and reclone or you can rename the branch in your current repo.

Remove and reclone

rm -rf /clones/control-repo

git clone /git/control-repo.git /clones/control-repo

Rename branch in local repo

git branch -m master production

git remote set-head origin production

You are now in a position to add and update your environment config files. For the initial setup we will only add the Apache module to the Puppet file and full documentation can be found at Puppetfile Configuration.

Add the below into your Puppetfile. You can add preferred versions and refs if you wish.

mod 'puppetlabs/apache'

When you are ready, you can branch other environments of the production branch and start some form of Git flow. More to come.

Setup r10k

There are a number of modules that you can install to manage r10k like puppet/r10k but I have opted against this for now. Initially we will use the control-repo to deploy required files other than the puppet modules we want. The Puppetfiles deployed using the control-repo will have the modules we want to install for each environment. Full documentation can be found at r10k dynamic-environments but the shortened version is here.

Install the r10k Module - Not sure if this step needs to be done or whether it is installed when puppet is installed. Will need to check at some point.

/opt/puppetlabs/puppet/bin/gem install r10k

Configure r10k by copying the example r10k.yaml file and make amendments as required.

cd /etc/puppetlabs/r10k

cp r10k.yaml.example r10k.yaml

diff --side  r10k.yaml r10k.yaml.example | grep "|"

production:                                                 |   operations:

remote: 'git@server2:git/control-repo'         |   remote: 'git@github.com:my-org/org-operations-modules'

You should now have a production environment configuration for deploying a production environment. To do this, on the Puppet master run the following command which will deploy your production environment and all its modules or just the apache module in our case. **NOTE** If you have created a folder called production in '/etc/puppetlabs/code/environments' before running r10k for the first time, r10k will see the first run as a subsequent run rather than the first run. This is important because after the first run, Puppetfile deployment defaults to off and you will not see your modules in the Puppetfile deployed. To deploy modules subsequently, you will need to add the --puppetfile flag.

r10k deploy environment production

Subsequent runs of r10k will need the --puppetfile flag

r10k deploy environment production --puppetfile

Managing environment content with Puppetfiles