Comment gérer efficacement apt sur plusieurs machines?

11

Je gère environ 30 serveurs Ubuntu à l'aide de marionnettes. J'ai vu de nombreuses références à cron-apt et apticron comme approches pour maintenir leurs packages à jour, mais je n'ai pas été en mesure de trouver un moyen de gérer le processus de manière centralisée. Avec cront-apt / apticron, je devrais toujours me connecter à chaque hôte et exécuter aptitude updatepour effectuer la mise à jour. Sans parler des notifications de révision des 30 machines chaque fois qu'un package principal est mis à jour.

Il doit y avoir une meilleure façon. Aucune suggestion?

ubuntu  debian  apt 
— Insyte
source

Réponses:

3

Le paysage pourrait vous intéresser. Il s'agit de l'outil de gestion «officiel» pour la gestion de grands déploiements Ubuntu, et Canonical est probablement très désireux d'obtenir vos dollars pour son utilisation.

RÉÉDITER:

Tout d'abord, un avertissement; Je n'ai pas utilisé de mise en miroir pour Debian ou Ubuntu, donc je ne connais pas le logiciel.

Deuxièmement, il semble qu'apt-mirror serait une solution «trop lourde», mes excuses. L'idée initiale était que vous auriez une machine de test distincte (ou un environnement de test, probablement une machine virtuelle?) Sur laquelle déployer la mise à jour. Une fois que vous êtes satisfait des performances de la mise à jour, vous tirez / placez le package dans votre miroir "deploy" (il y aurait le miroir local des sources officielles et un miroir secondaire pour les seules mises à jour que vous souhaitez déployer). Les machines distantes exécuteraient alors une mise à jour à une heure prédéfinie et la retireraient de votre miroir de "déploiement" sur chaque machine, un travail cron consistant en:

apt-get update && apt-get upgrade --quiet --assume-yes

Malheureusement, comme j'ai commencé à lire les détails, il semble que cela apt-mirrorva tirer toutes sortes de choses et pas seulement les paquets que vous recherchez. Donc, je vais abandonner cette idée, bien que le concept ait un certain mérite.

— Avery Payne
source
Le paysage semble intéressant. Je vais devoir y regarder de plus près. Je ne sais pas comment exécuter un miroir apt local (ce que je fais actuellement) m'aiderait à approuver / examiner les mises à jour en attente. Pouvez-vous clarifier cela?
— Insyte
14

Un collègue a découvert et a examiné brièvement apt-dater, qui est un «gestionnaire de mise à jour de packages à distance basé sur un terminal».

Vous utilisez une interface basée sur des curseurs pour gérer les mises à jour sur tous vos hôtes, ou groupes d'hôtes, etc. Prend en charge la journalisation de la session apt complète, y compris les erreurs qui peuvent être rencontrées, etc.

Repose sur ssh et sudo sur les machines gérées.

voir http://www.ibh.de/apt-dater/

Je ne l'ai pas utilisé moi-même, donc je ne peux pas l'approuver, mais cela semble proche de ce que vous recherchez.

— Jeff
source
Cela semble très prometteur. Insyte, je vais recommander cette réponse par rapport à la mienne. Bien que vous puissiez faire toutes les étapes que j'ai décrites, voulez-vous vraiment investir du temps dans cela, alors que vous pourriez probablement faire une configuration très rapide de cela et simplement continuer votre vie? @Jeff, +1 pour une belle suggestion.
— Avery Payne
4

Puisque vous utilisez déjà Puppet, la façon la plus simple de le faire (et la meilleure à des fins de contrôle / suivi des modifications) est de spécifier la version souhaitée des packages que vous souhaitez installer dans le manifeste de marionnettes. Vous gardez un œil sur la liste des annonces de sécurité, et lorsque quelque chose que vous utilisez arrive, vous mettez à jour Puppet pour dire "installez cette nouvelle version de ce paquet". En supposant que vous utilisez le contrôle des révisions sur vos manifestes, vous savez alors quand la "stratégie" a été modifiée et les rapports de Puppet vous indiquent exactement quand la modification a été réellement effectuée (afin que vous puissiez facilement corréler cela avec les événements de journal ultérieurs).

— womble
source
C'est à peu près ce que nous faisons. Nous n'utilisons pas le type de package marionnette car cela obligerait chaque serveur à installer chaque package. Au lieu de cela, nous écrivons un fichier sur le serveur avec le nom et la version du package, puis utilisons un script pour les parcourir et vérifier s'ils sont installés, puis essayer de les installer. La deuxième partie est un script qui lit mon dossier de messagerie avec des courriels apticron et saisit tous les packages qui ont besoin d'une mise à jour et de réécrire le fichier manifeste. Nous ne savons pas encore à quel point cette méthode fonctionne bien.
— David Pashley
2
Pourquoi le type de package Puppet installerait-il tous les packages sur chaque machine? Vous placez les strophes de chaque package dans la classe ou le type défini approprié, de sorte qu'il ne soit installé que sur la ou les machines appropriées. Si vous souhaitez centraliser la liste des versions dans un fichier, disposez d'une grande liste de ressources virtuelles, puis réalisez-les si nécessaire.
— womble
2

Jetez un œil à clusterssh (apt-get install clusterssh):

$ cssh serveur1 serveur2 serveur3 ...

— Thiago Figueiro
source
1
Cela fonctionne toujours en 10.9.3 ... c'est assez hilarant de l'utiliser
— Jonathan S. Fisher
1

Sans y avoir vraiment réfléchi auparavant, ma première idée serait quelque chose de similaire à ce qu'avery a suggéré, surtout si vous avez déjà un environnement de test.

Fondamentalement, vous configurez vos machines de production pour une mise à niveau automatique à partir de votre propre référentiel local et vous ne mettez à jour ce référentiel qu'après avoir mis à niveau votre environnement de test vers la dernière version de ce que vous exécutez.

Apticron n'évolue pas bien, il est conçu pour être exécuté dans de très petits environnements, mais il a de bons points:

  • Il vous envoie non seulement une liste, mais aussi les journaux des modifications pour les packages à mettre à niveau.
  • Pour obtenir les journaux des modifications, il télécharge les packages, donc lorsque vous effectuez une mise à niveau, vous n'avez pas à attendre qu'ils soient téléchargés.
— l'autre reçoit
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.