Puppet, installation et première configuration

Il s'est écoulé quelques mois depuis mon premier billet sur les logiciels libres de gestionnaires de configurations de machines. Ce laps de temps m'a permis de consulter un nombre important d'articles, de forum et de littérature. Il est donc maintenant temps de partager cela avec vous.

J'avais initialement prévu de faire un seul gros article, mais devant le nombre important de choses à dire et la complexité du sujet, j'ai préféré le découper en plusieurs parties.

La première, que vous êtes en train de lire est une introduction à Puppet ou l'on va détailler l'installation (serveur et cliente) et la configuration initiale du système. Viendront ensuite des billets spécifiques sur la définition des sites et noeuds puis un ou plusieurs autres sur les modules.

Introduction

Puppet est donc un "gestionnaire de configurations de machines". Derrière ce terme un peu barbare se cache la possibilité de centraliser la configuration système de vos machines au sein d'un référentiel unique. Le procédé peut très bien s'appliquer à une seule machine ou à un parc important et hétérogènes.

Puppet fonctionne sur le principe de clients (installé sur les machines de votre parc) et d'un serveur (installer sur un ou plusieurs serveurs de votre réseau). Puppet permet ainsi de s'assurer qu'à un instant t, toutes les machines clients sont dans un état de configuration défini sur le serveur.

Pour des besoins de tests il est tout à fait envisageable d'héberger à la fois le client et le serveur sur une seule et même machine. J'ai choisi, pour illustrer cet article, d'une architecture un peu plus proche de la réalité:

Puppet "testbed"

Pourquoi Puppet et non pas Chef ou CfEngine ?

Tout simplement la solution qui m'a semblé la mieux documentée et avec un nombre important de ressources (blog / forum) sur le sujet. Chaque solution a ses avantages, je vous laisse chercher sur votre moteur de recherche préféré les différents articles permettant de les comparer et de choisir celle qui s'adaptera le mieux à vos besoins et surtout avec votre manière de fonctionner.

Installation du serveur Puppet (aka PuppetMaster)

La version 2.6.6 est disponible dans les dépôts officiels de la Debian 6 (Squeeze) au moment de la rédaction de ce billet. Afin de permettre une utilisation avec les clients en 2.7 (version actuellement packagée sous Ubuntu 12.04), il est nécessaire de passer par le dépôt backports que l'on installe de la manière suivante:

L'installation du serveur (module PuppetMaster) et de ses dépendances se fait sur une distribution GNU/Linux Debian 6 via les commandes suivantes (en root ou précédée de sudo):

Une commande permet de s'assurer que le serveur est bien lancé:

Attention: Si votre serveur est protégé par un Firewall alors il faut penser à ouvrir le port TCP/8140 qui est le port par défaut, sinon les clients n'arriveront pas à le joindre. Si votre serveur est hébergé derrière un réseau NAT, il faudra également rediriger le port TCP/8140 vers votre machine.

Installation d'un client Puppet (Debian ou Ubuntu)

Encore plus simple est l'installation d'un client Debian (sur laquelle le dépôt backport a été ajouté):

 ou Ubuntu en utilisant la commande suivante (en root ou précédée de sudo):

Pour fonctionner, le client Puppet a besoin de connaitre l'adresse du serveur (PuppetMaster). On doit donc éditer, sur la machine cliente, le fichier /etc/puppet/puppet.conf et y ajouter la ligne suivante dans la section [main]:

Attention: si vous utilisez un nom, ce qui est conseillé, il faut bien s'assurer que la résolution s'effectue correctement à la fois sur le serveur et sur les clients.

Pour sécuriser la connexion entre les clients et le serveur, Puppet utilise des tunnels SSL. Ces derniers nécessitent une phase d'initialisation à faire seulement une fois lors de la configuration du client. On commence par lancer la commande suivante sur le client (en root ou précédée de sudo):

On demande ensuite, sur le serveur, la liste des certificats SSL en attente de validation (en root ou précédée de sudo):

Nous avons donc une machine identifié par le nom "optiplex790" (le nom de ma machine cliente) qui nécessite d'être autorisé par le serveur. Pour effectuer cette tache d'autorisation, on doit valider son certificat (en root ou précédée de sudo):

Remarque: il est également possible de forcer l'authentification pour une plage d'adresses IP donnée. Cela représente tout de même une faille de sécurité qui est difficilement acceptable sur une réseau en production.

