Interview mit Stefan Hildebrandt

„Der Umstieg auf Docker spart im Betrieb keine Kosten“

Redaktion JAXenter

Stefan Hildebrandt

Stefan Hildebrandt stellt in seinem Vortrag auf der W-JAX die These auf, dass sich die vielgerühmten Docker-Container in vielen Unternehmen nicht für den produktiven Einsatz lohnen. Beim Testen aber schon. Im Interview werfen wir einen ersten Blick auf automatisiertes Testen mit Docker-Containern.

JAXenter: Du sagst in deinem Abstract, dass Docker-Container zwar ein interessantes Auslieferungs- und Betriebskonzept bieten, aber sich in vielen Organisationen noch nicht für produktiven Einsatz verwenden lassen. Aus welchen Gründen ist Docker oftmals noch nicht reif für den Produktionseinsatz?

Stefan Hildebrandt: Neben potenziellen Sicherheitsproblemen, den man nur mit einigem Aufwand begegnen kann – z. B. mit restriktiven AppArmor-Regeln – sehe ich die meistens Probleme bei den Prozessen und Werkzeugen, die ein von der Entwicklung getrennter Betrieb einsetzt, der in den meisten größeren Konzernen unumgänglich ist: Angefangen vom Betriebssystem wie Windows oder Solaris, über Monitoring-Lösungen bis hin zu kompletten Betriebslösungen, die automatisch für Ausfallsicherheit und Skalierung sorgen. Hier wurden teils beträchtliche Mittel eingesetzt, um den aktuellen Status aufzubauen. Und da sich aktuell durch einen Umstieg auf Docker für die Kostenstelle „Betrieb“ keine Vorteile erarbeiten lassen, wird hier ein Umstieg noch einige Zeit dauern.

JAXenter: In welchen Fällen leistet Docker aber dennoch wertvolle Beiträge auf dem Weg zu Continuous Delivery?

Stefan Hildebrandt: Die Einführung von Continuous Delivery ist kein rein technisches Thema, sondern ein Kulturwandel. Dafür braucht es verlässliche Tests, durch die Vertrauen außerhalb der Entwicklung erarbeitet werden kann. Da der Zeitraum zum Testen um Größenordnungen kleiner wird und die Wiederholungsrate im Gegenzug stark erhöht wird, kann sich auch niemand mehr um eine vollständige Automatisierung der Regressionstests drücken. Automatisierte Tests, die schnell genug angepasst werden können, wartbar und skalierbar genug sind, müssen zusammen mit der Applikation in cross-funktionalen Teams entstehen. Sie sollten komplett versioniert sein und den Wegen des produktiven Codes problemlos folgen können. Dafür müssen die Laufzeitumgebungen auch zu Code werden.

JAXenter: Womit wir bei Infrastructure-As-Code wären.

Stefan Hildebrandt: Aus meiner Sicht ist Docker hier ein einfacher Wrapper, um alle geläufigen Lösungen für eine Testumgebung zusammenzuführen. Sofern noch kein Provisionierungswerkzeug eingesetzt wird, reichen für den Einstieg meistens bekannte Werkzeuge wie Gradle/Maven zusammen mit ein paar Zeilen Shellscript. Ein zentrales Feature von Docker ist das effiziente Verteilen von Anwendungen inklusive der kompletten Laufzeitumgebung auf viele Rechner. Genau dieses Feature wird interessant, wenn es darum geht viele Umgebungen für Entwickler, Tester und CI-Jobs zu betreiben. Damit müssen sich Entwickler oder Tester, als Nutzer dieser Umgebungen, nicht mit den Installationsdetails aller benötigten Systeme auseinandersetzten, sondern nutzten nur einfache Docker-Befehle wie pull, start und stop. Das initiale Aufsetzen der Container kann durch eine kleinere Gruppe von Linux-afinen Mitarbeitern erfolgen. Updates der Container mit neuen Versionen der Anwendung oder aktuelleren oder erweiterten Daten erfolgt dann durch Anpassung in Konfigurationsdateien oder SQL-Skripten und ist für die meisten Projektteilnehmer möglich. Diese kann man teilweise auch relativ einfach an CI-Server delegieren.

