Frage Aktualisierung der Produktion Ubuntu-Boxen die dos and don'ts


Hin und wieder logge ich mich in production web / db / tools ein und sehe die typische Nachricht:

30 Pakete können aktualisiert werden. 16 Updates sind Sicherheitsupdates.

Meine Frage ist, wie behandeln Sie alle Updates auf Ihrer Produktion Ubuntu-Boxen? Automatisieren Sie diese Updates? Stellen Sie Ausfallzeiten für sie ein? Das Problem ist, dass Sie nie wissen, wenn ein Update etwas kaputt macht, wie zum Beispiel eine bestehende Konfigurationsdatei usw.

Der andere Teil dieses Problems ist es, mit Patches Schritt zu halten, "eine gute Sache", aber Patches werden fast täglich veröffentlicht. Wie viele geplante Ausfälle muss man machen, wenn jeden Tag ein neuer Sicherheitspatch verfügbar ist?

Ich denke, ein Thread auf Antworten, wie Sie Ihre Updates verwalten, wäre sehr nützlich.


24
2018-01-20 16:26


Ursprung




Antworten:


Es gibt nichts Besonderes beim Patchen von Ubuntu vs. Windows, RHEL, CentOS, SuSE, Debian usw.

Der grundlegende Geisteszustand, in dem Sie beim Entwerfen Ihres Patch-Verfahrens sein müssen, ist etwas anzunehmen werden brechen.

Einige der grundlegenden Richtlinien, die ich beim Entwerfen eines Patch-Setups verwende, sind:

  • Verwenden Sie immer ein lokales System, um intern in Ihrem Netzwerk zu zentralisieren, von wo die Patches installiert werden

Dies kann die Verwendung von WSUS oder Spiegelungen von <your_os_here> zu einer internen Patch-Management-Maschine. Ein bevorzugtes Tool, mit dem Sie den Status von Patches, die auf Ihren einzelnen Computern installiert sind, zentral abfragen und darüber informieren können.

  • Stellen Sie die Anlagen - wenn möglich - auf den Maschinen vor.

Wenn Patches verfügbar sind, werden sie vom zentralen Server auf die einzelnen Rechner kopiert. Dies ist wirklich nur eine Zeitersparnis, so dass Sie nicht warten müssen, bis sie AND installieren und installieren, Sie müssen lediglich die Installation während des Patch-Fensters starten.

  • Rufen Sie ein Ausfallfenster auf, um die Patches zu installieren. Möglicherweise müssen Sie einen Neustart durchführen, und wahrscheinlich wird etwas kaputt gehen. Stellen Sie sicher, dass die Interessenvertreter für diese Systeme wissen, dass Patches bereitgestellt werden. Bereite dich darauf vor, dass das "dies" nicht funktioniert.

In Übereinstimmung mit meiner grundlegenden Theorie, dass Patches Dinge brechen, stellen Sie sicher, dass Sie ein Ausfallfenster haben, um Patches lange genug anzuwenden, um kritische Probleme zu beheben und möglicherweise den Patch zurückzurollen. Sie brauchen nicht notwendigerweise Leute zu haben, die nach den Patches testen. Persönlich vertraue ich stark auf meine Überwachungssysteme, um mich wissen zu lassen, dass alles auf dem minimalen Niveau funktioniert, mit dem wir davonkommen können. Seien Sie aber auch darauf vorbereitet, dass bei der Arbeit an den Menschen kleine Probleme auftreten. Du solltest immer jemanden haben, der bereit ist, ans Telefon zu gehen - am besten nicht der Typ, der bis 3 Uhr morgens die Kästen gepatcht hat.

  • automatisiere so viel wie möglich

Wie alles andere in IT, Skript, Skript, dann skripte etwas mehr. Skript das Paket herunterladen, die Installation starten, den Spiegel. Im Grunde wollen Sie Patch-Fenster in eine Baby-Sitz-Aufgabe verwandeln, die nur einen Menschen braucht, falls etwas kaputt geht.

  • Habe jeden Monat mehrere Fenster

Dies gibt Ihnen die Möglichkeit, einige Server nicht zu patchen, wenn sie aus irgendeinem Grund nicht in der "vereinbarten Nacht" gepatcht werden können. Wenn Sie sie nicht in der Nacht 1 tun können, müssen sie nachts frei sein. 2. Sie können auch die Anzahl der gleichzeitig gepatchten Server beibehalten.

