Liberty-Installation, Feature-Manager, Verzeichnisstruktur

Setzt 00-was-ist-websphere.md voraus, falls die Einordnung Liberty vs. traditionelles WAS (Cell/Node/Dmgr, Editionen) noch nicht vertraut ist — dieses Dokument konzentriert sich bewusst nur auf den Liberty-Installationsteil.

Status: verifiziert. Alle Aussagen unten sind gegen einen echten, in dieser Umgebung gestarteten Open-Liberty-Server geprüft — siehe 02-liberty-serverstart-verifiziert.md für den konkreten Log-Nachweis.

Zwei Wege, Liberty zu "installieren"

Ein WAS-Spezialist trifft in der Praxis auf zwei grundlegend unterschiedliche Installationswege — beide sollte man kennen:

Klassisch/manuell: Liberty-ZIP/-Installer von IBM herunterladen, entpacken (wlp/-Verzeichnis), server create <name> ausführen, server.xml von Hand pflegen. So passiert es typischerweise auf einem produktiven Linux-Server, den der WAS-Admin selbst betreut.
Build-getrieben (dieses Projekt): der liberty-maven-plugin lädt die Runtime als Maven-Artefakt (io.openliberty:openliberty-runtime), erzeugt daraus einen Server und deployt die Anwendung automatisch — siehe concordia-portal/pom.xml. Das ist kein Ersatz für Weg 1, sondern das für Entwicklung/CI/Nachweis übliche Muster (Reproduzierbarkeit, keine manuellen Schritte) — im echten Betrieb kommt am Ende trotzdem ein wlp/usr/servers/<name>/-Verzeichnis heraus, das genauso aussieht wie bei Weg 1.

Verzeichnisstruktur, die dabei entsteht

concordia-portal/target/liberty/wlp/
  bin/                       Liberty-CLI (server, securityUtility, ...)
  usr/
    servers/
      concordiaPortalServer/
        server.xml           <- unsere Config, siehe unten
        apps/                deployte Anwendung(en)
        logs/
          messages.log       <- menschenlesbares Log, hier verifiziert (CWWKF0011I)
          console.log
        workarea/            interner Laufzeitzustand

Wichtig für den Admin-Alltag: server.xml ist die einzige Datei, die man normalerweise von Hand pflegt — alles unter workarea/ ist reine Laufzeit-Ablage und wird bei jedem Start neu aufgebaut.

Feature-Manager: das Kernkonzept von Liberty

Der große konzeptionelle Unterschied zu traditionellem WebSphere: Liberty startet nur die Features, die explizit in server.xml angefordert werden — kein "alles ist installiert, man schaltet nur den Traffic frei", sondern echtes On-Demand-Modell:

<featureManager>
    <feature>servlet-6.0</feature>
    <feature>monitor-1.0</feature>
</featureManager>

Das ist unser aktueller Stand (siehe concordia-portal/src/main/liberty/config/server.xml). Weitere Ausbaustufen ergänzen gezielt:

Feature	Ausbaustufe	Zweck
`servlet-6.0`	1 (aktuell)	Web-Container für die Beispielanwendung
`monitor-1.0`	1 (aktuell)	Basis-Monitoring-MBeans, siehe `docs/20-monitoring-tuning/`
`ssl-1.0`, `appSecurity-5.0`	3	HTTPS + Security-Infrastruktur
`ldapRegistry-3.0`	3	Anbindung an das zentrale LDAP-Verzeichnis, siehe `docs/60-security-lifecycle/`
`jdbc-4.3`	5	DataSource zu DB2 (Stand-in), siehe `docs/40-bindeglied-dev-ops-db2-netzwerk/`

Warum das für den Betrieb zählt: jedes zusätzliche Feature bedeutet mehr Angriffsfläche und mehr Speicherverbrauch beim Start. Ein WAS-Admin, der ein server.xml reviewt, sollte routinemäßig fragen "wird dieses Feature wirklich gebraucht?" — bei traditionellem WAS gibt es diese Stellschraube in der Form nicht (dort ist der Großteil immer mitinstalliert).

Zwei Betriebsarten im Alltag

mvn liberty:run (Vordergrund, Strg+C zum Beenden) — der tägliche Admin-/Debugging-Modus: Server bleibt oben, Logs laufen live mit.
mvn verify -Pliberty-verify (nicht-interaktiv, startet+prüft+stoppt automatisch) — das CI-/Nachweis-Muster, das auch die Verifikation in diesem Projekt nutzt (siehe 02-liberty-serverstart-verifiziert.md).

Beide nutzen dasselbe server.xml — kein Unterschied in der Konfiguration, nur in der Aufruf-Art.

⌂ Cockpit