Wie kann man viele Hosts yum update / aptitude sicher upgraden?

Puppet ist eigentlich nur ein Dienstprogramm zur Konfigurationsverwaltung, kein Automatisierungstool. Wenn Sie eine ordnungsgemäße Automatisierung wünschen, sollten Sie sich mcollective ansehen, das als Drittanbieter-Tool begann und jetzt unter dem Dach von Puppetlabs geführt wurde. Da ich nicht mit mcollective gearbeitet habe, kann ich auch nicht wirklich sagen, wie gut es damit umgehen würde, aber ich verstehe, dass es am besten als willkürlicher Aufgabenausführungsmechanismus funktioniert, der nicht so gut funktioniert, wenn versucht wird, regelmäßig wiederholte Aufgaben zu erledigen .

Ich glaube, der beste Weg, dies zu tun, wäre, ein Skript und einen Prozess zu entwickeln, mit dem Sie aktualisieren möchten, und dann Puppet zu verwenden, um die Konfigurationen zu veröffentlichen. Stellen Sie sich also die folgenden Fragen.

1. Wie oft sollen die Maschinen aktualisiert werden?
2. Möchte ich, dass sie automatisch neu gestartet werden, wenn ein neuer Kernel installiert wird, oder möchte ich nur eine Benachrichtigung?
3. Sollen wir während der Updates spezielle Befehle ausführen?
4. Verfüge ich über genügend Systeme, sodass Updates gestaffelt erfolgen sollten?

Wenn Sie mit dem Aufbau der Konfiguration beginnen und diese Fragen beantworten, werden Sie wahrscheinlich mehr finden, das aus Ihrer spezifischen Umgebung herauskommt. Als konkretes Beispiel mache ich folgendes:

• Bei den meisten meiner Systeme erfolgen Updates einmal pro Woche per Cron-Job. Je nach Einsatzzweck und Umgebung kommen manche Systeme deutlich häufiger vor.
• Die meisten Systeme werden automatisch neu gestartet, bestimmte Systeme senden (je nach Zweck) eine E-Mail-Erinnerung zum Neustart. Dies wird durch einen Cron-Job gehandhabt, der die vmlinuz-Datei mit der höchsten Versionsnummer in /boot prüft gegen die Ausgabe von uname -r
• Nachdem ich durch das glibc-Update von RHEL 5.3->5.4 verbrannt wurde, stelle ich sicher, dass ich yum, dann glibc und dann alles andere aktualisiere.
• Da all dies von Cron-Jobs ausgeführt wird, habe ich zwischen jedem Yum-Lauf zufällige Schlafzeiten. Die Ausführung jedes Hosts kann zwischen 5 und 45 Minuten dauern, wodurch die Last angemessen verteilt wird.

Dies ist alles in zwei Dateien enthalten, die beiden Cron-Einträge (Updates und Kernel-Check), die in /etc/cron.d gespeichert sind und das Update-Skript. Ich mache das mit einem zunehmend chaotisch aussehenden Shell-Skript, das Befehlszeilenargumente verwendet, um das Update oder die Kernel-Prüfung durchzuführen und ob neu gestartet werden soll oder nicht. Puppet verwaltet dann diese beiden Dateien. Da Sie es sowohl mit rpm- als auch mit dpkg-basierten Systemen zu tun haben, würde ich wahrscheinlich entweder zwei Skripte erstellen oder separate do_update erstellen Funktionen für die beiden Varianten und werden jeweils mit einem anderen Befehlszeilenschalter aufgerufen. Dann können Sie entweder das richtige Skript herausschieben, indem Sie den operatingsystem überprüfen Fakt in Ihrer Dateideklaration oder erstellen Sie den Cron-Eintrag als Vorlage und verwenden Sie denselben Fakt, um zu entscheiden, welcher Schalter verwendet werden soll.

Mit einem gut getesteten Skript hat diese Methode sehr gut funktioniert. Gut genug, dass dieses Setup seit einigen Jahren erfolgreich verwendet wird, um Hunderte von Systemen zu verwalten. Wir werden gelegentlich Schluckauf sehen, wenn die Kernel-Paketierer anfangen, mehr und mehr Ebenen von Nebenversionen zu den Dateien hinzuzufügen und die Vergleichsroutine würgt.

Puppet selbst ist nicht das Werkzeug für diesen Job. Puppetlabs hat ein separates Tool namens MCollective, das Capistrano, Fabric und Func ähnelt.

Es gibt einen MCollecive-Agenten namens Packages Agent, der neben anderen Arten der Paketverwaltung Yum-Updates durchführen kann.

Sie haben erwähnt, dass ein Teil Ihrer Infrastruktur Ubuntu ausführt. Vielleicht sollten Sie sich das Paket für unbeaufsichtigte Upgrades ansehen.

Wenn Ihre Hosts RHEL-Hosts sind, sollten Sie sich RHN Satellite ansehen. Andernfalls ist Spacewalk möglicherweise einen Blick wert ** (siehe Hinweis unten). Sie sind darauf ausgelegt, lokale Kopien von Upstream-Paket-Repositories zu verwalten und die Verwaltung von Systemen zu erleichtern, die auf dem RHN Satellite-Server registriert sind. Sie können planen, dass Pakete zu einem bestimmten Zeitpunkt aktualisiert werden, oder wenn Sie OSAD aktiviert haben, können die Aktualisierungen zeitnah in der RHN Satellite/Spacewalk-Web-GUI geplant werden.

Einige Leute haben unten mit Puppet gepostet, es gibt einige Blogs und Webseiten darüber, wie man Puppet mit RHN Satellite integriert.

ALTERNATIV....

Wenn Sie mehr daran interessiert sind, sich ein aufstrebendes Projekt anzusehen, das schließlich RHN Satellite ersetzen wird, können Sie sich das Katello-Projekt ansehen. Katello enthält viele Projekte, die Teil von Red Hats CloudForms-Produkt sind, und soll der Upstream für den eventuellen Ersatz von RHN Satellite sein. Tatsächlich integriert Katello Puppet über Foreman. Katello langfristig zu betrachten, ist definitiv eine Überlegung wert gegenüber Spacewalk (aber noch nicht RHN Satellite aufgrund von Abonnement/Support).

** Ich habe in meinem Beitrag sowohl RHN Satellite als auch Spacewalk als RHN Satellite bezeichnet, um die Dinge einfacher zu machen. Der wirkliche Unterschied besteht darin, ob Sie RHEL-Systeme haben oder nicht. Wenn dies der Fall ist, benötigen Sie RHN Satellite, da es von RHN auf unterstützte Weise heruntergeladen werden kann. Spacewalk wäre für Benutzer, die einen Rebuild von RHEL oder Fedora verwenden (ich verstehe Spacewalk kann auch Debian unterstützen, aber ich persönlich weiß nicht viel darüber.) Daher kann es bei der Suche nach Informationen notwendig sein, nach Spacewalk und/oder RHN Satellite

zu suchen