Am wichtigsten Bleib bei den Patches! Wenn Sie das nicht tun, werden Sie feststellen, dass Sie sehr große 10+ Stunden Patch-Fenster haben müssen, nur um zu dem Punkt zurückzukehren, an dem Sie gefangen sind. Wir stellen sogar noch mehr Punkte vor, bei denen die Dinge schiefgehen könnten, und machen es schwieriger, den Patch zu finden, der das verursacht hat.


Der andere Teil dieses Problems ist es, mit Patches Schritt zu halten, "eine gute Sache", aber Patches werden fast täglich veröffentlicht. Wie viele geplante Ausfälle muss man machen, wenn jeden Tag ein neuer Sicherheitspatch verfügbar ist?

Das Patchen eines Servers einmal im Monat oder einmal jeden zweiten Monat ist - IMHO - ein sehr erreichbares und akzeptables Ziel. Mehr als das, und Sie werden ständig Server patching, viel weniger und Sie beginnen in Situationen, wo Sie Hunderte von Patches haben, die pro Server angewendet werden müssen.

Für wie viele Fenster brauchst du einen Monat? Das hängt von Ihrer Umgebung ab. Wie viele Server haben Sie? Wie hoch ist die benötigte Zeit für Ihre Server?

Kleinere Umgebungen, die 9x5 sind, können wahrscheinlich mit einem Patch-Fenster pro Monat davonkommen. Große 24x7-Shops können zwei benötigen. Sehr große 24x7x365 müssen möglicherweise jede Woche ein rollendes Fenster haben, damit jede Woche ein anderer Satz von Servern gepatcht wird.

Finden Sie eine Frequenz, die für Sie und Ihre Umgebung funktioniert.

Eine Sache zu beachten ist, dass 100% aktuell ist ein unmöglich Ziel zu erreichen - lassen Sie sich von Ihrer Sicherheitsabteilung nicht anders informieren. Tun Sie Ihr Bestes, fallen Sie nicht zu weit zurück.


13
2018-01-20 16:55



Sie sagen, den Installationsstart automatisieren, obwohl dies der ursprünglichen Prämisse der Nachricht widerspricht, ein Ausfallfenster zu erhalten. Können Sie den Teil "Automatisieren der Installation starten" Ihrer Antwort näher erläutern? - imaginative
Sie automatisieren den Start der Installation, wenn Ihr Ausfall beginnt - Sie müssen sich nicht mehr in jede Box einloggen, um die Installation zu starten ... Ich werde versuchen, mir eine bessere Formulierung auszudenken - Zypher


Dinge die zu tun sind:

  1. Mach ein Backup
  2. Stellen Sie sicher, dass es sich um ein wiederherstellbares Backup handelt (obwohl diese beiden allgemeine Punkte sind)
  3. Versuchen Sie, den Traffic während des Upgrades von der Produktionsbox wegzuleiten.
  4. Versuchen Sie eine Out-of-Band-Zugriffsmethode, falls alles schief geht, KVM, serielle Konsole, lokaler Zugriff oder Remote-Hands.
  5. Testen Sie auf einem Server und stellen Sie sicher, dass alles funktioniert, bevor Sie Updates auf mehreren Servern bereitstellen
  6. Verwenden Sie Marionette, wenn Sie können, um sicherzustellen, dass die Versionsnummern auf mehreren Servern gleich sind. (Sie können damit auch Upgrades erzwingen)
  7. Auf einem Testserver, diff die Versionen der Konfigurationsdateien gegen die neuen (Update installiert), und stellen Sie sicher, nichts wird Dinge ernsthaft zu brechen. Ich erinnere mich, dass sich dpkg fragt, bevor ich neue Versionen installiere, die sich von den aktuell installierten Versionen unterscheiden.

Dinge zu vermeiden:

  1. Tägliche Updates um die Mittagszeit, oder 09:00 Uhr an einem Montagmorgen oder 17:00 Uhr an einem Freitagnachmittag! (Danke @ 3 Einfluss!)
  2. Upgrade von MySQL auf wirklich großen Datenbankservern (Neustart kann sehr lange dauern)
  3. Alle Ihre Server gleichzeitig ausführen (insbesondere Kernel)
  4. Alles tun, was / etc / networks ändern könnte (weil Sie die Verbindung verlieren könnten)
  5. Automatisierte Updates, die das oben beschriebene durchführen können, ohne dass Sie dabei sind, um alles zu überprüfen, sind in Ordnung.

