Unser Unternehmen bietet ein breites Spektrum an IT-Dienstleistungen für Kunden an. Um die bestmögliche Qualität zu gewährleisten, verlassen wir uns in hohem Maße auf Automatisierung, insbesondere auf Red Hat Ansible. In diesem Blogbeitrag sehen wir uns an, wie unser Workflow bei der Automatisierung mit Ansible aussieht und welche Tools wir dabei einsetzen, um eine zuverlässige Automatisierung zu gewährleisten.
Unser DevOps-Prozess und warum wir uns für Ansible entschieden haben
Ich bin Systemarchitekt in einer unserer Betriebsabteilungen, die die Infrastruktur, das Management und das Hosting der Anwendungen unserer Kunden bereitstellt. Ich versuche, Lösungen zu entwickeln, um unsere Arbeit für alle unsere Betriebsteams zu verbessern und zu automatisieren. Ansible ist eines der Tools, auf die wir uns bei unserer Arbeit stark verlassen.
Da die meisten der von uns verwendeten Tools quelloffen sind, versuche ich, alle unsere Tools ebenfalls als Open Source zu veröffentlichen. Sie sind für eine breite Palette von Kundenkonfigurationen gedacht, so dass ihr Code recht komplex werden kann. Ich muss mich daher auf die Code-Beiträge meiner Kollegen und anderer Personen verlassen können. Um dies zu vereinfachen, wird der gesamte Code auf GitHub gehostet.
Wir setzen stark auf Standardisierung und Automatisierung, um neue Beiträge, Fehlerbehebungen und Unterstützung für neue Betriebssysteme oder Tools zu testen.
Werkzeuge zur Aufrechterhaltung der Codequalität
Glücklicherweise gibt es in der Ansible-Welt eine breite Palette von Tools, mit denen wir unsere Änderungen testen und sicherstellen können, dass der Code von hoher Qualität ist.
Ansible Lint
Das erste Tool ist Ansible Lint, ein Befehlszeilen-Programm zum Linting von Playbooks, Rollen und Sammlungen. Sein Hauptziel ist es, bewährte Praktiken, Muster und Verhaltensweisen zu fördern und gleichzeitig häufige Fallstricke zu vermeiden, die leicht zu Fehlern führen oder die Wartung des Codes erschweren können. Ansible Lint kann über die Befehlszeile ausgeführt werden, lässt sich aber heutzutage auch über das Language Server Protocol (LSP) in die meisten IDEs integrieren. LSPs bieten Funktionen wie automatische Vervollständigung und Codehinweise direkt in der IDE. Sie werden von IDEs wie VSCode und IntelliJ, aber auch von Neovim unterstützt. Ich bin ein Fan von Neovim! Wenn ich also eine Datei mit Ansible-Code öffne, liefert die LSP automatisch Hinweise von ansible-lint, was verbessert werden könnte. Wenn ich neuen Ansible-Code schreibe, vervollständigt das LSP hilfsbereit automatisch die Ansible-Parameter und ihre Werte, so dass ich nicht raten muss, welche Parameter von dem Modul unterstützt werden.
Steampunk Spotter
Ich hatte kürzlich das Vergnügen, Steampunk Spotter zu testen, ein neues Ansible-Playbook-Scan-Tool. Falls ihr noch nichts davon gehört habt: es handelt sich um eine Software, das Ansible Playbooks scannt, analysiert und Empfehlungen ausspricht, um die Zuverlässigkeit und Sicherheit der Automatisierung zu erhöhen. Es ist perfekt, um es zusätzlich zu Ansible Lint zu verwenden, da es spezielle Prüfungen für komplexere Szenarien wie das Upgrade auf neuere Ansible-Versionen einführt.
Spotter hat vielleicht nicht so viele Regeln wie ansible-lint, aber eine Sache, die mir jetzt schon gefällt, ist der Umgang mit den gefürchteten Fully Qualified Collection Names (FQCN). Früher konnte man “file” als Modulnamen angeben, heute sollte man den FQCN “ansible.builtin.”file verwenden. Bei der Arbeit mit älteren Codebasen, in denen FQCNs nicht verwendet werden, könnte ich diese Regel einfach ignorieren. Ich ziehe es jedoch vor, die Dinge in Ordnung zu bringen, und genau hier glänzt Spotter. Es bietet die Möglichkeit, einige Fehler zu beheben und kann alte Modulnamen durch ihre FQCNs ersetzen.
Das Tolle daran ist, dass Spotter einige der Probleme automatisch beheben kann und mir mit Funktionen wie der Generierung einer requirements.yml-Datei oder dem Verweis auf die Moduldokumentation einer bestimmten Version Zeit spart. Er gibt Hinweise auf bewährte Praktiken, z. B. zum Einstellen des “mode” bei Verwendung des “file-”-Moduls.
Molecule
Wenn meine Codeänderungen abgeschlossen sind oder der beigesteuerte Code gut aussieht, teste ich ihn. Hier verwende ich Molecule, das Unterstützung für das Testen mit mehreren Instanzen, Betriebssystemen, Distributionen, Virtualisierungsanbietern, Test-Frameworks und Testszenarien bietet. Wie ich bereits erwähnt habe, müssen meine Playbooks und Rollen auf mehreren Betriebssystemen funktionieren. Um dies zu testen, verwende ich Molecule in Kombination mit Docker. Molecule startet automatisch Container mit den von mir angegebenen Betriebssystemen und führt meinen Ansible-Code aus. Ich tue dies auf meinem lokalen Rechner für mindestens ein Betriebssystem. Wenn der Test erfolgreich ist, schiebe ich den Code zu GitHub, wo alle anderen Betriebssysteme automatisch getestet werden. Ich verwende GitHub Actions hauptsächlich für CI/CD-Pipelines, und in dieser Pipeline wird Molecule für alle unterstützten Betriebssysteme ausgeführt. Auf diese Weise werden beim lokalen Testen und in der Build-Pipeline dieselben Tools verwendet.
Chef InSpec
Wir verlassen uns nicht allein auf Ansible, um zu überprüfen, ob die Änderungen, die der Code vornimmt, korrekt sind. Wir verwenden Inspec, um die Ergebnisse zu testen. Chef InSpec ist ein Open-Source-Testframework für Infrastrukturen mit einer für Menschen und Maschinen lesbaren Sprache zur Spezifikation von Compliance-, Sicherheits- und Richtlinienanforderungen.
Wir definieren den gewünschten Zustand unserer Automatisierung in sogenannten Baselines. Baselines sind Testfälle, die prüfen, ob der Server oder die Anwendung so konfiguriert ist, wie wir es wünschen. Diese Tests werden nach der Ausführung unseres Ansible-Codes ausgeführt. Nur wenn diese Tests bestanden werden, werden die Änderungen akzeptiert und zusammengeführt.
Unsere Release-Pipeline
Sobald der Code in den Haupt-Branch im Git zusammengeführt ist, müssen wir ihn noch veröffentlichen. Auch dieser Prozess ist mit GitHub Actions weitgehend automatisiert und besteht aus mehreren Schritten. Zunächst wird ein Changelog auf der Grundlage der Pull Requests und ihrer Labels erstellt. Anschließend wird ein neuer Veröffentlichungsentwurf erstellt, der die Änderungen im GitHub-Repository enthält. Dieser Entwurf wird dann manuell veröffentlicht – auf diese Weise können wir eine Version mit sinnvollen Änderungen und nicht nur mit korrigierten Tippfehlern erstellen. Nach der Veröffentlichung des Releases wird ein weiterer Automatisierungsprozess ausgelöst, der den Code in Ansible Galaxy bereitstellt.
Und das war’s. Durch die Kombination der richtigen Tools können wir sicherstellen, dass unsere Playbooks hochwertig, sicher und zuverlässig sind. Das bedeutet, dass wir unsere Automatisierung optimieren und beschleunigen können, während wir uns voll und ganz auf sie verlassen.
Du möchtest Teil der Telekom MMS werden?
Kolleg*innen gesucht:
Hier geht’s zu den aktuellen Stellenausschreibungen:
Linux und Open Source Enthusiast. Aus dem traditionellen Betrieb kommend, schlage ich jetzt Brücken zwischen Betrieb und Entwicklung und tauche nebenbei in die Cloud-Native Landschaft ein.
