Introduction

Puppet est un logiciel de gestion de configuration. C’est à dire qu’il permet de répliquer et conserver à l’identique un ensemble de paramètres (des fichiers de configuration) sur un ensemble de machines.

Puppet a été créé pour un besoin simple : répliquer de la configuration à grande échelle sur un ensemble de machines, et en assurer la consistance. Nous allons principalement l’utiliser pour répliquer notre configuration de Munin sur l’ensemble des machines du parc, pour faciliter le déploiement de notre solution de monitoring.

Puppet fonctionne sur le modèle maître-esclaves : un serveur principal va contenir l’ensemble des paramètres à répliquer, et des serveurs esclaves vont interroger le serveur maître pour récupérer leur configuration. Il est possible de configurer le maître afin de différencier la configuration fournie à chaque esclave.

La communication entre le maître et ses esclaves est chiffrée et signée (le maître connaît ses esclaves, les esclaves connaissent leur maître), évitant que des informations sensibles ne se baladent sur le réseau, ou ne soit fournies accidentellement à des tiers.

Éléments en présence

Nous allons considérer les éléments suivants :

  • Le maître, aussi appelé PuppetMaster, est la machine qui va stocker les configurations à répliquer et fournir ce dont ellesont besoin aux machines esclaves.

  • Les machines esclaves, ou “clients Puppet”, sont les machines sous le contrôle du PuppetMaster, elles vérifient périodiquement auprès du PuppetMaster si leur configuration a besoin d’être mise à jour et appliquent les directives fournies par le PuppetMaster.

Pour ce tutoriel, nous allons considérer deux machines : le PuppetMaster que je vais appeler “master” et une machine cliente que je vais appeler “slave01”.

Je suppose que les machines “master” et “slave01” sont correctement mises en place dans le parc (qu’elles sont présentes dans le fichier /etc/hosts ou qu’elles ont un enregistrement DNS valide). Je suppose également que le FQDN des machines est correct (mis en place dans /etc/hostname ou avec la commande hostname -b).

Installation du Maître et de l’Esclave

Installation du Maître

À noter que dans le cas de la configuration qui est décrite, le maître ne sera pas son propre esclave. Il est néanmoins possible de gérer certains aspects de la configuration du maître via le maître lui-même en effectuant après l’installation du maître l’installation d’un esclave sur la même machine (mais attention aux migraines).

Sous Debian, Puppet est dans les dépôts. Pour installer le maître il suffit de taper : sudo apt-get install puppetmaster

Pour des raisons de sécurité, le PuppetMaster n’est pas configuré pour se lancer au démarrage de la machine. Éditez le fichier /etc/defaults/puppetmaster et placez la variable START à “yes”.

Lancez ensuite le serveur maître de Puppet avec la commande service puppetmaster start

Installation de l’esclave

De la même manière que le maître, lancez sur l’esclave : sudo apt-get install puppet

Comme pour le PuppetMaster, il faut préciser à l’esclave Puppet qu’il doit se lancer au démarrage de la machine : éditez /etc/defaults/puppet et placez la variable START à “yes”.

Ouvrez à présent le fichier de configuration /etc/puppet/puppet.conf et rajoutez la ligne suivante dans la section [main] :

server=master

J’utilise ici le domaine court (“master”) en supposant que celui-ci se résout correctement, mais vous pouvez mettre l’adresse IP du serveur “master” ou son FQDN à la place

C’est le moment d’essayer notre configuration ! Lancez la commande :

sudo puppetd --test --waitforcert 60

Si tout va bien, l’esclave va interroger le maître pour récupérer sa configuration. Comme c’est la première fois qu’il le fait, l’esclave va attendre que son certificat soit signé par le maître, qui le reconnaîtra alors comme un de ses esclaves.

Pour débloquer la situation, lancez la commande suivante sur le maître :

puppet cert --list

Vous devriez alors voir une liste de certificats en attente de signature. Toujours sur le maître, signez le certificat de votre esclave :

puppet cert --sign slave01

Sur l’esclave, la situation se débloque, et il vous informe que son certificat a été signé, tout est prêt !

Lancez finalement le démon Puppet sur l’esclave :

service puppet start

Le lancement du démon est nécessaire pour une propagation automatique des opérations que nous allons faire sur le maître. Un lancement manuel de la mise à jour de l’esclave peut cependant être fait avec la commande puppetd --test .

Comment ça marche ?

Sur le Maître, le point d’entrée principal de la configuration est /etc/puppet/manifests/site.pp

Le répertoire /etc/puppet/templates/ sert à stocker les templates de configuration qui pourront être lu par le moteur de Puppet (plus pratique de fournir le chemin vers un fichier template plutôt que de renseigner le contenu du fichier au milieu des règles de Puppet).

Le répertoire /etc/puppet/modules/, oubliez le pour l’instant.

Notre modèle de configuration pour la suite

Comme nous ne souhaitons pas mettre TOUTE la configuration dans /etc/puppet/manifests/site.pp, nous allons créer des répertoires dans le dossier manifests et inclure les fichiers qui sont présents dans ces répertoires, histoire de ranger un peu.

Créez les dossiers classes et nodes dans le dossier manifests .

Le dossier classes contiendra les éléments de configuration génériques, potentiellement paramétrables, que nous allons appliquer à nos esclaves.

Dans le dossier nodes, je vous conseille de créer un fichier par esclave, afin de personnaliser efficacement les classes requises pour chacun des esclaves.

Le fichier /etc/puppet/manifests/site.pp contiendra donc les appels aux fichiers présents dans ces répertoires :

# import many manifest files with node definitions
import 'classes/*.pp'
import 'nodes/*.pp'

Et nous auront donc dans le dossier /etc/puppet/manifests/classes un fichier munin.pp qui ressemblera à ça :

class munin {
    ...
}

Et dans le dossier /etc/puppet/manifests/nodes un fichier slave01.pp qui ressemblera à ça :

node 'slave01' {

    $hostname = 'slave01'

    include munin
}

C’est tout ! La configuration des esclaves pour servir de nœuds Munin via Puppet sera détaillé dans le prochain article.

À noter : La commande “import” de Puppet ne fait que déclarer les fichiers à lire, la commande “include” exécute la classe et donc applique effectivement la configuration du fichier.

Pour aller plus loin avec Puppet

Pour aller plus loin avec Puppet, vous pouvez lire la documentation issue du site de Puppetlabs.

Pour conclure

Nous avons posé les bases de notre solution de monitoring, notre serveur Nagios est en place, et Puppet est prêt à répliquer la configuration des nœuds Munin. Il nous reste à créer cette configuration, et à effectuer le lien entre le Master Munin et Nagios, pour que les alertes puissent remonter.

Dans le billet suivant, nous détaillerons la configuration des nœuds Munin avec Puppet et la configuration du Master Munin pour les alertes.

.

.