Erkunden der Umgebungsbereitstellung
Angenommen, Sie haben jemals mitten in der Nacht einen Notruf für Support wegen eines abgestürzten erhalten.
In diesem Fall kennen Sie die Qualen des Suchens in mehreren Kalkulationstabellen oder sogar in Ihrem Gedächtnis, um die manuellen Schritte zum Einrichten eines neuen Computers abzurufen.
Hinzu kommt die Schwierigkeit, die Entwicklungs- und Produktionsumgebung konsistent zu halten.
Eine einfachere Möglichkeit, menschliche Fehler beim Initialisieren von Computern zu beseitigen, ist die Verwendung von Infrastructure-as-Code.
Manuelle Bereitstellung im Vergleich zu Infrastructure-as-Code
Eine gängige Analogie zum Verständnis der Unterschiede zwischen manueller Bereitstellung und Infrastructure-as-Code ist die Unterscheidung zwischen dem Besitz von Haustieren und Nutzvieh.
Wenn Sie Haustiere haben, geben Sie jedem einen eigenen Namen und betrachten sie als Individuen. Wenn einem Ihrer Haustiere etwas Schreckliches passiert, sind Sie geneigt, sich sehr darum zu sorgen.
Wenn Sie eine Viehherde haben, geben Sie den Tieren vielleicht noch Namen, aber Sie betrachten sie als Herde.
Im Hinblick auf die Infrastruktur kann ein manueller Bereitstellungsansatz schwerwiegende Auswirkungen haben, wenn ein einzelner Computer abstürzt und Sie ihn ersetzen müssen (Pets).
Wenn Sie einen Infrastructure-as-code-Ansatz einführen, können Sie einfacher einen anderen Computer bereitstellen, ohne Ihre gesamte Infrastruktur (Herde) zu beeinträchtigen, wenn ein einzelner Computer ausfällt.
Implementieren von Infrastructure-as-Code
Mit Infrastructure-as-Code erfassen Sie Ihre Umgebung (oder Umgebungen) in einer Textdatei (Skript oder Definition).
Ihre Datei kann beliebige Netzwerke, Server und andere Computingressourcen enthalten.
Sie können das Skript oder die Definitionsdatei in die Versionskontrolle einchecken und dann als Quelle zum Aktualisieren vorhandener Umgebungen oder zum Erstellen neuer Umgebungen verwenden.
Beispielsweise können Sie einen neuen Server hinzufügen, indem Sie die Textdatei bearbeiten und die Releasepipeline ausführen, anstatt sie remote in die Umgebung auszuführen und einen neuen Server manuell zu bereitstellen.
In der folgenden Tabelle sind die wesentlichen Unterschiede zwischen manueller Bereitstellung und Infrastructure-as-Code aufgeführt.
| Manuelle Bereitstellung | Infrastructure-as-Code |
|---|---|
| Snowflake-Server. | Ein konsistenter Server zwischen Umgebungen. |
| Bereitstellungsschritte variieren je nach Umgebung. | Umgebungen lassen sich problemlos erstellen oder skalieren. |
| Mehr Überprüfungsschritte und komplexe manuelle Prozesse. | Vollständig automatisierte Erstellung von Umgebungsupdates. |
| Erhöhter Dokumentationsaufwand, um Unterschiede zu berücksichtigen. | Übergang zu unveränderlicher Infrastruktur. |
| Bereitstellung an Wochenenden, um Zeit für die Wiederherstellung nach Fehlern zu gewähren. | Verwendung von Blau/Grün-Bereitstellungen. |
| Längeres Releaseintervall, um Probleme und lange Wochenenden zu minimieren. | Behandlung von Servern als Nutzvieh, nicht als Haustiere. |
Vorteile von Infrastructure-as-Code
Die folgende Liste enthält die Vorteile von Infrastructure-as-Code:
- Fördert die Überprüfung, indem es die Nachverfolgung vereinfacht, was wann und wie bereitgestellt wurde. (Mit anderen Worten: verbesserte Nachverfolgbarkeit).
- Stellt konsistente Umgebungen von Release zu Release bereit.
- Höhere Konsistenz über Entwicklungs-, Test- und Produktionsumgebungen hinweg.
- Automatisiert Auf- und Abskalierungsprozesse.
- Ermöglicht die Versionskontrolle für Konfigurationen.
- Stellt Code Review- und Komponententestfunktionen bereit, um die Verwaltung von Infrastrukturänderungen zu unterstützen.
- Verwendet unveränderliche Dienstprozesse. Das bedeutet: Wenn eine Änderung an einer Umgebung erforderlich ist, wird diese nicht aktualisiert, sondern es wird ein neuer Dienst bereitgestellt, und der alte wird deaktiviert.
- Ermöglicht Blau/Grün-Bereitstellungen. Diese Releasemethodik minimiert Ausfallzeiten, indem zwei identische Umgebungen vorhanden sind: Eine ist live, die andere nicht. Updates werden auf den Server angewendet, der nicht live ist. Nachdem die Tests überprüft und abgeschlossen wurden, wird sie gegen die anderen Liveserver ausgetauscht. Sie wird zur neuen Liveumgebung, und die vorherige Liveumgebung ist nicht mehr live.
- Behandelt Infrastruktur als flexible Ressource, die bei Bedarf bereitgestellt, ihre Bereitstellung aufgehoben und erneut bereitgestellt werden kann.