5 Lektionen, die wir durch das Schreiben von über 300.000 Zeilen Infrastrukturcode gelernt haben

Eine kurze Meisterklasse zur Entwicklung von Infrastrukturcode

Im Oktober dieses Jahres hielt ich eine Präsentation auf der HashiConf 2018-Konferenz, auf der ich über fünf wichtige Lektionen sprach, die ich und meine Gruntwork-Kollegen beim Erstellen und Verwalten einer Bibliothek mit mehr als 300.000 Zeilen Infrastrukturcode gelernt haben, die von Hunderten von Unternehmen in Produktionssystemen verwendet werden. In dieser Veröffentlichung werde ich Videos und Folien aus der Präsentation sowie eine gekürzte Textversion der Beschreibung der 5 Hauptlektionen veröffentlichen.

Videos und Folien

Intro: DevOps jetzt in der Steinzeit

Trotz der Tatsache, dass die Branche voller modischer, fortschrittlicher Wörter ist: Kubernetes, Microservices, Service Grids, unveränderliche Infrastruktur, Big Data, Datenseen usw., ist die Realität, dass Sie sich nicht fühlen, wenn Sie in die Schaffung von Infrastruktur eintauchen so modisch und progressiv.

Persönlich erinnert mich DevOps mehr daran:

Die Schaffung einer Infrastruktur auf Produktionsebene ist schwierig. Das ist echter Stress. Und isst viel Zeit. Viel Zeit.

Es zeigt, wie viel Zeit für die Implementierung des nächsten Infrastrukturprojekts benötigt wird. Wir stützten uns auf empirische Daten, die wir im Rahmen der Arbeit mit Hunderten verschiedener Unternehmen gesammelt haben:

Lektion 1. Checkliste für die Fertigungsinfrastruktur

DevOps-Projekte dauern immer länger als erwartet. Immer. Warum so?
Der erste Grund ist ein Yak-Haarschnitt . Unten finden Sie eine anschauliche Darstellung dieses Phänomens (dies ist ein Auszug aus der Serie „Malcolm im Rampenlicht“).

Der zweite Grund ist, dass der Prozess der Erstellung einer Infrastruktur auf Produktionsebene (z. B. die Infrastruktur, auf die Sie Ihr Unternehmen setzen würden) aus Tausenden von Kleinteilen besteht. Die überwiegende Mehrheit der Entwickler kennt diese Details nicht. Daher vergessen Sie bei der Bewertung eines Projekts normalerweise viele kritische (und zeitaufwändige) Aufgaben.
Verwenden Sie die folgende Checkliste, um dies zu vermeiden, wenn Sie mit der Arbeit an einem neuen Abschnitt der Infrastruktur beginnen:

Nicht alle Elemente der Liste werden für jede einzelne Infrastruktur benötigt, aber Sie müssen bewusst und explizit dokumentieren, welche Elemente Sie implementiert haben und welche Sie überspringen möchten und warum.

Lektion 2. Toolbox

Wir listen die wichtigsten Tools auf, mit denen wir bei Gruntwork die Infrastruktur erstellen und verwalten (Stand 2018):

• Terraform . Wir verwenden Terraform, um die gesamte zugrunde liegende Infrastruktur bereitzustellen, einschließlich des Netzwerks, der Lastausgleichssubsysteme, der Datenbanken, der Tools zur Verwaltung von Benutzern und Berechtigungen sowie aller unserer Server.
• Packer . Wir verwenden Packer, um Images von virtuellen Maschinen zu konfigurieren und zu erstellen, die wir auf unseren Servern ausführen.
• Docker . Einige unserer Server bilden Cluster, in denen wir Anwendungen als Docker-Container ausführen. Für Docker-Cluster verwenden wir hauptsächlich die folgenden Tools: Kubernetes , ECS und Fargate .

Alle diese Tools sind nützlich, aber das ist nicht der Punkt. Sie müssen verstehen, dass einige Tools nicht ausreichen. Es ist auch notwendig, das Verhalten des Teams zu ändern.

Insbesondere helfen selbst die besten Tools der Welt Ihrem Team nicht, wenn sie sie nicht verwenden möchten oder nicht genügend Zeit haben, um zu lernen, wie sie verwendet werden. Die wichtigste Schlussfolgerung ist daher, dass die Verwendung von "Infrastruktur als Code" eine Investition ist, dh, dass bestimmte Anfangskosten von Ihnen verlangt werden. Wenn Sie mit Bedacht investieren, erhalten Sie langfristig hohe Dividenden.

Lektion 3. Große Module sind böse

Neulinge in der Anwendung von „Infrastruktur als Code“ definieren häufig ihre gesamte Infrastruktur für alle ihre Umgebungen (Entwicklungsumgebung, Zwischenumgebung, Produktionsumgebung usw.) in einer Datei oder einer Reihe von Dateien, die als Ganzes bereitgestellt werden. Vergebens.

Hier sind nur einige der Nachteile dieses Ansatzes:

