Puppet 3.6 et PuppetDB 2.0

Je viens de passer mon environnement de test à Puppet 3.6.1 et PuppetDB 2.0. J’ai rencontré quelques soucis suite à cette mise à jour. Quelques points peuvent être gênants et doivent vous alerter en cas de mise à jour dans un environnement de production. Voici le résumé des problèmes rencontrés… ...

Puppet 3 et PuppetDB

Je viens de mettre à jour mon environnement de test vers Puppet 3 (depuis une version 2.7.19). Pas de grosses difficultés, pas de grosses surprises… Je vais vous décrire dans cet article la méthode utilisée. Le principal point bloquant que j’ai rencontré lors de cette mise à jour s’est trouvé être mon serveur MySQL (utilisé pour la partie storeconfigs/inventory). J’ai eu toute une série de bugs que je n’ai pas réussi à résoudre et le fait que cette méthode sera bientôt obsolète m’a encouragé à passer à PuppetDB. J’ai eu également 2/3 erreurs plus simples liées à certains de mes manifests… ...

Superviser Puppet avec Xymon

Dans cet article, je vais vous présenter une solution pour superviser l’exécution du vos agents Puppet avec Xymon. Cette solution utilise un module Puppet et plus précisément une librairie Ruby pour rajouter une possibilité de “reporting” au niveau de votre Puppet Master. Grâce à cette librairie, vous avez en plus de vos rapports habituels (logs, dashboard…), un voyant puppet pour chacun de vos serveurs Puppetisés. Ce voyant affiche le résultat du dernier déclenchement de l’agent : le test deviendra par exemple rouge (et donc alertant) si l’exécution de Puppet a échouée. Pour la partie installation client/serveur Xymon, je vous renvoie sur mon précédent article. ...

Puppet : portée des variables (scope and Puppet)

Si vous utilisez une version récente de Puppet (> 2.7) ou si vous envisagez de mettre à jour, il est peut-être temps de faire du ménage dans vos variables et dans la façon dont vous les déclarez. A partir de la version 2.7, vous risquez de voir apparaître un certain nombre de message pour vous encourager à ne plus utiliser des “variables dynamiques” (dynamic lookup) et d’utiliser des variables qualifiées. Dans les prochaines versions, si vous ne faites rien, vos variables auront “undefined” pour valeur ! Basé sur le grand ménage du lundi dans mes modules, voici les warnings sur lesquels je suis tombé et les corrections que j’ai dû apporter. ...

 6 juin 2012 509 mots 3 min

Installer un serveur Puppet scalable – partie 3

Suite des articles sur l’installation d’un serveur Puppet scalable (à lire : partie 1 et partie 2). Votre PuppetMaster est installé, nous allons maintenant voir comment rajouter un autre PuppetMaster avec un partage de charge et les problématiques levées par ce fonctionnement (gestions des clés SSL par exemple). Il y a plusieurs solutions pour le partage de charge : nous verrons ici une solution à base d’HAProxy. Dans la deuxième partie de cet article, nous étudierons l’installation du dashboard de Puppet Labs. ...

Pourquoi trier un hash dans un template Puppet

Je vous propose ici une petite astuce pour parcourir un hash dans un template Puppet. Le besoin : je génère un fichier via un template dans lequel je parcours un hash pour afficher la liste des clés/valeurs. Problème : Puppet génère un fichier différent à chaque lancement car on ne peut pas prédire l’ordre de ce hash. J’ai rencontré ce problème de façon aléatoire sur certains serveurs avec Ruby 1.8 (Ruby 1.9 conserve l’ordre du hash). ...

 21 février 2012 611 mots 3 min

Installer un serveur Puppet scalable – partie 2

Suite de l’article Installer un serveur Puppet scalable – partie 1 : vous avez maintenant un serveur Puppet qui fonctionne. On va rajouter un backend MySQL pour utiliser toutes les fonctionnalités offertes par Puppet et supprimer le serveur web WEBRick pour installer Apache/Passenger ou Nginx/Passenger. Dans cet article, on part donc de la configuration présentée dans la partie 1 pour arriver à un Puppet Master avec un premier niveau de scalabilité. ...

 16 janvier 2012 1397 mots 7 min

Installer un serveur Puppet scalable – partie 1

Voici une méthode pour installer un serveur Puppet (le Puppet Master) et le rendre par la suite scalable. Par défaut, l’installation “classique” ne permet pas d’atteindre de grosses performances : le Puppet Master utilise, par exemple, le serveur web WEBrick qui atteindra rapidement ses limites. L’idée ici est de remplacer WEBrick par un Apache/Phusion Passenger et dans un deuxième temps, d’ajouter l’utilisation d’un serveur SQL. Même si l’installation d’origine fonctionne sans ces modifications, certaines fonctionnalités ne sont pas disponibles (comme par exemple l’utilisation des ressources exportées, le dashboard… qui nécessitent un serveur SQL). Dans cet article, l’installation est basée sur une Debian Squeeze fraichement installée. Je fais le choix de partir sur des versions non packagées pour certaines briques : je veux par exemple profiter de la souplesse de mise à jour de Puppet via les gems et de Ruby Enterprise. La première partie couvre l’installation simple du serveur et du client. ...

 9 janvier 2012 1701 mots 8 min

Utiliser Puppet avec un ENC (External Node Classifier)

Par défaut, la configuration des scénarios à jouer sur les serveurs clients de Puppet se fait au niveau du fichier “nodes.pp”. Cette solution atteint vite ses limites dès lors que vous avez de nombreux clients, paramètres, classes. En effet, ce fichier devient vite assez dense rendant sa lecture difficile et la porte ouverte aux erreurs qui peuvent rapidement se transformer en actions non désirées sur vos clients ! De même, connaître d’un coup d’oeil l’ensemble des scénarios joués ainsi que leurs paramètres devient compliqué. Puppet propose d’autres solutions comme par exemple utiliser un LDAP ou un External Node Classifier (ENC), ce que nous allons voir dans cet article. Je vais reprendre ici la définition d’un ENC que vous trouverez sur la documentation de Puppet tout en rajoutant des exemples précis sur l’utilisation de ressources de type “define” avec l’utilisation de tables de hachage en paramètre. ...

 10 octobre 2011 1038 mots 5 min

Gérer les logs Puppet avec Rsyslog

Puppet permet, d’origine, de remonter ses logs dans par exemple le dashboard. Voici une méthode plus “classique” qui consiste à utiliser rsyslog sur les clients pour envoyer les logs concernant Puppet sur votre serveur de log centralisé (un loghost rsyslog). Le loghost est souvent une brique disponible dans une architecture. Il peut donc être intéressant d’en profiter pour centraliser les logs Puppet et peut-être les intégrer à un outil, déjà présent, de gestion de logs. Je propose ici deux méthodes pour l’installation et la configuration du loghost et des clients Puppet : une version classique et la version Puppet. ...