Infrastruktur als Code: Erste Bekanntschaft

Unser Unternehmen ist dabei, das SRE-Team einzubeziehen. Ich bin von der Entwicklungsseite auf diese ganze Geschichte eingegangen. Dabei hatte ich Gedanken und Erkenntnisse, die ich mit anderen Entwicklern teilen möchte. In diesem Meditationsartikel spreche ich darüber, was passiert, wie es passiert und wie alle anderen damit leben können.

Fortsetzung einer Reihe von Artikeln, die auf Reden auf unserer internen DevForum- Veranstaltung basieren :

1. Schrödinger-Katze ohne Box: das Problem des Konsenses in verteilten Systemen.
2. Infrastruktur als Code. (Du bist hier)
3. Generierung von Typescript-Verträgen für c # -Modelle. (In Bearbeitung ...)
4. Wie Server miteinander übereinstimmen: Raft Distributed Consensus-Algorithmus.
5. Infrastruktur als Code: So überwinden Sie Probleme mit XP.
...

Wir haben beschlossen, das SRE-Team dazu zu bringen, Google Sre- Ideen umzusetzen . Wir haben Programmierer von ihren eigenen Entwicklern rekrutiert und sie für mehrere Monate zum Lernen geschickt.

Das Team stand vor folgenden Trainingsaufgaben:

• Beschreiben Sie unsere Infrastruktur, die sich hauptsächlich in Microsoft Azure befindet, in Form von Code (Terraform und alles, was es gibt).
• Bringen Sie Entwicklern den Umgang mit der Infrastruktur bei.
• Bereiten Sie Entwickler auf den Dienst vor.

Einführung in das Konzept der Infrastruktur als Code

Im üblichen Modell der Welt (klassische Verwaltung) gibt es zwei Kenntnisse über Infrastruktur:

1. Oder in Form von Wissen in den Köpfen von Experten.
2. Oder diese Informationen beziehen sich auf einige Schreibmaschinen, von denen einige Experten kennen. Es ist jedoch keine Tatsache, dass eine Person von außen (falls unser gesamtes Team plötzlich stirbt) herausfinden kann, was funktioniert und wie. Die Maschine kann viele Informationen enthalten: Zubehör, Kronenstecker, ein Laufwerk (siehe Festplattenmontage ) und nur eine endlose Liste der möglichen Ereignisse. Es ist schwer zu verstehen, was in der Realität passiert.

In beiden Fällen sind wir gefangen und werden abhängig:

• oder von einer Person, die sterblich ist, anfällig für Krankheiten, Verlieben, Stimmungsschwankungen und einfach banale Entlassungen;
• oder von einer physisch arbeitenden Maschine, die ebenfalls fällt, stiehlt, Unerwartetheit und Unannehmlichkeiten aufweist.

Es versteht sich von selbst, dass im Idealfall alles in lesbaren, unterstützten und qualitativ hochwertigen geschriebenen Code übersetzt werden sollte.

Die Infrastruktur als Code (Incfastructure as Code - IaC) beschreibt somit die gesamte verfügbare Infrastruktur in Form von Code sowie zugehörige Tools für die Arbeit damit und die Realisierung der tatsächlichen Infrastruktur daraus.

Infrastruktur als Codeprobleme

Schauen wir uns nun Beispiele an, wie die Infrastruktur in Code verkabelt werden kann. Der Code ist gut geschrieben, von hoher Qualität, mit Kommentaren und Einrückungen.

Beispielcode von Terraforma.



Beispielcode von Ansible.



Meine Herren, aber wenn alles so einfach wäre! Wir sind mit Ihnen in der realen Welt und er ist immer bereit, Sie zu überraschen, Überraschungen und Probleme zu präsentieren. Nicht ohne sie hier.

1. Das erste Problem ist, dass IaC in den meisten Fällen eine Art DSL ist.

Und DSL ist wiederum eine Beschreibung der Struktur. Genauer gesagt, was Sie haben sollten: Json, Yaml, Modifikationen einiger großer Unternehmen, die ihre eigene DSL entwickelt haben (HCL wird in der Terraform verwendet).

Das Problem ist, dass es darin leicht keine so vertrauten Dinge für uns gibt wie:

• Variablen
• Bedingungen;
• Irgendwo gibt es keine Kommentare, zum Beispiel in Json. Standardmäßig werden sie nicht bereitgestellt.
• Funktionen
• und ich spreche nicht über so hochrangige Dinge wie Klassen, Vererbung und all das.

2. Das zweite Problem mit diesem Code ist meistens eine heterogene Umgebung . Normalerweise sitzen Sie und arbeiten mit C #, d. H. mit einer Sprache, einem Stapel, einem Ökosystem. Und hier haben Sie eine Vielzahl von Technologien.

