Konsistenz bei Cloud-Bereitstellungen ist der Schlüssel!

Wir alle kennen das: Wir testen die Infrastructure-as-Code (IaC), die ein Kollege erst letzte Woche geschrieben hat, und müssen feststellen, dass unsere lokale Terraform-Version nicht mit ihrem Code kompatibel ist. ARRRGGGHHH! Es scheint, als gäbe es immer mehr Software-Tools, die heutzutage für den Betrieb und die Wartung der Infrastruktur erforderlich sind. Wir brauchen CLIs von Cloud-Anbietern, Ansible, Terraform, Kubectl und vieles, vieles mehr, denn die Liste wird immer länger. Außerdem gibt es überall Versionskonflikte. Viel Glück bei der Verwaltung von zwei verschiedenen Cloud-Umgebungen, wenn sie mit unterschiedlichen Versionen desselben Tools eingerichtet wurden! Deshalb habe ich letztes Jahr beschlossen, keine Tools mehr lokal zu installieren, sondern alles in Containern laufen zu lassen. Ich nenne diese Tooling-Container Toolboxen.
Jedes Mal, wenn ich ein neues Projekt bei einem Cloud-Anbieter beginne, stelle ich einen Tooling-Container zusammen, den ich für die Bereitstellung und Konfiguration der Infrastruktur verwende. In der Regel baue ich ihn aus einer Toolbox-Vorlage, die im Binx.io GitHub Repository gespeichert ist. Dies ist ein guter Ausgangspunkt, da ich eine vorhandene Dockerdatei für die Installation der gängigsten Tools verwenden kann. Um die Container so leicht wie möglich zu halten, installiere ich nur die Tools, die ich brauche. In der Regel ist dies also nur das CLI-Tool des von mir verwendeten Cloud-Anbieters und ein oder zwei andere Dinge. Diese Dockerdatei kann dann in ein Git-Repository gepusht und an alle Mitglieder des Teams verteilt werden, um sicherzustellen, dass wir alle die gleichen Tools und Versionen verwenden. Von hier aus müssen wir uns nur noch darum kümmern, wie wir uns beim Cloud-Anbieter authentifizieren.
Für die Authentifizierung wähle ich bei jedem Cloud-Anbieter einen anderen Ansatz. Für CI-Pipelines ist die Authentifizierung kein großes Problem, da Sie nur die wenigen benötigten Befehle codieren und die Geheimnisse als Umgebungsvariablen speichern müssen. Allerdings kann es ziemlich schnell langweilig werden, jedes Mal, wenn Sie die Toolbox starten, dieselben Befehle eingeben zu müssen. Um es einfacher zu machen, tue ich eines von zwei Dingen:

1. Nutzen Sie die Tatsache, dass CI-Tools in der Regel das --entrypoint Flag für einen Container überschreiben, so dass wir den Befehl ENTRYPOINT im Dockerfile verwenden können, um die für die Authentifizierung benötigten Zeilen zu skripten und dann die Geheimnisse als Umgebungsvariablen an den Container zu übergeben.
2. Schreiben Sie ein Shell-Skript, das die Zeilen ausführt, die für die Anmeldung beim Tooling-Container erforderlich sind, und geben Sie der Ausführung dieser Datei einen Alias, so dass sie schnell ausgeführt werden kann.
   Von diesen beiden Methoden bevorzuge ich die zweite, da Sie den Container so allgemein halten, dass andere ihn nutzen können. Außerdem kann ich mich so um die Einhängungen der Volumes kümmern, ohne jedes Mal hinzufügen zu müssen. Ich verwende das Format clientname-environment als Alias für mein Skript, damit ich genau weiß, welchen Tooling-Container ich ausführe und für wen. Bye, bye, Authentifizierungsprobleme!
   Jetzt kann ich meine Tooling-Container problemlos bei ihren jeweiligen Cloud-Umgebungen authentifizieren. Das Einzige, worüber ich mir noch Gedanken machen muss, ist die Versionsverwaltung. Es ist mittlerweile ein Klischee in der IT-Branche, aber Sie sollten sich nicht auf Container verlassen, die den Tag latest verwenden. Um mir die Verwaltung von Tooling-Versionen und die Aktualisierung der Container zu erleichtern, verwende ich eine GitOps-Strategie. Die Strategie ist einfach:
3. Für Features wird ein standardmäßiger Git-Fluss mit Zweigen verwendet, die nach der Genehmigung in den Master-Zweig zusammengeführt werden.
4. Eine CI-Pipeline-Datei wird verwendet, um das Image zu erstellen.
5. Jedes Mal, wenn ein Push auf den Master-Branch erfolgt, wird das resultierende Container-Image mit dem Tag latest in die Container-Registry gestellt.
6. Wenn ein Commit mit git --tag getaggt wurde, wird das resultierende Container-Image unter Verwendung der Tag-Referenz und des letzten Tags in die Container-Registry übertragen.
7. Die Änderungen zwischen den markierten Versionen werden in einer CHANGELOG.md dokumentiert.
   Jetzt muss ich meinem Team nur noch mitteilen, dass wir die Version 0.2.3 der Toolbox verwenden, und wir können alle sicher sein, dass wir und unsere CI-Pipelines mit denselben Versionen der jeweiligen Software arbeiten. Wie das alte Sprichwort sagt: "Konsistenz ist der Schlüssel"!