Systemupdates für viele Server

Wir haben viele Server und möchten sie trotzdem alle aktualisieren. Der eigentliche Weg ist, dass alle Sysadmins von Server zu Server gehen und ein machen aptitude update && aptitude upgrade- es ist immer noch nicht cool.

Ich suche jetzt nach einer Lösung, die noch besser und sehr klug ist. Kann Puppe diesen Job machen? Wie machst du das?

Sie können den folgenden execTyp verwenden:

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

Um ehrlich zu sein, habe ich es nicht selbst versucht, aber ich denke, Sie müssen nur ein neues Modul erstellen, das eine solche Exec-Definition enthält.

Der apt-get upgradeBefehl ist interaktiv. Damit es leise läuft, können Sie die -q=2oben gezeigte Option hinzufügen .

Wenn alle Ihre Hosts Debian sind, können Sie das Paket für unbeaufsichtigte Upgrades ausprobieren.

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

Hier haben wir Puppet verwendet, um unsere virtuellen Debian-Maschinen zu verwalten. Mit Puppet können wir Konfigurationen für unbeaufsichtigte Upgrades auf allen Servern aktivieren und verwalten.

Kürzlich hat unser Team das mcollective-Tool getestet, um Befehle auf allen Servern auszuführen. Um jedoch mcollective Ruby-Kenntnisse zu nutzen, sind diese erforderlich.

[s] Guto

Ich würde Puppet, Facter und mCollective empfehlen.

mCollective ist ein sehr schönes Framework, in dem Sie Befehle über eine Reihe von Hosts (in Parallelen) ausführen können, wobei Facter als Filter verwendet wird.

Fügen Sie dazu einen lokalen Proxy / Cache hinzu, und Sie sind für die Serververwaltung gut gerüstet.

Verwenden Sie ein Tool, mit dem ein einzelner Befehl auf mehreren Servern ausgeführt werden kann. Und damit meine ich nicht, dass mit Terminator oder ClusterSSH eine Unmenge von Terminals geöffnet ist, sondern ein einziges Terminal für einen Verwaltungsserver, auf dem ein für den Job geeignetes Tool ausgeführt wird.

Ich würde in diesem Zusammenhang func, Salt oder mCollective empfehlen. Wenn Sie Puppet bereits haben, entscheiden Sie sich für mCollective (es lässt sich gut in Puppet integrieren). Wenn Sie dies nicht tun und einen alten Python auf Ihren Computern haben, wird Ihnen möglicherweise die Funktion gefallen. Wenn Sie Python neu haben, versuchen Sie es mit Salt. Alle diese Tools führen den in der Befehlszeile angegebenen Befehl asynchron aus, was viel mehr Spaß macht als eine sequentielle ssh-Schleife oder sogar die gleichen Eignungsbefehle in unzähligen Terminator-Fenstern für unzählige Server auszuführen.

Sie werden Salt auf jeden Fall lieben .

Ich denke, es gibt viele Dinge, die zu einer guten Lösung beitragen:

• Bandbreite
• Einfache Verabreichung
• Detaillierte Protokollierung für den Fall, dass etwas schief geht.

Bandbreite : Grundsätzlich fallen mir zwei Alternativen ein, um Bandbreite zu sparen:

• Einrichten eines Debian-Spiegels und Konfigurieren aller Clients für die Verwendung dieses Spiegels finden Sie unter http://www.debian.org/mirror/ . (Ich würde das empfehlen)
• Einrichten eines Proxys (apt-cacher, apt-proxy oder Squid) und Erhöhen des Caches, damit alle Ihre Kunden von diesem Cache profitieren können

Administration : Ich würde eine parallele Shell wie PDSH , PSSH , GNU Parallel konfigurieren und den Befehl auf allen Clients ausgeben, wenn ich den Befehl zuvor auf einem Beispielcomputer getestet hätte. Dann ist es nicht sehr wahrscheinlich, dass es bei allen anderen fehlschlägt. Alternativ können Sie einen Cron-Job auf allen Clients in Betracht ziehen, der dann jedoch automatisch fehlschlägt. Daher würde ich die erste Lösung vorziehen.

Wenn Sie Bedenken hinsichtlich der Gleichzeitigkeit von Upgrades haben, können Sie Ihre Befehle mit planen at

Protokollierung : Wie bei parallelen Shells haben Sie die Möglichkeit, die Ausgabe umzuleiten. Ich würde stderr und stdout kombinieren und in eine Protokolldatei schreiben.

Mein eigener paralleler SSH- Wrapper: classh ist eine Alternative zu den verschiedenen parallelen und Cluster-SSH-Tools.

Vielleicht gefällt es dir besser oder du hasst es. Es gibt nur drei Gründe, warum ich es hier erwähne:

