Yak shaving – Krzysztof stellt sich vor - TEAL Technology Consulting GmbH
2268
post-template-default,single,single-post,postid-2268,single-format-standard,bridge-core-2.0.2,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-19.0.2,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,wpb-js-composer js-comp-ver-6.0.5,vc_responsive

Yak shaving – Krzysztof stellt sich vor

Hallo, mein Name ist Krzysztof und ich bin der letzte Neuzugang im Teal-Team. Vor Teal war ich im Telekommunikationsbereich tätig, wo ich den Einkauf, das Projektmanagement, das Programmmanagement, die Technologiearchitektur in den Bereichen IP, IMS (Voice) und LTE (4G) und schließlich alles, was mit der Netzqualität zu tun hat, sowohl bei Daten- als auch bei Sprachdiensten, übernahm. Kürzlich war ich als Managementberater tätig, immer noch in der Telekommunikationsbranche, wobei sich der Schwerpunkt auf die Agilität von Unternehmen und die damit verbundene Softwareentwicklung verlagerte. Ich habe viel Zeit damit verbracht, zu erklären, warum Veränderungen, die auf die „alte“ Art und Weise durchgeführt wurden, heutzutage kaum noch sinnvoll sind, warum CI/CD wichtig ist, warum das Testen einmal im halben Jahr ein Fehler ist, warum Clouds und Automatisierung die Oberhand gewinnen und wie man sie in Unternehmen vorantreiben kann.

Ich habe all die interessanten Themen berührt, aber sehr selten so weit, dass ich das gefühlt habe:

https://twitter.com/rbranson/status/744634444380680193

Die Entscheidung, etwas zu ändern und nicht immer dasselbe zu tun, kam nach einem langen internen Kampf und einer langen Vorbereitung im Zusammenhang mit den Clouds: AWS:SA-Zertifizierung, GCP-Zertifizierungsvorbereitung, einschließlich Stunden in den QuikLabs mit Kubernetes und Cloud-Netzwerken (GCP-Zertifizierung steht noch aus).

Was kann man erwarten, wenn man nach Jahren in der Unternehmensberatung zu einem Technologieunternehmen kommt? Meine erste Aufgabe (und natürlich nicht nach einem Projekt zu suchen), war es, einen Blog-Post über unsere Arbeit an einem EASE-Training zu schreiben. Die Idee war, die von uns verwendeten Terraform- und PowerShell-Skripte zu vereinfachen und eine Beschreibung der Ideen dahinter hinzuzufügen. Was sich so einfach anhörte, endete in einem ständigen Strom von Yak-Shaving. Übrigens, wenn ihr nicht wisst, was „Yak-Shaving“ ist, empfehle ich, hier nachzuschauen:

https://blog.gruntwork.io/introducing-the-yak-shaving-series-247e7f20f81

Ich wollte zunächst, dass Terraform in meiner gemischten Windows-/Linux-Umgebung auf der Linux-Seite funktioniert. Aber leider hatte WSL 1 seltsame Probleme mit Dateiberechtigungen, wenn Visual Studio Code im WSL-Modus ausgeführt wurde. Nach einiger Suche stellte sich heraus, dass es sich um bekannte Probleme handelte. Die Lösung bestand entweder in der Verwendung von WSL2, was die Nutzung des Windows Insider-Programms erforderte, oder in einer ordnungsgemäßen Linux-Installation. Ich mag mein Windows/Linux, und nachdem ich ein wenig über meine Möglichkeiten gelesen hatte, die Maschine mit dem instabilen Windows zu installieren, entschied ich mich für Windows Insider. Nun, der Computer wurde nicht getoastet. Aber ich hatte trotzdem einen Herzinfarkt, als ich bemerkte, dass mein Hauptlaufwerk mit Veracrypt-verschlüsselten Daten in der Laufwerksliste fehlte und im Laufwerkspartitionsprogramm als unbrauchbar und unformatiert markiert wurde. Ich brauchte ein paar Stunden, um herauszufinden, dass nur ein Volume Header fehlte und dass Veracrypt das Problem beheben konnte.

Mit einem laufenden Visual Studio Code und Terraform begann ich, mit Code zu spielen. „Lasst uns das richtig machen und die Versionskontrolle durchführen“, sagten sie. Ich war früher ein sehr einfacher Git-Benutzer. Wenn ich die Chance habe, mich zu verbessern, sage ich nie „nein“ 😉. Eine Lektion über Git: Vergewissere dich, dass deine .gitignore vorhanden ist, BEVOR DU JEGLICHE Commits machst. Eine hilfreiche Quelle dafür ist: https://www.gitignore.io/. Ansonsten wirst du dich ein paar Stunden lang fragen, warum in aller Welt git versucht, „/.terraform/…/azure_plugin“ (110 MB) auf GitHub zu pushen, sogar NACH dem Hinzufügen einer .gitignore zum Verzeichnis, wobei du dem Verzeichnis ausdrücklich sagst, dass es dieses Verzeichnis und seinen gesamten Inhalt ignorieren soll. Falls du wie ich aus einer Zeit vor dem Schreiben dieses Textes bist und dich immer noch fragst, warum es das tut, liegt es daran, dass ich „git add .“ vor einem der früheren Commits hinzugefügt habe, als .gitignore weder im Index noch im Baum vorhanden war. Beim Push wird nacheinander in den Baum auf der anderen Seite (GitHub) übertragen, in der Reihenfolge der Commits…

