Bonne pratique pour gérer les mises à jour de packages pour de nombreux serveurs CentOS

Dans le cadre de mon travail, je gère quelques dizaines de serveurs CentOS 5, en utilisant des marionnettes pour la configuration principale. Environ la moitié de nos serveurs ont une configuration standardisée pour l'hébergement de divers sites Django, tandis que le reste est un méli-mélo d'applications.

Je trie progressivement nos pratiques d'hébergement, et j'en suis maintenant au point de savoir comment gérer les mises à jour de sécurité au niveau du système d'exploitation. Je me méfie d'avoir juste un travail cron, yum -y updatemais je ne veux pas non plus avoir à parcourir chaque serveur à temps et à examiner chaque package avec les mises à jour disponibles, car cela prendrait un certain temps.

Je me demande donc s'il existe de bons raccourcis ou de bonnes pratiques de travail qui minimiseraient les risques impliqués et minimiseraient le temps que je devrais passer. Ou, pour le dire autrement, existe-t-il des outils ou des pratiques qui peuvent automatiser une grande partie du travail tout en donnant le contrôle.

Étapes que j'ai décidées jusqu'à présent:

• désactiver tous les référentiels tiers et configurer notre propre référentiel afin que je puisse contrôler les mises à jour qui y sont effectuées.
• nous avons des serveurs intermédiaires pour (la plupart) de nos serveurs de production où je pourrais faire des tests (mais combien de tests suffisent-ils?)

Notez également que j'ai examiné le plugin de sécurité yum mais qu'il ne fonctionne pas sur CentOS .

Alors, comment gérez-vous les mises à jour d'un nombre important de serveurs CentOS exécutant une gamme hétérogène d'applications?

Dans la plupart de mes environnements, il s'agit généralement d'un script de démarrage et de post-installation pour obtenir le système principal à jour et à jour. J'ai généralement un dépôt local qui se synchronise avec un miroir CentOS quotidiennement ou hebdomadairement. J'ai tendance à geler le package du noyau à tout moment en cours au moment de l'installation et à mettre à jour les packages individuellement ou si nécessaire. Souvent, mes serveurs ont des périphériques qui ont des pilotes étroitement liés aux versions du noyau, c'est donc une considération.

CentOS 5 a mûri au point où des mises à jour constantes ne sont pas nécessaires. Mais gardez également à l'esprit que CentOS 5 tire à sa fin. Le taux de mises à jour a quelque peu ralenti, et la nature des mises à jour est plus en ligne avec les corrections de bugs et moins sur les changements de fonctionnalités majeurs.

Donc, dans ce cas spécifique, la première chose à faire est de créer un miroir / référentiel local. Utilisez votre gestion de configuration existante pour contrôler l'accès aux référentiels tiers. Peut-être planifier la politique pour mettre à jour les services critiques ou accessibles au public (ssh, http, ftp, dovecot, etc.) Tout le reste nécessitera des tests, mais j'ai l'impression que la plupart des environnements ne fonctionnent pas avec des systèmes entièrement mis à jour / corrigés.

Il existe de nombreux outils qui peuvent vous y aider! Il gère généralement le système de packages et les packages qui vont où est géré par la gestion de la configuration. Ces outils couvrent généralement plus que le yum et les rpms, et vous feront gagner du temps et éviteront de nombreux maux de tête!

L'outil que je connais le plus est la marionnette que j'utilise pour gérer pratiquement toutes les configurations de mon environnement. Voici quelques exemples de marionnettes pour gérer spécifiquement yum:

http://people.redhat.com/dlutter/puppet-app.html

Il existe un certain nombre d'outils de gestion de configuration actuellement disponibles, ceux-ci ont de très grands groupes d'utilisateurs:

• Cfengine http://cfengine.com/cfengine3
• Puppet http://puppetlabs.com/puppet/puppet-difference/
• Chef http://wiki.opscode.com/display/chef/Home (Quelques personnes que je connais l'ont récemment implémenté et adorent)

Leur mise en œuvre dans un environnement ajoutera des années à votre vie. Il réduit le nombre de maux de tête provenant de systèmes mal configurés et permet une mise à niveau / mise à jour facile. La plupart de ces outils peuvent également fournir certaines fonctionnalités de niveau d'audit, ce qui peut réduire considérablement le temps de réparation des erreurs de configuration.

En ce qui concerne votre question sur les tests, j'ai utilisé un environnement de transfert vers lequel nous dirigeons la charge de certains clients (généralement des clients bêta ou un petit sous-ensemble du trafic de production). Nous laissons généralement ce cluster exécuter un nouveau code pendant au moins quelques jours, jusqu'à une semaine (selon la gravité du changement) avant de le déployer en production. Habituellement, j'ai trouvé que cette configuration fonctionne mieux si vous essayez de déterminer combien de temps la plupart des erreurs mettent à découvrir. Dans les systèmes très utilisés, cela peut être une question d'heures, dans la plupart des environnements que j'ai vus, une semaine est suffisamment longue pour découvrir des bogues, même rares, dans la mise en scène / QA.

Une partie très importante des tests est la réplication des données / utilisation. Vous avez mentionné que vous disposez de versions intermédiaires de la plupart de votre matériel de production. Ont-ils également des copies identiques des données de production? Pouvez-vous rejouer une partie de la charge de production contre elle? Pouvez-vous même l'intégrer au cluster de production à l'aide de la mise en miroir du trafic? Cela devient généralement un compromis direct entre la quantité de ressources que l'entreprise est prête à dépenser pour les tests / l'assurance qualité. Plus il y a de tests, mieux c'est, essayez de ne pas vous limiter (dans la limite du raisonnable) et voyez ce que l'entreprise soutiendra (puis trouvez un moyen d'en faire 10% de plus).