Puppet II, le retour de la poupée

1. Mongrel + Nginx

En commençant avec Puppet, on se met à déployer quelques petits trucs de-ci de-là, sans se presser, le temps de se faire la main. Mais par défaut, Puppet tourne avec Webrick, un serveur web tout à fait basique écrit en Ruby, dont la capacité est assez limitée lorsque la charge commence à augmenter. Lorsqu'un nombre critique de clients - donc de machines puppet-isées - est atteint, les requêtes ne sont plus complétées et les erreurs s'empilent. Il est temps de changer de serveur pour quelque chose de plus robuste et plus scalable (cet article fera plaisir à ton décideur).

Actuellement, deux solutions à ce problème sont disponibles. D'un côté, Passenger, alias mod_rails ou mod_rack, qui est généralement utilisé en tant que module apache ; et de l'autre, Mongrel, qui est un serveur (et une bibliothèque) en Ruby particulièrement rapide, qui permet d'avoir de multiples instances lancées. Il se marie très bien avec nginx, le très populaire serveur web et reverse proxy, venu du froid de la toundra russe.

Personnellement, j'ai retenu, de façon arbitraire, le couple Mongrel et nginx. C'est donc ce type d'architecture que nous allons monter, afin de supporter la charge toujours plus intense qui pèse sur notre puppetmaster.

On va alors modifier /etc/default/puppetmaster pour lui dire de démarrer non plus un Webrick, mais un Mongrel, et plus précisément 4 instances de Mongrel.

Les lignes

deviennent

Petite explication pour la dernière ligne : Puppet écoute par défaut sur le port 8140, et c'est sur ce port que les clients essaieront de le joindre. La modification fait écouter les 4 instances de Mongrel sur les ports 18140 à 18143. L'incrémentation est bien entendu liée à la valeur de PUPPETMASTERS précisée juste au-dessus.

Relançons le puppetmaster et examinons les processus qui tournent :

Dans cette configuration, nous disposons de 4 instances pouvant servir des clients, mais qui ne tournent pas sur le bon port. Il ne tient qu'à nous de faire en sorte que le port 8140 soit la porte d'entrée vers des petits processus fraîchement lancés.

Pour cela, c'est nginx qui va entrer en jeu. Il va écouter sur le port 8140 et dispatcher les requêtes à nos différentes instances Mongrel.

Voici le nginx.conf, les explications juste ensuite :

Puppet est basé sur des certificats SSL, il faut donc dire à nginx où se trouvent tous ces certificats ainsi que les options qui leur sont liées.

La partie « upstream » définit les instances locales dont nous disposons, rien de sorcier. C'est en quelque sorte la destination finale des requêtes qui vont nous parvenir.

La première partie « server » écoute sur le port 8140 et sert de proxy vers la partie « upstream » définie juste au-dessus. C'est par là que quasiment toutes les requêtes passeront, à l'exception de la première connexion d'un hôte. En effet, c'est à ce seul effet qu'une section écoutant sur le port 8141 est créée. Avant la première connexion, le client et le serveur n'ont pas connaissance l'un de l'autre et plus particulièrement au niveau de leurs certificats. C'est pourquoi la directive ssl_verify_client est mise à « off ». Cela permettra à nos deux parties de se faire les politesses d'usage nécessaires au bon fonctionnement de la chaîne.

Il faudra aussi ajouter, dans la section « puppetmasterd » de puppet.conf, la ligne suivante :

Si vous n'avez pas de plugins disponibles, modifiez la configuration du client pour désactiver le « pluginsync » et éviter une erreur sur la CLI.

Le premier appel à Puppet ressemblera alors à :

Le manifest sur le serveur est des plus simples pour cette démonstration :

Un petit tail -f sur /var/log/nginx/access-main.log permet de voir que les requêtes passent bien à travers le nginx avant d'arriver aux puppetmasters.

A noter que j'utilise la signature automatique des certificats, ce qui me permet de ne pas avoir à faire de puppetca –sign à chaque nouveau client. Certains n'aiment pas, mais mon master n'étant pas accessible publiquement, cette pratique n'est guère gênante. Si vous ne l'utilisez pas, vous devrez signer le certificat avec la commande puppetca après la première demande.

Nous avons désormais un puppetmaster capable de recevoir plus de demandes, mais dans le monde exigeant d'aujourd'hui où les SLA sont souvent aussi élevées que des bonus de traders, on ne peut se permettre de perdre son master. Deux puppetmasters, c'est mieux qu'un seul et nous allons tout de suite lui trouver un petit frère.

