Resource Ordering

Getting Started

There are package dependcies in Java, gem dependencies in Ruby, and npm package dependencies in Nodejs. In puppet it also has dependencis between packages, services and any customized resource type, we call it resource order in puppet. In the previous sections, be build some simple modules and classes, but once you Puppet manefest come to grow, and it become much more complex, then you will find it hard to manage all you resources. Puppet is a DSL to declare you system to be a desired state, not a language handle all resources in a process, so puppet has another way to declare the resource orders between. It has four key words to specify the resource order in puppet, they are: before, require, notify and subscribe, by which all the puppet resource can be managed in a certain order.

Metaparameters for Resource Ordering

Metaparameter: Before

beforemetaparameter use to define the current resource must be initialized before the one specified, for example, you will need to ensure that the openssh-server package is installed before you try to manage the sshd service. To achieve this, you include a before metaparameter with the value Service['sshd']:

package { 'openssh-server':
  ensure => present,
  before => Service['sshd'],
}

Metaparameter: Require

requireis the oppsite way to define the resource order compare to before, for examople, you want to discribe the sshd service:

service { 'sshd':
  ensure   => running,
  enable   => true,
  require  => Package['openssh-server'],
}

It's equivalent to put before in openssh-server package, and put require in sshd service, but normally suggest to use require as it's more likely consistent with habitual thingking.

Metaparameter: Notify

It would be very annoying if puppet allowed you to deploy a new config file without providing a way to restart a service to take advantage of the change. Using the notify metaparameter we can tell a resource to signal another resource, often a file notifying a service, and cause it to refresh, which in the case of a service causes a restart.

class sshd_config {
  file { '/etc/ssh/sshd_config':
    notify  => Service['sshd'],  # this sets up the relationship
    mode    => '0600',
    owner   => 'root',
    group   => 'root',
    require => Package['openssh-server'],
    content => template('ssh/sshd_config.erb'),
  }
}

Above sshd_config would setup a resource order, once you changed this config, it would notify service sshd and cause a refresh, and for services, a refresh means restart.

Metaparameter: Subscribe

While subscribe is the oppsite way to notify, above resouce order could also be re-written with below:

service { 'sshd':
  ensure   => running,
  enable   => true,
  subscribe=> File['/etc/ssh/sshd_config'],
}

Learning by Doing

Compose a Puppet manifest to manage ssh config and service.

create sshd_config folder

mkdir sshd_config/{manifests,examples,files} -p

Compose sshd_config class

Create the sshd_config Puppet class via vim sshd_config/manifests/init.pp and fill in the file with below content:

class sshd_config{
  service { 'sshd':
          ensure   => running,
          enable   => true,
  }

  file { '/etc/ssh/sshd_config':
          notify  => Service['sshd'],  # this sets up the relationship
          mode    => '0600',
          owner   => 'root',
          group   => 'root',
          source  => 'puppet:///modules/sshd_config/sshd_config',
  }
}

sshd_config Invocation

Create a test.pp via vim sshd_config/examples/test.pp with below content

include sshd_config

Validate

puppet parser validate sshd_config/manifests/init.pp
puppet parser validate sshd_config/examples/test.pp

Copy the sshd_config

Before we run the Puppet manifest, we need to have a sshd_config placed in sshd_config/files directory, to make it stratforward, we directly copy the file from /etc/ssh/sshd_config to sshd_config/files directory. Suggest you back-up the orginal /etc/ssh/sshd_config first.

Make change in sshd_config/files/sshd_config

To simulate a real case, we need to update shd_co nfig/files/sshd_config a little bit, for example, I changed part of the config from Protocol 2 to Protocol 1

Now we have the Puppet manifest and sshd_config file in place, then it's good to run the puppet apply.

Before we go run, check the origin config file sshd_config/files/sshd_config, and use ps to check the sshd process via ps ef|grep sshd, because after we run the puppet apply, both the config file and the process will be refreshed.

Dry Run

puppet apply --noop sshd_config/examples/test.pp

Puppet Apply

If everything okay, then puppet apply

puppet apply sshd_config/examples/test.pp

Verify

After apply, check the /etc/ssh/sshd_config, this file should be replace by the one sshd_config/files/sshd_config, and the sshd process id should changed, because the config file change will notify sshd service with a refresh event, and refresh event for service means a restart.