Verteilte, skalierbare, cloudfähige Anwendungen sind die Zukunft der Softwareentwicklung. Moderne Softwareprojekte basieren auf einer Vielzahl von Komponenten, um die fachliche Funktionalität schnell zu implementieren. Dies sind zum Beispiel verschiedene Datenbank- sowie Messaging-Systeme, Suchmaschinen und vieles mehr. Darüber hinaus werden Anwendung zunehmend verteilt betrieben, um Anforderungen an Antwortzeiten, Skalierbarkeit und Ausfallsicherheit gerecht zu werden. Dies stellt Softwareentwickler vor die Herausforderung, alle benötigten Komponenten auf ihrem Entwicklungssystem installieren und konfigurieren zu müssen, um so stets eine aktuelle und produktionsnahe Entwicklungsumgebung zu nutzen zu können. Eine ähnliche Herausforderung stellt sich dem Betriebsteam für die Pflege der Produktionsumgebung.
Für CenterDevice haben wir dazu eine Docker basierte Entwicklungsumgebung geschaffen, die den Entwicklern diese Arbeit abnimmt. In diesem Artikel stelle ich diese Entwicklungsumgebung vor.
Docker wurde bereits in den Artikeln 1 , 2 , 3 , 4 und 5 vorgestellt. Der wesentliche Vorteil von Docker ist, dass Docker Images eigenständige Laufzeitumgebungen darstellen, die sowohl von Entwicklern als auch vom Betrieb in der Produktion eingesetzt werden können. Mein Kollege Alexander Berresch und ich haben uns diese Eigenschaft von Docker zunutze gemacht und eine Entwicklungsumgebung für die CenterDevice geschaffen, die vollständig auf Docker Images basiert.
Wir nennen diese Entwicklungsumgebung Runtime Environment for Development (RED) und setzten sie seit einem Jahr erfolgreich bei der Entwicklung von CenterDevice ein.
RED bei CenterDevice
Der Artikel The CenterDevice Cloud Architecture Revisited gibt einen Überblick über die Softwarearchitektur von CenterDevice und stellt die externen Komponenten wie MongoDB, RabbitMQ, ElasticSearch und Tomcat vor. Diese externen Komponenten werden in RED als Docker Images zentral gepflegt. Damit müssen unsere Entwickler für die täglich Arbeit lediglich aktualisierte Docker Images aus unserer zentralen private Docker Registry (siehe auch 3 und docker-registry ) laden und können arbeiten, ohne zeitaufwendig ihre Entwicklungsumgebung zu pflegen.
Die eigenen Software Komponenten werden ebenfalls als Docker Images verpackt und anschließen als Container in RED gestartet. Es ist aber auch möglich, Komponenten in einem hybriden Modus zu starten, sodass die gerade zu entwickelnden Komponenten in der IDE und alle externen Komponenten in Docker Containern laufen.
Durch die Containerisierung aller Komponenten lässt sich eine produktionsnahe Entwicklungsumgebung schaffen, die Sharding und Replication von Datenbanken beinhaltet und in der Produktion eingesetzt werden kann. Des Weiteren bietet dieser Ansatz den Vorteil, dass neue Teammitglieder schnell eine vollständige Entwicklungsumgebung auf ihren Rechnern aufsetzen und somit schneller produktiv arbeiten können.
Technische Umsetzung
RED wurde speziell für CenterDevice von uns entwickelt. Die Prinzipien und die grundlegende technische Umsetzung können jedoch verallgemeinert und auf beliebige Projekte angewendet werden. Die Grundlagen für RED sind VirtualBox , Vagrant und Docker .
VirtualBox wird zur Virtualisierung genutzt, sodass RED betriebssystemunabhängig auf allen gängigen Betriebsystemen von Entwicklern eingesetzt werden kann. Vargant automatisiert den Umgang mit VirtualBox, sodass die Virtualisierung „head less“ auf den Entwicklersystemen laufen kann. Docker erlaubt ein einfaches Deployment von Abhängigkeiten in Form von externen Komponenten sowie die Bündlung von Artefakten und Konfigurationen — siehe Abbildung 1.
Abbildung 1 zeigt eine Übersicht über die in RED eingesetzten Technologien.
Zukunft
Zur Zeit werden die Docker Images noch von den CenterDevice Entwicklern selbst gebaut und in unsere private Docker Registry geladen. In Zukunft möchten wir diesen Schritt in unsere Continuous Integration Pipeline einbauen und von Jenkins automatisch erledigen lassen. So können wir unsere Integrationstest ebenfalls auf Docker Images umstellen und damit eine bessere Isolation der Tests ermöglichen.
Es gibt noch mehr
Alexander Berresch wird in einem weiteren Artikel nächste Woche die technische Umsetzung genauer beschreiben und dazu ein kleines Beispiel auf GitHub veröffentlichen, so dass Ihr selbst ein RED für Eure eigenen Projekte aufsetzen könnt. Also bleibt dran und meldet Euch bei uns, falls Ihr Fragen oder Anregungen habt.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Lukas Pustina
28.10.2015 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Lukas Pustina
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.