Sollten Sie automatische Updates ausführen

Ich verwende Produktions-Centos-Webserver. Ich möchte wissen, wie Aktualisierungen am besten ausgeführt werden. Soll ich das mit yum-cron oder yum-updatesd automatisieren? Oder besteht die Gefahr, dass Updates die Websites beschädigen, sodass es besser ist, auf einem Testserver zu aktualisieren und Updates dann wöchentlich manuell auszuführen?

Die Mehrheit der Server verwendet nur die offiziellen Repositorys, aber einige haben das atomare Repository für PHP-Module, die ansonsten nicht verfügbar sind. Was ist in diesem Fall am besten? kann ich yum so einstellen, dass nur Atomic für die PHP-Module verwendet wird? Ich möchte nicht, dass alles auf den neuesten Stand der Dinge in Atomic gebracht wird. Ich würde eher Centos (oder Red Hat) vertrauen, um meine Server stabil und sicher zu halten.

Beides hat Vor- und Nachteile, und Sie müssen Ihre Systemarchitektur unbedingt durcharbeiten, um herauszufinden, welcher Weg für Sie am besten geeignet ist. Unabhängig davon, welchen Weg Sie einschlagen, sollten Sie verstehen, warum Sie diese Methode gewählt haben und welche Nachteile sie haben, damit Sie sie ausgleichen können.

Hier sind einige Dinge zu beachten:

• Sicherheitsupdates sollten immer auf die eine oder andere Weise und eher früher als später angewendet werden. Wenn auf Ihrem Server aus irgendeinem Grund Sicherheitsupdates nicht rechtzeitig installiert werden, korrigieren Sie Ihre Sysadmin-Gewohnheiten.

• Distro-Updates sind normalerweise gut, besonders wenn sie aus offiziellen Quellen stammen. Wenn Sie sich nicht wohl fühlen, verwenden Sie möglicherweise nicht die beste Distribution für Ihre Anforderungen. Sie sollten eine Distribution verwenden, die Ihrer Methodik entspricht. Mit anderen Worten, eine, bei der Sie darauf vertrauen können, dass die Aktualisierungen in Ihrem besten Interesse sind. Wenn sie sich zu schnell bewegen oder Softwareänderungen vornehmen, die Ihre Inhalte beschädigen, sollten Sie wahrscheinlich eine andere Distribution verwenden.

• Aktualisierungen können Ihre Inhalte beschädigen. Ein Umstieg auf neuere Software kann Ihren Code beschädigen, wenn Sie veraltete Funktionen verwenden oder nur schlechte Inhalte geschrieben haben. Sie sollten eine Systemarchitektur in Betracht ziehen, mit der Sie Ihr Produkt auf Updates testen können, bevor Sie sie auf Produktionssystemen ausführen.

• Wenn Sie Auto-Update-Funktionen verwenden, sollten Sie immer die Möglichkeit haben, ein Rollback auf bekannte Arbeitskonfigurationen durchzuführen. Vollständige Systemschnappschüsse können lebensrettend sein, wenn ein Update Ihr Produkt auf einem Produktionssystem beschädigt.

Dies ist keine vollständige Liste, nur ein paar Dinge, die Sie zum Nachdenken anregen. Letztendlich ist dies keine Entscheidung, die andere für Sie treffen können. Du bist der Admin. Kennen Sie Ihre Systeme. Kenne deine Distribution.

Ich stimme zu 100% mit dem überein, was Caleb bereits gesagt hat. Einige weitere CentOS-spezifische Kerben von mir:

Die Distribution basiert auf RedHat und seinen Patches. Diese Patches wurden sehr gut getestet und in den letzten 4 Jahren, in denen CentOS 5 mit über 50 Servern verwendet wurde, gab es noch nie einen schlechten Patch.

ABER: Obwohl wir alle Patches täglich automatisch auf Server anwenden, auf denen nur Distributionssachen ausgeführt werden, starten wir Produktionsserver (nach dem Glibc- oder Kernel-Update) erst, nachdem unsere Testsysteme einige Tage in dieser Konfiguration ausgeführt wurden.

Für andere Repositorys spiegeln wir diese in ein Staging-Verzeichnis. Diese Patches werden zuerst auf Testserver angewendet. Wenn sich herausstellt, dass nichts kaputt geht, aktivieren wir das Staging-Verzeichnis und kopieren es in ein Produktions-Repository.

Das automatische Patchen hat den Nebeneffekt, dass gepatchte Komponenten häufig neu gestartet werden. Wenn Sie sie also nach dem Start falsch konfiguriert haben, schlägt der Neustart fehl.