Recommandé
Recommandé
Contenu connexe
Similaire à Docker in der Anwendungsentwicklung
Similaire à Docker in der Anwendungsentwicklung (20)
Plus de Torsten Fink
Docker in der Anwendungsentwicklung
- 2. Zu meiner Person 2003: Promotion an der FU zum Thema SW-Architekturen und Verteilte Systeme Ab 2004: Berater bei der akquinet ¡ technischer Architekt in J2EE-Projekten ¡ Projektleitung ¡ Betriebsführung, Wartung ¡ klassische Beratung und Schulungen 2006-2010: Leiter des JBoss-Competence-Centers bei der akquinet Ab 2011: Geschäftsführer der akquinet tech@spree
- 3. Meine Firma
- 4. Motivation Virtualisierung ist ein spannendes Thema ¡ Umstellung unser lokalen Server-Infrastruktur (a.k.a Küche) vor etwa 6 Jahren ¡ Ebenfalls schon länger lokal bei Entwicklern im Einsatz ¡ Windows für die MacBooks :-) ¡ Isolierte RDBMS (Oracle, DB2), oder AppServer (WebSphere) ¡ Isolierte Test-Systeme => gute Erfahrungen, aber etwas schwerfällig Docker war sofort spannend ¡ Leichtgewichtig, lebendige Ökostruktur ¡ Anfangs noch buggy ¡ Anscheinend jetzt Konsolidierungsphase Thoughtworks – Technology Radar
- 6. Vorgehen Aufsetzen einer Masterarbeit ¡ Untersuchung der Einsatzmöglichkeiten an einem internen Produkt Integration mit laufenden Projekten und Administration ¡ Regelmäßige Vorstellung der Ergebnisse intern ¡ Aktives Suchen nach Integrationsmöglichkeiten Nach Abschluss der Arbeit ¡ kontinuierliche Integration in Projekte Hier jetzt die Management-Sicht der Ergebnisse :-) Master- arbeit Projekte
- 9. Ein paar Anmerkungen... Microservice (MS) := ¡ Vertikal geschnittene Komponente mit starker fachlicher Kohäsion ¡ Einzeln betreibbar Ein getrennter Betrieb der SW-Komponenten ¡ Ermöglicht Aktualisierung von Einzelkomponenten ohne Abschalten des Gesamtsystems ¡ Isoliert Einzelfehler und ermöglicht Fehlerbehebung ebenfalls ohne Gesamtabschaltung ¡ Ermöglicht häufigere und risikoärmere Releases Wichtig dafür ist ¡ Klare lose Kopplung (insb.: MS bleiben funktional, wenn andere nicht verfügbar sind) ¡ Entflechtung der Daten in der DB Dennoch ¡ Transformation: lokales System => verteiltes System (mit allen Herausforderungen)
- 12. Der erste Schritt der Masterarbeit: Auftrennen von Microservices Los geht’s mit der Architektur ...
- 13. Vorher... Internes Produkt (noch nicht öffentlich) ¡ Automatische regelmäßige Sammlung von Informationen im Web ¡ Verwaltungsanwendung für Veranstaltungen ¡ Informationsportal ¡ Keycloak für die Benutzerverwaltung, Authentisierung und Autorisierung
- 14. ... Nachher Rausziehen als MS nur angedacht Verteilen von Anfragen auf die einzelnen Webanwendungen 1 MS = 2 Docker Container 1 Anwendung = 7 Container + 1 VM
- 15. Projekterfahrungen – Projekt I Kunde mit VM-basierten Microservices ¡ Microservice := VM mit REST-Schnittstelle (Implementierung beliebig) ¡ Anfänglich hohe Entwicklungsgeschwindigkeit ¡ Dann (nach etwa 3 Jahren) ¡ Wartungsprobleme (nichtfunktionale Builds, verlorenes Entwicklerwissen, unklare Verantwortungen) ¡ Nichtfunktionale Probleme durch zu enge Kopplung (Performance, Verfügbarkeit) ¡ Aktuell ¡ Aufwändiger Betrieb und Wartung
- 16. Projekterfahrungen – Projekt II Kunde mit Spring-Boot-/Kotlin-basierten Microservices ¡ Anfänglich hohe Entwicklungsgeschwindigkeit (Allerdings nur Lese-Zugriffe) ¡ Dann Performanceprobleme durch zu enge Kopplung mit DB ¡ Lösung über lokale optimierte Daten pro MS (Experimente mit Time-Series-DB für Bewegungsdaten) ¡ Weitere Performanceprobleme durch Aufrufketten ¡ Beschwerden liefen bei uns auf als letztes Glied in der Kette ¡ Analyse war schwierig => Einführung einer fachlichen Transaktion-ID .... Zurück zu verteilten Transaktionen :-)
- 17. Projekterfahrungen – Projekt II Wie bei SOA ¡ Herausforderungen durch verteilte Verantwortungsbereiche Positive Erfahrungen mit ¡ Swagger-Specs als Auftragsbestandteil (Fachlichkeit ist damit aber immer noch offen)
- 19. Bestandteile des Konfigurationsmanagements Varianten ¡ Entwicklung - JRebel, Batchsize=1, Logging, Standard-DB-User, Testdaten, DB im Container ¡ Testsystem - Batchsize>1, Logging, Extern verwaltete DB-User DB außerhalb des Containers ¡ CI-Tests - wie Testsystem, aber mit Testdaten ¡ Produktivsystem - wie Testsystem, aber mit Produktivdaten Konfigurationsartefakte ¡ Java EE – Komponenten (WARs, EARs, EJB-Jars) ¡ Applicationserver ¡ Docker Container mit ihrer Verdrahtung
- 20. Umsetzung Maven als führendes System ¡ Image := 1 Maven-Komponente ¡ Vererbungshierarchie auf Container um Gemeinsamkeiten der Staging-Varianten zu konzentrieren ¡ Einsatz eines docker-maven-plugin ¡ Verwaltung von Container-Geflechten mit Docker-Compose Bewertung ¡ Nicht komplexer als bisherige Alternativen ¡ Schnell genug bei der Entwicklung
- 23. Vorher .... Typischerweise in Projekten: ¡ 1 Seite im Confluence „Aufsetzen der Entwicklungsumgebung“ Beinhaltet ¡ Installation + Konfiguration des RDBMS (inkl. Testdaten) ¡ Installation der Build-Werkzeuge (Java, Maven, Node, Gulp ...) ¡ Installation des Quellcodeverwaltungssystems (z.B. Git) ¡ Auschecken des Quellcode ¡ Installation und Konfiguration des Appservers Dauer: 0,5 bis 1 PT Probleme: ¡ „Verstöße“ gegen die Vorgaben (z.B. die neueste DB...) ¡ Interaktion mit anderen Produktversionen aus anderen Projekten
- 24. .... Nachher Aufsetzen beinhaltet ¡ Installation von Java, Maven, Docker, Quellcodeverwaltung ¡ Auschecken des Quellcodes ¡ Per Maven: ¡ Konfiguration von Docker-Images für DB und AppServer ¡ Start der kompletten Entwicklungsumgebung Dauer: 1Ph ¡ mit geringer Fehlerwahrscheinlichkeit Kommentar: ¡ Zusätzliche Docker-Schicht erhöht die Komplexität => wenn etwas nicht funktioniert, wird die Analyse noch schwieriger
- 25. More to come ... Vision: ¡ nur noch Docker für die lokale Softwareinstallation kein Maven, Java, Git, Node.js etc. Erste praktischen Erfahrungen ¡ Kapseln von „exotischeren“ Werkzeugen im Build durch Docker (z.B. ASCIIDoc => Confluence) ¡ Docker for Windows != Docker ¡ BTW, Docker for Mac hat Performance-Probleme bei Dateizugriffen ¡ STMP-Server als Docker-Container
- 26. Projekterfahrungen Übernommen wurde bis jetzt ¡ Verwalten der DB und ihrer Konfiguration als Docker Image ¡ Verwalten des App-Servers => Handling ist einfach, Systeme sind gut isoliert Was wir gerne noch lösen würden ¡ Isolation von Node.js, npm, Gulp (dafür müssen diese noch aus Maven heraus gelöst werden) Außerdem ¡ Hilfreich, um beim Kunden Teststellungen aufzusetzen
- 30. Aufgabe, Idee, Realität Aufgabe: ¡ Fixieren eines großen Systems durch Tests als Grundlage für Refactorings Idee ¡ Einsatz von Docker-Images für schnelles Zurücksetzen Realität ¡ Produktivdaten (5GB) waren zu groß für Docker ¡ Lösung: Snapshots mit BtrfFS Test Zurücksetzen
- 32. ... Wir sind noch nicht am Ziel ... Zentrales Docker-Repo ¡ Installation und erste Tests waren erfolgreich ¡ Offen ist fundiertes Konzept für die Integration in SW-Entwicklungsprozess ähnlich zum Maven Repo Docker-basierte Produktivumgebung ¡ Aktuell laufen alle Projekte klassisch auf dedizierten VMs oder in Azure. ¡ Zentrales Docker-Repo ist Grundlage für Produktivbetrieb ¡ Sicherheit ist noch ein offenes Thema Verwaltung/Betrieb von Anwendungen bestehend aus vielen MS mit Docker ¡ Bis wann reicht Docker/Docker-Compose, ab wann brauch man Kubernetes o.ä. ¡ Wann lohnt sich MS-Architektur für den Kunden?
- 33. Resümee
- 34. Die Welt hat sich wieder verbessert.... Docker ¡ Ist stabil, schnell und macht Spass. ¡ Erleichtert den Entwicklungsprozess durch ¡ Isolation von SW-Produkten ¡ Schnelles Aufsetzen von vernetzten Systemen ¡ Müssen wir uns noch für den Produktivbetrieb genauer ansehen Microservices ¡ Sind IMHO eine konsequente und gute Weiterentwicklung von SOA ¡ Haben Chancen und Risiken :-)