← Zur Uebersicht
docs/50-automatisierung-deployment/01-skripte-und-liberty-cli.md

Automatisierung: Skripte und Liberty-CLI

Status: verifiziert. Jedes Skript unter scripts/ wurde in dieser Umgebung real ausgeführt (nicht nur syntaktisch geprüft).

Überblick

Skript Zweck Real getestet als
deploy.sh Kompletter Zyklus: bauen → Liberty starten → auf Bereitschaft warten → stoppen deploy.sh test → BUILD SUCCESS, Server lief nachweislich bis CWWKF0011I
health-check.sh Wartet mit Timeout auf HTTP 200 von /health Bestandteil von deploy.sh, zusätzlich einzeln nutzbar
ldap-test.sh Isolierter LDAP-Smoke-Test (Container erreichbar? Bind ok? Basis-DN lesbar?) Gegen concordia-openldap: alle drei Prüfungen erfolgreich
ldap-tls-cert-generate.sh Erzeugt ein eigenes LDAPS-Zertifikat mit korrektem Subject Alternative Name Siehe docs/60-security-lifecycle/04-ldaps-tls.md
ldap-tls-trust-setup.sh Baut den Liberty-Truststore aus diesem Zertifikat Wie oben
gc-log-analyse.sh Zieht Heap-/Thread-Report aus dem laufenden Liberty-Prozess via jcmd Erzeugt echten Report unter target-reports/, siehe docs/20-monitoring-tuning/
cert-rotation.sh Sichert alten Keystore, erzeugt neues Zertifikat Gegen Demo-Server ausgeführt: alter Fingerabdruck ≠ neuer Fingerabdruck, siehe docs/60-security-lifecycle/03-zertifikate-ssl.md

Warum deploy.sh NICHT selbst mit nohup/Hintergrundprozessen hantiert

Ein früherer Versuch, mvn liberty:run per nohup ... & selbst im Hintergrund zu starten und danach mit einer eigenen Health-Check-Schleife zu pollen, scheiterte unter Windows/Git-Bash mit einem Liberty-eigenen Fehlercode (CWWKM2002E ... RC=24). Statt das Hintergrundprozess-Problem selbst zu lösen, nutzt deploy.sh stattdessen das bereits erprobte, foreground-blockierende liberty-verify-Maven-Profil (siehe docs/10-installation-konfiguration/02-liberty-serverstart-verifiziert.md): Maven selbst kümmert sich um Start, Warten auf CWWKF0011I und sauberes Stoppen — ein Beispiel dafür, dass "das robustere, bereits verifizierte Werkzeug wiederverwenden" oft die bessere Wahl ist als "das eigene Skript cleverer machen".

Was ein echtes Deployment zusätzlich täte

Genau wie im Novaris-Referenzprojekt (dort explizit als "simuliert" gekennzeichnet) bildet deploy.sh einen Aspekt bewusst vereinfacht ab: es gibt keine drei getrennten physischen Zielserver für test/qs/prod in dieser Lernumgebung — jede Stage deployt lokal auf denselben Port. Ein echtes Deployment würde zusätzlich:

  1. Über SSH/Ansible/einen Jenkins-Agenten auf dem jeweiligen Zielserver der Stage ausgeführt.
  2. Die Stage-spezifischen Umgebungswerte (LDAP-Host, DB2-Connection, Zertifikate) aus einem Secret-Store beziehen statt aus lokalen Umgebungsvariablen.
  3. Bei Fehlschlag automatisch auf die vorherige Version zurückrollen (Rollback), statt nur fehlzuschlagen.

Liberty-CLI-Befehle, die hinter den Skripten stecken

Zum Nachschlagen — alle real in dieser Umgebung ausgeführt:

./server create <name>                 # neuen Server anlegen
./server start <name> / stop <name>    # start/stop
./server javadump <name>               # Thread-Dump, siehe docs/20-monitoring-tuning/
./securityUtility createSSLCertificate # Zertifikat erzeugen, siehe docs/60-security-lifecycle/

Alle unter concordia-portal/target/liberty/wlp/bin/ nach dem ersten Build verfügbar.

⌂ Cockpit