Puppet declara dependencias de manera implícita, pero no siempre se cargan los recursos de la manera esperada. En Puppet hay tres maneras de declaraciones implícitas

• title hash: Es una ordenación aleatoria pero consistente
• manifest: Ordena siguiendo el orden de declaración en el manifiesto (por defecto en Puppet 4)
• random: Aleatorio en cada ejecución. Es útil para debuggar problemas con relaciones de dependencia

Los metaparámetros de dependencia explicita proveen un medio de organización de dependencias muy potente. Veámoslo.

Ordenando recursos

En la siguiente declaración se declara una dependencia:

package { 'nginx':
       ensure => 'present',
       before => Service['nginx']

}

service { 'nginx':
       ensure => 'running',
       enabled => 'true',
       require => Package['nginx']
}

En este caso, el servicio ‘nginx’ se ejecutará sólo si el packete ‘nginx’ está presente. Los metaparámetros before y require son reduntanes en este caso y no ofrecen datos a otros recursos. En la declaraciones explicitas no es necesario declarar relaciones innecesarias, ya que hace más frágil el manifiesto.

Disparadores de eventos

Los metaparámetros notify y subscribe funcionan de manera similar a los dos anteriores, pero también enviarán eventos de refresco (refresh events) al recurso dependiente si la dependencia cambia. Por ejemplo, un servicio dependiente se recargará si su configuración cambia.

package { 'nginx':
       ensure => 'latest',
       notify => Service['nginx']

}

service { 'nginx':
       ensure => 'running',
       enabled => 'true',
       subscribe => Package['nginx']
}

Cuando el paquete nginx se actualice a la última versión, el recurso enviará un refresh event al servicio nginx para que se recargue. Ambos metaparámetros son redundantes.

El evento de refresco tiene un significado especial para recursos exec con el atributo refreshonly. Estos recursos sólo se aplicarán sí, y sólo si, la dependencia cambia.

file {'nombre':
  ensure  => 'file',
  source  => 'puppet://puppetserver/modules/module_name/name.sh',
  path => '/usr/local/bin/name.sh',
  notify => Exec['name.sh']
}

exec {'name.sh'':
  path => '/usr/local/bin',
  logoutput => 'true'
  refreshonly => true,
}

En script name.sh no se ejecutará a menos que el archivo se haya creado.

Flechas para encadenar recursos

La relaciones dependencia anteriores pueden declararse usando flechas aunque, sin embargo, su uso está desaconsejado por ser de lectura más difícil. Por ejemplo, para instalar Nginx antes que iniciar el servicio:

Package ['nginx'] -> Service['nginx']

Para envíar un evento de refresco:

Package ['nginx'] ~> Service['nginx']

Es posible expresarlo a la inversa, pero esto no habría que hacerlo nunca:

 Service['nginx'] <~ Package ['nginx']

Colectores

Un colector es un grupo de varios recursos. Hay que usarlo con precaución, ya que puede tener consecuencias inintencionadas nefastas. Se declara con el tipo de recurso seguido de <| atributo |> Por ejemplo:

User <||>                                          # Todos los usuarios declarados 
Service <| ensure == running |>    # Todos los servicios que están ejecutándose
Package <| tag == 'http' |>         # Todos los paquetes etiquetado con 'http'

La condición de búsqueda puede ser booleana:

