Bewährte Methode zum Verwalten von Paketaktualisierungen für viele CentOS-Server

Im Rahmen meiner Arbeit verwalte ich einige Dutzend CentOS 5-Server, wobei ich Puppet als Haupteinrichtung verwende. Etwa die Hälfte unserer Server ist standardisiert für das Hosten verschiedener Django-Sites eingerichtet, während der Rest aus einer ganzen Menge von Anwendungen besteht.

Ich sortiere nach und nach unsere Hosting-Praktiken aus und bin jetzt so weit, dass ich herausfinden kann, wie Sicherheitsupdates auf Betriebssystemebene verwaltet werden. Ich bin vorsichtig, wenn nur ein Cron-Job erledigt wird, yum -y updateaber ich möchte auch nicht jeden Server rechtzeitig umrunden und jedes Paket mit verfügbaren Updates überprüfen müssen, da dies eine Weile dauern würde.

Ich frage mich also, ob es gute Abkürzungen oder Arbeitspraktiken gibt, die die damit verbundenen Risiken minimieren und den Zeitaufwand minimieren. Oder anders ausgedrückt: Gibt es Tools oder Praktiken, mit denen ein Großteil der Arbeit automatisiert werden kann, ohne die Kontrolle zu verlieren?

Schritte, für die ich mich bisher entschieden habe:

• Deaktivieren Sie alle Repositorys von Drittanbietern und richten Sie unser eigenes Repository ein, damit ich steuern kann, welche Updates dort durchgeführt werden.
• Wir haben Staging-Server für (die meisten) unserer Produktionsserver, auf denen ich Tests durchführen kann (aber wie viele Tests reichen aus?)

Beachten Sie auch, dass ich mir das yum-Sicherheits-Plugin angeschaut habe , es aber unter CentOS nicht funktioniert .

Wie verwalten Sie Updates für eine erhebliche Anzahl von CentOS-Servern, auf denen eine heterogene Reihe von Anwendungen ausgeführt wird?

In den meisten meiner Umgebungen handelt es sich normalerweise um ein Kickstart- und ein Post-Install-Skript, um das Hauptsystem auf den neuesten Stand zu bringen und es zu diesem Zeitpunkt zu aktualisieren. Normalerweise habe ich ein lokales Repo, das täglich oder wöchentlich mit einem CentOS-Spiegel synchronisiert wird. Ich neige dazu, das Kernel-Paket zum aktuellen Zeitpunkt der Installation einzufrieren und Pakete einzeln oder nach Bedarf zu aktualisieren. Oft haben meine Server Peripheriegeräte, deren Treiber eng mit den Kernelversionen verknüpft sind.

CentOS 5 ist soweit ausgereift, dass ständige Updates nicht mehr erforderlich sind. Denken Sie aber auch daran, dass CentOS 5 heruntergefahren wird. Die Aktualisierungsrate hat sich etwas verlangsamt, und die Art der Aktualisierungen entspricht eher den Bugfixes und betrifft weniger wichtige Funktionsänderungen.

In diesem speziellen Fall können Sie also als Erstes einen lokalen Mirror / Repo erstellen. Verwenden Sie Ihr vorhandenes Konfigurationsmanagement, um den Zugriff auf Repos von Drittanbietern zu steuern. Vielleicht planen Sie Richtlinien, um wichtige oder öffentlich zugängliche Dienste (ssh, http, ftp, dovecot usw.) zu aktualisieren. Alles andere muss getestet werden, aber ich habe das Gefühl, dass die meisten Umgebungen nicht mit vollständig aktualisierten / gepatchten Systemen ausgeführt werden.

Es gibt viele Tools, die dabei helfen können! Es ist allgemein das Paketsystem und welche Pakete wohin gehen, wird von der Konfigurationsverwaltung behandelt. Diese Tools decken jedoch in der Regel mehr als nur yum und die RPMs ab. Sie sparen Zeit und vermeiden viele, viele Kopfschmerzen!

Das Tool, mit dem ich am besten vertraut bin, ist Puppet, mit dem ich praktisch jede Konfiguration in meiner Umgebung verwalte. Hier sind einige Puppenbeispiele für die Verwaltung von Yum:

http://people.redhat.com/dlutter/puppet-app.html

Derzeit sind eine Reihe von Konfigurationsverwaltungstools verfügbar, die ziemlich große Benutzergruppen haben:

• Cfengine http://cfengine.com/cfengine3
• Puppet http://puppetlabs.com/puppet/puppet-difference/
• Chef http://wiki.opscode.com/display/chef/Home (Einige der Leute, die ich kenne, haben dies kürzlich implementiert und lieben es)

Die Implementierung in einer Umgebung verlängert Ihr Leben um Jahre. Es reduziert die Anzahl der Kopfschmerzen von schlecht konfigurierten Systemen und ermöglicht ein einfaches Upgraden / Aktualisieren. Die meisten dieser Tools bieten auch Funktionen auf Prüfebene, wodurch sich die Reparaturzeit für Konfigurationsfehler erheblich verkürzt.

In Bezug auf Ihre Frage zum Testen habe ich eine Staging-Umgebung verwendet, an die einige Kunden die Last weiterleiten (normalerweise Beta-Kunden oder eine kleine Teilmenge des Produktionsverkehrs). In der Regel lassen wir diesen Cluster mindestens ein paar Tage lang bis zu einer Woche lang (abhängig von der Schwere der Änderung) neuen Code ausführen, bevor wir ihn für die Produktion bereitstellen. Normalerweise funktioniert dieses Setup am besten, wenn Sie herausfinden, wie lange es dauert, bis die meisten Fehler erkannt werden. In stark genutzten Systemen kann dies eine Frage von Stunden sein. In den meisten Umgebungen, die ich gesehen habe, ist eine Woche lang genug, um auch seltene Fehler bei der Bereitstellung / Qualitätssicherung zu entdecken.

Ein wirklich wichtiger Teil beim Testen ist die Replikation von Daten / Nutzung. Sie haben erwähnt, dass Sie Staging-Versionen der meisten Ihrer Produktionshardware haben. Haben sie auch identische Kopien der Produktionsdaten? Können Sie eine der Produktionslasten dagegen wiederholen? Können Sie es mithilfe der Verkehrsspiegelung sogar zum Teil des Produktionsclusters machen? Dies wird in der Regel zu einem direkten Kompromiss zwischen der Menge an Ressourcen, die das Unternehmen für Tests / Qualitätssicherung bereit ist. Je mehr Tests durchgeführt werden, desto besser. Versuchen Sie, sich nicht (im Rahmen der Vernunft) einzuschränken und zu sehen, was das Unternehmen unterstützen wird (und finden Sie dann einen Weg, um 10% mehr zu erreichen).