• Es ist extrem einfach zu installieren und zu verwenden: eine einzelne .py-Datei ohne externe Abhängigkeiten über die Python 2.5-Standardbibliotheken hinaus.
• Es ist innerhalb seiner Grenzen äußerst zuverlässig. Ich benutze es jeden Arbeitstag, oft fast 100 Mal pro Tag und normalerweise für Sammlungen von Hunderten bis einigen Tausend Zielen pro Befehl. (Ich habe es auf Ziellisten von weit über 25.000 Servern gleichzeitig getestet). Es ist nie gescheitert zu laufen, nicht zu vervollständigen oder mir ein unbestimmtes Verhalten zu geben. (Die einzigen Einschränkungen im Zusammenhang mit denen der Python- subprocess.communicate()Methode: Sie können also nur etwa 64 KB stdout und separat bis zu 64 KB stderr erfassen. Außerdem wird jeder Remote-Prozess, der versucht, aus seinem stdin zu lesen, einfach zum Stillstand gebracht bis der lokale ssh-Unterprozess automatisch durch die Timeout-Behandlung von classh beendet wird )

• Es ist extrem einfach, ein benutzerdefiniertes Skript in Python zu schreiben, um classh.py als Modul zu verwenden. Es ist also sehr einfach, etwas zu schreiben wie:

  
      !#/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>
  

Das ist alles dazu. In der verschachtelten abgeschlossenen Schleife können Sie beispielsweise eine Liste aller Personen erstellen, die einen bestimmten Beendigungsstatus zurückgegeben haben, oder nach bestimmten Fehlermeldungen suchen und Folgeaufträge einrichten, um diese zu verarbeiten. (Die Jobs werden gleichzeitig ausgeführt, standardmäßig 100 Jobs zu jedem Zeitpunkt, bis jeder abgeschlossen ist. Daher wird ein einfacher Befehl auf einigen hundert Hosts normalerweise in wenigen Sekunden ausgeführt und ein sehr komplexes Shell-Skript in einer einzigen langen Befehlszeichenfolge. Sagen wir, fünfzig Zeilen oder so ... können in meiner Umgebung über ein paar tausend Hosts in ungefähr 10 Minuten fertigstellen ... ungefähr 10.000 Hosts pro Stunde in meiner Umgebung, wobei sich viele davon interkontinent befinden).

Dies kann also als Ad-hoc-Maßnahme verwendet werden, bis Sie Ihre Puppenkonfiguration implementiert und gut getestet haben. Außerdem ist es sehr hilfreich, kleine Ad-hoc-Umfragen bei Ihren Hosts durchzuführen, um festzustellen, in welchen von Ihren Standards abweichen verschiedene kleine Wege.

Die Antwort mit exec ist ziemlich hilfreich.

Laut dem apt-get-Handbuch ist es jedoch keine gute Idee, -q = 2 auf diese Weise zu verwenden (obwohl ich es jahrelang ohne Probleme verwendet habe).

-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.

Ich habe selbst jahrelang ein Skript verwendet und apt-get folgendermaßen ausgeführt:

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

Dinge wie Marionetten und andere Werkzeuge, von denen die Leute sagten, dass sie funktionieren könnten, aber es scheint übertrieben zu sein, wenn man im Grunde nur ein paar Befehle nachahmt, die von einem Menschen eingegeben wurden. Ich glaube daran, das einfachste Tool für einen bestimmten Job zu verwenden. In diesem Fall ist ein Bash-Skript so einfach wie es nur geht, ohne die Funktionalität zu verlieren.

Seit Jahren aktualisiere und installiere ich gerne Pakete mit apt-dater . Es ist ein leichtes und effektives Tool für die Remote-Paketverwaltung. Es verwendet screen, sudound ssh.
Für die Paketverwaltung ist apt-dater möglicherweise eine einfachere Lösung als Konfigurationsverwaltungstools.
apt-dater ist praktisch für die zentralisierte Paketverwaltung auf verschiedenen GNU / Linux -Varianten wie Debian und CentOS.

Sie können Stoff verwenden . Fabric ist eine Python-Bibliothek (2.5-2.7) und ein Befehlszeilentool zur Optimierung der Verwendung von SSH für die Anwendungsbereitstellung oder Systemverwaltungsaufgaben.

Verwenden Sie webmin ,,, und verwenden Sie die Webmin-Cluster-Funktion, mit der Sie alle Systeme zu einer Webmin-Konsole hinzufügen und ihnen einen Befehl erteilen oder alle von einem Ort aus steuern können.

Oder

Verwenden Sie Cluster ssh

Oder

PSSH

Eine andere Lösung, wenn auf allen Hosts Debian (oder Derivate) ausgeführt wird, ist die Verwendung des Cron-Apt-Pakets . Wie in der Dokumentation vorgeschlagen, muss jedoch ein wenig Vorsicht walten lassen.

Ich verwende derzeit cron-apt auf einem Dutzend Servern, um alle Sicherheitsupdates automatisch und unbeaufsichtigt durchzuführen. Um unerwünschte Upgrades zu vermeiden, verwende ich cron-apt nur auf Servern, auf denen die stabile Debian-Distribution ausgeführt wird, und ich stelle sicher, dass meine apt-Quellen so konfiguriert sind, dass der Distributionsname wheezy und nicht der Alias ​​(stabil) verwendet wird.

Die von mir verwendete spezifische Cron-Apt-Konfiguration ist in einer Aktionsdatei zusammengefasst: /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"

Jedes andere Upgrade wird manuell über den Bildschirm oder was auch immer am besten geeignet ist durchgeführt, da möglicherweise manuelle Eingriffe während des Upgrades erforderlich sind.