Service <| (ensure == running) or (enabled == true ) |>
Service <| (ensure == running) and (title != system' ) |>

En resumen

Hemos visto los siguientes controles:

• before y la flecha ->    Expresa una dependencia
• notify y la flecha ~>    Envía un refresh event
• require                           Exprea un recurso dependiente
• subscribe                       Se aplica cuando recibe un refresh event
• refreshonly                   Se ejectuta sólo cuando recibe un refresh event

En mi último post, vimos como instalar Puppet en la arquitectura master-agent y la creación de un módulo para declarar algunos recursos. En este, quiero mostrar cómo configurar un parámetro utilizando la aplicación Facter y despues, cómo extender Facter para tomar ese parámetro desde un archivo que lo contenga, creado «a mano» en el agente. Utilizaré la configuración del post anterior de la serie automatizaciones para el ejemplo un servicio PHP-FPM

Modulo «zona horaria»

El modulo que crearemos se llamará zonahoraría. Tomará la zona horaria desde un parámetro del sistema y en la segunda parte del post modificaré el manifiesto para lea desde un fact a medida.

Instalando PHP

Instalamos el módulo de PHP:

cd /etc/puppetlabs/code/environment/test/modules
/opt/puppetlabs/bin/puppet module install mayflower-php --version 4.0.0-beta1

 Creando módulo «zonahoraria»

En el directorio de módulos:

/opt/puppetlabs/bin/puppet module generate enredadera-zonahoraria

 Creando init.pp

El init.pp del módulo utilizará la clase del módulo recién instalado (podéis encontar más información acerca del módulo en este enlace).

class zonahoraria::setup {

}

 Configuración global

class { '::php::globals':
    php_version			=> '7.0',
    config_root			=> '/etc/php/7.0',
}

 Configuración de PHP

class { '::php':
      ensure               => latest,
      manage_repos         => true,
      fpm                  => true,
      dev                  => true,
      composer             => true,
      pear                 => true,
      phpunit              => false,
      settings             =>	{
            'PHP/max_execution_time'  => '90',
            'PHP/max_input_time'      => '300',
            'PHP/memory_limit'        => '64M',
            'PHP/post_max_size'       => '32M',
            'PHP/upload_max_filesize' => '32M',
            'Date/date.timezone'      => $timezone,
            },
      extensions    => {
                          imagick   => {
                                           provider => pecl,
                         }
      }
}

La variable $timezone tiene el valor (en el agente):

/opt/puppetlabs/bin/facter timezone

CET

Precendecia

La clase ::php::global debe ejecutarse antes de la clase ::php, por lo que ha de utilizarse algún parámetro como require para garantizar el orden de ejecución o un operador de precedencia.

En el post anterior utilizamos el operador -> de un modo que en esta clase podríamos usar:

Class[::php::global] -> Class['::php]

No obstante, puede definirse la precedencia en las propias declaraciones de los recursos y, de este modo, la clase «zonahoraria» mostraría la siguiente estructura:

class zonahoraria::setup {

  class { '::php::globals':
            
            ...

 	}->
  class { '::php':
            
            ...

        }
}

Ejecutando el manifiesto

Pedimos el manifiesto desde el agente para su ejecución:

/opt/puppetlabs/bin/puppet agent -t

 Comprobación

Comprobamos que parámetro timezone.

cat /etc/php/7.0/fpm/php.ini | grep timezone

; Defines the default timezone used by the date functions
; http://php.net/date.timezone
;date.timezone =
date.timezone =CET

 Leyendo el parámetro desde un archivo en el agente

Para ello hay que escribir un archivo a mano en la máquina del agente y ampliar las funcionalidades de Facter para que lea este archivo.

Archivo con parámetro

Creamos el archivo con la zona horaria:

echo " Europe/Madrid" > /usr/local/etc/timezone

 Montaje del directorio

Editamos de nuevo el archivo fileserver.conf  y añadimos el punto de montaje /usr/local/etc:

[files]
  path /usr/local/bin:/usr/local/etc
  allow *

 Ampliando el comportamiento facter

Facter permite añadir nuevos «hechos», que pueden escribirse en Ruby, y utilizarse en los manifiestos.

Creamos un fact en el módulo «zonahoraria»:

mkdir -p /etc/puppetlabs/code/environments/test/modules/zonahoraria/lib/facter
vim /etc/puppetlabs/code/environments/test/modules/zonahoraria/lib/facter/zonahoraria.rb

 Fact

Facter.add(:zonahoraria) do
  setcode do
    if File.exists? '/usr/local/etc/timezone'
      zone = File.readlines('/usr/local/etc/timezone')
      zone[0]
    end
  end
end

 Cambiando el fact en el manifiesto

Con la siguiente línea reemplazmos la variable de facter timezone por la que hemos creado, zonahoraria:

find modules/zonahoraria/manifests/init.pp | xargs perl -pi -e 's/timezone/zonahoraria/g'

 Actualizando el parámetro en el agente

Pedimos el manifiesto al master:

/opt/puppetlabs/bin puppet agent -t

 Por ultimo

Comprobamos que el parámetro leído del archivo se haya actualizado:

cat /etc/php/7.0/fpm/php.ini | grep timezone
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
;date.timezone =
date.timezone = Europe/Madrid

Esta es la idea básica de declaración de facts en Puppet. Por supuesto, hay mucho más. Una lista completa de los facts del sistema pueden obtenserse con el comando /opt/puppetlabs/bin/facter