Testen und Docker. Beispiele aus der Praxis. Dehla Sokenou

Transkript

1 Testen und Docker Beispiele aus der Praxis Dehla Sokenou

2 Übersicht ÜBERSICHT Was ist Docker? Ein Praxisbeispiel Last- und Performancetests mit Docker Docker auf dem Build-und Testserver Fazit

3 Docker?

4 Ein kurzer Überblick Docker ist eine Virtualisierungsumgebung Isolation von Anwendungen in Container Sehr viel leichtgewichtiger als klassische VMs DOCKER

5 Ein kurzer Überblick Docker ist eine Virtualisierungsumgebung Isolation von Anwendungen in Container Sehr viel leichtgewichtiger als klassische VMs DOCKER

6 Docker-Lebenszyklus Container vs. Images DOCKER

7 Dockerfile Script zur Erzeugung von Docker-Image(s) DOCKER

8 Praxisbeispiel

9 Configuration Manager V: BEISPIEL Kern: Serverkomponente An mehreren Standorten (ggf. weltweit) verteilt Schnittstellen für Client-Systeme Web- und Rich-Client-Frontend Erweiterungen: Kundenspezifische Addons Unterschiedliche Betriebskonfigurationen Umgebung: Diverse Client-Systeme, bspw. Kassen

10 Configuration Manager Servernetzwerk BEISPIEL

11 Herausforderungen BEISPIEL Kommunikation der Komponenten Simulation des weltweiten Einsatzes Simulation von Clients Berücksichtigung von Laufzeitdifferenzen Effiziente Verteilung und Setup der Einzelkomponenten Kundenspezifische Betriebskonfigurationen und Erweiterungen Abgrenzung zum Produkttest

12 Motivation für Docker-Einsatz BEISPIEL 1. HornetQ-Konfiguration optimieren Problem: Viele Netzwerkausfälle aufgrund von Schlechten Netzwerkverbindungen Unterdimensionierter Umgebung Zustand vor der Optimierung: Server stehen zum Teil unter Dauerlast Nachrichten werden nicht verarbeitet Im schlimmsten Fall: HornetQauf dem Server hängt sich auf

13 Motivation für Docker-Einsatz BEISPIEL 1. HornetQ-Konfiguration optimieren Problem: Viele Netzwerkausfälle aufgrund von Schlechten Netzwerkverbindungen Unterdimensionierter Umgebung Zustand vor der Optimierung: Server stehen zum Teil unter Dauerlast Nachrichten werden nicht verarbeitet Im schlimmsten Fall: HornetQauf dem Server hängt sich auf Probleme treten erst auf Unter bestimmten Bedingungen Ab einer gewissen Menge Subknoten

14 Motivation für Docker-Einsatz 2. Automatische Tests auf Buildserver optimieren Problem: Buildskönnen z.t. nicht parallel laufen, da sie gemeinsame Ressourcen nutzen Dies betrifft insbesondere die Testausführung! Abgebrochene Buildshinterlassen manchmal Zustände, die nur schwer aufzuräumen sind und den nachfolgenden Build, insbesondere nachfolgende Tests, stören BEISPIEL

15 Last- und Performancetests mit Docker

16 Ausflug: Integrationstest L&P-TESTS

17 Last und Performance Integrationstestaufbau skaliert nicht! L&P-TESTS

18 Last und Performance Integrationstestaufbau skaliert nicht! L&P-TESTS

19 Soll-Zielumgebung L&P-TESTS

20 1. Ansatz: Zielumgebung mit VMs L&P-TESTS ESX-Host exklusiv für Last- und Performancetests Inklusive Emulator für Netzwerkprobleme (Latency, Package Loss) Vorbereitung einer Template-VM Clonen und Anpassen der Einstellungen, bspw. IPs Erledigen Scripte, die sich auch in einen Buildeinbauen lassen Server setzen sich per Autoinitialisierung selbst auf

21 1. Ansatz: Zielumgebung mit VMs L&P-TESTS Vorteile: Analogie zur Produktivumgebung Im Beispiel: Windows Server Einfache Simulation von Netzwerkproblemen Nachteile: Schwergewichtig In der Regel nur wenige Instanzen auf einem Host (im Beispiel 60 VMs) zu realisieren Alternativ: Space mieten Aufsetzen dauert verhältnismäßig lang Wird eher dauerhaft aufgesetzt und nicht nur temporär

22 Zielumgebung mit Docker L&P-TESTS Docker-Host für Last- und Performancetests Eigene (private) Docker-Registry Aufeinander aufbauende Images, bspw. 1. Ebene: Betriebssystem + Java + Datenbank 2. Ebene: Application-Server (JBoss oder Wildfly) 3. Ebene: Deploy der Anwendung Durch Dockerfiles (Scripte) gut automatisierbar Auch in den Buildintegrierbar