1.1 Multiplication des masters puppet

Pour que les serveurs aient la même configuration, nous allons pour cet article aller au plus simple et utiliser NFS pour le partage des fichiers des masters. Dans un environnement de production exigeant des SLA fortes, il est plus conseillé de recourir à des systèmes de fichiers clusterisés, comme ocfs ou glusterfs, qui ne constitueront pas un « single point of failure ».

Sur la machine glmf-infra1, nous installons et paramétrons le nécessaire :

Les répertoires partagés seront donc respectivement montés dans /etc/puppet et dans /var/lib/puppet. Il s'agit alors de « migrer » les données présentes sur le master dans le NFS, puis de monter ces deux répertoires sur chacun des masters.

Sur glmf-master1 :

On aura donc sur les deux masters les entrées suivantes dans le fichier /etc/fstab :

Par défaut, Mongrel n'écoute que sur l'adresse locale, nous allons donc lui dire de tendre l'oreille vers le monde extérieur par le biais de /etc/default/puppetmaster.

Nos deux puppetmasters ont maintenant la même configuration et répondent tous les deux au nom « glmf-master1 » grâce à la directive certname.

Nous devons aussi modifier la configuration de nginx pour qu'il prenne en compte les deux puppetmasters et qu'il répartisse les requêtes entre eux. On transforme donc la partie suivante :

en

Et on redémarre le démon. Pour vérifier que tout fonctionne comme prévu, il nous suffit de lancer plusieurs requêtes vers le master afin d'être certains de toucher les deux lors de la répartition des requêtes. On suit donc le /var/log/daemon.log des 2 masters :

sur glmf-master1 :

sur glmf-master2 :

et le client, pour qui tout est transparent :

Nous avons donc deux masters qui servent un nginx positionné en frontal, ce qui nous permet d'absorber un grand nombre de requêtes. Néanmoins, ce type d'architecture n'est pas souhaitable pour un environnement de production en l'état car, comme je l'ai précisé plus haut, le montage NFS est un point « bloquant » en cas de panne. De plus, il faudrait doubler le nginx qui se trouve en frontal à l'aide, par exemple, d'un heartbeat tout ce qu'il y a de plus classique avec une simple IP virtuelle. Ceci est laissé comme exercice au lecteur ;-)

2. Ressources exportées & configurations stockées

Avec la version 0.25, une nouvelle fonctionnalité est apparue, il s'agit des storedconfigs qu'on pourrait traduire par « configurations stockées ». Ce mécanisme permet la collecte de données sur les clients Puppet, en vue de leur réutilisation ultérieure. On peut alors générer des configurations à partir de ces données, mais aussi les redéployer. En effet, ces données peuvent être des fichiers ! Avant d'entrer plus dans le détail, commençons par paramétrer tout ce petit monde.

2.1 Paramétrage

J'ai retenu le backend MySQL pour utiliser les storedconfigs. Il est possible d'utiliser aussi SQLite et PostgreSQL.

On installe donc MySQL Server :

Il faut maintenant créer la base ainsi qu'un utilisateur pour Puppet :

Puisque nous ne sommes pas en local, il faut également penser à commenter la ligne dans /etc/mysql/my.cnf,qui contient l'instruction suivante :

Et sur les masters, on ajoute à la section [puppetmasterd] les lignes suivantes :

Et alors, au premier client qui se connecte, on obtient dans les logs du puppetmaster qui aura pris la requête en charge :

2.2 Utilisation dans les manifests

En guise d'introduction, nous allons exporter un fichier contenant des infos concernant le nœud affecté, que facter nous fournit sous la forme de variables, dans un fichier. Les clients 1 et 2 de notre architecture vont exporter le fichier tandis que le troisième va collecter ces fichiers.

Aucun message particulier n'est affiché par les nœuds qui exportent des données, tandis qu'on voit bien sur le nœud qui importe la création des fichiers :

3. Puppet & VCS : un duo efficace

3.1 Travailler à plusieurs & tracer les changements