Il ne reste plus, sur le client, qu'à éditer le fichier /etc/default/puppet pour automatiser le lancement de Puppet au démarrage de la machine:

Et enfin à relancer le daemon du client en tache de fond:

Pour les phases de tests (par exemple lors de la mise en place de nouveaux modules), il est conseillé de désactiver le demon sur les clients...:

... et de le lancer à la main et en mode "verbeux":

Et sous Windows ?

Puppet propose un client open-source sous Windows.

La procédure d'installation se trouve ici. Sous Winddows 7, le fichier de configuration puppet.conf ou il faudra configurer l'adresse du PuppetMaster se trouve dans le répertoire C:ProgramDataPuppetLabspuppetetc.

Pour lancer Puppet client, il suffit ensuite de lancer une premier fois Puppet à partir du menu Démarrer > Programmes > Puppet > Run Puppet Agent. Ce dernier va afficher un message comme quoi le serveur n'arrive pas à l'identifier. On doit, comme pour les client GNU/Linux forcer l'authentification avec la commande suivante sur le serveur:

Le prochain lancement de Puppet (menu Démarrer > Programmes > Puppet > Run Puppet Agent) devrait se faire sans problème.

Et hop passons aux choses sérieuses...

Configuration de votre référence: le serveur Puppet

Toute la configuration (référentiel) de Puppet est centralisé dans l'arborescence /etc/puppet de votre serveur fraichement installé. Dans le "best practice" de Puppet, il est fortement conseillé de gérer ce répertoire (et ce qu'il contient) en configuration (sous CVS, SVN ou GIT). C'est dans ce répertoire que nous allons définir notre site (réseau), nos noeuds (machines) et les modules (actions) à appliquer lors de la mise en configuration.

