Was sind unveränderliche Server?

Es gibt einige Fragen zu unveränderlichen Servern , wie zum Beispiel:

• Wie kann man das unveränderliche Servermuster implementieren, ohne die Post-Mortem-Fähigkeit zu verlieren?
• Welche Rolle spielen Configuration Management-Tools in unveränderlichen Infrastrukturen?

Es scheint offensichtlich, dass es mit Servern zu tun hat (der Teil, den ich bekomme). Und nur die Grammatik der unveränderlichen zu verdauen , würde ich denken, es hat etwas mit "nicht möglich, stumm zu schalten " zu tun . Wenn diese Vermutung nahe liegt, hätte ich keine Ahnung, was genau nicht stummgeschaltet werden kann (und ich bezweifle, dass es mit Soundkarten oder so etwas zu tun hat ...).

Meine Fragen :

• Was ist eigentlich ein "unveränderlicher Server" (im Kontext von DevOps)?
• Warum werden sie verwendet?

Unveränderlichkeit ist ein Begriff, der in Informatikkreisen häufig verwendet wird und sich im Allgemeinen auf "nach der Erstellung nicht mehr änderbar" zusammensetzt. Es wird normalerweise in Bezug auf Parallelität, Parallelität und Thread-Sicherheit verwendet.

Die Diskussion über dieses Thema ist faszinierend, kann aber im Allgemeinen auf Stack Overflow anderswo gefunden werden . Ich widersetze mich dem Drang, mich hier darauf einzulassen. Das Schlüsselkonzept ist "nach der Erstellung nicht änderbar".

Stellen Sie sich vor, Sie stellen unter Amazon einen Webdienst bereit, indem Sie ihn in ein Maschinen-Image (AMI - eine vorgefertigte Instanz, die Sie wiederholt erneut bereitstellen können) backen. Es stellt eine Verbindung zu einer Back-End-Datenbank über Anmeldeinformationen her, die beim Start aus einer Registrierung abgerufen werden. Es speichert Protokolle in einem Protokollierungstool wie Splunk. Für den normalen täglichen Betrieb gibt es keinen Grund, in diese Box zu sshen. Wenn Sie diesen Dienst skalieren müssen, erstellen Sie einfach weitere Instanzen dieser AMI und passen Sie einen Lastenausgleich an. Das Herunterfahren ist einfach die Zerstörung von Instanzen und Load Balancern.

Für den täglichen Betrieb hat dieses Feld keinen Grund, sich zu ändern . Wir können einfach mehr aus dem AMI herausholen.

Was passiert, wenn Sie einen Sicherheitspatch auf Betriebssystemebene bereitstellen müssen? Dies ist der Zeitpunkt, an dem Sie eine Entscheidung treffen müssen: Backen Sie ein neues AMI mit dem installierten Patch und stellen Sie alle laufenden Instanzen erneut bereit, oder sshen Sie in vorhandene Images und aktualisieren Sie den Patch? Es gibt viele Leute, die sich einfach nur einschleichen würden. Die Anhänger der "unveränderlichen Architektur" haben mich nur angeschrien, weil sie mir sogar nahegelegt haben, dass so etwas möglich ist.

Immutabilisten (wenn es ein solches Wort gibt) befürworten das Backen des neuen Ami. Sie befürworten, jeden Grund zu entfernen, um ssh jemals in eine Maschine zu integrieren. Sie befürworten, dass eine bestimmte Maschinenkonfiguration beim Start dieser Maschine erfolgen sollte, indem Konfigurationsdetails aus einem Repository abgerufen werden. Dies ist der ultimative Ausdruck für "Vieh, keine Haustiere".

Bei der unveränderlichen Architektur handelt es sich speziell um Maschinenkonfigurationen, die nach der Erstellung des Maschinenabbilds keinen Grund zur Änderung haben . Wenn sich etwas ändern muss, backen Sie ein neues Instanz-Image, fahren Sie das alte herunter und rufen Sie das neue auf.

Cloud-Technologien haben die Grenze zwischen Hardware und Software verschoben, so dass viele technische Abläufe, die früher ausschließlich der Hardware-Welt vorbehalten waren, ebenfalls Gegenstand der Software sind. Gemeinsam genutzte Computerumgebungen sind möglicherweise so alt wie Computer selbst ^1, aber Cloud-Technologien könnten sie bekannt machen, indem sie praktische und vertraute Metaphern für die Interaktion mit ihnen bieten: Cloud-Benutzer reservieren eine Instanz, einen vollständigen Computer oder ein Mimic, während ältere gemeinsam genutzte Computerumgebungen alle möglichen Einstellungen haben von unhandlichen Einschränkungen und "Ihr Programm muss auf diesen FTP-Server hochgeladen werden, wird in der Umgebung X (normalerweise mit einer 10-jährigen Version der Software, die Sie verwenden möchten) für höchstens 60 Minuten ausgeführt", könnte ehemaligen oder tatsächlichen Benutzern vertraut vorkommen von Rechenzentren.

