Gérer les mises à niveau sur des centaines de serveurs Debian

Selon vous, quelles sont les meilleures pratiques pour maintenir à jour des dizaines (sinon des centaines) de serveurs Debian? Gardant à l'esprit que:

• Il existe des groupes de serveurs (ie serveurs web identiques, serveurs DB, ...)
• Il peut y avoir plusieurs problèmes Debian (lenny, etch)
• Faire une boucle sur tous les serveurs et faire une mise à jour et une mise à niveau apt-get n'est pas acceptable (car c'est ce que je fais en ce moment :)) Ça devrait être mieux que ça!

Actuellement, lorsque j'ai finalement terminé toutes les mises à niveau, une nouvelle mise à jour de sécurité est publiée et je dois recommencer.

Merci d'avance à la communauté serverfault!

J'utilise apt-dater pour gérer la mise à niveau de toutes mes boîtes Debian. Semble faire assez bien l'affaire. Je n'ai cependant pas essayé de le faire passer à des centaines d'hôtes.

Google a résolu ce problème avec debmarshal:

http://code.google.com/p/debmarshal/

Ce qui vous permet d'approuver des packages à partir d'un référentiel en amont pour l'installation sur vos hôtes de production.

Ensuite, vous pouvez simplement exécuter cron-apt en mode entièrement automatique.

Voici une vidéo d'introduction:

http://www.youtube.com/watch?v=L3hRToC23mQ

Nous testions l'utilisation de marionnettes pour mettre à niveau des correctifs de sécurité sur des packages non essentiels. Nous exécuterions apticron pour envoyer par e-mail une liste de mises à jour pour chaque serveur, puis exécuter quotidiennement un script qui a fusionné ces mises à jour dans un fichier manifeste de marionnettes qui a donné le package et la version pour chaque distribution. Cela mettrait ensuite à jour un tas de fichiers sur les serveurs individuels et lancerait un script de mise à niveau lorsqu'un package devait être mis à niveau. Cela a bien fonctionné, mais nous ne l'avons pas testé autant que je le souhaiterais. Ce schéma a contourné la limitation de Puppet de ne pas avoir la même ressource définie à plusieurs endroits.

Je n'étais pas non plus à l'aise de faire des mises à niveau automatiques de choses comme MySQL ou PostgreSQL, où une mise à jour aléatoire arrêterait un service, peut-être au milieu de la journée. Ceux-ci nécessiteraient toujours des mises à jour manuelles.

Spacewalk et Debmarshall ressemblent à des alternatives appropriées pour notre schéma de marionnettes.

Apparemment, Spacewalk a maintenant un support préliminaire pour Debian. Cela, peut-être avec Puppet, serait mon point de départ. Je suis sûr que le gars qui développe le support Debian pour Spacewalk vous aimera pour avoir travaillé avec lui pour porter le support Debian à un niveau supérieur.

À la manière des systèmes de configuration basés sur l'extraction comme Puppet, il existe également bcfg2 et cfengine. L'un ou l'autre pourrait convenir à vos besoins. Je déploie bcfg2 dans mon laboratoire en ce moment.

Une solution peut être donnée par func

Je ne sais pas quel type de solution vous attendez. Vous connaissez probablement les tâches cron, mais je ne mettrais pas à jour les systèmes en aveugle car des interventions humaines sont nécessaires (et c'est pourquoi ils vous paient pour cela, non?)

Si vous aviez des systèmes complètement identiques, vous pourriez envisager d'utiliser quelque chose comme rsync pour apporter les différences, mais déterminer quels fichiers ne pas rsync pourraient être difficiles, et je ne le ferais pas pendant que les services sont en cours d'exécution. Au moins, les scripts de mise à jour sont configurés pour gérer le redémarrage des services et la fusion des différences de fichiers de configuration.

Peut-être que si vous expliquez le problème avec les commandes apt-get, nous pourrions voir ce que vous voulez éviter.

Si le problème est la bande passante et le temps de téléchargement, vous devriez peut-être configurer une boîte pour agir comme votre référentiel Debian local. Il existe des guides Debian sur la façon de procéder.

Voici quelques conseils sur la façon de minimiser le nombre de choses que vous devez mettre à jour.

Lorsque vous installez Debian, n'installez pas Desktop à moins que vous n'ayez vraiment besoin d'utiliser X sur cette console. La plupart des serveurs ne nécessitent pas l'installation de X. Cela peut réduire considérablement le nombre de packages sur le système, et vous n'avez donc pas besoin de mettre à jour autant de packages.

Vérifiez que le fichier sources.list inclut uniquement les référentiels dont vous avez vraiment besoin. Si vous avez expérimenté un référentiel et que vous l'avez oublié, vous pouvez apporter des mises à jour dont vous n'avez pas besoin ou que vous ne voulez pas.

Si vous rencontrez des problèmes pour effectuer aveuglément des mises à jour sur un serveur de production, veillez à consulter les guides de mise à niveau Debian en cas de mise à jour majeure (4.0 à 5.0). Ceux-ci se dérouleront très bien si vous suivez les instructions de mise à niveau. Ce n'est pas aussi simple que d'exécuter apt-get dist-upgrade et de partir. Parfois, dans les instructions, il y a même des pointeurs sur le moment d'exécuter aptitude plutôt que apt-get - il y a de petites différences entre eux.

Avez-vous maintenant cet outil "coquille de danseur"? Je l'aime et je l'utilise. Mais je ne sais pas si vous pouvez l'utiliser pour autant d'hôtes. Vous pourriez peut-être essayer ...

http://www.netfort.gr.jp/~dancer/software/dsh.html.en

Et il est dans le référentiel.

ClusterSSH. Vous vous connectez à tous les serveurs et leur donnez exactement les mêmes commandes, afin que vous puissiez également réagir aux boîtes de dialogue. Si un serveur reçoit une question supplémentaire, cliquez simplement dessus et ce sera le seul qui répondra.

Je l'ai utilisé pour mettre à niveau 25 serveurs Web d'Etch vers Lenny. A fonctionné comme un charme.

http://sourceforge.net/projects/clusterssh/

Le cluster ssh est une bonne suggestion.

debmarshal ne fait pas encore partie de debian - je ne suis même pas sûr que ce sera un paquet - semble être un système complètement différent avec un référentiel spécialisé. Comme l'a dit l'orateur, il s'agit actuellement d'une hostilité à l'égard des utilisateurs, et non d'une convivialité.

Spacewalk semble être un clone de Redhat Network, au moins dans l'interface Web. J'ai eu de mauvais résultats en utilisant Redhat Network pour mettre à jour les systèmes. Une fois, il a été suspendu, sans raison apparente, et a causé une panne de service. J'ai fait une mise à jour Yum immédiatement après et cela s'est bien passé, donc je ne peux que supposer que le problème provenait de quelque chose qui a bloqué du côté de RHN. L'autre chose que je n'aime pas dans les mises à jour RHN est que vous ne savez pas quand la mise à jour aura lieu, pour surveiller les problèmes.