Es ist eine sehr reale Situation, wenn eine Bash mit Python einen Prozess startet, in dem Json ausrutscht. Sie analysieren es, dann generiert ein anderer Generator weitere 30 Dateien. Für all dies kommen die Eingabevariablen aus Azure Key Vault herein, die vom in Go geschriebenen Plugin für drone.io zusammengeführt werden, und diese Variablen durchlaufen yaml, das als Ergebnis der Generierung aus der jsonnet-Vorlagen-Engine erhalten wurde. In einer so vielfältigen Umgebung ist es ziemlich schwierig, streng gut beschriebenen Code zu haben.

Die traditionelle Entwicklung im Rahmen einer Aufgabe umfasst eine Sprache. Hier arbeiten wir mit einer Vielzahl von Sprachen.

3. Das dritte Problem ist das Tuling . Wir sind es gewohnt, Redakteure (Frau Visual Studio, Jetbrains Rider) zu kühlen, die alles für uns tun. Und selbst wenn wir langweilig sind, werden sie sagen, dass wir falsch liegen. Es scheint normal und natürlich zu sein.

Aber irgendwo in der Nähe gibt es einen VSCode, in dem einige Plugins installiert, unterstützt oder nicht unterstützt werden. Neue Versionen wurden veröffentlicht und nicht unterstützt. Ein banaler Übergang zur Implementierung einer Funktion (auch wenn sie existiert) wird zu einem komplexen und nicht trivialen Problem. Eine einfache Umbenennung einer Variablen ist eine Wiederholung in einem Projekt mit einem Dutzend Dateien. Es ist ein Glück, wenn es etwas ist, das repariert werden muss. Natürlich gibt es an einigen Stellen Hintergrundbeleuchtung, automatische Kompilierung und Formatierung (obwohl ich Windows in Terraform nicht gestartet habe).

Zum Zeitpunkt des Schreibens wurde das vscode-terraform-Plugin noch nicht veröffentlicht, um Version 0.12 zu unterstützen, obwohl es bereits seit 3 ​​Monaten veröffentlicht wurde.

Es ist Zeit zu vergessen ...

1. Debuggen
2. Refactoring-Tool.
3. Automatische Vervollständigung.
4. Kompilierungsfehler erkennen.

Es ist lustig, erhöht aber auch die Entwicklungszeit und die Anzahl der Fehler, die unvermeidlich auftreten.

Das Schlimmste ist, dass wir nicht darüber nachdenken müssen, wie man Dateien entwirft, in Ordner zerlegt, zerlegt, Code unterstützt, lesbar macht usw., sondern darüber, wie ich diesen Befehl richtig schreiben würde, weil ich ihn irgendwie falsch geschrieben habe .

Als Anfänger versuchen Sie, Terraformen zu lernen, und die IDE hilft Ihnen dabei überhaupt nicht. Wenn es Unterlagen gibt, gingen sie hinein und schauten. Wenn Sie jedoch eine neue Programmiersprache eingeben, schlägt die IDE vor, dass es einen solchen Typ gibt, aber keinen. Zumindest auf int- oder string-Ebene. Dies ist oft nützlich.

Aber was ist mit den Tests?

Sie fragen: "Was ist mit Tests, meine Programmierer?" Ernsthafte Leute testen alles an dem Produkt und es ist hart. Hier ist ein Beispiel für den Komponententest für das Terraform-Modul von der Microsoft- Website.



Sie haben eine gute Dokumentation. Ich habe Microsoft immer wegen seiner Herangehensweise an Dokumentation und Schulung gemocht. Aber Sie müssen nicht Onkel Bob sein, um zu verstehen, dass dies kein idealer Code ist. Beachten Sie die rechts gerenderte Validierung.

Das Problem mit dem Komponententest ist, dass Sie und ich die Richtigkeit der Ausgabe von Json überprüfen können. Ich warf 5 Parameter, ich bekam ein Json-Fußtuch für 2000 Zeilen. Ich kann analysieren, was hier passiert, das Testergebnis validieren ...

Es ist schwer, Json in Go zu analysieren. Und Sie müssen in Go schreiben, da Terraforms auf Go eine gute Übung für das sind, was Sie in der Sprache testen, in der Sie schreiben. Die Organisation des Codes ist sehr schwach. Gleichzeitig ist es die beste Bibliothek zum Testen.

