In unserem Unternehmen findet der Onboarding-Prozess des SRE-Teams statt. Ich bin von der Entwicklerseite in diese Geschichte eingestiegen. Dabei sind mir Gedanken und Einsichten gekommen, die ich gerne mit anderen Entwicklern teilen möchte. In diesem Artikel, der mehr einem Nachdenken gleicht, spreche ich darüber, was passiert, wie es passiert und wie wir alle weiterhin damit leben können.
Fortsetzung der Artikelreihe, die auf den Vorträgen unserer internen Veranstaltung basieren. :
2. Infrastruktur als Code. (Sie sind hier)
3. Generierung von Typescript-Verträgen aus C#-Modellen. (In Bearbeitung…)
4. Einführung in den Raft-Konsensalgorithmus. (In Bearbeitung…)
…
Wir haben beschlossen, ein SRE-Team zu bilden, indem wir die Ideen von aufgreifen. Wir haben Programmierer aus unseren eigenen Entwicklern rekrutiert und sie für mehrere Monate zur Weiterbildung geschickt.
Vor dem Team standen die folgenden Lernziele:
- Unsere Infrastruktur, die größtenteils in Microsoft Azure besteht, in Form von Code (Terraform und alles, was dazugehört) zu beschreiben.
- Die Entwickler im Umgang mit der Infrastruktur zu schulen.
- Die Entwickler auf den Bereitschaftsdienst vorzubereiten.
Wir führen das Konzept Infrastruktur als Code ein.
In einem normalen Weltmodell (klassische Verwaltung) befinden sich die Kenntnisse über die Infrastruktur an zwei Orten:
- Entweder in den Köpfen der Experten.
- Oder diese Informationen sind auf bestimmten Maschinen gespeichert, von denen einige den Experten bekannt sind. Doch es steht nicht fest, dass eine außenstehende Person (falls unser ganzes Team plötzlich stirbt) in der Lage ist herauszufinden, was und wie funktioniert. Auf der Maschine kann es viele Informationen geben: Zugänge, Cronjobs, das teilweise montierte (siehe ) Laufwerk und einfach eine endlose Liste dessen, was passieren kann. Es ist schwer zu verstehen, was tatsächlich passiert.
In beiden Fällen befinden wir uns in einer Falle und werden abhängig:
- entweder von einem Menschen, der sterblich ist und Krankheiten, Verliebtheiten, Stimmungsschwankungen und einfach banalen Kündigungen unterliegt;
- oder von einer physisch arbeitenden Maschine, die ebenfalls ausfällt, gestohlen wird, unerwartete Probleme und Unannehmlichkeiten bringt.
Es naht die Lösung, dass idealerweise alles in lesbaren, wartbaren, qualitativ hochwertig geschriebenen Code überführt werden sollte.
So ist Infrastruktur als Code (Infrastructure as Code – IaC) die Beschreibung der gesamten vorhandenen Infrastruktur in Form von Code sowie begleitende Mittel, um mit ihr zu arbeiten und sie in die reale Infrastruktur umzusetzen.
Warum alles in Code übersetzen?Menschen sind keine Maschinen. Sie können sich nicht alles merken. Die Reaktion eines Menschen und einer Maschine ist unterschiedlich. Alles Automatisierte arbeitet potenziell schneller als das, was ein Mensch tut. Das Wichtigste ist eine einzige Quelle der Wahrheit (single source of truth).
Woher kommen neue SRE-Ingenieure?Also, wir haben uns entschieden, neue SRE-Ingenieure einzustellen, aber woher bekommen wir sie? Das Buch mit den richtigen Antworten () sagt uns: von den Entwicklern. Schließlich arbeiten sie mit Code, und Sie erreichen den idealen Zustand.
Wir haben lange und ausgiebig gesucht, aber mussten leider feststellen, dass wir keinen einzigen passenden Kandidaten auf dem Arbeitsmarkt gefunden haben. Wir mussten unter unseren eigenen Leuten suchen.
Probleme bei Infrastructure as Code
Lassen Sie uns nun Beispiele dafür anschauen, wie Infrastruktur in Code implementiert werden kann. Der Code ist gut geschrieben, qualitativ hochwertig, mit Kommentaren und Einrückungen.
Beispielcode aus Terraform.
Beispielcode aus Ansible.
Meine Damen und Herren, aber wenn alles so einfach wäre! Wir leben in einer realen Welt, und sie ist immer bereit, Ihnen Überraschungen und Probleme zu präsentieren. Auch hier geht es nicht ohne diese.
1. Das erste Problem ist, dass IaC in den meisten Fällen eine Art DSL ist.
Ein DSL wiederum ist eine Beschreibung der Struktur. Genauer gesagt, das, was Sie haben sollten: JSON, YAML, Modifikationen von einigen großen Unternehmen, die ihr eigenes DSL entwickelt haben (in Terraform wird HCL verwendet).
Das Problem ist, dass es darin leicht an so vertrauten Dingen fehlen kann wie:
- Variablen;
- Bedingungen;
- Manchmal fehlen Kommentare, zum Beispiel sind sie in JSON standardmäßig nicht vorgesehen;
- Funktionen;
- und ich spreche noch nicht von solchen hochgradigen Dingen wie Klassen, Vererbung und dergleichen.
2. Das zweite Problem dieses Codes ist, dass es meistens eine heterogene Umgebung ist.Normalerweise arbeiten Sie mit C#, also mit einer Sprache, einem Stack, einem Ökosystem. Und hier haben Sie eine riesige Vielfalt an Technologien.
Eine durchaus realistische Situation, in der ein Bash-Skript mit Python einen Prozess startet, in den Json eingespeist wird. Sie analysieren ihn, danach generiert ein anderer Generator weitere 30 Dateien. Für all dies kommen Eingangsvariablen aus dem Azure Key Vault, die mit einem in Go geschriebenen Plugin für drone.io abgerufen werden, und diese Variablen laufen durch eine YAML-Datei, die aus einem Template-Generator namens jsonnet erstellt wurde. Es ist ziemlich schwierig, einen streng gut beschriebenen Code zu haben, wenn Sie eine so vielfältige Umgebung haben.
Traditionelle Entwicklung in einem einzigen Projekt erfolgt mit einer einzigen Sprache. Hier arbeiten wir jedoch mit vielen verschiedenen Sprachen.
3. Das dritte Problem ist das Tooling.Wir sind an großartige Editoren (Ms Visual Studio, Jetbrains Rider) gewöhnt, die alles für uns erledigen. Selbst wenn wir uns vertun, sagen sie uns, dass wir falsch liegen. Das scheint normal und natürlich zu sein.
Aber irgendwo in der Nähe gibt es VSCode, in dem es einige Plugins gibt, die irgendwie installiert werden, unterstützt oder nicht unterstützt werden. Neue Versionen kommen heraus und werden nicht unterstützt. Der banale Übergang zur Implementierung einer Funktion (auch wenn sie vorhanden ist) wird zu einem komplizierten und nicht trivialen Problem. Eine einfache Umbenennung einer Variablen ist ein Replace in einem Projekt aus einem Dutzend Dateien. Es ist Glück, wenn es das ersetzt, was ersetzt werden muss. Natürlich gibt es hier und da Syntaxhervorhebung, es gibt Autocompletion, und irgendwo gibt es Formatierung (das hat bei mir in Terraform unter Windows nicht geklappt).
Zum Zeitpunkt des Schreibens des Artikels wurde noch nicht für die Unterstützung von Version 0.12 veröffentlicht, obwohl sie bereits vor 3 Monaten veröffentlicht wurde.
Es ist an der Zeit, das zu vergessen …
- Debugging.
- Refactoring-Tool.
- Auto-Vervollständigung.
- Fehlererkennung beim Kompilieren.
Es ist lustig, aber das erhöht die Entwicklungszeit und die Anzahl der Fehler, die unvermeidlich auftreten.
Das Schrecklichste ist, dass wir nicht darüber nachdenken müssen, wie wir das Design planen, Dateien in Ordnern anordnen, den Code modularisieren und wartbar, lesbar usw. machen, sondern darüber, wie ich diesen Befehl korrekt schreibe, weil ich ihn irgendwie falsch geschrieben habe.
Als Anfänger versuchen Sie, Terraform zu erlernen, und die IDE hilft Ihnen dabei überhaupt nicht. Wenn es Dokumentation gibt – treten Sie ein, sehen Sie sich um. Aber wenn Sie in eine neue Programmiersprache einsteigen, würde die IDE Ihnen sagen, dass es solchen Typ gibt, aber diesen nicht. Zumindest auf der Ebene von int oder string. Das ist oft nützlich.
Und wie wäre es mit Tests?
Ihr fragt euch: „Wie sieht es mit Tests aus, meine Herren Programmierer?“ Ernsthafte Leute testen alles im Produktivbetrieb, und das ist hart. Hier ein Beispiel für einen Unit-Test für ein Terraform-Modul von der Webseite .
Sie haben eine gute Dokumentation. Microsoft hat mir schon immer mit ihrem Ansatz zur Dokumentation und Schulung gefallen. Aber man muss kein Uncle Bob sein, um zu verstehen, dass der Code hier nicht ideal ist. Achtet auf die Validierung, die nach rechts verschoben wurde.
Das Problem mit dem Unit-Test ist, dass wir die Korrektheit des JSON-Ausgangs überprüfen können. Ich habe 5 Parameter eingegeben, und ich bekam ein JSON mit 2000 Zeilen zurück. Ich kann analysieren, was hier passiert, das Testergebnis validieren...
Es ist schwierig, JSON in Go zu analysieren. Man muss jedoch in Go schreiben, weil Terraform in Go eine gute Praxis ist, um in der Sprache zu testen, in der man schreibt. Die Organisation des Codes selbst ist sehr schwach. Trotzdem ist dies die beste Bibliothek für Tests.
Selbst Microsoft schreibt seine Module und testet sie auf diese Weise. Natürlich ist das Open Source. Alles, worüber ich spreche, könnt ihr kommen und reparieren. Ich kann mich hinsetzen und alles in einer Woche reparieren, die VS-Code-Plugins open sourcen, Terraform aktualisieren und ein Plugin für Rider erstellen. Vielleicht schreibe ich ein paar Parser, füge Linter hinzu und kontribuiere zur Testbibliothek. Ich kann alles machen. Aber das sollte nicht mein Fokus sein.
Beste Praktiken für Infrastruktur als Code
Gehen wir weiter. Wenn es in IaC keine Tests gibt, wenn IDE und Tooling schlecht sind, dann sollten es zumindest beste Praktiken geben. Ich habe einfach Google Analytics aufgerufen und einen Vergleich von zwei Suchanfragen durchgeführt: Terraform Best Practices und C# Best Practices.
Was sehen wir? Eine gnadenlose Statistik, die nicht in unserem Sinne ist. Was die Menge an Material betrifft – dasselbe. In der C#-Entwicklung schwimmen wir förmlich in Materialien, wir haben herausragende Best Practices, Bücher von Experten sowie Bücher, die Bücher anderer Experten kritisieren. Ein Meer an offizieller Dokumentation, Artikeln, Schulungskursen und jetzt auch Open Source-Entwicklung.
Was die Suche nach IaC betrifft: Hier versucht ihr, Information Stück für Stück aus Vorträgen von Highload oder HashiConf, aus der offiziellen Dokumentation und zahlreichen Issues auf GitHub zu sammeln. Wie diese Module überhaupt verteilt werden, was man mit ihnen machen kann? Es scheint, dass das ein echtes Problem ist… Es gibt jedoch eine Community, meine Herren, in der jede Frage 10 Kommentare auf GitHub hervorruft. Aber das ist nicht sicher.
Leider fangen die Experten im Moment erst an, sich zu zeigen. Zurzeit sind es noch zu wenige. Und die Community befindet sich auf einem sehr frühen Stand.
Wohin geht das alles und was sollen wir tun
Man könnte alles hinschmeißen und zurück zu C# gehen, in die Welt der Rider. Aber das ist nicht die Frage. Warum sollten Sie sich überhaupt damit beschäftigen, wenn nicht um eine Lösung zu finden? Im Folgenden präsentiere ich meine subjektiven Schlussfolgerungen. Sie können mir in den Kommentaren widersprechen, ich fände das interessant.
Ich setze persönlich auf einige Dinge:
- Die Entwicklung in diesem Bereich passiert sehr schnell. Ich zeige das Diagramm der Anfragen zu DevOps.
Möglicherweise ist das Thema sehr angesagt, aber die Tatsache, dass das Feld wächst, gibt Hoffnung.Wenn etwas so schnell wächst, werden zwangsläufig kluge Köpfe auftauchen, die sagen, wie es richtig gemacht wird, und wie nicht. Die zunehmende Beliebtheit führt dazu, dass vielleicht jemand endlich die Zeit findet, ein Plugin für jsonnet für vscode zu schreiben, das den Zugang zur Implementierung einer Funktion ermöglicht, anstatt sie über ctrl+shift+f zu suchen. Wenn sich alles entwickelt, gibt es mehr Materialien. Derselbe neue Buchausgang von Google über SRE ist ein hervorragendes Beispiel dafür.
- Es gibt entwickelte Methoden und Praktiken in der gewöhnlichen Entwicklung, die wir hier erfolgreich anwenden können. Ja, es gibt Nuancen beim Testen und in einer heterogenen Umgebung sowie unzureichende Werkzeuge, aber eine riesige Anzahl von Praktiken wurde angesammelt, die nützlich sein und helfen können.
Ein banales Beispiel: gemeinsame Arbeit durch Pair Programming. Es hilft sehr, die Sache zu klären. Wenn du einen Nachbarn hast, der auch versucht, etwas zu verstehen, werdet ihr zusammen besser verstehen.
Das Verständnis davon, wie Refaktorisierung funktioniert, hilft sogar in einer solchen Situation, sie durchzuführen. Das bedeutet, dass du nicht alles auf einmal ändern musst, sondern den Namen ändern, dann die Position verändern, dann vielleicht einen bestimmten Teil hervorheben; oh, hier fehlen auch Kommentare.
Fazit
Obwohl meine Überlegungen pessimistisch erscheinen mögen, blicke ich hoffnungsvoll in die Zukunft und hoffe aufrichtig, dass es uns (und Ihnen) gelingen wird.
Die zweite Teil des Artikels wird bald veröffentlicht. Darin werde ich erläutern, wie wir versucht haben, agile Praktiken anzuwenden, um unseren Lernprozess und die Arbeit mit der Infrastruktur zu verbessern.
Quelle: habr.com