Die Lösung bestand darin, diese Commits zu squashen und „git rm cached“ zu machen, um diese früheren Commits ohne .gitignore wieder rückgängig zu machen, um schließlich wieder zu commiten. Dann lernst du auf die harte Tour: „Es gibt drei Orte, an denen eine Datei sein kann – der Baum, der Index und die Arbeitskopie. Wenn du eine Datei nur zu einem Ordner hinzufügen willst, füge sie der Arbeitskopie hinzu. Wenn du etwas wie git add file tun willst, füge sie zum Index hinzu. Und wenn du sie übertragen willst, füge sie ebenfalls zum Baum hinzu.“ (Quelle: manojlds on stackoverflow)

Obwohl das Yak-Shaving gut läuft, konnte ich schließlich unser Terraform-Skript vereinfachen, das einen minimalen Ressourcensatz mit einem virtuellen Netzwerk, Subnetz, einer Schnittstelle sowie einer öffentlichen IP, VM und Sicherheitsregeln einrichtet. Das verbleibende Puzzle-Element bestand darin, Terraform dazu zu bringen, ein Skript innerhalb der VM auszuführen. Früher wählten wir für die Ausführung von PowerShell Azure Maschinenerweiterungen, wobei wir das Skript von GitHub übernahmen. Ich dachte an Möglichkeiten, es zu vereinfachen, so dass es etwas tut, ohne zu viel Text zu haben und den GitHub-Pull zu vermeiden. Ich begann, mit dem Skript zu spielen… Nein, lieber Yak, ich habe dich nicht vergessen. Ich bin genau hier…

Beginn eines einfachen Skripts:

#
"$(Get-Date) This is a test." | Out-File -FilePath "C:\Users\Public\TestFile.txt" -Append

Put in a key-value pair for the Azure Extension in JSON: "commandToExecute": "powershell.exe -ExecutionPolicy Unrestricted " $(Get-Date) This is a test. " | Out-File -FilePath "C:\Users\Public\TestFile.txt\" -Append",
#

Ausgabe:

#
azurerm_virtual_machine_extension.MYDEPLOY: "settings" contains an invalid JSON: invalid character '$' after object key:value pair
#

Hmm… Soll ich das „$“ leeren? 20 Minuten später war ich mir sicher, dass es nicht einmal auf der Liste der zu entfernenden Zeichen steht, da ich mich auf 3 verschiedene Quellen stützte. Alle Anführungszeichen sind weiß, während der Text dazwischen orange ist. Klammern sehen gut aus.  Was zum…? Anfängerfehler… Es sind mehrere Anführungszeichen gesetzt: „Key: Wert, Text, Wert, Text, Wert“, was nicht korrekt ist in JSON, aber da die Anzahl der Anführungszeichen korrekt ist, sieht alles gut aus. Nachdem ich das herausgefunden hatte, was eine Weile dauerte, fand ich einen Online-JSON-Formatprüfer, mit dem ich allen \ und “ entkommen konnte, ohne jedes Mal „terraform plan“ einzugeben.

Alles sauber. Leider baut Terraform den gesamten Stack zunächst 6 Minuten lang auf, nur um ohne Rückmeldung der VM stecken zu bleiben. Großartig. Wie kann ich diesen Zyklus verkürzen? Nachdem ich etwas mehr über Terraform gelesen/gehört habe, entscheide ich, dass die Module das sind, was ich brauche. Ich werde ein Modul machen, die Infra unter der Erweiterung bauen und später die Erweiterung so oft ausführen, wie ich will. Die große Erkenntnis war, als ich begriff, dass dies einfach NICHT die Art und Weise ist, wie Terraform funktioniert. Ich verwechselte die Beschreibung der Infra (alle „.tf“-Dateien, einschließlich der Modulbeschreibungen) mit ihrem Zustand (.tfstate).  Es gibt eine Methode, den Zustand mit „terraform state mv“ zu übertragen, aber das wird hier nicht wirklich benötigt… Als ich einmal mit der Automatisierung anfing, vergaß ich, dass ich Abstraktionen benutzte, die irgendwo in virtuelle (und manchmal auch physische) Ressourcen übersetzt werden. Erweiterungen sind in Azure verfügbar, und das Testen des Skripts ist so viel einfacher…

Also, 4 Tage nach dem Moment, in dem ich dachte, es würde „ein oder zwei Stunden“ dauern, kann ich sagen, dass ich sowohl mit der Aufgabe als auch mit dem frischgebackenen kurzhaarigen Yak fertig bin. Ich hoffe, ich habe dich wenigstens zum Lachen gebracht 😉

Bildquelle: pixabay

LETZTE BEITRÄGE