• Niedrige Geschwindigkeit Wenn die gesamte Infrastruktur an einem Ort definiert ist, nimmt die Ausführung eines Befehls viel Zeit in Anspruch. Wir waren mit Situationen in Unternehmen konfrontiert, in denen das terraform plan Team 5-6 Minuten brauchte!
• Geringe Sicherheit . Wenn Sie die gesamte Infrastruktur gemeinsam verwalten, benötigen Sie zum Ändern von Berechtigungen Berechtigungen, um auf alles zugreifen zu können. Das heißt, fast jeder Benutzer sollte ein Administrator sein, und dies ist auch sehr unpraktisch.
• Hohe Risiken . Wenn Sie alle Eier in einen Korb legen, entsteht eine Situation, in der ein lokaler Fehler den Betrieb der gesamten Infrastruktur stören kann. Wenn Sie beispielsweise geringfügige Änderungen an einer externen Anwendung in der Entwicklungsumgebung vornehmen, kann ein einzelner Tippfehler oder ein falscher Befehl zum Löschen der Produktionsdatenbank führen.
• Es ist schwer zu verstehen . Je mehr Code an einer Stelle platziert wird, desto schwieriger ist es für eine Person, all dies zu verstehen. Und wenn all dies miteinander verbunden ist, werden unverständliche Teile einen grausamen Witz mit Ihnen spielen.
• Schwer zu testen . Das Testen des Infrastrukturcodes ist schwierig. Das Testen großer Mengen von Infrastrukturcode ist nahezu unmöglich. Wir werden später darauf zurückkommen.
• Es ist schwer zu analysieren . Die Ausgabe von Befehlen wie Terraform Plan wird unbrauchbar, da sich niemand die Mühe macht, Tausende von Zeilen anzuzeigen. Darüber hinaus wird die Code-Analyse unbrauchbar.

Kurz gesagt, Sie müssen Ihren Code aus kleinen, eigenständigen und wiederverwendbaren Verbundmodulen erstellen. Dies ist weder eine Neuigkeit noch eine Entdeckung. Sie haben dies tausendmal gehört, allerdings in etwas anderen Situationen:

"Mach eins und mach es gut" - Unix-Philosophie.
„Die erste Regel für Funktionen ist, dass sie klein sein sollten. Die zweite Regel besagt, dass Funktionen noch kleiner sein sollten. " - "Code reinigen"

Lektion 4. Infrastrukturcode ohne automatische Tests ist fehlerhaft

Wenn Ihr Infrastrukturcode keine automatisierten Tests enthält, funktioniert er nicht ordnungsgemäß. Du weißt es einfach noch nicht. Das Testen des Infrastrukturcodes ist jedoch schwierig. Sie haben weder einen „lokalen Host“ (z. B. können Sie keine virtuelle private AWS VPC-Cloud auf Ihrem Laptop bereitstellen) noch echte „Komponententests“ (z. B. können Sie Terraform-Code nicht von der „Außenwelt“ isolieren, da dies der Fall ist Zeiten und soll mit der Außenwelt kommunizieren).

Um den Infrastrukturcode korrekt zu testen, müssen Sie ihn normalerweise in einer realen Umgebung bereitstellen, eine reale Infrastruktur ausführen, überprüfen, ob der Code funktioniert, und ihn dann beschädigen (eine Beschreibung dieses Teststils finden Sie unter Terratest. Dies ist eine Open Source-Bibliothek, die Tools zum Testen von Terraform-Code enthält , Packer und Docker, die mit AWS-, GCP- und Kubernetes-APIs arbeiten und Shell-Befehle lokal und auf Remote-Servern über SSH ausführen, sowie viele andere Funktionen). Daher müssen Sie beim Testen der Infrastruktur die Bedingungen leicht neu definieren:

Unit-Tests stellen ein oder mehrere eng verwandte Infrastrukturmodule desselben Typs bereit und testen sie (z. B. Module für eine einzelne Datenbank).

Integrationstests stellen mehrere Infrastrukturmodule verschiedener Typen bereit und testen sie, um sicherzustellen, dass sie zusammenarbeiten (z. B. Datenbankmodule und Webdienstmodule).

End-to-End-Tests (e2e) stellen die gesamte Architektur bereit und testen sie.
Bitte beachten Sie, dass das Diagramm eine Pyramide ist: Wir haben viele Komponententests, weniger Integrationstests und sehr wenige e2e-Tests. Warum? Dies hängt von der Dauer der einzelnen Testarten ab:

Infrastrukturtests nehmen viel Zeit in Anspruch, insbesondere auf den oberen Ebenen der Pyramide, und natürlich möchten Sie ganz unten so viele Fehler wie möglich finden und beheben. Dazu benötigen Sie:

1. Erstellen Sie kleine und einfache eigenständige Module (siehe Lektion 3) und schreiben Sie viele Komponententests für sie - stellen Sie sicher, dass sie ordnungsgemäß funktionieren.
2. Kombinieren Sie diese kleinen, einfachen und bewährten Blöcke, um eine komplexere Infrastruktur zu erstellen, die Sie mit weniger Integrations- und E2E-Tests testen.

Lektion 5. Freigabeprozess

Um all das zusammenzufassen. So erstellen und verwalten Sie jetzt Ihre Infrastruktur:

• Überprüfen Sie die Checkliste für die Infrastruktur in Produktionsqualität und stellen Sie sicher, dass Sie in die richtige Richtung arbeiten.
• Definieren Sie Ihre „Infrastruktur als Code“ mit Tools wie Terraform, Packer und Docker. Stellen Sie sicher, dass Ihr Team genügend Zeit hat, um diese Tools zu erlernen (siehe DevOps-Ressourcen ).
• Erstellen Sie Code aus kleinen und eigenständigen Verbundmodulen (oder verwenden Sie Standardmodule aus der Infrastruktur als Codebibliothek ).
• Bereiten Sie mit Terratest automatisierte Tests für Ihre Module vor .
• Vervollständigen Sie die Anforderung, um Ihre Änderungen zur Überprüfung Ihres Codes aufzunehmen.
• Geben Sie die neue Version des Codes frei.
• Kopieren Sie die neue Version des Codes von einer Umgebung in eine andere.