Microsoft selbst schreibt seine Module und testet sie auf diese Weise. Dies ist natürlich Open Source. Alles, was ich über dich spreche, kann kommen und reparieren. Ich kann mich hinsetzen und alles in einer Woche reparieren, VS-Code-Plugins öffnen, Terraforms erstellen und ein Fahrer-Plugin erstellen. Schreiben Sie vielleicht ein paar Analysegeräte, Schrauben Sie Linters und kopieren Sie die Bibliothek zum Testen. Ich kann alles machen Das muss ich aber nicht machen.

Best Practices Infrastruktur als Code

Wir gehen weiter. Wenn es in IaC keine Tests gibt, die mit IDE und Optimierung schlecht sind, sollte es zumindest Best Practices geben. Ich bin gerade zu Google Analytics gegangen und habe zwei Suchanfragen verglichen: Terraform Best Practices und C # Best Practices.



Was sehen wir? Rücksichtslose Statistiken sind nicht zu unseren Gunsten. Durch die Menge an Material - das gleiche. In der C # -Entwicklung baden wir nur in Materialien, wir haben Super-Best Practices, es gibt Bücher, die von Experten geschrieben wurden, und auch Bücher, die von anderen Experten geschrieben wurden, die diese Bücher kritisieren. Das Meer von offiziellen Dokumentationen, Artikeln, Schulungen, jetzt auch Open Source-Entwicklung.

Was die IaC-Anfrage betrifft: Hier versuchen Sie Stück für Stück, die Informationen aus den Berichten der Hochlast oder HashiConf, aus der offiziellen Dokumentation und zahlreichen Problemen auf dem Github zu sammeln. Wie verbreiten Sie diese Module, was tun Sie damit? Es scheint, dass dies ein echtes Problem ist ... Es gibt eine Community, meine Herren, in der Sie für jede Frage 10 Kommentare zu einem Github erhalten. Das ist aber nicht richtig.

Leider tauchen zu diesem Zeitpunkt gerade erst Experten auf. Zwar gibt es zu wenige von ihnen. Und die Gemeinschaft selbst hängt auf der Ebene der Primordia.

Wo geht das alles hin und was zu tun

Sie können alles fallen lassen und zu C # zurückkehren, in die Welt eines Fahrers. Aber nein. Warum würden Sie das überhaupt tun, wenn Sie keine Lösung finden würden? Als nächstes gebe ich meine subjektiven Schlussfolgerungen. Sie können mit mir in den Kommentaren streiten, es wird interessant sein.

Persönlich habe ich ein paar Dinge angezogen:

1. Die Entwicklung in diesem Bereich ist sehr schnell. Ich gebe den Zeitplan für Anfragen für DevOps.
   
   
   
   Vielleicht ist das Thema Hype, aber die Tatsache, dass die Sphäre wächst, gibt uns Hoffnung.
   
   Wenn etwas so schnell wächst, werden sicherlich kluge Leute auftauchen, die sagen, wie es geht und wie nicht. Die zunehmende Beliebtheit führt dazu, dass möglicherweise jemand Zeit hat, das jsonnet-Plugin für vscode endgültig hinzuzufügen, sodass wir mit der Implementierung der Funktion fortfahren können, anstatt sie mit Strg + Umschalt + f zu suchen. Wenn sich alles entwickelt, erscheinen mehr Materialien. Das gleiche Google-Buch über SRE ist ein gutes Beispiel.
2. In der konventionellen Entwicklung gibt es entwickelte Techniken und Praktiken, die wir hier erfolgreich anwenden können. Ja, es gibt Nuancen beim Testen und in einer heterogenen Umgebung, unzureichende Abstimmung, aber es wurde eine große Anzahl von Methoden gesammelt, die sich als nützlich und hilfreich erweisen können.
   
   Ein triviales Beispiel: Zusammenarbeit durch Paarprogrammierung. Es hilft sehr, es herauszufinden. Wenn Sie einen Nachbarn in der Nähe haben, der ebenfalls versucht, etwas zu verstehen, werden Sie gemeinsam besser verstehen.
   
   Wenn Sie verstehen, wie Refactoring durchgeführt wird, können Sie es auch in einer solchen Situation erstellen. Das heißt, Sie können nicht alles auf einmal ändern, sondern die Benennung ändern, dann den Ort ändern und dann einen Teil hervorheben, oh, aber es gibt nicht genügend Kommentare.

Fazit

Trotz der Tatsache, dass meine Argumentation pessimistisch erscheint, freue ich mich auf die Zukunft und hoffe aufrichtig, dass wir (und Sie) Erfolg haben werden.

Als nächstes kommt der zweite Teil des Artikels . Darin spreche ich darüber, wie wir extreme Programmierpraktiken angewendet haben, um unseren Lernprozess zu verbessern und mit der Infrastruktur zu arbeiten.