6
2018-01-20 16:48



Du hast es vergessen ... tu es nie an einem Freitag am Ende eines Tages, außer du würdest dein Wochenende nicht wertschätzen :) - 3dinfluence


Ein weiterer wichtiger Punkt: Wenn Sie Windows gewohnt sind, werden Sie überrascht sein, dass die meisten Linux-Updates dies tun nicht erfordern Ausfallzeiten oder Neustart. Einige tun dies, beispielsweise Kernel-Updates. Updates, die einen Neustart oder eine Downtime erfordern, werden jedoch normalerweise als solche gekennzeichnet und können nach einem separaten Zeitplan ausgeführt werden.


4
2018-01-20 19:51



Bedenken Sie, dass ein Update eines laufenden Dienstes erfordert, dass der Dienst irgendwann gestoppt wird, damit Sie das neue erhalten. Trotzdem bekommst du nicht alle 10 Minuten die lästige Aufforderung :) - gbjbaanb
Das Dienstprogramm debian / ubuntu checkrestart Es ist sehr nützlich festzustellen, welche Prozesse aktualisiert wurden, aber immer noch gestoppt und neu gestartet werden müssen, um den neuen Code zu erhalten. - thomasrutter


Unsere Ubuntu-Maschinen laufen alle mit LTS-Releases.

Wir installieren einfach alle Updates automatisch - sicher, es ist nicht "Best Practice", aber wir sind ein relativ kleiner Laden und haben keine Test / Entwicklungs / Produktionsumgebung für jeden einzelnen Service. Die LTS Updates sind in der Regel ziemlich gut getestet und minimal invasiv.

Das Upgrade auf eine neue Version ist offensichtlich ein wenig komplizierter.


4
2018-01-25 19:03





Für ubuntu LTS-Systeme gehen wir wie folgt vor:

  1. Maitain eine Reihe von Akzeptanztests, die alle kritischen Pfade in unserer Software überprüfen
  2. Installieren Sie Sicherheitsupdates unbeaufsichtigt jeden Morgen um 4 Uhr morgens und führen Sie sofort die Abnahmetests durch. Wenn etwas fehlschlägt, wird ein Ingenieur ausgelagert und hat viel Zeit, um Dinge zu reparieren oder vor 9 Uhr zurückzusetzen. Das ist bisher nur zweimal in fünf Jahren passiert - LTS ist gut getestet und stabil.
  3. Wir implementieren unsere gesamte Infrastruktur jede Woche (auf DigitalOcean) automatisch mit Blue / Green-Bereitstellungen, die alle Pakete in ihrer neuesten Version halten. Wenn bei einer neuen Bereitstellung die Akzeptanztests fehlschlagen, wird die Bereitstellung angehalten, bis ein Techniker das Problem beheben kann.

Der nächste logische Schritt für uns besteht darin, In-Memory-Sitzungsinformationen zu eliminieren, sodass wir die Infrastruktur einfach jeden Tag oder sogar mehrmals täglich neu bereitstellen können, ohne Kunden zu beeinträchtigen und Schritt (2) zu vermeiden.

Dieser Ansatz ist wartungsarm und vermeidet Wartungsfenster vollständig.


2
2018-01-23 11:19



Ich arbeitete bei einer Firma, die einen ähnlichen Prozess machte; Unsere Muttergesellschaft hatte ein "komplettes und professionell entwickeltes System". Als die Sicherheitslücke "Heartbleed" bekannt wurde, wurden am nächsten Morgen mehrere hundert Server gepatcht. Die "sicheren" Prozesse des Mutterunternehmens führten dazu, dass sie ihre mehreren hundert Server abstürzten und die IT-Gruppe jeden Monat manuell eine Patch-Installation durchführen mussten. Komplexität ist der Feind von Sicherheit und Zuverlässigkeit :-) - Tom Harrison Jr


Eine Sache, die ich empfehlen würde, ist die Handhabung von Rollbacks von Paketen. Sehen Transaktionen und Rollback mit Debian für einen Vorschlag, wie man es macht, wie manchmal Sie eine schnelle Reparatur für ein Upgrade benötigen, das etwas bricht.


0
2018-01-25 19:50