Mises à jour du système pour de nombreux serveurs

Nous avons de nombreux serveurs et souhaitons tous les mettre à jour. La manière actuelle est que n'importe quel administrateur système passe de serveur en serveur et crée un aptitude update && aptitude upgrade- ce n'est toujours pas cool.

Je cherche maintenant une solution encore meilleure et très intelligente. La marionnette peut-elle faire ce travail? Comment faites-vous?

Vous pouvez utiliser le exectype tel que:

exec { "upgrade_packages":
    command => "apt-get upgrade -q=2",
    path    => "/usr/local/bin/:/bin/:/usr/bin/",
    # path  => [ "/usr/local/bin/", "/bin/" ],  # alternative syntax
}

Pour être honnête, je ne l'ai pas essayé moi-même, mais je pense que vous avez juste besoin de créer un nouveau module qui inclut une telle définition exec.

La apt-get upgradecommande est interactive. Pour le faire fonctionner silencieusement, vous pouvez ajouter l'option -q=2comme indiqué ci-dessus.

si tous vos hôtes sont debian, vous pouvez essayer le paquet de mises à niveau sans assistance.

http://packages.debian.org/sid/unattended-upgrades

Ici, nous avons utilisé des marionnettes pour gérer nos machines virtuelles Debian, avec des marionnettes, nous sommes en mesure d'activer et de gérer des configurations de mise à niveau sans surveillance sur tous les serveurs.

Récemment, notre équipe teste l'outil mcollective pour exécuter des commandes sur tous les serveurs, mais pour utiliser les compétences rubis mcollective sont nécessaires.

[s] Guto

Je recommanderais d'aller pour Puppet, facter et mCollective.

mCollective est un cadre très agréable où vous pouvez exécuter des commandes sur une série d'hôtes (en parallèle) en utilisant Facter comme filtre.

Ajoutez à cela un proxy / cache local et vous seriez bien placé pour la gestion des serveurs.

Utilisez un outil conçu pour exécuter une seule commande sur plusieurs serveurs. Et par cela, je ne veux pas dire avoir un terminal kazillion ouvert avec Terminator ou ClusterSSH, mais plutôt avoir un seul terminal pour un serveur de gestion exécutant un outil approprié pour le travail.

Je recommanderais func, Salt ou mCollective dans ce contexte. Si vous avez déjà Puppet, optez pour mCollective (il s'intègre bien dans Puppet). Si ce n'est pas le cas, et que vous avez un vieux Python sur vos machines, vous pourriez apprécier func. Si vous utilisez Python dans une nouvelle version, essayez Salt. Tous ces outils exécutent la commande spécifiée sur la ligne de commande de manière asynchrone, ce qui est beaucoup plus amusant qu'une boucle ssh séquentielle ou même fait les mêmes commandes d'aptitude dans les fenêtres Terminator umpteen aux serveurs umpteen.

Vous aurez certainement l' amour de sel .

Je suppose donc que de nombreuses choses contribuent à une bonne solution:

• Bande passante
• Facilité d'administration
• Enregistrement détaillé en cas de problème.

Bande passante : Fondamentalement, deux alternatives pour économiser la bande passante me viennent à l'esprit:

• Configurer un miroir Debian et configurer tous vos clients pour utiliser ce miroir, voir http://www.debian.org/mirror/ pour plus de détails. (Je recommanderais ceci)
• Mettre en place un proxy (apt-cacher, apt-proxy ou Squid) et augmenter le cache pour que tous vos clients puissent profiter de ce cache

Administration : Je configurerais un shell parallèle comme PDSH , PSSH , GNU Parallel et émettrais la commande sur tous les clients, si je testais la commande précédemment sur un exemple de machine. Ensuite, il est peu probable qu'il échoue sur tous les autres. Alternativement, vous pouvez envisager un travail cron sur tous les clients, mais il peut échouer automatiquement, donc je préférerais la première solution.

Si vous vous inquiétez de la simultanéité des mises à niveau, vous pouvez planifier vos commandes avec at

Journalisation : Comme pour les shells parallèles, vous avez la possibilité de rediriger la sortie. Je combinerais stderr et stdout et l'écrirais dans un fichier journal.

Mon propre wrapper ssh parallèle: classh est une alternative aux divers outils Parallel et cluster ssh.

Vous pourriez l'aimer mieux ou vous pourriez le détester. Il n'y a que trois raisons pour lesquelles je le mentionne ici:

• Il est extrêmement simple à installer et à utiliser: un seul fichier .py sans dépendances externes au-delà des bibliothèques standard Python 2.5.
• Il est extrêmement fiable dans ses limites. Je l'utilise tous les jours ouvrables, souvent près de 100 fois par jour et généralement sur des collections de centaines à quelques milliers de cibles par commande. (Je l'ai testé sur des listes cibles de plus de 25 000 serveurs à la fois). Il n'a jamais manqué de s'exécuter, n'a pas réussi à se terminer ou ne m'a donné aucun comportement indéterminé. (Les seules limitations liées à celles de la subprocess.communicate()méthode Python --- vous ne pouvez donc obtenir que la capture d'environ 64 Ko de stdout et, séparément, jusqu'à 64 Ko de stderr, par exemple; également tout processus distant qui tente de lire à partir de son stdin stalle simplement jusqu'à ce que le sous-domaine ssh local soit tué, automatiquement par la gestion du délai d'expiration de classh )