Lorsque l'on travaille seul, on est tenté de se dire : « je sais ce que je fais, personne ne viendra mettre le bazar dans mes manifests ». Dans le cadre d'une équipe d'admins, cette réflexion n'est tout de suite plus valable. C'est pourquoi la plupart des puppet-eurs utilisent un VCS en combinaison avec leur outil de gestion de configuration préféré. Que ce soit CVS, Subversion ou le très hype git - pour lequel vous trouverez d'excellentes introductions dans les archives de GLMF que vous stockez ou sur unixgarden.com - le principe reste le même que lorsque vous codez sur un projet en commun : tracer les changements, vérifier les conflitset et au besoin, les gérer. Cela permet aussi d'avoir un historique des modifications afin d'identifier l'origine d'un problème et au besoin de revenir rapidement à un état « connu » et fonctionnel. Dans le cadre de mon travail, c'est Subversion le VCS qui a été choisi et c'est donc sur ce dernier que je vais me baser pour les exemples qui vont suivre.

3.2 All your files are belong to us

Afin de garder trace de tout changement dans Puppet, que ce soit au niveau des manifests, des fichiers servis ou des templates, il est impératif que toutes les modifications soient faites au niveau du dépôt et jamais dans sa copie en production.

Nous allons donc faire un checkout de notre dépôt puppet dans /etc/puppet/ et pouvoir ainsi le mettre à jour par un simple update :

3.3 Scripts de {pre|post} commit

Même les sysadmins sont humains, du moins en grande partie, et ils font eux aussi des erreurs, de frappe le plus souvent. Il faut donc pallier aux problèmes liés aux erreurs et éviter de mettre en production une version qui ne passe pas le stade de la compilation des manifests. Ceci est possible et facilement réalisable grâce aux scripts de pre-commit qui vont vérifier que les fichiers commités sont au moins syntaxiquement corrects. Les scripts qui remplissent ces fonctions dans Subversion sont appelés des « hooks ». Ils se situent donc dans le répertoire du même nom. Ici, c'est le script de pre-commit, donc avant l'envoi des modifications dans le dépôt, qui nous intéresse.

Voici le script qui se trouve dans <racineSVN>/puppet-article/hooks/pre-commit. Il est adapté de celui du wiki Puppet. A noter qu'un petit bug existe en version 0.24.x et a été corrigé dans les versions 0.25.

Exemple de commit réussi :

Exemple de commit rejeté :

Il est également possible de mettre en place un script de post-commit, donc une fois que les modifications sont entrées de manière effective dans le dépôt. Son usage le plus commun est l'envoi par mail de la sortie d'un diff entre l'ancienne et la nouvelle version d'un fichier. Cette pratique permet de tenir au courant chacun des sysadmins qui travaille sur le dépôt de la modification d'un fichier.

Le script de post-commit, quant à lui, est plus simple :

3.4 Update automatique VS mise en production contrôlée

Un autre point important de l'utilisation d'un VCS pour la gestion de Puppet est la façon de mettre en production les modifications. Certains, que nous ne nommerons pas, font un update régulier de leur dépôt en cron. Ainsi, les modifications une fois commitées arrivent directement en production. D'autres choisissent de faire l'update à la main et ainsi contrôler le moment précis où les modifications seront effectives. J'aurai personnellement tendance à conseiller la seconde solution, parce que des modifications non voulues ou incorrectes sur des dizaines (ou même plus) de machines peuvent avoir des conséquences relativement fâcheuses.

4. Ajouter des facts & des fonctions

Un des points forts de Puppet est son extensibilité. Il est possible de créer des extensions pour presque tout ce qui le compose : des facts, des fonctions, des types, des providers. Le seul prérequis est la connaissance du langage Ruby. De plus, de nombreux exemples sont disponibles et l'aide ne manque pas, notamment via le biais du canal IRC #puppet sur le réseau Freenode.

Quelques prérequis :

- le système de pluginsync doit être activé, c'est de cette façon que sont distribuées les fonctions et les facts ;

- les éléments personnalisés sont placés dans le module custom, sous les chemins suivants :

4.1 Ecrire un fact personnalisé

On a parfois besoin de connaître des infos que facter ne propose pas d'emblée et qui sont spécifiques à notre architecture. Pour cela, rien de bien compliqué, quelques lignes de Ruby suffisent la plupart du temps. Comme petit exercice de démonstration, je vais utiliser un fact personnalisé que j'utilise dans mon environnement de production. J'utilise des machines Alix (de chez PC Engines) sous OpenBSD en guise de petits serveurs DNS/DHCP pour de petits réseaux, et elles ont quelques particularités de configuration. Afin de les appliquer de façon sélective :

