★ Docker basiertes Runtime Environment for Developers

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.

[caption id=“attachment_25648” align=“aligncenter” width=“500”]https://blog.codecentric.de/files/2014/12/7734A6C5-1684-4AD9-B775-11BAC4556A8F.png Abbildung 1 zeigt eine Übersicht über die in RED eingesetzten Technologien.[/caption]

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.