Unser Unternehmen ist dabei, ein SRE-Team einzustellen. Ich bin von der Entwicklungsseite her in die ganze Geschichte hineingekommen. Dabei sind mir Gedanken und Erkenntnisse entstanden, die ich mit anderen Entwicklern teilen möchte. In diesem Reflexionsartikel spreche ich darüber, was passiert, wie es passiert und wie jeder weiterhin damit leben kann.
Fortsetzung einer Reihe von Artikeln, die auf Reden bei unserer internen Veranstaltung basieren :
2. Infrastruktur als Code. (Sie sind hier)
3. Generierung von Typescript-Verträgen mithilfe von C#-Modellen. (Im Gange...)
4. Einführung in den Raft-Konsensalgorithmus. (Im Gange...)
...
Wir beschlossen, ein SRE-Team zu gründen und die Ideen umzusetzen . Sie rekrutierten Programmierer aus dem Kreis ihrer eigenen Entwickler und schickten sie für mehrere Monate zur Schulung.
Das Team hatte folgende Trainingsaufgaben:
- Beschreiben Sie unsere Infrastruktur, die größtenteils in Microsoft Azure in Form von Code vorliegt (Terraform und alles drumherum).
- Bringen Sie Entwicklern bei, wie man mit der Infrastruktur arbeitet.
- Bereiten Sie Entwickler auf den Einsatz vor.
Wir stellen das Konzept der Infrastruktur als Code vor
Im üblichen Weltmodell (klassische Verwaltung) ist Wissen über Infrastruktur an zwei Orten angesiedelt:
- Oder in Form von Wissen in den Köpfen von Experten.
- Oder diese Informationen stehen auf einigen Schreibmaschinen, die Experten teilweise bekannt sind. Aber es ist keine Tatsache, dass ein Außenstehender (für den Fall, dass unser gesamtes Team plötzlich stirbt) herausfinden kann, was funktioniert und wie es funktioniert. Auf einer Maschine können sich viele Informationen befinden: Zubehör, Cronjobs, eingeschüchtert (siehe. ) Festplatte und nur eine endlose Liste dessen, was passieren kann. Es ist schwer zu verstehen, was wirklich passiert.
In beiden Fällen geraten wir in die Falle, abhängig zu werden:
- oder von einer Person, die sterblich ist, anfällig für Krankheiten, Verliebtheiten, Stimmungsschwankungen und einfach banale Entlassungen;
- oder von einer physisch funktionierenden Maschine, die ebenfalls herunterfällt, gestohlen wird und Überraschungen und Unannehmlichkeiten mit sich bringt.
Es versteht sich von selbst, dass im Idealfall alles in für Menschen lesbaren, wartbaren und gut geschriebenen Code übersetzt werden sollte.
Somit ist Infrastruktur als Code (Incfastructure as Code – IaC) eine Beschreibung der gesamten vorhandenen Infrastruktur in Form von Code sowie zugehöriger Tools, um damit zu arbeiten und daraus eine echte Infrastruktur zu implementieren.
Warum alles in Code übersetzen?Menschen sind keine Maschinen. Sie können sich nicht an alles erinnern. Die Reaktion eines Menschen und einer Maschine ist unterschiedlich. Alles Automatisierte ist potenziell schneller als alles, was ein Mensch tut. Das Wichtigste ist eine einzige Quelle der Wahrheit.
Woher kommen neue SRE-Ingenieure?Also haben wir beschlossen, neue SRE-Ingenieure einzustellen, aber woher bekommen wir sie? Buch mit richtigen Antworten () verrät uns: von den Entwicklern. Schließlich arbeiten sie mit dem Code und Sie erreichen den Idealzustand.
Wir haben lange und intensiv auf dem Personalmarkt außerhalb unseres Unternehmens nach ihnen gesucht. Aber wir müssen zugeben, dass wir niemanden gefunden haben, der unseren Wünschen entsprach. Ich musste unter meinen eigenen Leuten suchen.
Probleme Infrastruktur als Code
Schauen wir uns nun Beispiele an, wie Infrastruktur in Code fest codiert werden kann. Der Code ist gut geschrieben, von hoher Qualität, mit Kommentaren und Einrückungen.
Beispielcode von Terraforma.
Beispielcode von Ansible.
Meine Herren, wenn es nur so einfach wäre! Wir befinden uns in der realen Welt und sie ist immer bereit, Sie zu überraschen, Ihnen Überraschungen und Probleme zu bereiten. Auch hier geht es nicht ohne sie.
1. Das erste Problem besteht darin, dass IaC in den meisten Fällen eine Art DSL ist.
Und DSL wiederum ist eine Beschreibung der Struktur. Genauer gesagt, was Sie haben sollten: Json, Yaml, Modifikationen einiger großer Unternehmen, die ihr eigenes DSL entwickelt haben (HCL wird in Terraform verwendet).
Das Problem besteht darin, dass es möglicherweise leicht solche vertrauten Dinge nicht enthält wie:
- Variablen;
- Bedingungen;
- Irgendwo gibt es keine Kommentare, zum Beispiel in Json, standardmäßig werden sie nicht bereitgestellt;
- Funktionen;
- Und ich spreche nicht einmal von so hochrangigen Dingen wie Klassen, Vererbung und all dem.
2. Das zweite Problem bei solchem Code besteht darin, dass es sich meist um eine heterogene Umgebung handelt. Normalerweise sitzt man da und arbeitet mit C#, d.h. mit einer Sprache, einem Stack, einem Ökosystem. Und hier gibt es eine riesige Vielfalt an Technologien.
Es ist eine sehr reale Situation, wenn Bash mit Python einen Prozess startet, in den Json eingefügt wird. Sie analysieren es, dann erzeugt ein anderer Generator weitere 30 Dateien. Für all dies werden Eingabevariablen von Azure Key Vault empfangen, die von einem in Go geschriebenen Plugin für Drone.io zusammengestellt werden, und diese Variablen durchlaufen Yaml, das als Ergebnis der Generierung aus der Jsonnet-Vorlagen-Engine generiert wurde. Es ist ziemlich schwierig, einen streng gut beschriebenen Code zu haben, wenn man eine so vielfältige Umgebung hat.
Die traditionelle Entwicklung im Rahmen einer Aufgabe geht mit einer Sprache einher. Hier arbeiten wir mit einer Vielzahl von Sprachen.
3. Das dritte Problem ist das Tuning. Wir sind es gewohnt, coole Editoren (Ms Visual Studio, Jetbrains Rider) zu verwenden, die alles für uns erledigen. Und selbst wenn wir dumm sind, werden sie sagen, dass wir falsch liegen. Es 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, unterstützt oder nicht unterstützt sind. Neue Versionen kamen heraus und wurden 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. Sie werden Glück haben, wenn er Ihnen das vermittelt, was Sie brauchen. Natürlich gibt es hier und da eine Hintergrundbeleuchtung, es gibt eine automatische Vervollständigung, irgendwo gibt es eine Formatierung (obwohl es bei mir in Terraform unter Windows nicht funktioniert hat).
Zum Zeitpunkt des Schreibens wurden noch nicht zur Unterstützung der Version 0.12 freigegeben, obwohl diese bereits seit drei Monaten veröffentlicht ist.
Es ist Zeit zu vergessen...
- Debuggen.
- Refactoring-Tool.
- Automatische Vervollständigung.
- Fehler beim Kompilieren erkennen.
Es ist lustig, aber dadurch verlängert sich auch die Entwicklungszeit und die Anzahl der Fehler, die zwangsläufig auftreten.
Das Schlimmste ist, dass wir gezwungen sind, nicht darüber nachzudenken, wie wir entwerfen, Dateien in Ordnern organisieren, zerlegen, den Code wartbar, lesbar machen usw., sondern darüber, wie ich diesen Befehl richtig schreiben kann, weil ich ihn irgendwie falsch geschrieben habe .
Als Anfänger versuchen Sie, Terraforms zu lernen, und die IDE hilft Ihnen überhaupt nicht. Wenn es Unterlagen gibt, gehen Sie hinein und schauen Sie nach. Wenn Sie jedoch eine neue Programmiersprache eingeben würden, würde Ihnen die IDE mitteilen, dass es einen solchen Typ gibt, aber so etwas gibt es nicht. Zumindest auf Int- oder String-Ebene. Dies ist oft nützlich.
Was ist mit den Tests?
Sie fragen: „Was ist mit den Tests, meine Herren Programmierer?“ Ernsthafte Leute testen alles in der Produktion, und das ist hart. Hier ist ein Beispiel für einen Unit-Test für ein Terraform-Modul von der Website .
Sie verfügen über eine gute Dokumentation. Ich mochte Microsoft schon immer wegen seines Ansatzes in Sachen Dokumentation und Schulung. Aber Sie müssen nicht Onkel Bob sein, um zu verstehen, dass dies kein perfekter Code ist. Beachten Sie die Validierung rechts.
Das Problem bei einem Unit-Test besteht darin, dass Sie und ich die Korrektheit der Json-Ausgabe überprüfen können. Ich gab 5 Parameter ein und bekam ein Json-Fußtuch mit 2000 Zeilen. Ich kann analysieren, was hier vor sich geht, Testergebnisse validieren ...
Es ist schwierig, Json in Go zu analysieren. Und Sie müssen in Go schreiben, denn Terraform in Go ist eine gute Praxis zum Testen in der Sprache, in der Sie schreiben. Die Organisation des Codes selbst ist sehr schwach. Gleichzeitig ist dies die beste Bibliothek zum Testen.
Microsoft selbst schreibt seine Module und testet sie auf diese Weise. Natürlich ist es Open Source. Alles, worüber ich spreche, können Sie kommen und reparieren. Ich kann mich hinsetzen und alles in einer Woche reparieren, Open-Source-VS-Code-Plugins, Terraforms, ein Plugin für den Fahrer erstellen. Schreiben Sie vielleicht ein paar Analysatoren, fügen Sie Linters hinzu und stellen Sie eine Bibliothek zum Testen bereit. Ich kann alles. Aber das ist nicht das, was ich tun sollte.
Best Practices: Infrastruktur als Code
Lass uns weitermachen. Wenn es in IaC keine Tests gibt, die IDE und das Tuning schlecht sind, dann sollte es zumindest Best Practices geben. Ich bin gerade zu Google Analytics gegangen und habe zwei Suchanfragen verglichen: Best Practices für Terraform und Best Practices für C#.
Was sehen wir? Rücksichtslose Statistiken sind nicht zu unseren Gunsten. Die Materialmenge ist gleich. In der C#-Entwicklung wimmelt es nur so von Materialien, wir haben erstklassige Best Practices, es gibt Bücher, die von Experten geschrieben wurden, und auch Bücher, die über Bücher von anderen Experten geschrieben wurden, die diese Bücher kritisieren. Ein Meer offizieller Dokumentationen, Artikel, Schulungen und jetzt auch Open-Source-Entwicklung.
Was die IaC-Anfrage betrifft: Hier versuchen Sie, nach und nach Informationen aus Highload- oder HashiConf-Berichten, aus offiziellen Dokumentationen und zahlreichen Ausgaben auf Github zu sammeln. Wie verteilt man diese Module im Allgemeinen und was macht man damit? Es scheint, dass dies ein echtes Problem ist ... Es gibt eine Community, meine Herren, in der Sie für jede Frage 10 Kommentare auf Github erhalten. Aber genau das ist es nicht.
Leider fangen Experten derzeit gerade erst an, sich zu profilieren. Bisher gibt es zu wenige davon. Und die Community selbst hält sich auf rudimentärer Ebene auf.
Wohin führt das alles und was ist zu tun?
Sie können alles fallen lassen und zu C# zurückkehren, in die Welt des Fahrers. Aber nein. Warum sollten Sie sich überhaupt die Mühe machen, dies zu tun, wenn Sie keine Lösung finden können? Nachfolgend präsentiere ich meine subjektiven Schlussfolgerungen. Sie können in den Kommentaren mit mir darüber streiten, es wird interessant sein.
Persönlich wette ich auf ein paar Dinge:
- Die Entwicklung in diesem Bereich geht sehr schnell voran. Hier ist ein Zeitplan für Anfragen für DevOps.
Das Thema mag ein Hype sein, aber allein die Tatsache, dass die Sphäre wächst, gibt Anlass zur Hoffnung.Wenn etwas so schnell wächst, werden auf jeden Fall kluge Leute auftauchen, die Ihnen sagen, was Sie tun und was nicht. Die zunehmende Beliebtheit führt dazu, dass vielleicht jemand Zeit hat, endlich ein Plugin für vscode zu jsonnet hinzuzufügen, das es Ihnen ermöglicht, mit der Implementierung der Funktion fortzufahren, anstatt mit Strg+Umschalt+F danach zu suchen. Während sich die Dinge weiterentwickeln, erscheinen mehr Materialien. Die Veröffentlichung eines Buches von Google über SRE ist ein hervorragendes Beispiel dafür.
- In der konventionellen Entwicklung gibt es entwickelte Techniken und Praktiken, die wir hier erfolgreich anwenden können. Ja, es gibt Nuancen beim Testen und eine heterogene Umgebung, unzureichende Tools, aber es hat sich eine große Anzahl von Praktiken angesammelt, die nützlich und hilfreich sein 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 es gemeinsam besser verstehen.
Zu verstehen, wie Refactoring durchgeführt wird, hilft dabei, es auch in einer solchen Situation durchzuführen. Das heißt, Sie können nicht alles auf einmal ändern, sondern die Benennung ändern, dann den Ort ändern, dann können Sie einen Teil hervorheben, oh, aber es gibt hier nicht genügend Kommentare.
Abschluss
Auch wenn meine Argumentation pessimistisch erscheinen mag, blicke ich hoffnungsvoll in die Zukunft und hoffe aufrichtig, dass für uns (und Sie) alles gut wird.
Als nächstes wird der zweite Teil des Artikels vorbereitet. Darin werde ich darüber sprechen, wie wir versucht haben, agile Entwicklungspraktiken zu nutzen, um unseren Lernprozess und die Arbeit mit der Infrastruktur zu verbessern.
Source: habr.com