© Liashko/Shutterstock.com
Entwickler Magazin
Einführung in Test-driven Docker Development

Triple-D, oder: Mit Docker ist alles testbar

Docker ist bei Entwicklern und Administratoren angekommen. Eine unfassbar schnelle Adaption von Docker ist im IT-Markt zu beobachten. Der Einsatz gelingt eigentlich überall, aber was ist eigentlich mit der Qualität der Produkte, die wir herstellen? Das Docker-Ökosystem ändert sich derart schnell, dass sich ferner die Frage nach der Zukunftsfähigkeit unserer Erzeugnisse stellt. Wie testen wir das Setup und das Zusammenspiel unserer Infrastruktur auf der nun alles so elegant abläuft? Fehler passieren, Sicherheitsmängel treten auf, und Änderungen sind heutzutage die Norm. Kann man ein Docker-Setup eigentlich gut testen oder sogar die Entwicklung der Infrastruktur im Test-First-Modus betreiben?

Peter Roßbach


Die enorme Geschwindigkeit, mit der wir DevOps die Möglichkeiten der Docker-Technologie angenommen haben, ist beeindruckend und beängstigend zugleich [1]. Leider gibt es bei so viel Licht auch immer etwas Schatten. Ein Dockerfile ist schnell geschrieben, und wir nutzen dabei viele Images und Artefakte von Fremden. Dies sollte jeden nachhaltig zum Nachdenken über die Bereitstellung unserer Anwendungen anregen. Wie verlässlich und vertraulich sind die Inhalte dieser aus dem Netz geladenen Container eigentlich? Nach kurzer Zeit beginnt man sich aus diversen Gründen seine eigene kleine Docker-Images-Plattform zu gestalten. Genau hier möchte der Artikel helfen, die Qualität dieser Docker-Entwicklung sicherzustellen. In einer zukunftsfähigen Infrastruktur sollte keine IT-Komponente laufen, die nicht änderbar, testbar und vermessbar ist.

Im Umfeld von Docker gibt es jede Menge Elemente, die einer Überprüfung standhalten sollten. Das Ergebnis der Bauanleitung des Dockerfiles soll überprüft werden können [2]. Packages, Docker-Anweisungen und die Upstream-Base-Images ändern sich häufig [3]. Eventuell will man ganze Familien von Images erzeugen, um das eigene Projekt auf verschiedenen Betriebssystemen, Webservern, Webcontainern, Datenbanken oder Sprachversionen anzubieten. Damit definieren wir gleich die nächsten Testaufgaben: Die ablauffähigen und konfigurierbaren Docker-Container müssen überprüft werden. Docker-Container stapelt und verbindet man praktisch immer. Es entsteht natürlicherweise ein Verbund von Containern, der eine Anwendung oder gar ein ganzes System von verschiedenen Microservices bildet. Anschaulich wird das in den Konzepten von Kubernetes Pods, oder dem Werkzeug Fig beschrieben [4], [5]. Aus dieser Erkenntnis ergibt sich direkt die nächste Aufgabe: Wie erfolgt eigentlich der Test einer ganzen Infrastruktur? Es ist die Bereitstellung von Maschinen, Netzwerken, Storage Volumes und Konfigurationen zu überprüfen. Die Aufgabe der Integrationstests von Anwendungen auf der Basis von Docker-Containern ist ein verwandtes Thema und wird im Artikel von Roland Huß beschrieben [6]. Diese Art von Testen ist eine meist unterschätzte Disziplin. An dieser Stelle hilft es, erst einmal durchzuatmen und nachzudenken. Will man diese Testaufgabe überhaupt annehmen? Wenn ja, mit welchen Methoden und Werkzeugen lässt sich die Aufgabe am besten meistern?

Gut, dass die IT schon vor dem Erscheinen von Docker für Probleme dieser Art Lösungen realisiert hat. Einer der umfangr...

Entwickler Magazin
Einführung in Test-driven Docker Development

Triple-D, oder: Mit Docker ist alles testbar

Docker ist bei Entwicklern und Administratoren angekommen. Eine unfassbar schnelle Adaption von Docker ist im IT-Markt zu beobachten. Der Einsatz gelingt eigentlich überall, aber was ist eigentlich mit der Qualität der Produkte, die wir herstellen? Das Docker-Ökosystem ändert sich derart schnell, dass sich ferner die Frage nach der Zukunftsfähigkeit unserer Erzeugnisse stellt. Wie testen wir das Setup und das Zusammenspiel unserer Infrastruktur auf der nun alles so elegant abläuft? Fehler passieren, Sicherheitsmängel treten auf, und Änderungen sind heutzutage die Norm. Kann man ein Docker-Setup eigentlich gut testen oder sogar die Entwicklung der Infrastruktur im Test-First-Modus betreiben?

Peter Roßbach


Die enorme Geschwindigkeit, mit der wir DevOps die Möglichkeiten der Docker-Technologie angenommen haben, ist beeindruckend und beängstigend zugleich [1]. Leider gibt es bei so viel Licht auch immer etwas Schatten. Ein Dockerfile ist schnell geschrieben, und wir nutzen dabei viele Images und Artefakte von Fremden. Dies sollte jeden nachhaltig zum Nachdenken über die Bereitstellung unserer Anwendungen anregen. Wie verlässlich und vertraulich sind die Inhalte dieser aus dem Netz geladenen Container eigentlich? Nach kurzer Zeit beginnt man sich aus diversen Gründen seine eigene kleine Docker-Images-Plattform zu gestalten. Genau hier möchte der Artikel helfen, die Qualität dieser Docker-Entwicklung sicherzustellen. In einer zukunftsfähigen Infrastruktur sollte keine IT-Komponente laufen, die nicht änderbar, testbar und vermessbar ist.

Im Umfeld von Docker gibt es jede Menge Elemente, die einer Überprüfung standhalten sollten. Das Ergebnis der Bauanleitung des Dockerfiles soll überprüft werden können [2]. Packages, Docker-Anweisungen und die Upstream-Base-Images ändern sich häufig [3]. Eventuell will man ganze Familien von Images erzeugen, um das eigene Projekt auf verschiedenen Betriebssystemen, Webservern, Webcontainern, Datenbanken oder Sprachversionen anzubieten. Damit definieren wir gleich die nächsten Testaufgaben: Die ablauffähigen und konfigurierbaren Docker-Container müssen überprüft werden. Docker-Container stapelt und verbindet man praktisch immer. Es entsteht natürlicherweise ein Verbund von Containern, der eine Anwendung oder gar ein ganzes System von verschiedenen Microservices bildet. Anschaulich wird das in den Konzepten von Kubernetes Pods, oder dem Werkzeug Fig beschrieben [4], [5]. Aus dieser Erkenntnis ergibt sich direkt die nächste Aufgabe: Wie erfolgt eigentlich der Test einer ganzen Infrastruktur? Es ist die Bereitstellung von Maschinen, Netzwerken, Storage Volumes und Konfigurationen zu überprüfen. Die Aufgabe der Integrationstests von Anwendungen auf der Basis von Docker-Containern ist ein verwandtes Thema und wird im Artikel von Roland Huß beschrieben [6]. Diese Art von Testen ist eine meist unterschätzte Disziplin. An dieser Stelle hilft es, erst einmal durchzuatmen und nachzudenken. Will man diese Testaufgabe überhaupt annehmen? Wenn ja, mit welchen Methoden und Werkzeugen lässt sich die Aufgabe am besten meistern?

Gut, dass die IT schon vor dem Erscheinen von Docker für Probleme dieser Art Lösungen realisiert hat. Einer der umfangr...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang