Java Magazin 10/14

Aufbau einer Continuous-Delivery-Pipeline für PaaS

Autoren: ,

Im letzten Artikel der Serie wird auf dem bisher beschriebenen Stack von Machine, Infrastructure und Platform as a Service eine Continous-Delivery-Pipeline beschrieben, mit der sich Umgebungen und deren Anwendungen automatisiert erstellen lassen bzw. deployt werden können. Dieses Mal wollen wir uns mit der Automatisierung der Build-Pipeline beschäftigen.

Bevor wir auf den Aufbau, die Automatisierung und die Konfiguration einer Build-Pipeline eingehen, wollen wir einen Blick auf die vorherigen Artikel aus dieser Serie werfen. Im ersten Artikel hat Stefan Siprell anschaulich die Vorteile von Continuous Delivery in einer eigenen privaten Cloud für Unternehmen dargestellt. Im zweiten Artikel haben Felix Massem und Jan-Frederic Markert am Beispiel des Bare-Metal-Provisionierungsframeworks Foreman den Ansatz Metal as a Service (MAAS) vorgestellt. Dabei wurden die automatischen Schritte von der Hardwareerkennung, der Installation des Betriebssystems bis hin zur Provisionierung von Servern mit Puppet gezeigt. Der dritte Artikel von Lukas Pustina und Daniel Schneller hat OpenStack als Framework für Infrastructure as a Service (IAAS) vorgestellt. Anhand der Erfahrungen eines realen Projekts wurde gezeigt, wie mithilfe von OpenStack elastische, virtuelle Umgebungen für Test- und Produktionssysteme aufgesetzt, konfiguriert und verwaltet werden. Im vierten Artikel hat Marco Metzen OpenShift als Platform-as-a-Service-(PAAS-)Framework vorgestellt. Mit OpenShift können Anwendungen in Cloud Umgebungen gehostet werden. OpenShift kümmert sich um die Provisionierung und Skalierung der Anwendung. Entwickler können sich bei diesem Ansatz um die Weiterentwicklung der Anwendung kümmern. Das Zusammenspiel dieses gesamten Stacks (Abb. 1) ermöglicht es, eine flexible, skalierbare private Cloud im eigenen Unternehmen zu betreiben, vergleichbar mit der Amazon Cloud. Im vorliegenden Artikel wird der automatisierte Aufbau einer Continuous-Delivery-Infrastruktur vorgestellt. Das beschriebene Vorgehen und die verwendeten Technologien setzen nicht zwingend die Frameworks aus den vorhergehenden Artikeln voraus. Wir werden auf die Vorteile von Virtualisierung eingehen, die für den Aufbau und die Erweiterung von Continuous-Integration-/Delivery-Umgebungen hilfreich sind.
PAAS – Do-it-Yourself-Style
Unabhängig davon, ob Bare-Metal-Hardware oder virtualisierte Server in Ihrem Unternehmen eingesetzt werden, benötigen wir im ersten Schritt eine Infrastruktur zum Bauen, Testen und Ausliefern der Software. Da
Automatisierung in dieser Artikelserie eine große Rolle spielt, soll das nicht „per Hand“, sondern mit einem Provisionierungswerkzeug erfolgen. Der folgende Abschnitt gibt einen Überblick über die Komponenten einer Delivery-Infrastruktur und wie diese mithilfe von Puppet automatisiert aufgesetzt werden. Einzige Vorbedingung ist, dass auf den Maschinen Puppet vorinstalliert ist, um die weitere Konfiguration zu managen.
Für eine kompakte Einführung in Puppet sei auf die Einführung von Puppetlabs verwiesen [1]. Die verwendeten Beispiele wurden unter Ubuntu Trusty Tahr getestet. Abbildung 2 zeigt eine Übersicht der Zielinfrastruktur. Ein Continuous-Integration-Server dient als Knotenpunkt, um den Sourcecode aus der Versionsverwaltung zu klonen, bauen, testen, versionieren und zu paketieren. Die erzeugten Pakete werden in ein tefakt-Repository ausgeliefert und von dort bei Bedarf für Deployments in beliebige Umgebungen genutzt. Darüber hinaus steuert der CI-Server die Qualitätsanalyse der Software, deren Ergebnisse auf dem dazugehörigen Server abgelegt werden.

Vollständiger Artikel