Puppet n'est en réalité qu'un utilitaire de gestion de configuration, pas un outil d'automatisation. Si vous voulez une automatisation appropriée, alors vous voudrez regarder mcollective qui a commencé comme un outil tiers, et a maintenant été placé sous l'égide de puppetlabs. N'ayant pas travaillé avec mcollective, je ne peux pas vraiment dire à quel point il gérerait cela non plus, mais je crois comprendre que cela fonctionne mieux comme un mécanisme d'exécution de tâche arbitraire, qui ne fonctionnera pas aussi bien lorsque vous essayez de faire des tâches répétées régulièrement .
Je pense que la meilleure façon de procéder serait de développer les scripts et le processus par lesquels vous souhaitez mettre à jour, puis d'utiliser la marionnette pour pousser les configurations. Alors posez-vous les questions suivantes.
- À quelle fréquence dois-je mettre à jour les ordinateurs ?
- Est-ce que je veux qu'ils redémarrent automatiquement lorsqu'un nouveau noyau est installé, ou est-ce que je veux juste une notification ?
- Devrions-nous exécuter des commandes spéciales pendant les mises à jour ?
- Ai-je suffisamment de systèmes pour que les mises à jour soient échelonnées ?
Au fur et à mesure que vous commencez à créer la configuration et à répondre à ces questions, vous en trouverez probablement d'autres qui sortiront de votre environnement spécifique. Pour un exemple spécifique, voici ce que je fais :
- Pour la plupart de mes systèmes, les mises à jour se font une fois par semaine, via la tâche cron. Selon l'objectif et l'environnement, certains systèmes sont beaucoup plus fréquents.
- La plupart des systèmes redémarrent automatiquement, certains systèmes (selon l'objectif) envoient un rappel par e-mail pour redémarrer. Ceci est géré par une tâche cron qui vérifie le fichier vmlinuz numéroté le plus élevé dans
/bootcontre la sortie deuname -r - Après avoir été brûlé par la mise à jour glibc de RHEL 5.3->5.4, je m'assure de mettre à jour yum, puis glibc, puis tout le reste.
- Comme tout cela est exécuté par des tâches cron, j'ai des sommeils avec des temps aléatoires entre chaque exécution de yum. Chaque hôte peut prendre entre 5 minutes et 45 minutes, ce qui permet de répartir raisonnablement la charge.
Tout cela est contenu dans deux fichiers, les deux entrées cron (mises à jour et vérification du noyau) stockées dans /etc/cron.d et le script de mise à jour. Je le fais avec un script shell de plus en plus désordonné qui prend des arguments de ligne de commande pour effectuer la mise à jour ou la vérification du noyau et décider de redémarrer ou non. Puppet gère ensuite ces deux fichiers. Étant donné que vous travaillez à la fois avec des systèmes basés sur rpm et dpkg, je créerais probablement deux scripts ou créerais des do_update séparés fonctions pour les deux saveurs et ont chacune été appelée avec un commutateur de ligne de commande différent. Ensuite, vous pouvez soit pousser le bon script en cochant le operatingsystem fact dans votre déclaration de fichier, ou modélisez l'entrée cron et utilisez le même fact pour décider quel commutateur utiliser.
En utilisant un script bien testé, cette méthode a très bien fonctionné. Assez bien, en fait, que cette configuration soit utilisée avec succès depuis quelques années pour gérer des centaines de systèmes. Nous verrons parfois des hoquets lorsque les empaqueteurs du noyau commenceront à ajouter de plus en plus de niveaux de versions mineures aux fichiers et que la routine de comparaison s'étouffera.
La marionnette elle-même n'est pas l'outil pour ce travail. Puppetlabs a un outil séparé appelé MCollective, qui est similaire à Capistrano, Fabric et Func.
Il existe un agent MCollecive appelé l'agent de packages qui est capable de faire des mises à jour yum, entre autres types de gestion de packages.
Vous avez mentionné qu'une partie de votre infrastructure exécute Ubuntu. Peut-être devriez-vous vous pencher sur le package de mises à jour sans surveillance.
Si vos hôtes sont des hôtes RHEL, vous souhaiterez peut-être vous pencher sur RHN Satellite. Sinon, Spacewalk peut valoir le coup d'œil ** (voir note ci-dessous). Ils sont conçus pour gérer les copies locales des référentiels de paquetages en amont et pour faciliter la gestion des systèmes enregistrés sur le serveur Satellite RHN. Vous pouvez programmer la mise à jour des paquetages à une heure spécifique, ou si vous avez activé OSAD, les mises à jour peuvent être programmées à une heure proche dans l'interface graphique Web RHN Satellite/Spacewalk.
Certaines personnes ont posté en utilisant puppet ci-dessous, il y a des blogs et des pages Web écrits sur la façon d'intégrer Puppet avec RHN Satellite.
AUTREMENT....
Si vous êtes plus intéressé par un projet émergent qui remplacera éventuellement RHN Satellite, vous pouvez jeter un œil au projet Katello. Katello contient de nombreux projets qui font partie du produit CloudForms de Red Hat et serait l'amont pour le remplacement éventuel de RHN Satellite. En fait Katello intègre Puppet via l'utilisation de Foreman. À long terme, Katello vaut vraiment la peine d'être envisagé via Spacewalk (mais pas encore RHN Satellite en raison de l'abonnement/de l'assistance).
** J'ai fait référence à RHN Satellite et Spacewalk en tant que RHN Satellite dans mon message pour faciliter les choses. La vraie distinction vient de la météo ou non, vous avez des systèmes RHEL, si tel est le cas, vous aurez besoin de RHN Satellite car il peut télécharger à partir de RHN d'une manière prise en charge, Spacewalk serait pour les utilisateurs utilisant une reconstruction de RHEL ou Fedora (je comprends Spacewalk peut également prendre en charge Debian, mais je n'y connais pas grand-chose personnellement.) Ainsi, lors de la recherche d'informations, il peut être nécessaire de rechercher Spacewalk et/ou RHN Satellite