Automatisches Deployment in der SVD

• 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.

Ü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:

„Ein Deployment umfasst alle Tätigkeiten vom Deploymentauftrag bis zur funktionierenden Anwendung„

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.

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.