Deployment und Betrieb

Das Legacy-System wird als WAR in einem externen Apache Tomcat 7 mit Java 8 betrieben. Der Container und die Anwendung bilden gemeinsam die auszuliefernde Laufzeiteinheit.

Tomcat-Deployment

Das Deployment-Image basiert auf einem internen Tomcat-7-/JDK-8-Image. Beim Image-Build werden folgende Dateien eingebracht:

• bflies.war nach webapps/bflies.war,
• context.xml in die globale Tomcat-Konfiguration,
• eine JavaMail-Bibliothek in das globale Tomcat-Library-Verzeichnis.

Tomcat entpackt beziehungsweise deployt das WAR beim Start. Die Anwendung erwartet den Kontextpfad /bflies.

Containerkonfiguration

Die Legacy-context.xml definiert:

• die MySQL-DataSource,
• Connection-Pool- und Validierungsparameter,
• die JavaMail-Session,
• den DataSourceRealm für Benutzer und Rollen.

Historisch enthielt diese Datei auch umgebungsspezifische Verbindungsdaten. Im Zielbild werden solche Werte nicht mehr in Git oder in ein unveränderliches Image eingebaut, sondern zur Laufzeit als geschützte Konfiguration bereitgestellt.

GitLab-Pipeline

Die Legacy-Pipeline besteht im Wesentlichen aus zwei Schritten:

1. ANT wird in einem Build-Container bereitgestellt und erzeugt bflies.war.
2. Buildah kopiert das WAR in das Tomcat-Image und veröffentlicht bei Releases das Container-Image.

Der WAR-Build und der Container-Build sind technisch getrennt, die Pipeline besitzt aber keine umfangreiche automatisierte Laufzeitprüfung. Der Build-Erfolg bestätigt daher vor allem, dass Quellen, Frontend-Ressourcen und Bibliotheken paketiert werden konnten.

Externe Abhängigkeiten

Für den vollständigen Betrieb benötigt die Anwendung mindestens:

• eine erreichbare MySQL-Datenbank mit passendem Schema,
• einen SMTP-Server,
• den internen Container-Registry- und GitLab-Zugang für Build und Auslieferung,
• die erwarteten Benutzer- und Rollentabellen für den Tomcat Realm.

Keycloak, Kubernetes und Flyway gehören nicht zur Legacy-Laufzeit. Sie sind Bestandteile der geplanten Modernisierung.

Betriebsrelevante Eigenschaften

• Die Anwendung verwendet serverseitige HTTP-Sessions.
• Authentifizierung und Autorisierung hängen vom Tomcat Realm und der Datenbank ab.
• Hibernate validiert das Datenbankschema beim Start.
• Das Datenbank-Bootstrap kann vor beziehungsweise während des Anwendungsstarts Schemaänderungen ausführen.
• Umfangreiche Frontend-Ressourcen werden bereits beim Build optimiert und anschließend statisch aus dem WAR ausgeliefert.
• Anwendungs- und Containerlogs sind die wichtigsten Diagnosequellen.

Referenzfunktion

Das eingefrorene Deployment bleibt während der Migration die Referenz für Startverhalten, HTTP-Pfade, Authentifizierung, Datenbankzugriffe und Benutzerabläufe. Neue Artefakte werden zunächst gegen diesen Stand verglichen, bevor eine Laufzeitkomponente modernisiert wird.