Accueil arrow Informatique arrow Linux arrow Puppet ou l'administration système centralisée
Puppet ou l'administration système centralisée
Écrit par majordom   
21-01-2010

Comme le dit le site de ReductiveLabs.

"Puppet est un logiciel pour automatiser les tâches d'administration de systèmes *nix (comme ajouter des utilisateurs, installer des paquets, et mettre à jour des configurations de serveurs) basée sur une spécification centralisée."

 http://reductivelabs.com/wp-content/themes/reductive/images/main/pic0.jpg

 Dans cet article nous verrons l'installation de puppet du coté client comme du coté serveur, nous verrons aussi la mise en place de la communication entre le serveur et les clients, et enfin nous saurons comment rédiger un manifeste qui réalisera pour nous quelques tâches simples mais indipensables. Les machines utilisées sont des machines de base Debian.

J'ai utilisé plusieurs sources pour réaliser cet article :

 C'est très important de faire la distinction entre des scripts shell encapsulés dans du SSH qui copie des fichiers de conf entre les systèmes et un outil comme Puppet. Puppet definit et met en oeuvre des configurations. La configuration est un ensemble de paramètres qui peut se constituer de fichiers de conf, de packages, de services et bien d'autres choses encore, puisqu'on peut définir ses propres types.

Sur chaque machine doit être installé un client (puppet) qui se connecte au serveur  (puppetmaster) à travers une couche SSL en utilisant un certificat. Sur le serveur sont stockés des manifests qui contiennent les spécifications. Le serveur possède même un mécanisme pour distribuer des fichiers et ensuite les distribuer via les manifests.

1 - Installation

 

Attention la configuration DNS des clients et des serveurs doit être nickel !!!

Verifiez bien vos fichiers /etc/hosts et /etc/resolv.conf. Le client et le serveur communique au travers d'une communication SSH sécurisée avec échange de certificats.

 

                    ATTENTION, un bug dans joomla m'oblige à ne pas pouvoir utiliser le caractère "crochet ouvert" le contraire de "]". j'utilise la parenthèse ouverte pour le remplacer.  Quand j'aurai trouvé du courage pour passer sous spip le problème sera réglé...

 

 

Coté serveur :

apt-get install puppetmaster

Le fichier de configuration du serveur puppet est /etc/puppet/puppet.conf

