Test Driven Infrastructure

---

Hintergründiges

In der Softwareentwicklung gibt es viele Möglichkeiten, Code zu testen: Unittests, Smoke Tests, Acceptance Tests. Doch wie sieht es mit IT-Infrastruktur aus? Wie das funktioniert und wie unser Weg dorthin verlief – das soll in einer kleiner Blogartikel Reihe beschrieben werden.

Die Motivation, für die eigene Software Tests zu implementieren ist klar: Qualitätssicherung, reproduzierbare Fehlersuche oder auch Refaktorierung. Dabei lassen sich Tests jederzeit erneut lokal oder automatisiert auf einer Continuous-Integration-Umgebung ausführen.

Doch wie sieht es mit IT-Infrastruktur aus? Können wir Methoden und Werkzeuge adaptieren, wenn wir beispielsweise eine neue Cloud-Umgebung auf AWS für unsere Kunden aufbauen oder beim späteren Betrieb sicherstellen, dass ein Gesamtsystem noch wie geplant funktioniert?

Kurze Antwort: Ja!

Stellt sich nur die Frage: Wie können wir das umsetzen? Und am besten, getreu des DevOps-Mindsets das Beste aus beiden Welten miteinander verknüpfen. Längst nutzen SysOps und Cloud-Ingenieure CI-Tools oder entwickeln Integrationstests für 3-Tier-Webapplikationen. Auf der anderen Seite haben Software-Entwickler die Themen Monitoring oder Logfile-Management auf ihrer Agenda.

Unser Weg zu “Test Driven Infrastructure”

Wir von Centrias haben von Anfang an auf Provisionierungstools wie Puppet und später Ansible gesetzt. Gerade in volatilen AWS-Setups, wo EC2-Instanzen oder Docker Container “kommen und gehen” bietet sich ein vollautomatisiertes Setup an bzw. ist ohne den Einsatz der genannten Tools schlicht nicht möglich.

Puppet und Co. allein aber bieten uns noch nicht die Fülle an Möglichkeiten, da beispielsweise das Testen neuer Manifeste oder Rollen aufwendig und zeitraubend ist.

Hier kommen neue Tools ins Spiel: ServerSpec, InSpec und Test Kitchen – um nur drei zu nennen.

Isolierte Testumgebungen auf Vagrant-, Docker- oder EC2 Basis bereitzustellen, Tests durchzuführen und danach diese temporäre Infrastruktur wieder sauber abzuräumen ist die Aufgabe von Test Kitchen. Als Beispiel sei eine Ansible Rolle für MySQL genannt, die reproduzierbar gleichermaßen auf etwa Amazon Linux und Ubuntu funktioniert.

Die eigentlichen Tests implementieren wir dann in ServerSpec- oder InSpec Notation. Wir prüfen damit etwa das Vorhandensein von Paketen, laufende Dienste und wichtige Konfigurationseinstellungen.

Einen besonderen Stellenwert nimmt InSpec ein: Seit Version 2.0 können auch AWS-Ressourcen damit geprüft werden. Hier einige konkrete Beispiele, die klar unseren Fokus und Anspruch auf Security und Compliance aufzeigen:

• IAM root User verlangt MFA
• AWS CloudTrail und AWS Config müssen konfiguriert sein
• keine Security Group öffnet pauschal den SSH Port ohne IP Einschränkung
• bestimmte S3 Buckets sind nicht öffentlich zugänglich
• neben Logging sind auch Monitoring-Alarme konfiguriert (AWS CloudWatch)

## CI-Integration

Stichtagsbezogene oder sogenannte adhoc-Tests sind wichtig, genügen aber keiner Compliance-Strategie. Deshalb überwachen wir kontinuierlich AWS-Infrastruktur und können so zeitnah auf Probleme oder Unzulänglichkeiten reagieren und diese abstellen. Es gibt zwei grundsätzliche Vorgehensweisen, um diesen Anspruch in die Tat umsetzen zu können:

• tägliche, automatische Überprüfung durch Jenkins CI Jobs
• Reaktion auf Änderungen an der Software oder der Infrastruktur

## Ausblick

In einem der nächsten Blog Artikel möchten wir eine konkrete Implementierung von InSpec Controls für AWS zeigen.