Einführung
In einer traditionellen veränderlichen Serverinfrastruktur werden Server kontinuierlich aktualisiert und an Ort und Stelle geändert. Ingenieure und Administratoren, die mit dieser Art von Infrastruktur arbeiten, können SSH auf ihren Servern ausführen, Pakete manuell aktualisieren oder downgraden, Konfigurationsdateien auf Serverbasis optimieren und neuen Code direkt auf vorhandenen Servern bereitstellen. Mit anderen Worten, diese Server sind veränderlich. Sie können nach der Erstellung geändert werden. Infrastruktur, die aus veränderlichen Servern besteht, kann selbst als veränderlich, traditionell oder (abwertend) als handwerklich bezeichnet werden.
Einimmutable infrastructure ist ein weiteres Infrastrukturparadigma, bei dem Server nach ihrer Bereitstellung niemals 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 in Betrieb genommen und die alten außer Betrieb genommen.
Zu den Vorteilen einer unveränderlichen Infrastruktur zählen eine konsistentere und zuverlässigere Infrastruktur sowie ein einfacher und vorhersehbarerer Bereitstellungsprozess. Dadurch werden in veränderlichen Infrastrukturen häufig auftretende Probleme wie Konfigurationsdrift und Schneeflockenserver gemildert oder gänzlich vermieden. Die effiziente Nutzung umfasst jedoch häufig eine umfassende Automatisierung der Bereitstellung, eine schnelle Serverbereitstellung in einer Cloud-Computing-Umgebung sowie Lösungen für den Umgang mit statusbehafteten oder kurzlebigen Daten wie Protokollen.
Der Rest dieses Artikels wird:
-
Erläutern Sie die konzeptionellen und praktischen Unterschiede zwischen veränderlicher und unveränderlicher Infrastruktur
-
Beschreiben Sie die Vorteile einer unveränderlichen Infrastruktur und setzen Sie die Komplikationen in einen Kontext
-
Geben Sie einen allgemeinen Überblick über die Implementierungsdetails und die erforderlichen Komponenten für eine unveränderliche Infrastruktur
Unterschiede zwischen veränderlicher und unveränderlicher Infrastruktur
Der grundlegendste Unterschied zwischen veränderlicher und unveränderlicher Infrastruktur besteht in ihrer zentralen Politik: Die Komponenten der ersteren sollen nach der Bereitstellung geändert werden. Die Komponenten der letzteren sind so konstruiert, dass sie unverändert bleiben und letztendlich ausgetauscht werden. Dieses Lernprogramm konzentriert sich auf diese Komponenten als Server. Es gibt jedoch auch andere Möglichkeiten, eine unveränderliche Infrastruktur zu implementieren, z. B. bei Containern, bei denen dieselben übergeordneten Konzepte angewendet werden.
Im Detail gibt es sowohl praktische als auch konzeptionelle Unterschiede zwischen server-basierten veränderlichen und unveränderlichen Infrastrukturen.
Konzeptionell unterscheiden sich die beiden Arten von Infrastruktur in ihrem Ansatz, wie Server behandelt werden sollen (z. erstellt, gepflegt, aktualisiert, vernichtet). Dies wird häufig mit einer Analogie „Haustiere versus Vieh“ illustriert.
In der Praxis ist die veränderbare Infrastruktur ein viel älteres Infrastrukturparadigma vor den Kerntechnologien wie Virtualisierung und Cloud Computing, das unveränderliche Infrastrukturen möglich und praktisch macht. Wenn Sie diese Historie kennen, können Sie die konzeptionellen Unterschiede zwischen beiden und die Auswirkungen der Verwendung der einen oder anderen in der modernen Infrastruktur kontextualisieren.
In den nächsten beiden Abschnitten werden diese Unterschiede näher erläutert.
Praktische Unterschiede: Die Cloud umarmen
Bevor Virtualisierung und Cloud Computing möglich und allgemein verfügbar wurden, konzentrierte sich die Serverinfrastruktur auf physische Server. Die Erstellung dieser physischen Server war teuer und zeitaufwändig. Die Ersteinrichtung kann Tage oder Wochen dauern, da es lange gedauert hat, neue Hardware zu bestellen, die Maschine zu konfigurieren und sie dann an einemcolo oder einem ähnlichen Ort zu installieren.
Die veränderliche Infrastruktur hat hier ihren Ursprung. Da die Kosten für den Austausch eines Servers so hoch waren, war es am praktischsten, die Server, die Sie in Betrieb hatten, so lange wie möglich und mit so wenig Ausfallzeiten wie möglich zu verwenden. Dies bedeutete, dass bei regelmäßigen Bereitstellungen und Updates zahlreiche Änderungen vorgenommen wurden, aber auch bei Ad-hoc-Korrekturen, Optimierungen und Patches, wenn ein Fehler auftrat. Die Folge von häufigen manuellen Änderungen ist, dass sich Server nur schwer replizieren lassen und somit zu einer einzigartigen und fragilen Komponente der gesamten Infrastruktur werden.
Das Aufkommen vonvirtualization and on-demand/cloud computing war ein Wendepunkt in der Serverarchitektur. Virtuelle Server waren selbst im Maßstab günstiger und konnten in wenigen Minuten anstelle von Tagen oder Wochen erstellt und zerstört werden. Dies ermöglichte erstmals neue Bereitstellungsworkflows und Serververwaltungstechniken, z. B. die Verwendung vonconfiguration management odercloud APIs, um neue Server schnell, programmgesteuert und automatisch bereitzustellen. Die Geschwindigkeit und die geringen Kosten beim Erstellen neuer virtueller Server machen das Unveränderlichkeitsprinzip praktisch.
Traditionelle veränderbare Infrastrukturen wurden ursprünglich entwickelt, als die Verwendung von physischen Servern bestimmte, was in ihrer Verwaltung möglich war, und wurden im Laufe der Zeit mit der Verbesserung der Technologie weiterentwickelt. Das Paradigma, Server nach der Bereitstellung zu ändern, ist in der modernen Infrastruktur noch immer weit verbreitet. Im Gegensatz dazu wurden unveränderliche Infrastrukturen von Anfang an so konzipiert, dass sie auf virtualisierungsbasierten Technologien basieren, um Architekturkomponenten wie die virtuellen Server von Cloud Computing schnell bereitzustellen.
Konzeptionelle Unterschiede: Haustiere gegen Vieh, Schneeflocken gegen Phönixe
Die grundlegende konzeptionelle Änderung, die Cloud Computing vorantrieb, bestand darin, dass Server als verfügbar angesehen werden konnten. Es ist unpraktisch zu erwägen, physische Server zu verwerfen und zu ersetzen. Bei virtuellen Servern ist dies jedoch nicht nur möglich, sondern auch einfach und effizient.
Die Server in herkömmlichen veränderlichen Infrastrukturen waren unersetzbare, einzigartige Systeme, die jederzeit ausgeführt werden mussten. Auf diese Weise waren sie wie Haustiere: einzigartig, unnachahmlich und von Hand gepflegt. Ein Verlust könnte verheerend sein. Die Server in unveränderlichen Infrastrukturen hingegen sind verfügbar und können mit automatisierten Tools leicht repliziert oder skaliert werden. Auf diese Weise sind sie wie Vieh: eines von vielen in einer Herde, in der kein Individuum einzigartig oder unverzichtbar ist.
UmRandy Bias zu zitieren, wer zuerst die Haustiere angewendet hat vs. Rinderanalogie zum Cloud Computing:
Wie früher behandeln wir unsere Server wie Haustiere, zum Beispiel den Mailserver Bob. Wenn Bob untergeht, sind alle Hände an Deck. Der CEO kann seine E-Mail nicht erhalten und es ist das Ende der Welt. Auf die neue Art werden Server wie Rinder in einer Herde nummeriert. Zum Beispiel www001 bis www100. Wenn ein Server ausfällt, wird er zurückgenommen, abgeschossen und in der Leitung ersetzt.
Eine andere ähnliche Methode zur Veranschaulichung der Auswirkungen des Unterschieds zwischen der Behandlung von Servern besteht in den Konzepten von Snowflake-Servern und Phoenix-Servern.
Snowflake servers ähneln Haustieren. Hierbei handelt es sich um Server, die von Hand verwaltet, regelmäßig aktualisiert und optimiert werden, was zu einer einzigartigen Umgebung führt. Phoenix servers ähneln Rindern. Es handelt sich um Server, die immer von Grund auf neu erstellt werden und durch automatisierte Verfahren einfach wiederhergestellt werden können (oder aus der Asche aufsteigen).
Unveränderliche Infrastrukturen bestehen fast ausschließlich aus Vieh- oder Phönixservern, während veränderbare Infrastrukturen einige (oder viele) Haustiere oder Schneeflockenserver zulassen. Im nächsten Abschnitt werden die Auswirkungen von beidem erörtert.
Vorteile einer unveränderlichen Infrastruktur
Um die Vorteile unveränderlicher Infrastrukturen zu verstehen, müssen die Nachteile veränderlicher Infrastrukturen kontextualisiert werden.
Server in veränderlichen Infrastrukturen können unter Konfigurationsdrift leiden. Wenn dies nicht dokumentiert ist, führen spontane Änderungen dazu, dass die Serverkonfigurationen zunehmend voneinander und von der überprüften, genehmigten und ursprünglich bereitgestellten Konfiguration abweichen. Diese zunehmend schneeflockenähnlichen Server sind schwer zu reproduzieren und zu ersetzen, was das Skalieren und Wiederherstellen von Problemen erschwert. Selbst das Replizieren von Problemen zum Debuggen wird zu einer Herausforderung, da es schwierig ist, eine Staging-Umgebung zu erstellen, die der Produktionsumgebung entspricht.
Die Wichtigkeit oder Notwendigkeit der verschiedenen Konfigurationen eines Servers wird nach vielen manuellen Änderungen unklar. Daher können Aktualisierungen oder Änderungen unbeabsichtigte Nebenwirkungen haben. Selbst im besten Fall kann nicht garantiert werden, dass Änderungen an einem vorhandenen System vorgenommen werden. Daher können Bereitstellungen, die darauf angewiesen sind, fehlschlagen oder den Server in einen unbekannten Zustand versetzen.
Vor diesem Hintergrund sind die Hauptvorteile der Verwendung einer unveränderlichen Infrastruktur die Einfachheit, Zuverlässigkeit und Konsistenz der Bereitstellung, die letztendlich viele häufig auftretende Schwachstellen und Fehlerquellen minimieren oder beseitigen.
Bekanntermaßen fehlerfreier Serverstatus und weniger Bereitstellungsfehler
Alle Bereitstellungen in einer unveränderlichen Infrastruktur werden ausgeführt, indem neue Server basierend auf einem validierten und versionskontrollierten Image bereitgestellt werden. Infolgedessen hängen diese Bereitstellungen nicht vom vorherigen Status eines Servers ab und können daher nicht oder nur teilweise fehlschlagen.
Wenn neue Server bereitgestellt werden, können sie vor der Inbetriebnahme getestet werden. Dadurch wird der tatsächliche Bereitstellungsprozess auf ein einziges Update reduziert, um den neuen Server verfügbar zu machen, z. B. durch Aktualisieren eines Lastenausgleichs. Mit anderen Worten, Bereitstellungen werden zuatomic: Entweder werden sie erfolgreich abgeschlossen oder es ändert sich nichts.
Dies macht die Bereitstellung wesentlich zuverlässiger und stellt außerdem sicher, dass der Status jedes Servers in der Infrastruktur immer bekannt ist. Darüber hinaus erleichtert dieser Prozess die Implementierung vonblue-green deployment oderrolling releases, was keine Ausfallzeiten bedeutet.
Keine Konfigurationsdrift oder Schneeflockenserver
Alle Konfigurationsänderungen in einer unveränderlichen Infrastruktur werden implementiert, indem ein aktualisiertes Image in die Versionskontrolle mit Dokumentation eingecheckt und mithilfe eines automatisierten, einheitlichen Bereitstellungsprozesses Ersatzserver mit diesem Image bereitgestellt werden. Der Shell-Zugriff auf die Server ist manchmal vollständig eingeschränkt.
Auf diese Weise werden komplizierte oder schwer zu reproduzierende Setups vermieden, da das Risiko von Schneeflockenservern und Konfigurationsabweichungen vermieden wird. Dies verhindert auch Situationen, in denen jemand einen schlecht verstandenen Produktionsserver modifizieren muss, wodurch ein hohes Fehlerrisiko besteht und Ausfallzeiten oder unbeabsichtigtes Verhalten verursacht werden.
Konsistente Staging-Umgebungen und einfache horizontale Skalierung
Da alle Server denselben Erstellungsprozess verwenden, gibt es keine Bereitstellungskantenfälle. Dies verhindert unordentliche oder inkonsistente Staging-Umgebungen, indem das Duplizieren der Produktionsumgebung trivial gemacht wird, und vereinfachthorizontal scaling, indem Sie nahtlos mehr identische Server zu Ihrer Infrastruktur hinzufügen können.
Einfache Rollback- und Wiederherstellungsprozesse
Die Verwendung der Versionskontrolle zur Speicherung des Bildverlaufs hilft auch bei der Behebung von Produktionsproblemen. Der gleiche Prozess, der zum Bereitstellen neuer Abbilder verwendet wird, kann auch zum Zurücksetzen auf ältere Versionen verwendet werden, um die Ausfallsicherheit zu erhöhen und die Wiederherstellungszeit bei Ausfallzeiten zu verringern.
Details zur Implementierung der unveränderlichen Infrastruktur
Unveränderliche Infrastrukturen weisen einige Anforderungen und Details bei der Implementierung auf, insbesondere im Vergleich zu herkömmlichen veränderlichen Infrastrukturen.
Es ist technisch möglich, eine unveränderliche Infrastruktur unabhängig von Prinzipien der Automatisierung, Tools oder Softwareentwicklung zu implementieren, indem einfach das Schlüsselprinzip der Unveränderlichkeit eingehalten wird. Die folgenden Komponenten (ungefähr in Prioritätsreihenfolge) werden jedoch aus praktischen Gründen dringend empfohlen:
-
Servers in a cloud computing environment oder eine andere virtualisierte Umgebung (like containers, obwohl dies einige andere Anforderungen unten ändert). Der Schlüssel hierbei sind isolierte Instanzen mit schneller Bereitstellung von benutzerdefinierten Images sowie eine automatisierte Verwaltung für die Erstellung und Zerstörung über eine API oder ähnliches.
-
Full automation of your entire deployment pipeline, idealerweise einschließlich Bildvalidierung nach der Erstellung. Das Einrichten dieser Automatisierung erhöht die Vorlaufkosten für die Implementierung dieser Infrastruktur erheblich, ist jedoch ein einmaliger Aufwand, der sich schnell amortisiert.
-
Aservice-oriented architecture, die Ihre Infrastruktur in modulare, logisch diskrete Einheiten aufteilen, die über ein Netzwerk kommunizieren. Auf diese Weise können Sie die Cloud-Computing-Angebote insimilarly service-oriented (z. IaaS, PaaS).
-
Astateless, volatile application layer, einschließlich Ihrer unveränderlichen Server. Alles hier kann jederzeit schnell zerstört und wiederhergestellt werden (flüchtig), ohne dass Daten verloren gehen (zustandslos).
-
Apersistent data layer, einschließlich:
-
Centralized logging mit zusätzlichen Details zur Bereitstellung eines Servers, z. B. Image-Identifizierung über eine Version oder Git Commit SHA. Da Server in dieser Infrastruktur verfügbar sind (und häufig entsorgt werden), ermöglicht das externe Speichern von Protokollen und Metriken das Debuggen, auch wenn der Shell-Zugriff eingeschränkt ist oder nachdem ein Server zerstört wurde.
-
External data stores für Datenbanken und andere zustandsbehaftete oder kurzlebige Daten wieDBaaS/cloud databases undobject or block storage (entweder von der Cloud bereitgestellt oder selbst verwaltet). Sie können sich nicht auf den lokalen Speicher verlassen, wenn die Server flüchtig sind. Daher müssen Sie diese Daten an einem anderen Ort speichern.
-
-
Dedication from engineering and operations teams, um zusammenzuarbeiten und sich für den Ansatz zu engagieren. Trotz der Einfachheit des Endprodukts befinden sich in einer unveränderlichen Infrastruktur viele bewegliche Teile, von denen niemand etwas weiß. Darüber hinaus können einige Aspekte der Arbeit innerhalb dieser Infrastruktur neu oder außerhalb der Komfortzonen der Benutzer sein, z. B. das Debuggen oder Ausführen von einmaligen Aufgaben ohne Shell-Zugriff.
Es gibt viele verschiedene Möglichkeiten, um jede dieser Komponenten zu implementieren. Die Wahl hängt weitgehend von Ihren persönlichen Vorlieben und Ihrer Vertrautheit ab und davon, wie viel Ihrer Infrastruktur Sie selbst aufbauen möchten, anstatt sich auf einen kostenpflichtigen Service zu verlassen.
CI/CD tools kann ein guter Ausgangspunkt für die Automatisierung der Bereitstellungspipeline sein. Compose ist eine Option für eine DBaaS-Lösung. rsyslog undELK sind beliebte Optionen für die zentralisierte Protokollierung. Netflix’s Chaos Monkey, das Server in Ihrer Produktionsumgebung zufällig tötet, ist eine echte Feuerprobe für Ihre endgültige Einrichtung.
Fazit
Dieser Artikel befasste sich mit der unveränderlichen Infrastruktur, den konzeptionellen und praktischen Unterschieden zwischen ihr und der veränderlichen Infrastruktur älteren Stils, den Vorteilen ihrer Verwendung und Einzelheiten zu ihrer Implementierung.
Es kann schwierig sein zu wissen, ob oder wann Sie in Betracht ziehen sollten, auf eine unveränderliche Infrastruktur umzusteigen, und es gibt keinen klar definierten Grenz- oder Wendepunkt. Eine Möglichkeit besteht darin, einige der in diesem Artikel empfohlenen Entwurfspraktiken zu implementieren, z. B. die Konfigurationsverwaltung, auch wenn Sie noch in einer weitgehend veränderlichen Umgebung arbeiten. Dies wird in Zukunft den Übergang zur Unveränderlichkeit erleichtern.
Wenn Sie über eine Infrastruktur mit den meisten der oben genannten Komponenten verfügen und Probleme mit der Skalierung haben oder von der Unübersichtlichkeit Ihres Bereitstellungsprozesses frustriert sind, ist dies möglicherweise ein guter Zeitpunkt, um zu prüfen, wie eine Unveränderlichkeit Ihre Infrastruktur verbessern kann.