# Concordia Bank AG — WebSphere-Liberty-Betriebslernprojekt Lernprojekt zur Vorbereitung auf ein Bewerbungsgespräch für die Rolle **"Websphere Application Server Spezialist (WAS)"**. Im Gegensatz zu den meisten anderen Projekten in diesem Workspace liegt der Fokus **nicht auf Java-Entwicklung, sondern auf Middleware-Betrieb**: Liberty installieren/konfigurieren, überwachen, tunen, troubleshooten, automatisiert deployen, absichern (LDAP/SSL/Rollen) und hochverfügbar betreiben — exakt die Punkte aus der zugrunde liegenden Stellenanzeige. **Fachlicher Rahmen:** eine fiktive Bank (Core-Banking auf z/OS + DB2 for z/OS, Portale auf WebSphere Liberty, zentrales LDAP) — Details siehe [`docs/00-ueberblick/systemlandschaft.md`](docs/00-ueberblick/systemlandschaft.md). **Ehrlichkeits-Konvention** (übernommen aus dem Referenzprojekt `labs/novaris-versicherung-legacy`): jede Doku-Seite kennzeichnet klar, ob eine Aussage **gegen einen echten laufenden Server/Container verifiziert** ist, oder nur **dokumentiert/ vorbereitet** (z. B. weil echtes DB2 for z/OS oder ein IBM-MQ-HA-Cluster hier nicht verfügbar sind). ## Schnellstart Voraussetzungen: PowerShell 7, JDK 21, Maven und Podman (oder Docker) für die Infrastruktur-Abhängigkeiten. Für die manuelle Unix-/WSL-Variante liegt weiterhin die Bash-Skriptsammlung bei. Der plattformübergreifende PowerShell-Prüfeinstieg erzeugt Zertifikat und Truststore nativ. Infrastruktur zuerst (LDAP-Verzeichnis der fiktiven Bank, per LDAPS - siehe [`docs/60-security-lifecycle/04-ldaps-tls.md`](docs/60-security-lifecycle/04-ldaps-tls.md)): ```bash bash scripts/ldap-tls-cert-generate.sh # einmalig: eigenes TLS-Zertifikat mit korrektem SAN cd infra podman compose up -d cd .. bash scripts/ldap-tls-trust-setup.sh # Liberty-Truststore aus dem Zertifikat bauen ``` Die reproduzierbaren Prüfeinstiege liegen im Repository: ```powershell pwsh -NoProfile -File ci/scripts/verify-repository.ps1 -Mode Fast pwsh -NoProfile -File ci/scripts/verify-repository.ps1 -Mode Full pwsh -NoProfile -File ci/scripts/verify-repository.ps1 -Mode Integration ``` Dann Liberty: ```bash # Liberty-Server starten (echter Open-Liberty-Prozess, kein Docker-Image) cd concordia-portal CONCORDIA_LDAP_BIND_PASSWORD="ConcordiaAdmin123!" mvn liberty:run # in einem zweiten Terminal: curl http://localhost:19080/concordia-portal/health curl -u "m.bauer:AdminDemo123!" http://localhost:19080/concordia-portal/secure/whoami # Strg+C im ersten Terminal zum Beenden ``` Nicht-interaktive Variante (startet, verifiziert, stoppt automatisch wieder): ```bash cd concordia-portal CONCORDIA_LDAP_BIND_PASSWORD="ConcordiaAdmin123!" mvn verify -Pliberty-verify ``` ## Struktur | Verzeichnis | Inhalt | |---|---| | `docs/` | Ausführliche Doku, eine Ausbaustufe pro Zehner-Nummer — siehe Roadmap in [`docs/00-ueberblick/systemlandschaft.md`](docs/00-ueberblick/systemlandschaft.md) | | `concordia-portal/` | Maven-Modul (Jakarta EE, `liberty-maven-plugin`) — die duenne Beispielanwendung, an der die WAS-Administrationsthemen demonstriert werden | | `infra/` | Docker/Podman-Compose **nur** für Infrastruktur-Abhängigkeiten (OpenLDAP) — Liberty selbst läuft über Maven, nicht hier. Echtes DB2 for z/OS ist nicht verfügbar, siehe [`docs/40-bindeglied-dev-ops-db2-netzwerk/`](docs/40-bindeglied-dev-ops-db2-netzwerk/) | | `scripts/` | Betriebs-/Hilfsskripte (`deploy.sh`, `health-check.sh`, `ldap-test.sh`, `gc-log-analyse.sh`, `cert-rotation.sh`, `md-to-html.py`) — siehe [`docs/50-automatisierung-deployment/`](docs/50-automatisierung-deployment/) | | `Jenkinsfile` | CI/CD-Pipeline im Workspace-Stage-Muster, siehe [`docs/50-automatisierung-deployment/02-jenkinsfile-und-uebergabe.md`](docs/50-automatisierung-deployment/02-jenkinsfile-und-uebergabe.md) | | `project.yaml` | Maschinenlesbarer Projektstatus für das zentrale Workspace-Cockpit | | `ci/scripts/verify-repository.ps1` | Einheitlicher PowerShell-7-Einstieg für Unit-, Build- und echte LDAP-/Liberty-Prüfungen | ## Werkzeuge in diesem Projekt - **`scripts/md-to-html.py`**: erzeugt aus jeder `.md`-Datei eine `.html`-Schwesterdatei im selben Stil wie im Referenzprojekt (inline CSS, `color-scheme: light dark`). Im Workspace existiert kein zentrales Konvertierungs-Tool dafür, deshalb ein kleines, projektlokales Skript statt Handarbeit pro Datei: ```bash python scripts/md-to-html.py --all ``` ## Status Alle Ausbaustufen aus der Roadmap in [`docs/00-ueberblick/systemlandschaft.md`](docs/00-ueberblick/systemlandschaft.md#ausbaustufen-roadmap) sind angelegt. Nachweistabelle unten für den direkten Abgleich mit der Anzeige. Der kanonische Workspace-Pfad ist `labs/concordia-bank-middleware`; das private GitHub- Repository heißt `nursude/concordia-bank-middleware` und verwendet ausschließlich `main`. ## Nachweistabelle: Anzeigen-Anforderung → Projektstelle | Anzeigen-Anforderung | Wo im Projekt | Status | |---|---|---| | Installation, Instandhaltung und Konfiguration von Websphere Liberty | [`docs/10-installation-konfiguration/`](docs/10-installation-konfiguration/) | ✅ verifiziert | | Monitoring, Troubleshooting, Tuning/Skalierung (Java Heap, GC, Threads, Pools) | [`docs/20-monitoring-tuning/`](docs/20-monitoring-tuning/), [`docs/30-troubleshooting-runbooks/`](docs/30-troubleshooting-runbooks/) | ✅ verifiziert (HotSpot), Semeru/OpenJ9 dokumentiert | | Bindeglied Java-Entwicklung ↔ WAS-Administration ↔ DB2 für z/OS, Netzwerk (dezentral/zentral) | [`docs/40-bindeglied-dev-ops-db2-netzwerk/`](docs/40-bindeglied-dev-ops-db2-netzwerk/) | 📄 dokumentiert (kein echtes z/OS verfügbar) | | Implementierung/Automation von Betriebs-, Deployment- und Testprozessen | [`docs/50-automatisierung-deployment/`](docs/50-automatisierung-deployment/), [`scripts/`](scripts/), [`Jenkinsfile`](Jenkinsfile) | ✅ verifiziert (alle 5 Skripte real getestet) | | Bereitstellung/Administration der Applikationen inkl. Übergabe an Betrieb und Support | [`docs/50-automatisierung-deployment/02-jenkinsfile-und-uebergabe.md`](docs/50-automatisierung-deployment/02-jenkinsfile-und-uebergabe.md) | ✅ verifiziert (Checkliste + real getesteter Deploy-Zyklus) | | Einspielung und Konfiguration der Software | [`docs/10-installation-konfiguration/`](docs/10-installation-konfiguration/) | ✅ verifiziert | | Unterstützung beim Aufbau einer Infrastruktur | [`infra/`](infra/), [`docs/00-ueberblick/systemlandschaft.md`](docs/00-ueberblick/systemlandschaft.md) | ✅ verifiziert (OpenLDAP-Infra von Grund auf aufgesetzt) | | Security Lifecycle: Rollen und Rechte, Zertifikate, SSL | [`docs/60-security-lifecycle/`](docs/60-security-lifecycle/) | ✅ verifiziert (LDAP-Auth, Rollen-Mapping, SSL, Zertifikatsrotation) | | Sehr gute WAS-/Middleware-Kenntnisse | gesamtes Projekt, insb. [`docs/10-installation-konfiguration/`](docs/10-installation-konfiguration/) | ✅ | | Gute LDAP-Kenntnisse | [`docs/60-security-lifecycle/02-ldap-registry.md`](docs/60-security-lifecycle/02-ldap-registry.md) | ✅ verifiziert | | Linux/UNIX-Umfeld | alle Skripte/Doku bash-basiert, `infra/` containerisiert | ✅ | | High Availability (24x7) AppServer | [`docs/70-high-availability/01-appserver-ha-demo.md`](docs/70-high-availability/01-appserver-ha-demo.md) | ✅ verifiziert (zwei echte, gleichzeitig laufende Knoten) | | High Availability Messaging | [`docs/70-high-availability/02-messaging-ha.md`](docs/70-high-availability/02-messaging-ha.md) | 📄 dokumentiert (kein IBM-MQ-Cluster verfügbar) | Legende: ✅ = gegen echten Server/Container verifiziert, 📄 = dokumentiert/vorbereitet (Begründung jeweils auf der verlinkten Seite). ## Lizenz / Nutzung Privates Lernprojekt. Kein Produktionscode, keine echten Daten.