Testgetriebene Infrastrukturentwicklung mit Ansible und Molecule
Runde Sache
Wenn die IT-Infrastruktur mit Code gemanagt wird, muss dieser Code automatisiert testbar sein. Molecule ermöglicht die testgetriebene Entwicklung und somit auch Continuous Integration für das beliebte DevOps-Werkzeug Ansible.
Das Beschreiben und Steuern von Infrastruktur durch Code (Infrastructure as Code, IaC) bietet viele Vorteile: Die Dokumentation kann nicht veralten, denn sie liegt als Quellcode versioniert vor. Dabei ist sie direkt automatisiert ausführbar und erzeugt die gewünschte Infrastruktur. Außerdem werden so Kopfmonopole vermieden, bei denen wichtiges Know-how zum Betrieb der Infrastruktur lediglich in den Köpfen weniger Leute steckt. Gleichzeitig ist endlich für das ganze Team transparent, wer was wann wie an den Infrastrukturkomponenten verändert hat – sogar über Teamgrenzen hinweg. Nicht zuletzt abstrahieren moderne IaC-Werkzeuge wie Ansible mit ihren Modulen von vielen kleinen Details. Das reduziert den Entwicklungs- und vor allem den Wartungsaufwand.
Doch wenn nur noch Quellcode geschrieben wird, unterscheidet sich die Infrastrukturentwicklung nicht mehr von der „normalen“ Softwareentwicklung. Das wirft die Frage auf, wie es eigentlich um die Grundsätze der modernen Softwareentwicklung beim Thema Infrastructure as Code bestellt ist. Heute wird wohl kaum jemand ein Softwareprojekt beginnen und dabei auf die Vorzüge des Einsatzes von agilen Methoden, testgetriebener Entwicklung (Test-driven Development, TDD) und Continuous Integration (CI) verzichten wollen.
Warum eigentlich testgetrieben?
Und das hat gute Gründe: Wird Quellcode nicht regelmäßig ausgeführt, veraltet er sehr schnell. Das gilt für Software- wie Infrastrukturcode gleichermaßen. So kann ein Update einer genutzten Bibliothek den ganzen Code nutzlos machen. Das gilt analog für Betriebssystem-Updates. Ein Refaktorisieren des Codes, um neue Anforderungen umzusetzen, ist fehleranfällig und wird ohne Testabdeckung immer riskanter. Wer schon mal ein paar Zeilen Infrastrukturcode geschrieben hat, kennt das Problem: Nach einem halben Jahr funktioniert unter Umständen kaum noch etwas davon.
Durch das Ausführen von Tests lässt sich jederzeit überprüfen, ob die bisherigen Funktionen nach der Implementierung neuer Anforderungen weiterhin laufen. Fehler fallen so möglichst früh auf, was bekanntermaßen die Kosten für ihre Behebung senkt. Im zweiten Schritt laufen die Tests bei jeder Codeänderung im Versionskontrollsystem automatisiert auf einem Continuous-Integration-Server. Schlägt dort ein Test fehl, gibt es sofort Feedback. Das hilft auch, Fehler in der Zusammenarbeit zu vermeiden, wenn mehrere Entwickler gleichzeitig an derselben Komponente arbeiten.
Das beliebte DevOps-Tool Ansible lässt sich dank seiner flachen Lernkurve schnell zum Management der Infrastruktur einsetzen. Sobald die ersten Hürden genommen sind, arbeitet man damit ähnlich schnell, wie wenn man Betriebssystembefehle direkt auf der Kommandozeile ausführt – mit dem Vorteil, dass alle Schritte sofort als Code vorliegen. Über Ansible Modules lässt sich oft ein höherer Abstraktionsgrad erreichen (siehe ix.de/ix1904126). Da Ansible mit allen gängigen Linux-Distributionen und Windows umgehen kann, ist es möglich, praktisch die gesamte Infrastruktur per Ansible zu managen – mit allen Vorteilen des Infrastructure-as-Code-Ansatzes.
Die Auswahl an Testframeworks für Ansible ist allerdings nicht groß. TestKitchen von den Entwicklern des Ansible-Konkurrenten Chef beispielsweise lässt sich lediglich über einen speziellen Custom Provisioner mit Ansible nutzen.