• Il est extrêmement simple d'écrire un script personnalisé, en Python, pour utiliser classh.py comme module. Il est donc très facile d'écrire quelque chose comme:

  
      !#/bin/env python
      import classh
      job = classh.SSHJobMan(cmd, targets)
      job.start()
      while not job.done():
          completed = job.poll()
          for i in completed:
              # do something with the classh.JobRecord object referenced by i
      # done
  
  
  # You can optionally do post-processing on the dictionary of JobRecords here
  #  keyed off the target strings (hostnames)    
  </code></pre>
  

C'est tout ce qu'on peut en dire. Par exemple, dans la boucle imbriquée terminée, vous pouvez rassembler une liste de tous ceux qui ont renvoyé un état de sortie particulier ou pour rechercher des messages d'erreur spécifiques, et configurer des travaux de suivi pour les gérer. (Les travaux seront exécutés simultanément, par défaut 100 travaux à tout moment, jusqu'à ce que chacun soit terminé; donc une simple commande sur quelques centaines d'hôtes se termine généralement en quelques secondes et un script shell très complexe dans une seule longue chaîne de commande .. disons une cinquantaine de lignes ... peut compléter plus de quelques milliers d'hôtes en 10 minutes environ ... environ 10 000 hôtes par heure dans mon environnement, dont beaucoup sont intercontinentaux).

Donc, cela pourrait être quelque chose que vous pouvez utiliser comme mesure ad hoc jusqu'à ce que votre configuration de marionnettes soit mise en œuvre et teste bien ... et c'est également très pratique pour effectuer de petites enquêtes ad hoc de vos hôtes pour voir lesquels s'écartent de vos normes dans diverses petites manières.

La réponse en utilisant exec est assez utile.

Cependant, selon le manuel apt-get, ce n'est pas une bonne idée d'utiliser -q = 2 de cette façon (bien que je l'utilise depuis des années sans problème)

-q, --quiet
       Quiet; produces output suitable for logging, omitting progress indicators. More q's will produce more quiet up to a maximum of 2. You can also use -q=# to set the
       quiet level, overriding the configuration file. Note that quiet level 2 implies -y, you should never use -qq without a no-action modifier such as -d, --print-uris or
       -s as APT may decided to do something you did not expect. Configuration Item: quiet.

J'ai utilisé un script moi-même pendant des années, exécutant apt-get de la manière suivante:

ssh example.org "apt-get update && apt-get -y upgrade && apt-get -y dist-upgrade && apt-get clean"

Des choses comme des marionnettes et d'autres outils que les gens ont mentionnés peuvent fonctionner, mais il semble que ce soit exagéré pour ce qui consiste simplement à imiter quelques commandes tapées par un humain. Je crois en l'utilisation de l'outil le plus simple pour un travail spécifique, dans ce cas, un script bash est aussi simple que possible sans perte de fonctionnalité.

Depuis des années, je mets à jour et installe avec bonheur des paquets à l'aide d' apt-dater . C'est un outil léger et efficace pour la gestion à distance des packages. Il utilise screen, sudoet ssh.
Pour la gestion des packages, apt-dater peut être une solution plus simple que les outils de gestion de configuration.
apt-dater est pratique pour la gestion centralisée des paquets sur différentes versions GNU / Linux telles que Debian et CentOS.

vous pouvez utiliser Fabric . Fabric est une bibliothèque Python (2.5-2.7) et un outil en ligne de commande pour rationaliser l'utilisation de SSH pour le déploiement d'applications ou les tâches d'administration de systèmes.

utilisez webmin ,,, et utilisez sa fonction de cluster webmin, dans laquelle vous pouvez ajouter tous les systèmes à une seule console webmin et leur envoyer une commande ou les contrôler tous à partir d'un seul endroit.

Ou

Utiliser le cluster ssh

Ou

PSSH

Une autre solution si tous vos hôtes exécutent Debian (ou dérivés) est d'utiliser le paquet cron-apt . Mais, comme suggéré par la documentation, un peu de prudence doit être prise.

J'utilise actuellement cron-apt sur une douzaine de serveurs pour effectuer toutes les mises à jour de sécurité automatiquement et sans surveillance. Pour éviter toute mise à jour non désirées, je n'utilise que cron-apt sur des serveurs qui gère la distribution stable Debian et je fais en sorte de configurer mes sources apt utilisent donc le nom de la distribution, sifflante , et non son alias (stable).

La configuration cron-apt spécifique que j'utilise est résumée dans un fichier d'action: /etc/cron-apt/action.d/5-install

dist-upgrade -y -o APT::Get::Show-Upgraded=true -o Dir::Etc::SourceList=/etc/apt/sources.list.d/security.list -o Dir::Etc::SourceParts="/dev/null"

Toute autre mise à niveau, se fait manuellement, en utilisant l'écran ou ce qui est le plus approprié, car cela peut nécessiter une intervention manuelle pendant la mise à niveau.