Automatisches Deployment von JBoss Applikationen

Ausgangssituation

Die SVD Büromanagement GmbH ist der umfangreichste Dienstleister für die österreichische Sozialversicherung, der auch Rechenzentren betreibt. Die Anzahl der Deployments auf verschiedenen Stages (Entwicklung, Test, Produktion) nimmt ständig zu und unterschiedliche Zuständigkeiten sowie manuelle Tätigkeiten führen zu uneinheitlichen Serverlandschaften. Um die Deploymentprozesse zu vereinheitlichen und zu automatisieren wurde das Projekt ADEBA (namentlich angelehnt an Meister Adebar) ins Leben gerufen und gemeinsam mit Gepardec umgesetzt.

//

Zielsetzung

Für das Projekt wurden folgende Ziele vereinbart:

• Ein einheitlicher automatisierter Deploymentprozess für JEE Applikationen über alle Stages des Kunden (SVD) ist etabliert
• Ein zentral verwaltbares Konfigurationsrepository ist vorhanden
• Die Aufgaben und Verantwortlichkeiten für die Rollen im Deploymentprozess sind geklärt

Letztendlich erhoffte man sich eine auch eine Verringerung der Fehlerhäufigkeit sowie eine Beschleunigung der Deployments.

//

Lösung

Überlegungen zu Deployments

“Deployment”, wir wissen alle was das für einen JBoss bedeutet: Wir kopieren ein WAR- oder EAR-Archiv in einen Deployment-Ordner. Kann nicht so schwer sein. Nach kurzer Überlegung wird es dann aber doch komplexer. Was ist mit den Properties, den Datasources, den Modulen, der Security-Config im JBoss? Und was ist mit den Änderungen in der Datenbank, ganz zu schweigen von der Firewall-Konfiguration? Gehört das auch zum Deployment? Unserer Meinung nach schon und so war ein erster Schritt im Projekt, den Begriff Deployment zu definieren:

Gleich alle Schritte zu automatisieren, schien uns vorerst nicht erreichbar und so beschränken wir uns in diesem Projekt auf die Punkte:

• Einspielen von Java-Code Änderungen (WAR- oder EAR Deployment)
• Konfiguration des JBoss EAP Servers
• Einspielen von Änderungen von Schema und Konfigurationsdaten der Datenbank 

Tools Tools Tools

Basis unserer Lösung ist Ansible als universell einsetzbares Werkzeug im Rechenzentrumsbetrieb. Damit der Austausch mit der Entwicklung reibungslos vonstatten geht, werden die zu installierenden Pakete auf einem Nexus Maven Repository Manager gespeichert. 

Für die Verwaltung der umgebungspezifischen Parameter, wie z.B. Datenbankverbindungen, URLs oder Credentials zu anderen Systemen, würde sich Ansible Tower anbieten, aus verschiedenen internen Gründen haben wir uns allerdings für Gitlab als Speicherort für das Ansible Inventory entschieden. Auch die Ansible Playbooks und Module sind in einem Gitlab Repository gespeichert.

Zur Konfiguration des JBoss EAP Servers wir das von JBoss bereitgestellte Command Line Interface (jboss-cli) verwendet und Änderungen im Datenbankschema werden mit Flyway verwaltet. Sowohl jboss-cli Skripts als auch Flyway Skripts sind im Installationspaket mit eingepackt.

Der Ablauf eines Deployments ist folgendermaßen (siehe fiktives Projekt eSVE in obiger Grafik):

• Ein Deployment wird über einen Jenkins-Job angestoßen
• Download des Installationspaketes vom Maven Repository
• Auspacken und Analyse des Installationspaketes
• Download von Abhängigkeiten (JBoss-Paket, Flyway)
• Ersetzen umgebungsspezifischer Parameter in Templates
• Stoppen des JBoss-Servers (falls existent)
• Upgrade des Datenbank-Schemas
• Löschen und Aufbau der JBoss Instanz

Am Ende des Vorgangs ist eine voll funktionsfähige Anwendung vorhanden.

Organisatorische Aspekte

Technik ist die eine Seite, schwieriger sind oft organisatorische Aspekte einer Vereinheitlichung. Während für einige Anwendungen unterschiedliche Abteilungen für das Datenbank-Schema, die JBoss Konfiguration und den Java-Code zuständig waren, müssen jetzt alle drei Aspekte gemeinsam in ein Installationspaket verpackt werden. Die Abteilungen müssen enger zusammenarbeiten oder die Verantwortlichkeiten anders geregelt werden. Ein typisches DevOps Thema.

Wichtig war für dieses Projekt, dass sowohl die Ansible-Skripts als auch die umgebungsspezifischen Parameter der verschiedenen Stages unabhängig von der Anwendung (dem Installationspaket) verwaltet werden. Mit denselben Ansible Playbooks kann nicht nur eine Anwendung- sondern es können alle typischen JEE Anwendungen des Kunden installiert werden.

Ausblick

Im Projekt ADEBA wurden die ersten Anwendungen eines Kunden der SVD auf automatisches Deployment umgestellt. Mittlerweile wurden die Kernkomponenten des Systems als Projekt Storc Open Source gestellt und mit dem internen Projekt ABDIM ist ein weiterer Storch für automatisches Deployment bei einem zweiten Kunden der SVD abgehoben.

// Unsere Kompetenzen