Zum Inhalt springen

Blogeintrag

Erfahrungen mit Docker im TEC

Tools  Tool-Expertise 

Für das erfolgreiche Betreiben unseres TEC (Tool Evaluation Center) benötigen wir eine große Zahl an aktuellen Tools ad-hoc verfügbar, um sie gemeinsam mit unseren Kunden evaluieren zu können. Diesen Service wollen wir anbieten und diese technische Herausforderung ist und bleibt unser hoher Anspruch.

Bisher wurden diese Leistungen über unsere interne IT mit einem VMWare ESX-Server abgewickelt. Es zeigte sich jedoch, dass wir durch die dabei verwendete Technologie bei gewissen Aufgaben Einschränkungen bezüglich der Flexibilität unterliegen. Vor allem was folgende Punkte betrifft:

  • Durchführung eines automatischen Toolsetups auf einer neuen Maschine
  • Virtuelle Maschinen sind zu schwergewichtig und damit z.B. nicht offline am Laptop einsetzbar
  • Host-OS muss in der Regel aufwändig aktualisiert werden (Beispielsweise bei einer Migration aller Windows-VMs von Windows XP auf Window 7)
  • Tool-Updates und -Upgrades sind teilweise nur unter großem Aufwand durchführbar (das ist natürlich abhängig vom Tool)
  • automatisiertes Einspielen neuer Lizenzen
  • Historische Installationen unterstützen und verfügbar machen (ein Kunde will aus bestimmten Anforderungen heraus eine ältere Version evaluieren)
  • Aufbauen einer Toolchain

All diese Szenarien ließen uns nach einer geeigneten Lösung suchen, um effizienter arbeiten zu können. Vor allem wollten wir eine Lösung, um die manuellen Aufwände zu minimieren, denn eine adäquate Automatisierung ist nicht nur im Softwaretest hilfreich.

All diese Überlegungen führten uns nach Recherchen zu Docker, einer leichtgewichtigen Containerisierungslösung. Wir wollten uns – aus verständlichen Gründen – dem Thema eher konservativ und kritisch nähern und planten eine interne Evaluierung inkl. eines ausführlichen Proof of Concepts. Es stellte sich heraus, dass das kein einfaches Unterfangen war, denn die Entwicklung im gesamten Docker-Umfeld ist ausgesprochen volatil. Es war also weniger die Komplexität der Technologie, als die schnelle Weiterentwicklung des gesamten Docker-Ökosystems. 

 

 

Grafik: Unterschied zwischen virtueller Maschine und Container.

Abgesehen davon entstehen laufend neue Werkzeuge in diesem Ökosystem, die das Management der Container vereinfachen und das Handling mit Docker selbst verbessern. Das gibt einerseits Sicherheit, eine große Community zur Verfügung zu haben, andererseits ist nicht klar, ob und wie sich das Projekt selbst entwickeln wird. Im vorhandenen Ökosystem gibt es die Docker Engine (oder simpel Docker), um Container ablaufen zu lassen, den Docker Hub, eine öffentliche Images-Bibiliothek und diverse sehr nützliche Werkzeuge, wie Docker Compose für Multicontainer-Apps, Docker Machine zum Provisioning der Container im Netzwerk, die Docker Registry zur Imageverteilung und Docker Swarm (Clustermanagement). Das beste daran ist aber, sie sind alle offen und über ebenfalls offene APIs zugreifbar. Und die ganz neue Docker Toolbox erleichtert das Aufsetzen unter Windows oder OS X.

Welche (unserer) Probleme ließen sich mit Docker tatsächlich lösen?
Ein automatisches Toolsetup ist mit Docker wesentlich leichter zu implementieren, als mit einer VM. Die Integration mit CI (Continuous Integration) ist kein Problem und automatisiert viele Aufgaben, die derzeit manuell durchgeführt werden.
Da die Container leichtgewichtig sind und damit schneller in der Ausführung und schonender mit Systemressourcen umgehen, ist auch eine offline Nutzung auf Laptops machbar. Das kann dem Berater in Situationen, in denen kein Breitbandinternet zur Verfügung steht, schon einmal das "Leben retten".