Petite analyse : il est possible de restreindre la « portée d'éxécution » d'un fact avec la directive confine. Ici, on ne le déclenchera que si la valeur du fact operatingsystem est égale à openbsd. Sur les machines qui ne sont pas des Alix, elle renverra la valeur classic et dans le cas contraire, elle renverra alix. Le test porte sur la valeur d'un autre fact. A noter que ceci fonctionne parce que les Alix sont mes seules machines à base de Geode.

La création d'un fact personnalisé est bien structurée, il faut respecter le fait de renvoyer la valeur voulue pour le fact dans le bloc setcode. De même, c'est la première valeur renvoyée qui prime.

Il est possible de tester un fact personnalisé de façon autonome une fois déployé avec le switch -p de facter.

ou :

4.2 Ecrire une fonction personnalisée

De même que pour les facts, la nécessité peut se faire ressentir au niveau des fonctions originales de Puppet. Celles disponibles ne font pas ce dont nous avons besoin ? Qu'à cela ne tienne, écrivons la notre. Supposons que nous avons besoin de passer une variable tout en casse minuscule et de lui ajouter un chiffre aléatoire au bout.

elle sera donc appelée dans un manifest de la façon suivante, par exemple :

A noter une particularité, que certains considèreront comme un défaut voire un bug : lorsque l'on développe des fonctions supplémentaires pour Puppet, ces dernières sont chargées par le master au moment d'être utilisées et restent ensuite en mémoire. Ainsi, quand on utilise plusieurs puppetmasters et que les fonctions sont en cours de développement, il est possible que 2 masters n'aient pas la même version de la fonction en mémoire, ce qui peut rendre le déboguage quelque peu casse-tête avec des résultats qui ressemblent à « un coup ça marche, un coup ça ne marche pas ». Il faut donc redémarrer les masters entre chaque modification des fonctions. De toute façon, vous avez une architecture de test dans des machines virtuelles, non ?

5. Séparer ses données de sa logique

Une question qui revient souvent est « comment séparer mes données de mes manifests ? ». En effet, il est peu pratique, et pas bon niveau sécurité, d'avoir une clé privée SSH, un mot de passe ou toute autre donnée métier un tant soit peu sensible dans un manifest. Heureusement, il existe une solution simple et flexible, disponible sous la forme d'une fonction nommée extlookup(). Elle a été écrite par R. I. Pienaar et a été intégrée ensuite au répertoire « ext » de Puppet au vu de son succès. Pour la déployer, il faut la placer dans le dossier des fonctions personnalisées, tout simplement.

Cette fonction recherche ses informations dans des fichiers CSV selon un ordre que nous pouvons définir à l'aide d'une variable. Avec ce système, on obtient une excellente souplesse dans la récupération des données. Un exemple vaut mille mots :

Et pour cela, le fichier /etc/puppet/extdata/domain_lan.csv doit contenir la ligne :

Si on veut utiliser un serveur de logs particulier pour la machine glmf-client1, on ajoute dans le répertoire extdata le fichier glmf-client1.lan.csv avec une valeur différente pour le champ logserver. De même, lorsque nos machines sont géographiquement dispersées, il est fréquent et souvent intéressant de définir une variable précisant le site. Personnellement, je l'appelle site et m'en sers pour faire pointer des services vers un serveur qui se trouve être au plus prêt.

La fonction extlookup() évalue la variable extlookup_precedence dans l'ordre et renvoie la première valeur trouvée pour le champ demandé, et une erreur si le champ n'est défini dans aucun des fichiers qui la composent et se trouvent dans le dossier pointé par extlookup_datadir. Ainsi, dans l'exemple ci-dessus, on commence par faire la recherche sur le FQDN de la machine (variable facter fqdn), puis par rapport à la valeur de la variable site, ensuite par rapport au domaine de la machine (variable facter domain) et enfin, un fichier censé contenir des valeurs « par défaut » pour toutes les machines de l'infrastructure.

Conclusion

Puppet est un logiciel qui grandit vite, s'adapte rapidement aux demandes des utilisateurs et se révèle être très flexible. Nous venons de voir qu'il est possible de déployer des serveurs supplémentaires facilement et de façon tout à fait transparente pour les clients. Il est aussi facilement extensible, les connaissances requises en Ruby sont très basiques et n'importe quel sysadmin peut les acquérir dans les livres d'introduction au langage.

A bientôt pour de nouvelles aventures !