Die praktische Folge dieser Verschiebung ist, dass Bereitstellungsverfahren nun durch Software-Artefakte dargestellt werden können. (Bei den Bereitstellungsverfahren handelt es sich um Anweisungen zum Einrichten einer Infrastruktur mit Datenbanken, Webservern oder was auch immer zu dieser Infrastruktur gehört, zusammen mit dem Netzwerk, in dem sie ausgeführt werden.) Ausgerichtet auf diese neuen Objektive sieht die manuelle Wartung von Servern so ziemlich so aus Manuelles Patchen des Produktionscodes - was nur in sehr seltenen Fällen wünschenswert ist. Die manuelle Wartung kann zu Abweichungen zwischen den in der Produktion laufenden Systemen und dem diese Systeme beschreibenden Code führen, was wiederum zu nicht reproduzierbarem Verhalten und unmöglicher Fehleranalyse, Behebung von Fehlern und anderen Katastrophen führt.

Das unveränderliche Servermuster ist nur die Transposition für Cloud-Vorgänge des oben genannten Mantras, wonach die manuelle Wartung laufender Programme vermieden werden sollte. Anstatt Server manuell zu konfigurieren, empfiehlt das unveränderliche Servermuster, diese Konfiguration zu automatisieren.

Implementierungsvarianten

Während die allgemeine Idee des unveränderlichen Servermusters ziemlich klar ist, gibt es viele Implementierungsnuancen. Beispielsweise schlagen einige Ansätze vor, Server überhaupt nicht zu aktualisieren, sondern stattdessen systematisch zu ersetzen . Dies liegt daran, dass das Aktualisieren zu einer Situation führt, in der eine Bereitstellung aus Servern besteht, die zu mehreren unterschiedlichen Zeitpunkten gestartet wurden und mehrere unterschiedliche Aktualisierungsprozesse durchlaufen haben, was eine inhomogene Gruppe von Servern impliziert und zu geringfügigen Unterschieden bei der Verarbeitung von Servern führen kann. Ein zweiter beliebter Variationspunkt ist die Disziplin bezüglich des Fernzugriffs auf die Server. Einige möchten den administrativen Remotezugriff auf Server vollständig deaktivieren, um zu gewährleisten, dass keine manuelle Wartung erfolgt.

Geschichtsnotiz

Nach meinem besten Wissen wurde der Begriff "unveränderlicher Server" von Kief Morris populär gemacht, aber die Idee selbst ist viel älter. Bereits 1999 verbreiteten FreeBSD-Jails die Idee, die Konfiguration von Disposable-Computing-Umgebungen vollständig zu automatisieren. So begann ich viele Jahre, das Muster „Unveränderlicher Server“ zu implementieren, bevor ich diesen Namen hörte, um diese Technik zu beschreiben.

Die Unveränderlichkeit als physikalische Unveränderlichkeit auf der Basis von CD-ROMs war auch eine beliebte Maßnahme zur Herstellung vertrauenswürdiger Computersysteme. Dies ist nicht mit dem unveränderlichen Servermuster zu verwechseln.

Unveränderliche Server sind Server, auf denen keine Änderungen vorgenommen werden können (im Idealfall außer Aktualisierungen und Sicherheitspatches). Anstatt die Software auf dem Server zu ändern, spoolen Sie einen neuen Server mit der gewünschten Software und beenden dann den älteren.

Mit diesem Konzept können Sie sicherstellen, dass Ihr Test-, Entwicklungs- und QS-Server identisch sind, was aus mehreren Gründen im Rahmen dieser Frage nicht relevant ist. Ein weiterer Vorteil unveränderlicher Server ist die Möglichkeit, die Anwendung auf einem älteren Server zurückzusetzen. Zum Beispiel muss ich K auf Produktionsserver 1 ändern, also spoole ich Server 2 und ändere K. Jetzt, nach 10 Minuten, stelle ich fest, dass K etwas mit meiner Anwendung kaputt gemacht hat, anstatt es sofort reparieren zu müssen, was Stunden dauern könnte und möglicherweise Ausfallzeiten für meine Kunden verursachen, leite ich den Datenverkehr zurück zu Server 1, während ich herausfinde, was mit 2 nicht stimmt.

Die beste Erklärung findet sich (wie immer) in Martin Fowlers Wiki-Artikel über unveränderliche Server .