Das Host-OS lässt sich im Image abbilden und leicht über ein Image integrieren. Und Updates sowie Lizenzupdates sind ebenso einfach möglich.

Was funktioniert nicht?
Windows wird derzeit nicht nativ unterstützt. Das bedeutet, im Moment sind alle Windows-basierten Applikationen außen vor. Ein Container kann nicht auf Windows als Host-OS laufen. Unsere Annahme, dass sich das sicher schnell ändern wird, hat sich bisher als nicht zutreffend erwiesen. Das liegt nicht am Commitment Microsofts, welches ausgesprochen gelobt wird, sondern viel eher wohl an der Windows-Architektur selbst.

Außerdem stellt sich natürlich die Frage nach der Kompatibilität der Container, sollte diese Funktionalität jemals umgesetzt werden. Windows und Linuxcontainer wären mit Sicherheit inkompatibel (Docker setzt auf Kernelfunktionalität).

Was ist mit der GUI?
Viele der von uns verwendeten Tools sind an die Benutzeroberfläche des jeweiligen Betriebssystems gebunden (man denke nur an die gesamte Palette der GUI-Testautomatisierungswerkzeuge).
Diese Funktionalität lässt sich vollständig über das Unix X-Window-System abwickeln und stellt kein Problem dar. Für ein unter Windows laufendes Docker-System kann gleiches mit Xming erreicht werden (en.wikipedia.org/wiki/Xming). Durch das Fehlen eines Supports für native Windowsapplikationen bleiben aber Windows-Tools derzeit außen vor. Schade.

Potenzial, nicht nur im TEC
Neben dem einfachen Handling der Container und der schonenden Ressourcennutzung ist es beispielsweise auch möglich, Container miteinander zu verlinken. Docker Compose hilft hier bei der Verwaltung. Damit lassen sich komplexere Szenarien realisieren, auch Stubs und Mocks sind ein Thema.

Ein einmalig (durchaus aufwändig zu erstellendes) Docker Image bringt aber eine Menge an Vorteilen mit sich. Es lassen sich Softwarestacks nebeneinander bauen und betreiben, jeder im Team kann das gleiche Image verwenden, das spart nicht nur Ärger mit unterschiedlichen Testumgebungen, sondern auch Zeit, Aufwände und damit letztendlich Geld.

Im Test lassen sich über die CI automatisiert Images aus jedem Build erstellen. Dabei ist es kein Problem, diese auch historisch in einer privaten Registry zu halten, um später wieder darauf zuzugreifen.
Interessant wird es mit der Verteilung identischer Entwicklungs- oder Testumgebungen zur Automatisierung. Damit lassen sich alle möglichen Szenarien durchspielen.
Wenn Docker beim Architekturdesign schon berücksichtigt wird, können mit entsprechenden Microservices auch in der Produktion die vollständig gleichen und getesteten Container zum Einsatz kommen.

Resüme
Wir würden Docker gerne ganzheitlich für unsere Toolinstallationen einsetzen, leider wird Windows derzeit nativ nicht unterstützt. Das schränkt die Einsatzfähigkeit in unserem Kontext empfindlich ein, da viele Werkzeuge nur unter Windows verfügbar sind.
Im Moment werden wir also schrittweise mit Docker jene Tools ausrollen, die schon unterstützt werden, und die weitere Entwicklung wird zeigen, inwiefern zukünftig auch die gleiche Funktionalität von Microsoft Windows und OS X verfügbar ist.

Generell erscheint die aktuelle Situation um Docker, auch durch den Hype bedingt, noch etwas zu wenig gefestigt. Bis sich dies aber gesetzt und etabliert hat, auch im Sinne einer Best Practice, wird es noch einiges an Arbeit erfordern. Unsere Bemühungen, nicht nur die aktuellsten Werkzeuge im TEC zu betreiben, sondern auch auf modernste Technologien zu setzen, tut dies jedoch sicher keinen Abbruch und die gesammelten Erfahrungen mit Docker stellen wir natürlich auch unseren Kunden zur Verfügung.

Fachlicher Kontakt

Johannes Bergsmann

johannes.bergsmann@software-quality-lab.com

 +43 5 0657-420
 +43 676 840072 420