(main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true


(puppetmasterd]
templatedir=/var/lib/puppet/templates

(puppetd]
#le nom du serveur puppet
server = monserveurpupper.domaine.com
 

Coté client :

Un simple apt-get install puppet suffit pour installer tous les outils.(ruby, rdoc, facter, puppet, ...)

Le fichier de configuration s'appelle /etc/puppet/puppet.conf

 

(puppetd]
server = monserveurpupper.domaine.com
logdir = /var/log/puppet
vardir = /var/lib/puppet
rundir = /var/run

 

La comunication entre le serveur et les clients

Après avoir configuré les serveurs et clients, on relance le service puppet

/etc/init.d/puppet restart

-> cette commande va envoyer une demande de certificat auprès du serveur puppet

Maintenant, il faut se connecter au serveur puppet pour signer les certificats des clients.

puppetca --sign --all

-> cette commande signe tous les certificats, sans vérification, d'un seul coup !

Pour signer un certificat bien précis

puppetca --sign clientpuppet.mondomaine.com

On voit bien ici l'intérêt d'avoir une configuration DNS au poil !

Enfin pour valider la communication et l'exécution du premier manifest il faut encore relancer le client puppet sur les différents postes clients.

/etc/init.d/puppet restart

Pour vérifier que tout se passe bien on ouvre le /var/log/syslog et on vérifie qu'il y a bien ces lignes

Jan 22 11:04:02 clientpuppet.mondomaine.compuppetd(4927]: Starting catalog run
Jan 22 11:04:03 clientpuppet.mondomaine.compuppetd(4927]: (//Node(default]/upgrade/Exec(apt-get update && apt-get -y dist-upgrade > /tmp/maj]/returns) executed successfully
Jan 22 11:04:03 clientpuppet.mondomaine.compuppetd(4927]: Finished catalog run in 1.07 second

Dans ce cas, on voit qu'à 11h04, le client puppet s'est connecté au serveur puppet, il a executé avec succès un apt-get update && apt-get -y dist-upgrade et qu'il a terminé l'action en 1,07 seconde

Problèmes de communication

On peut passer des commandes pour bien vérifier que les certificats sont valides de part et d'autres

puppetd --server monserveurpupper.domaine.com --test

la commande répond :

notice: Ignoring cache
info: Caching catalog at /var/lib/puppet/state/localconfig.yaml
notice: Starting catalog run
notice: //Node(default]/upgrade/Exec(apt-get update && apt-get -y dist-upgrade >
 /tmp/maj]/returns: executed successfully
notice: Finished catalog run in 1.01 seconds

On voit donc que tout se passe bien. Quelquefois le serveur informe que le certificat n'est pas valide. Il faut donc supprimer le certificat sur le serveur par cette commande :

puppetca --clean clientpuppet.mondomaine.com

et ensuite on reprend toute la procédure.

Je reboot ensuite pour tuer les pid qui trainent et repartir sur une installation claire.

 

Mon premier manifest

 

Le manifest permet de déclarer des actions à exécuter, des fichiers à contrôler ou déployer, des paquets à contrôler ou déployer et bien d'autres choses encore. Le manifest central, (le manifest par défaut si vous voulez) s'appelle site.pp. Il est situé dans notre configuration (que j'ai laissé par défaut) dans /etc/puppet/manifests/site.pp

A chaque modification du ou des manifests il faut redémarrer le servce puppetmaster avec la commande vue plus haut. Je ne le redirai pas !

On va commencer par contrôler le service NTP :

on écrit ce qui suit dans le fichier site.pp

package {

     ntp:

            ensure => installed

}

 Voilà, c'est simple. Ce premier manifest permet de contrôler si ntp est bien installé, si non il l'installe automatiquement en utilisant les paquets debian.

Puppet serveur de fichiers

Il serait bien de pouvoir définir quel fichier ntp.conf utilisé par le service. Qu'à cela ne tienne puppet sait tès bien le faire !

on crée un fichier/etc/puppet/fileserver.conf

(files]
  path /etc/puppet/files
  allow *


plugins]
  allow *

maintenant le partage de fichier du serveur puppet est situé à la racine de /etc/puppet/files. allow * autorise tout le monde à venir chercher ces fichiers. On verra plus tard les restrictions d'accès.

maintenant on peut ajouter ceci à notre manifest site.pp

file {
    "ntp.conf":
    mode => 644,
    owner => root,
    group => root,
    path => "/etc/ntp.conf",
    source => "puppet://puppet/files/etc/ntp.conf"
       }

 

Puppet et les services

 

Puppet est aussi capable de gérer les services.

On rajoute le code ci-dessous au fichier site.pp et on explique

 service {
    ntp:
        ensure => true,
        enable => true,
        subscribe => ( File("ntp.conf"], Package (ntp] ] ,
    }

On s'assure que le service existe et qu'il est bien lancé sinon il est installé avec le package ntp et le fichier ntp.conf automatiquement.

 

Un peu d'organisation

Un bon informaticien est un informaticien organisé alors mettons un peu d'ordre dans la structure des fichiers. Puppet possède un système de classe très pratique pour se faire. Continuons avec notre exemple de NTP.

Tout d'abord, je crée un répertoire services dans lequel je mettrai toutes les classes qui géreront des services (ntp, ssh, etc)

Dans ce répertoire je crée un fichier ntp.pp dans lequel je met toutes les lignes du fichier site.pp ci-dessus à l'intérieur de la classe ntp

class ntp {

     package {

     ntp:

            ensure => installed

file {
    "ntp.conf":
    mode => 644,
    owner => root,
    group => root,
    path => "/etc/ntp.conf",
    source => "puppet://puppet/files/etc/ntp.conf"
       }

service {
    ntp:
        ensure => true,
        enable => true,
        subscribe => ( File("ntp.conf"], Package (ntp] ] ,
    }

 }

 puis dans site.pp on déclare d'aller lire le fichier ntp.pp; un petit include comme en php ou latex.

 

import "services/*"


node default {
    include ntp
    }

node default permet de dire que la classe ntp s'applique à tous les clients puppet qui ne sont pas spécifiés explicitement.

Les templates

Certains fichiers de config sont tous identiques sur tous les clients puppet sauf... une ligne ! Les templates permettent de gérer la distribution de fichier de conf avec des variables qu'il pourra récupérer grâce à son outil facter.

à suivre

 
Dernière mise à jour : ( 26-01-2010 )
 
< Précédent   Suivant >
[ Retour ]