Auf einem Server, sei es Hardware oder ein virtueller Server in der Cloud, wird normalerweise ein Betriebssystem und eine Anwendung ausgeführt.

Häufig erfordern die Anwendung und die Komponenten des Betriebssystems eine Konfiguration und Änderungen. Zum Beispiel Sicherheits-Patches, Bereitstellung neuer Versionen der Anwendung und Konfigurationsänderungen.

Wenn Sie bedenken, dass jede Änderung eine Veränderung des Serverstatus ist, wird der Begriff immutablesinnvoller. Dies bedeutet, dass auf einem solchen Server keine Mutationen zulässig sind.

Es ist häufig der Fall, wenn Personen an der Änderung des Serverstatus beteiligt sind - sei es die Bereitstellung einer Version oder eine Konfigurationsänderung oder ein Sicherheitspfad. Das Ergebnis ist ein Server, der nicht mehr wie erwartet funktioniert. Beispielsweise wird die Anwendung jetzt möglicherweise aufgrund einer Fehlkonfiguration usw. nicht ausgeführt.

Aus diesem Grund wird eine Vorgehensweise zum Erstellen unveränderlicher Server festgelegt. Bei unveränderlichen Servern wird ein Image eines Servers mit allen darin enthaltenen Konfigurationen, Patches und Anwendungsversionen erstellt. Dieses Server- Image kann dann zum Erstellen von Servern in verschiedenen Umgebungen verwendet werden.

Die erste Umgebung, in der ein solches Bild verwendet wird, ist eine Umgebung, in der das Bild getestet werden kann, um zu funktionieren. Etwaige Abweichungen werden erkannt, und nur dann ein solches Bild kann gefördert in einer Produktionsumgebung , um die Server zu ersetzen es mit der neuen Version (die Arbeit gut bekannt ist).

Sobald der Prozess des Erstellens der Images und des Promovierens der Images automatisiert ist, erhalten Sie einen sehr störungssicheren Prozess, bei dem nur sehr wenig menschlicher Aufwand anfällt und die Wahrscheinlichkeit sehr gering ist, dass ein Fehler in Ihren Service einfließt.

Häufig bieten unveränderliche Server nicht einmal die Möglichkeit, sie "einzugeben", beispielsweise fehlt der SSH-Server. In diesem Fall wird häufig auch die gesamte Metrologie eines Servers (Metriken, Protokolle) an Systeme außerhalb der Metrikdatenbank oder des Protokollaggregationsdienstes gesendet.

Bei Containern (siehe: Docker ) gibt es auch einen Prozess, um Bilder zu erstellen und diese dann in laufende Container zu spawnen. Diese werden häufig durch neue Container ersetzt, die auf aktualisierten Bildern basieren, und werden niemals mutiert. Das bedeutet, dass kein Mensch in den Container eintritt, um durch die Einführung einer Änderung "etwas zu reparieren".

Beginnen wir mit der Umkehrung, was ist ein veränderlicher Server?

Traditionell ist eine veränderbare Serverinfrastruktur eine Infrastruktur, die ständig geändert und aktualisiert wird. Sie können die Shell sichern, Pakete aktualisieren, konfigurieren, Dienste installieren und neuen Code bereitstellen. Dies macht es veränderbar, Sie können es verändern oder modifizieren.

Eine unveränderliche Infrastruktur ist ein weiteres Infrastrukturparadigma, bei dem Server nach ihrer Bereitstellung niemals mehr geändert werden. Wenn etwas aktualisiert, repariert oder auf irgendeine Weise geändert werden muss, werden neue Server bereitgestellt, die aus einem gemeinsamen Image mit den entsprechenden Änderungen erstellt wurden, um die alten zu ersetzen. Nach der Validierung werden sie verwendet und die alten außer Betrieb genommen.

Warum werden sie verwendet? Die Vorteile einer unveränderlichen Infrastruktur liegen in einer konsistenteren und zuverlässigeren Infrastruktur sowie in einem einfacheren und vorhersehbareren Bereitstellungsprozess. Außerdem werden häufige Serverprobleme in einer veränderlichen Infrastruktur wie Ausfallzeiten aufgrund von Serverabstürzen oder Ähnlichem gemindert.

Sie müssen jedoch wissen, wie Sie es mithilfe umfassender Bereitstellungsautomatisierungen und schneller Serverbereitstellung effizient bereitstellen können.

Stellen Sie sich vor, Sie gewinnen Bitcoin, Sie möchten keine Ausfallzeiten, wenn Ihr Server abstürzt. Sie müssen ihn so schnell wie möglich sichern, also sollte eine unveränderliche Infrastruktur die Lösung sein.