Logo Gepardec IT Services GmbH
Kontakt
SVD Logo

Automatisches Deployment in der SVD

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 ins Leben gerufen und gemeinsam mit Gepardec umgesetzt.

Die Zielsetzung

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

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

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

SVD Use Case

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.

Diese 3 Top Technologien wurden eingesetzt

Maven

JBoss EAP

Ansible

Sei immer vorne mit dabei.
Gepardec Newsletter.

Entdecke weitere Case Studies

SVD Logo

Automatisches Deployment von JBoss Applikationen

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 ins Leben gerufen und gemeinsam mit Gepardec umgesetzt.

So haben wir das geschafft
ÖGK Logo

Ein neues Zeitalter für die Österreichische Gesundheitskasse

Gepardec bringt die zentrale Fachanwendung der Österreichischen Gesundheitskasse (ÖGK) in ein neues Zeitalter. Eine evolutionäre Architektur, User Experience Design und eine leistungsfähige CI/CD-Infrastruktur ermöglichen der ÖGK eine zukunftssichere Softwareentwicklung.

So haben wir das geschafft
Mediakey Logo

Einer der größten Red Hat SSO-Cluster weltweit

APA-Tech hat im Auftrag des ORF den Single Sign-On Dienst "Media Key" mit uns entwickelt. Dazu haben wir mit Red Hat SSO (auf von Basis Keycloak) einen der größten und schnellsten Cluster dieser Art aufgesetzt und customized.

So haben wir das geschafft
WordPress Cookie Plugin von Real Cookie Banner