23 Zielumgebung mit Docker L&P-TESTS Vorteile: Leichtgewichtig Images können aufeinander aufbauen, viele Einrichtungsarbeiten deshalb nur einmal notwendig Aufsetzen geht schnell Container werden temporär gestartet und nach dem Test wieder beendet Jeder Test startet clean kein Zurücksetzen von Testdaten notwendig Nachteile: Ggf. weit weg von der Produktivumgebung In unserem Fall (Container setzt auf Zielsystemen Debian / CentOSauf) weit entfernt vom alternativen Zielsystem Windows Server

24 Zwischenfazit L&P-TESTS VMs haben weiterhin ihre Berechtigung Abbildung der realen Zielumgebung scheitert bei Docker ggf. an der fehlenden Unterstützung Docker ist zu bevorzugen Einfacheres und schnelleres Aufsetzen / Abräumen Ein Netzwerk mit ca. 300 Knoten ist in ca. 30 Minuten betriebsbereit Sehr viel weniger Ressourcenbedarf

25 Zwischenfazit L&P-TESTS VMs haben weiterhin ihre Berechtigung Abbildung der realen Zielumgebung scheitert bei Docker ggf. an der fehlenden Unterstützung Docker ist zu bevorzugen Einfacheres und schnelleres Aufsetzen / Abräumen Ein Netzwerk mit ca. 300 Knoten ist in ca. 30 Minuten betriebsbereit Sehr viel weniger Ressourcenbedarf Auf demselben ESX-Hosts laufen wahlweise: Ca. 60 VMs Aufsetzen pro VM > 10 Minuten Ca. 300 Docker-Container Aufsetzen pro Container ~ 10 Sekunden Anzahl der Knoten um den Faktor 5 höher! Aufsetzen um mindestens den Faktor 60 schneller!

26 Docker auf dem Build-Server

27 Integration in den Buildprozess BUILD-SERVER Viele Dockerplugins für Buildserver Jenkins Docker als Jenkins-Slaves Aufruf von Dockerkommandosim Build Deployin Docker-Container Bauen von Docker-Images auf Basis von Dockerfiles Docker-Integration in Pipeline Flexible Nutzung für jeden Bedarf Einsatz sollte zielgerichtet erfolgen

28 Warum Docker? BUILD-SERVER Parallel laufende Builds Genutzte Ressourcen für den Test nicht endlich Datenbanken / -schemata ApplicationServer / Ports Bessere Skalierung der Infrastruktur Erzeugung von Buildjobs on-the-fly möglich Z.B. für Feature-Branches Erlaubt die Ausführung der Tests ohne manuelle Anpassung des Jobs Mehrere Docker-Hosts lassen sich zu einem Schwarm (Cluster) zusammenschließen transparent für den Client

29 Ausgangssituation BUILD-SERVER

30 Umstieg auf Docker BUILD-SERVER

31 Konfiguration des Build-Servers BUILD-SERVER Build-Server läuft aus Performance-Gründen nativ und nicht selbst in einer VM Für unseren Fall: Plugin "docker-plugin" Buildwird auf einen Slave verlagert Slave wird vom Builderzeugt und abgeräumt Slave für Tests aus Slave kann ggf. weitere Container starten Bspw. für den Test verteilter Systeme Testergebnisse und Buildartefakte Werden durch Sharing im Verzeichnis des Jobs auf dem Jenkins-Master abgelegt

32 Umstieg auf Docker BUILD-SERVER Vorteile: Buildauf dem CI-Server-Slave Dieser wird on-the-flyerzeugt und verworfen Zustand kann eingefroren werden, bspw. als Docker-Image Tests können parallel ausgeführt werden, ohne sich gegenseitig zu beeinflussen Für den Nutzer transparent Nachteile: Erhöhter Aufwand bei Einrichtung des Build-Servers

33 Fazit

34 Docker Hype oder Hilfe? Aus unserer Erfahrung: Docker hilft bei diversen Alltagsproblemen Auch und gerade beim Testen Anwendbarkeit aber beschränkt Durchgehende Docker-Unterstützung fehlt noch So werden nicht alle Betriebssysteme unterstützt Ergebnisse im Container lassen sich nicht immer 1:1 auf Realität übertragen Aktuell noch viel Bewegung im Docker-Umfeld Macht das Update auf neuere Docker-Versionen schwierig FAZIT

35 Fazit Moderne Virtualisierungsumgebungen vereinfachen: 1. Das Aufsetzen von verteilten Systemen für den Test 2. Den Buildprozess Docker-Container ermöglichen die Beschränkung auf das Notwendige Tests mit VMs haben weiter ihre Berechtigung, wenn das Hostsystem Docker nicht nativ unterstützt FAZIT

36 Zeit für Fragen