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…
Nouvelle gestion des environnements
Un des gros changements de la version 3.6, c’est la modification de la configuration des environnements : l’ancienne méthode est deprecated. Si vous utilisez des blocs environnements dans votre puppet.conf ou si vous utilisez des valeurs globales pour manifest, modulepath, config_version, template_dir, vous aurez comme moi un beau :
Warning: Setting templatedir is deprecated. See http://links.puppetlabs.com/env-settings-deprecations
(at /usr/lib/ruby/vendor_ruby/puppet/settings.rb:1071:in `each')
Error 404 on SERVER: Not Found: Could not find file_content modules
Alors, c’est plus qu’un warning selon moi, puisque sans modification de votre configuration, ça ne fonctionnera plus !
Bref, il faudra suivre le lien donné dans ce warning et modifier votre configuration dans le puppet.conf sur votre puppet master (et peut-être sur vos clients) pour passer aux Directory Environments.
Pour résumer, j’ai simplement fait disparaitre toutes mes anciennes références aux paramètres cités plus haut et j’ai rajouté dans la partie master : environmentpath = $confdir/environments.
Il faudra ensuite créer vos environnements en suivant cet exemple, un environnement nommé TEST, avec ce contenu :
/etc/puppet/environments/TEST/
|-- environment.conf
|-- manifests
`-- modules
|-- mon_module1
|-- mon_module2
[...]
Le fichier environment.conf semble facultatif, en tout cas aujourd’hui. Le répertoire manifests peut-être vide. En gros ce qui est important, c’est le répertoire modules qui contiendra les modules que vous utilisez dans votre environnement.
Premiers tests et premiers soucis
Pour valider mes modifications, j’ai été tenté par la solution de couper mon Apache Passenger et démarrer le puppet master via :
puppet master --no-daemonize --debug
J’aime bien valider de gros changements dans ce mode-là, ça fait du vert et du rouge dans le terminal, c’est beau 😉
Vous pouvez oublier pour le moment cette solution, car WebRick semble avoir un problème :
Error: no 'environments' in {:root_environment=>#<Puppet::Node::Environment:0x7ff @manifest="/root", @name=:"*root*", @modulepath=[], @watching=true, @config_version=nil>, :current_environment=>#<Puppet::Node::Environment:0x7ff @manifest="/root", @name=:"*root*", @modulepath=[], @watching=true, @config_version=nil>} at top of [[0, nil, nil]]
Il y a un BUG ouvert sur Jira : https://tickets.puppetlabs.com/browse/PUP-2659. Il faudra suivre son avancée, mais en attendant il faudra passer par Apache Passenger. Attention à ceux qui n’étaient pas dans ce mode de fonctionnement !
Pour valider que votre configuration est correcte, vous pouvez demander le chemin des modules pour un environnement donné. Exemple pour l’environnement TEST :
[root] >> puppet config print modulepath --section master --environment TEST
/etc/puppet/environments/TEST/modules:/etc/puppet/modules:/usr/share/puppet/modules
Puis vient mon 2ème problème…
J’ai rencontré un autre problème en passant mes clients en 3.6.1 avec des erreurs du type :
Error: Could not set 'file' on ensure: Error 404 on SERVER: Not Found: Could not find file_content modules/mcollective/agent/__ATTENTION%20REP%20PUPPET__
Visiblement si vous utilisez une ressource de type file en mode récursif avec un fichier qui contient des caractères exotiques, Puppet n’est pas content !
C’est un bug ouvert depuis longtemps que j’ai transféré dans leur Jira car visiblement il resurgit avec cette version 3.6.1 (je n’ai pas le problème en 3.5.1).
Pas de solution au problème à part rester en 3.5.1 ou ne pas utiliser des caractères accentués !
Attention au tuning Passenger
Quelque chose a changé récemment dans l’application du tuning Passenger ou… dans la consommation mémoire de Puppet ?
Sur ce graphe, on voit clairement le passage à la nouvelle version. Et ça s’est terminé par des :
Warning: Error 400 on SERVER: Cannot allocate memory - fork(2)
J’avais dû revoir à la baisse mon tuning (en fait j’avais rencontré ce problème en passant en 3.5.1). Attention à ce qu’on peut voir dans certaines docs, surtout au niveau de PassengerMaxPoolSize. Un paramètre qui semble jouer pas mal aussi est PassengerMaxRequests qui permet de relancer le process passenger de l’application quand le nombre de requête indiqué est atteint. Bref, je suis parti sur cette configuration qui tient sans forcer 200 clients.
PassengerHighPerformance on
PassengerMaxPoolSize 3
PassengerPoolIdleTime 600
PassengerMaxRequests 1000
PassengerStatThrottleRate 600
PassengerUseGlobalQueue on
Aidez vous de passenger-memory-stats pour surveiller tout ça !
Au sujet de PuppetDB 2.0
Et bien… Rien en fait. Attention au restart après un upgrade qui ne redémarrera pas forcement la bonne version de PuppetDB. Si vous avez des erreurs du style Missing required query parameter 'payload', c’est ce qu’il s’est passé. N’oubliez pas de mettre à jour puppetdb-terminus sur vos puppet master.
Pour résumer
Il faut peut-être attendre un peu avant d’installer la version 3.6.1 surtout si vous n’êtes pas mode Passenger. Dans le cas contraire, vous risquez d’être obligé de passer dans ce fonctionnement là (ce qui n’est pas une mauvaise chose), mais c’est à prendre en compte. Pour le reste, la nouvelle gestion des environnements est plus claire et le bug remonté contournable… A vous de jouer 😉
EDIT du 11/06 : Puppet 3.6.2 est sorti. Le problème avec WebRick est résolu. Le problème de consommation mémoire, peut être lié au bug “Puppet master passenger processes keep growing”, est peut-être résolu… A suivre.