JBoss-Plattform modernisieren
Sie übernehmen eine JBoss-Landschaft. Jede Instanz ist der Fingerabdruck dessen, der sie zuletzt angefasst hat. Kein gemeinsamer Standard. Kein dokumentiertes Soll. Nur Server, die laufen, und die Frage: Was ist hier eigentlich die Baseline?
Tag 1 als neuer Platform Lead. Sie finden 23 JBoss-Instanzen vor.
Die Instanzen laufen das Kerngeschäft: Fachverfahren, Zahlungsverarbeitung, Kundendaten. Der Vorgänger ist weg. Was er gebaut hat, läuft noch. Was genau läuft, und warum es so konfiguriert wurde, weiß niemand mehr.
- jboss-prod-01 EAP 7.1 — EOL seit 2022
- jboss-prod-02 EAP 7.4.8 — manuell gepatcht
- jboss-prod-03 EAP 7.4.12 — Skript unbekannt
- Management Console offen im Netz (7 Instanzen)
- Management Console localhost only (16 Instanzen)
- Startup-Skripte 4 verschiedene Varianten
- Connector-Config 6 verschiedene Varianten
- JVM-Heap-Settings nirgends dokumentiert
- Baseline nicht definiert
- Vorgänger nicht mehr erreichbar
Eine verbindliche Baseline, die festlegt: So sieht eine korrekte JBoss-EAP-Instanz in dieser Umgebung aus. Nicht als Word-Dokument, sondern als Code im Repository.
Die Baseline wird auf alle Instanzen angewendet, reproduzierbar und ohne manuelle Schritte. Was einmal konfiguriert wurde, bleibt konfiguriert und lässt sich jederzeit wieder so herstellen.
Welche Instanz hat welche Konfiguration? Wann wurde sie geändert? Was weicht vom Soll ab? Diese Antworten kommen aus der Versionsverwaltung, nicht aus dem Gedächtnis einzelner Personen.
Das nächste Mal, wenn jemand geht, geht das Wissen nicht mit. Es steckt in Ansible-Rollen und Git-Repos, nicht in einer einzelnen Person.
Nicht ein Update. Eine Grundlage.
JBoss auf eine neue Version zu heben ist keine Modernisierung. Modernisierung bedeutet, dass Sie danach wissen, was läuft, warum es läuft, und dass Sie es jederzeit wieder exakt so herstellen können.
Welche Instanzen existieren, welche JBoss-Versionen laufen, welche Anwendungen sind deployed, wo liegen Abweichungen zwischen Instanzen. Keine Annahmen, nur Fakten aus der tatsächlichen Umgebung.
Was soll eine JBoss-EAP-Instanz in Ihrer Umgebung leisten? Welche Ports sind offen, welche nicht? Welche Security-Einstellungen gelten verbindlich? Das wird festgeschrieben, nicht beschlossen und dann vergessen.
Die Baseline wird automatisiert auf alle Instanzen angewendet. Ansible-Rollen, keine Skripte, die irgendwann irgendwer schrieb. Reproduzierbar. Prüfbar. Jederzeit wieder anwendbar.
Jede Instanzkonfiguration ist dokumentiert, versioniert und auditierbar. Nicht als Screenshot oder als Word-Dokument, sondern als Code im Repository, der die Geschichte jeder Änderung festhält.
Ansible-Rollen für jeden Schritt des JBoss-Betriebs
Die lennlay.jboss Enterprise Collection bündelt Rollen für Installation, Härtung, Konfiguration und Compliance-Prüfung. Alles, was Sie brauchen, um JBoss-EAP-Instanzen in einem definierten, nachvollziehbaren Zustand zu halten.
JBoss EAP wird in einer definierten, reproduzierbaren Weise installiert. Keine manuellen Schritte, keine offenen Fragen hinterher. Beim nächsten Einsatz läuft dieselbe Rolle, mit demselben Ergebnis.
CIS-basierte Härtungs-Baseline: Management-Interface-Schutz, Connector-Konfiguration, Security-Subsystem. Kein Checklisten-Abhaken von Hand, sondern eine automatisierte, jederzeit wiederholbare Policy. Jede Instanz bekommt dieselbe Baseline.
Standardisiertes Konfigurations-Management. Anwendungs-Deployments laufen über Ansible, nicht über die Management Console oder SCP. Was deployed ist, ist dokumentiert, versioniert und rückverfolgbar.
Scanner-Skripte prüfen eine laufende JBoss-Instanz gegen die definierte Baseline. Drifts werden erkannt, bevor der Auditor sie findet. Nicht als einmaliger Scan, sondern als laufende Kontrolle des Ist-Zustands.
Die JBoss-Baseline als geliefertes Artefakt
Red Hat JBoss EAP ist im GIaaS-MVP-Katalog. Die gehärtete JBoss-Baseline existiert als policy-gesteuertes Artefakt, nicht als manuelle Konfiguration, die irgendwo auf einem Server lebt und nie wieder so reproduziert werden kann.
GIaaS verkauft keine Images. GIaaS verkauft Sicherheit, Verantwortung und Audit-Sicherheit.
Definiert, was eine konforme JBoss-EAP-Instanz ausmacht. Security-Anforderungen, Konfigurationsstandards, Patch-Stand.
Automatisierter Build-Prozess. Die Policy wird in ein konkretes, getestetes Artefakt übersetzt. Kein manueller Schritt zwischen Definition und Ergebnis.
Das Artefakt wird versioniert, signiert und in einem kontrollierten Katalog bereitgestellt. Keine Ad-hoc-Images, keine unbekannte Provenienz.
Auslieferung an die Zielumgebung. Jeder Empfänger weiss, was er bekommt, und kann es gegen die Policy prüfen.
Voraussetzung für JBoss EAP: gültige Red Hat-Subscription.
Drei Momente, in denen Standardisierung aufhört, optional zu sein
JBoss-EAP-Versionen erreichen ihr End-of-Life. Es gibt keinen klaren Migrationspfad, weil es keinen definierten Standard gibt, zu dem migriert werden soll. Ohne Baseline gibt es keine Zielplattform, auf die man zusteuern kann.
Internes oder externes Audit steht an. Jede Instanz hat eine andere Konfiguration. Eine dokumentierte Baseline existiert nicht. Die erste Frage des Auditors kann niemand beantworten.
Die Person, die die JBoss-Landschaft kennt, hat das Unternehmen verlassen. Institutionelles Wissen über Konfiguration, Abhängigkeiten und Besonderheiten ist weg. Was bleibt, sind Server, die laufen, und niemand, der erklären kann, warum sie so konfiguriert sind.
JBoss-Plattform analysieren
Schildern Sie uns Ihre JBoss-Situation. In 15 Minuten klären wir gemeinsam, was der erste sinnvolle Schritt ist, und ob EaaS, die jboss Collection oder GIaaS der richtige Einstieg für Ihre Umgebung ist.
