Notes puppet

Fiche express
Type	Exemples de manifestes
Contexte	Classes et déclarations de nœuds Puppet illustratives (héritage de nœuds, syntaxe historique)
Voir aussi	Puppet · Puppet fonctions · Puppet references

Notes puppet rassemble un exemple de manifeste Puppet complet, à titre pédagogique : trois classes (ntp, resolv, postfix) et une hiérarchie de nœuds utilisant l'héritage (inherits). Les noms de nœuds et l'OS cible (Debian Etch, sortie en 2007) sont volontairement génériques/datés ; l'intérêt de l'exemple est la structure (dépendances entre ressources via require/subscribe, héritage de nœuds), pas les noms ou versions eux-mêmes.

Classes

ntp

Installation du paquet, du fichier de configuration (servi depuis le fileserver Puppet) et du service, avec les dépendances explicites entre les trois :

class ntp {
  # On installe le package si besoin
  package { 'ntp':
    ensure   => installed,
    provider => apt,
  }

  # Le fichier de configuration
  file { '/etc/ntp.conf':
    source  => 'puppet:///modules/ntp/etc/ntp.conf',
    # On déclenche ce contrôle "file" après l'installation du package
    require => Package['ntp'],
  }

  # On déclare aussi le service ntp, démarré et surveillé
  service { 'ntp':
    ensure    => running,
    enable    => true,
    # Si le package ou le fichier de conf sont modifiés, on redémarre le service
    subscribe => [Package['ntp'], File['/etc/ntp.conf']],
  }
}

Corrections apportées à l'exemple d'origine : provider => aptitude remplacé par provider => apt (le provider aptitude pour le type package est déprécié/non standard sur les versions récentes de Puppet) ; provider => debian retiré du type service au profit de enable => true, plus portable ; le chemin source réécrit au format puppet:///modules/... (fileserver moderne servant depuis le répertoire files/ d'un module), plutôt que l'ancien puppet://puppet/files/... qui dépend d'un mount fileserver custom.

resolv

class resolv {
  file { '/etc/resolv.conf':
    owner  => root,
    group  => root,
    mode   => '0644',
    # Contenu servi par le fileserver Puppet, module "resolv"
    source => 'puppet:///modules/resolv/etc/resolv.conf',
  }
}

postfix

class postfix {
  package { 'postfix':
    ensure   => latest,
    provider => apt,
  }

  file { '/etc/postfix/master.cf':
    content => template('postfix/master.cf.erb'),
    require => Package['postfix'],
  }
  file { '/etc/postfix/main.cf':
    content => template('postfix/main.cf.erb'),
    require => Package['postfix'],
  }

  # Démarré après les deux fichiers, et rechargé si l'un d'eux
  # (ou le paquet, ou la résolution DNS) change
  service { 'postfix':
    ensure    => running,
    enable    => true,
    subscribe => [Package['postfix'], File['/etc/postfix/master.cf'], File['/etc/postfix/main.cf'], File['/etc/resolv.conf']],
  }
}

Bug corrigé : l'exemple d'origine utilisait source => Template["/etc/postfix/master.cf"], une syntaxe qui n'existe pas dans le langage Puppet. Pour du templating ERB, c'est l'attribut content combiné à la fonction template() qu'il faut utiliser (comme corrigé ci-dessus) ; source sert uniquement à pointer vers un fichier statique (chemin local ou puppet:///).

Déclaration des nœuds (héritage)

Exemple d'utilisation de l'héritage de nœuds pour factoriser une base commune, puis spécialiser par rôle :

node 'generic-base' {
  # Classes communes à tous les nœuds
  include sudo, ntp, timezone, resolv
}

node 'webserver' inherits 'generic-base' {
  include apache, php
}

node 'mailserver' inherits 'generic-base' {
  include postfix
}

node 'web1.example.com' inherits 'webserver' {
  $hostkind = 'alternc'
}

node 'mail1.example.com' inherits 'webserver', 'mailserver' {
  # On peut surcharger localement certains paramètres via une sous-classe
  include mail1_resolv
}

Note (à vérifier) : l'héritage de nœuds (node ... inherits ...) est déprécié depuis Puppet 4 au profit de la composition par include directement dans chaque déclaration de nœud, voire d'un ENC externe (voir Puppet-dashboard ou Foreman) qui évite d'avoir à maintenir ces blocs node dans les manifestes eux-mêmes.

Voir aussi

• Puppet — page hub
• Puppet fonctions — détail des fonctions utilisables dans les manifestes (dont template())
• Puppet references — aide-mémoire de syntaxe
• Hiera — alternative moderne pour externaliser les données (au lieu de variables en dur dans les manifestes)