Commençons par une rapide description des fichiers contenus dans ce répertoire:

  • /etc/puppet/manifests/site.pp: C'est le premier fichier analysé par PuppetMaster pour définir son référentiel. Il permet de définir des variables globales et d'importer des modules (ensembles de classes) ainsi que des fichiers templates et noeuds de votre réseau. Attention de ne pas définir directement les templates et les noeuds dans ce fichier... C'est techniquement faisable mais pas très propre à maintenir.
  • /etc/puppet/manifests/template.pp: (optionnel) Permet de définir ou d'étendre (notion d'héritage comme en POO) des classes spécifiques à votre réseau.
  • /etc/puppet/manifests/node.pp: Permet de définir les noeuds (machines) de votre réseau. Il est conseillé de défini le nom d'un noeud par le nom FQDN de la machine. Si votre réseau est important (plusieurs centaines de machines à gérer), il est tout à fait possible de créer une arborescence dédié avec un fichier node.pp par sous-réseau.
  • /etc/puppet/modules/<module>/: Sous répertoire contenant la définition du module (action). Un fichier <module>/manifests/init.pp contient la définition du module (en clair c'est ici que l'on va définir ce que l'on doit faire sur la machine cliente) et le répertoire <module>/files/l'ensemble des fichiers nécessaires à l’exécution de ce module. Voyons maintenant le détail de ces fichiers.

Définition de votre site (réseau Puppet)

Idéalement, le fichier site.pp ne doit contenir que des lignes import (permettant d'importer les autres fichiers de configuration) et la définition des variables globales (nécessaire à plusieurs modules).

Les deux premières lignes définissent les paramètres permettant aux client d'accéder au serveur de fichier PuppetMastert en indiquant notamment le nom FQDN du serveur Puppet (à adapter à votre configuration). Attention de bien vérifier que les machines clients arrive bien à résoudre le nom FQDN en question. La troisième ligne demande au serveur de prendre en compte tous les noeuds disponibles dans le fichier node.pp.

Définition de vos noeuds (machines clientes Puppet)

Nous allons utiliser le fichier node.pp pour définir les configurations à appliquer sur les machines clientes de notre réseau. Par exemple pour définir le noeud nommé optiplex790 (machine dont nous avons validés l'authentification dans le chapitre précédant) et y appliquer le module dummy, il faut éditer le fichier /etc/puppet/manifests/node.pp en y ajoutant les lignes suivantes:

Le module dummy va être défini dans le paragraphe suivant.

Définition des modules (actions à appliquer sur les machines clientes Puppet)

Chaque module dispose de son propre répertoire sous /etc/puppet/modules/<module>. Ainsi on commence par créer l'arborescence du module dummy:

Le premier répertoire (manifests) va contenir la définition de l'action. Le second (files), les optionnels fichiers permettant d'effectuer cette action. On défini l'action dummy en créant le fichier /etc/puppet/modules/dummy/manifests/init.pp avec le contenu suivant:

Le module dummy va donc vérifier:

  • l'existence sur la machine cliente d'un fichier /etc/puppet.txt
  • appartenant à l'utilisateur root
  • appartenant au groupe root
  • avec les droits 644
  • et dont le contenu doit être égal au fichier /etc/puppet/modules/dummy/files/puppet.txt disponible sur le serveur

Prise en compte de la nouvelle référence par le serveur

Pour que PuppetMaster prenne en compte al nouvelle référence que nous venons de définir, il faut relancer le démon avec la commande (en root ou avec sudo):

Forcer la mise en configuration sur vos clients Puppet

Pour tester la configuration, nous allons lancer la commande suivante sur le noeud optiplex790 (machine sous Ubuntu 12.04):

Si vous rencontrez l'erreur suivante sur votre client:

C'est probablement que vous utilisez une version du client Puppet supérieure à PuppetMaster (par exemple un Puppet client 2.7 avec un PuppetMaster 2.6). Un bug report est disponible ici. Avec la même version des deux cotés et si tout ce passe bien le message suivant devrait s'afficher:

Dans le cas ou tout se passe correctement, vous devriez alors trouver un nouveau fichier puppet.txt  dans votre répertoire /etc:

Ne pas réinventer la roue...

Maintenant que vous avez les bases permettant d'associer des actions à des machines, seule votre imagination vous posera des limites. Cependant, avant de partir bille en tête dans le développement de nouveaux modules, je vous conseille de regarder du coté de la Forge Puppet qui est un site communautaire permettant de partager, rechercher et récupérer des modules pour un nombre très important de cas. C'est également un très bon moyen d'apprendre le langage utilisé par Puppet en récupérant et lisant le code des modules.

 

Pensez également à partager vos modules !

En cas de problèmes...

Si vous rencontrez un problème lors de la configuration de votre Puppet Master, le plus simple est d'ouvrir une console et de surveiller la log des demons en filtrant un peu la sortie:

et de lancer la commande coté client en mode debug:

Conclusion

Nous venons donc de faire nos premiers pas dans le très compl[et|exe] monde de Puppet. L'investissement nécessaire à l'administrateur est à la hauteur du gain de temps, de traçabilité et d'efficacité qu'il obtiendra en fin de projet.

A très vite pour la suite des billets sur Puppet !

  • obris

    Merci!

  • Pingback: Puppet, installation et première configuration | evalentin | Scoop.it

  • http://www.blueicefield.com Nassim

    Bonjour,

    Puppet est aussi ma solution préférée pour les déploiements automatisés.

    Par contre, j’ai juste une petite remarque à faire au niveau de tes schémas, les flèches devraient aller des clients au serveur étant donné que la communication se fait dans ce sens.

    • http://www.nicolargo.com nicolargo

      C’est tout à fait exact au niveau technique, mais ces schémas sont plus des illustrations fonctionnelles ou l’on veut montrer que les configurations sont stockées sur le serveur et appliquées sur les clients.

      • http://www.blueicefield.com Nassim

        Autant pour moi ^^

  • http://nicolas.ledez.net/ Nicolas Ledez

    Excellente initiation.

    Perso j’ai commencé avec Puppet il y a quelques mois. Mais le reproche que je pourrais lui faire ; c’est sa consommation mémoire (environ 30Mo dans mes souvenirs).

    Une idée pour résoudre ce problème sur des machines (VM) qui ont 256Mo de mémoire ?

    • http://www.nicolargo.com nicolargo

      Réponse @EmilienMiLk sur Twitter:

      “… Ok, parce que le client puppet consomme une centaine de Mo de ram constamment chez moi. Sur des VMs de 512Mo ou 1Go, ça fait bcp.

      Du coup il faut passer par le lancement de puppetd par crontab en utilisant le paramètre –onetime.”

    • Edouard

      Pour reduire l’empreinte mémoire on ne lance le client qu’en cas de besoin, via func.
      Après 256Mo pour une VM c’est vraiment short, 30Mo pour un puppet qui se retrouve sur toutes tes VM avec KSM ça va être peu dédupliqué (à supposer que l’hyperviseur soit un linux).

  • http://b-ds.fr Benjamin Dos Santos

    Bonjour

    Puppet fonctionne également en mode “master-less”. Très pratique pour le développement de module, ou même en production (serveurs déjà “orchestré”) :

    ex :

    puppet apply -e “class { ‘couchdb’: bind => ’0.0.0.0′ }”
    puppet apply -e ‘include couchdb’ –modulepath /etc/puppet/modules
    puppet apply –modulepath /etc/puppet/modules /tmp/site.pp

    etc …

    D’ailleurs ça fonctionne comme cela avec Vagrant.

    http://docs.puppetlabs.com/man/apply.html

  • http://www.blueicefield.com Nassim

    Personnellement, je trouve aussi que le gros défaut de Puppet est sa consommation en ressources et sa médiocre montée en charge. Cela est probablement lié à son langage de développement (je ne suis d’ailleurs pas un fan de Ruby).

    Techniquement, sur de grosses infrastructures ont peut réduire ce problème en :
    - Utiliser Puppet avec Apache et Passenger, c’est beaucoup plus performant.
    - Mettant en place un système de répartition de charge entre plusieurs Puppet Master (simple répartition de charge web).
    - Décaler les intervalles des mises à jour des différents clients pour que toutes les machines du parc ne viennent pas récupérer leur conf au
    même moment.

    • http://www.nicolargo.com nicolargo

      Merci pour ce commentaire intéressant !

      Quand tu parles de “répartition de charge web” tu veux dire un round-robin DNS entre plusieurs serveurs ?

      Comment gère tu le décalage de l’heure de mise à jour des clients ? Par cron ?

      • http://b-ds.fr/ Benjamin Dos Santos

        Une série d’articles sur la mise en place d’un puppet master “scalable” :

        http://binbash.fr/2012/01/09/installer-un-serveur-puppet-scalable-partie-1/

      • http://www.blueicefield.com Nassim

        Je parle essentiellement de loadbalancing HTTP puisqu’il s’agit du protocole utilisé par Puppet (avec une couche d’SSL pour la sécu bien entendu). Il est donc possible de faire cela avec LVS ou encore Nginx par exemple.
        Pour synchroniser les manifestes sur le cluster des Puppet Master, il y a là encore plein de méthodes différents :
        - NFS
        - Rsync + cron
        - GIT+cron ou GIT+HOOK
        - Backend de stockage (NAS, SAN…).

        Personnellement, je conseille vivement l’utilisation d’un outil de versionning comme GIT car cela facilite la gestion au quotidien des fichiers de configuration.

        Pour ce qui est des lancement différés des clients Puppet, en effet, j’utilise Cron pour cela. Cela d’ailleurs peut être inclus dans son manifest de sorte à ce que l’entrée dans la table cron se fasse dès le 1er lancement manuel de l’agent Puppet.

  • aucuneimportance

    typo : hébergé et non pas hébérgé

  • Pingback: Nicolargo : Puppet, installation et première configuration | Actualités de l'open source | Scoop.it

  • http://www.fitzdsl.net Fitzdsl

    Content de voir que tu as adopté Puppet.
    Je l’utilise en production depuis quelques années et c’est vraiment puissant comme outil.
    Le reproche fait sur la consomation mémoire est juste et je l’utilise donc en cron. Pour répondre à la question sur comment différencier les heures sur les crons, tu peux faire quelque chose comme:
    $exec1 = fqdn_rand(30)
    $exec2 = fqdn_rand(30) + 30
    cron { “puppet”:
    ensure => present,
    command => “/usr/sbin/puppetd –onetime –pluginsync –report –no-daemonize –preferred_serialization_format=yaml –logdest syslog > /dev/null 2>&1″,
    user => ‘root’,
    minute => [ $exec1, $exec2 ];
    }

    Voila, sinon je voulais surtout pointer vers un super projet libre : TheForeman (theforeman.org).
    C’est un outils qui va venir autour de puppet et permetre de gérer complètement le cycle de vie de tous tes serveurs :
    * Gestion des déploiement bar-metal (hôtes physiques) ou de vm (libvirt, oVirt, OpenStack, Amazon EC2, VMWare):
    ** Gestion des enregistrement DNS
    ** Gestion des leases DHCP
    ** Gestion des certificats de Puppet et affectation des classes puppet aux hôtes
    ** Gestion des rapports de run et reporting
    * Unattended installation (installation automatisée) : avec gestion notament des preseed et des ks
    * Intégration poussée des briques de virtualition :
    ** Creation et destruction de nouvelles machines
    ** VNC des VMs directement dans la WebInterface
    ** ACLs sur les hyperviseurs

    Et beaucoup beaucoup d’autres choses.
    En plus la communauté est super sympas, le projet est notament soutenu par RedHat. Je l’ai découvert au Fosdem y’a 2 ans
    et je suis vraiment content de l’avoir adopté.

    Vous pouvez retrouver ici une vidéo de notre industrialisation : http://www.youtube.com/watch?v=FYsHZbCQzH8

    Vraiment, je recommande à tous les utilisateurs de Puppet qui croient en l’automatisation !!
    Un peu de pub pour ceux qui veulent en savoir plus :) : http://www.fitzdsl.net/tag/foreman/

    • http://www.blueicefield.com Nassim

      Oui, je connais bien cet outil et il est effectivement indispensable surtout dans les moyennes et grosses infrastructures.

      L’éditeur de Puppet a lancé d’ailleurs le projet Puppet Dashboard qui est comparable en terme d’objectif mais dont les fonctionnalités sont encore bien loin de ce dont permet TheForeman.

  • Bertrand

    Pour installer puppet sur debian et ubuntu il est possible d’utiliser directement les dépots de puppetlabs! L’avantage est d’avoir une version à jour.

    http://apt.puppetlabs.com/

    Il suffit de télécharger le .deb qui correspond à sa distro et de l’installer avec dpkg. Ce paquet ne fait qu’installer la configuration pour le dépot de puppetlabs, et la signature de puppetlabs.

    Exemple pour Ubuntu 12.04:

    wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb
    dpkg -i puppetlabs-release-precise.deb
    apt-get update

    apt-get install puppet

    on peut vérifier la version qui sera choisie/mise à jour avec la commande:

    apt-cache policy puppet

  • http://wiki.gardouille.fr gardouille

    Sous Squeeze j’utilise Mongrel+nginx pour Puppet, ce qui permet une nette amélioration de la montée en charge et la rapidité d’accès des clients.

    Et pour le lancement du client, j’utilise un petit script (http://blogs.glou.org/arnaud/2011/02/24/lancer-puppet-depuis-cron/) qui placé dans un cron, lance le client dans l’heure (en fonction de l’ip), dans les 5 minutes, ou tout de suite.

    Script sympathique, hésitez pas à aller voir ;)

  • cyberfrk

    Bonjour,

    Tout d’abord, félicitationS pour le site et les nombreux tutos (je l’avoue, ils ne sont pas tous à ma portée mais abordable tout de même!).

    Infos utiles:
    Toutes les machines sont des Vms (virtualbox)
    -puppetmaster sous debian squeeze (netinstall + dns server)
    -clients puppet sous 7 et ubuntu (edubuntu)
    -puppet-3.0.1.msi sur client 7

    J’ai un souci pour la reconnaissance d’un client VM sous 7 (virtualbox). Je n’ai pas rencontré de problème avec le client ubuntu (edubuntu). Le certificat est bien apparu sur le serveur.

    Sur le client sous 7, Run Puppet Agent génère l’erreur ne permettant pas de l’identifier (tuto: Et sous Windows ?).

    L’execution de : “sudo puppetca –sign win7″ sur le serveur me donne:
    err: Could not call sign: Could not find certificate request for win7.
    Que signifie “win7″? Est-ce ne nom de machine sous 7? Si oui, j’ai la même erreur en mettant le bon nom du client 7.
    Je suppose qu’il s’agit d’une erreur de certificat mais j’ai pas de souci avec la VM sous edubuntu.

    Mes recherches n’ont pas été fructueuses, c’est pour cela que je m’en remet à vous. :(

    En vous remerciant par avance,
    Franck

    • http://www.nicolargo.com nicolargo

      C’est le nom logique mis dans le fichier node.pp sur le serveur.