Die meisten Aspekte, die den Einsatz für den produktiven Betrieb verhindern, treffen für Entwicklungs- und die meisten Testumgebungen nicht zu, sodass sie den Einsatz von Docker nicht verhindern. Klassiker, wie die Entwicklung auf Windows-Rechnern und der Betrieb auf Linux/Unix, kann man mit Docker relativ elegant verbessern.

JAXenter: Viele sind ja mit dem Testen klassischer Anwendungen vertraut. Was ändert sich nun, wenn man mit Containern testen möchte?

Stefan Hildebrandt: Für manuelles Testen – z. B. in einem fachlichen Abnahmetest – kann mit einem Klick innerhalb von Minuten eine Umgebung mit einem definierten Stand der Anwendung bereitgestellt werden. Ansonsten muss sich hier nichts ändern.

Für automatisierte Tests können Container inklusive Daten zur Verfügung gestellt werden, sodass in den Testfällen das Setup der Umgebung entfällt und auch alle anderen Vorbedingen immer dieselben sind. Hierdurch wird die Laufzeit extrem verkürzt und sehr viel Komplexität aus den Tests entfernt. Komplexität wird auch durch die exklusive Nutzung einer Umgebung durch einen Nutzer reduziert, da hier keine Synchronisierung über Namensräume oder Nummernkreise erfolgen muss.

Bei Fehlern in einem Test kann die gesamte Umgebung wieder heruntergefahren, getagt und inklusive Testdaten und Logfiles in ein Repository hochgeladen werden. Dieses Tag kann dann in dem Fehlerticket referenziert werden, sodass bei der Behebung die komplette Umgebung für eine Analyse und Fehlerbehebung bereitsteht.

JAXenter: Du stellst in deinem Vortrag auf der W-JAX die Kombination Docker, Gradle, Maven und Arquillian vor. Was gefällt dir an diesem Technologie-Stack?

Stefan Hildebrandt: Hierbei handelt es sich eher um mehrere Toolstacks, die teilweise dieselben Features bieten aber alle unterschiedliche Stärken haben. Daher muss ich abhängig von meiner Umgebung und meinen Anwendungsfall entscheiden, welches Tool ich an welcher Stelle einsetzen möchte. Gradle ist sehr stark, wenn es darum geht Container zu erstellen. Arquillian ist Spezialist für die Starten und Stoppen während der Testausführung. Mit dem Maven Plug-in kann man – mit kleinen Einschränkungen – beides machen.

JAXenter: Und was würdest du sagen ist die Kernbotschaft deiner Session? Was willst du den Leuten auf jeden Fall mit auf den Weg geben?

Stefan Hildebrandt: Fehlende Umgebungen oder fehlende Testdaten sind keine Ausrede mehr, stabile und wartbare Integrationstests zu erstellen. Durch Docker lassen sich viele Aufgaben effizient asynchron auf CI-Servern erledigen, sodass eine Testumgebung nur noch heruntergeladen und angeschaltet werden muss, wodurch der Zeitgewinn für den einzelnen Anwender gegenüber anderen Ansätzen, die z. B. auf vagrant setzten, extrem sein kann.

Stefan Hildebrandt ist als Softwareentwickler und Berater seit zehn Jahren in größeren Projekten bei Kunden aus unterschiedlichen Branchen tätig. Seine Schwerpunkte sind Web- und Backend-Entwicklung mit Java und JavaScript sowie Werkzeuge zur Test- und Deployment-Automatisierung. Sein Interesse gilt vermehrt der ganzheitlichen Betrachtung des Softwareentwicklungsprozesses und der Potenziale, die außerhalb der eigentlichen Entwicklung schlummern.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.