Hinweise für PaaS-Umgebungen (Platform as a Service) für die Konfiguration von Liberty
In PaaS-Umgebungen (Platform as a Service) wie IBM® Bluemix, Pivotal Cloud Foundry und OpenShift Enterprise können Anwendungsinstanzen verwaltet und überwacht werden. Sie unterliegen aber auch einigen Einschränkungen. Aufgrund der PaaS-Umgebungen innewohnenden Merkmale sind einige Liberty-Features überflüssig oder weisen ein anderes Verhalten auf und werden daher nicht unterstützt.
Einschränkungen bezüglich des Liberty-Server-Managements
Features für Liberty-Verbünde gelten nicht für eine PaaS-Umgebung, weil alle JVM-Instanzen eines Liberty-Servers von der PaaS-Infrastruktur gestartet, gestoppt und verwaltet werden. Das Liberty-Feature "Admin Center" ist nicht für die Verwendung in einer PaaS-Umgebung vorgesehen, in der eine Anwendung für die Verwendung mehrerer JVM-Instanzen ohne Verbundcontroller skaliert werden kann. In dieser Topologie könnte eine Anforderung an Admin Center an eine der aktiven Instanzen weitergeleitet weitern und wäre nur in dem Server sichtbar, in dem die Anforderung ausgeführt wird.
- adminCenter-1.0
- clusterMember-1.0
- collectiveController-1.0
- collectiveMember-1.0
- dynamicRouting-1.0
- healthAnalyzer-1.0
- healthManager-1.0
- scalingController-1.0
- scalingMember-1.0
Einschränkungen bezüglich des Dateisystems
Die meisten PaaS-Umgebungen stellen ihren Anwendungen kein persistentes lokales Dateisystem bereit. Im Falle von Liberty wirkt sich dies auf die Anwendungen und Komponenten im Server aus, die Daten lokal schreiben und erwarten, dass diese nach einem Neustart der Server-JVM persistent gespeichert werden.
Der Liberty-Transaktionsmanager schreibt Protokolldateien in das lokale Dateisystem, wenn mehrere Ressourcenmanager an der Transaktion beteiligt sind. Wenn die Protokolle nach einem JVM-Ausfall und -Neustart nicht verfügbar sind, können Transaktionen nicht automatisch ausgeführt werden und müssen manuell aufgelöst werden, um Daten zu entsperren und eine Konsistenz der Daten in Ressourcenmanagern zu erzielen. Um dieses Szenario zu vermeiden, verhindert das Liberty-Buildpack oder die Liberty-Cartridge, dass Transaktionsprotokolldatensätze geschrieben werden und gibt eine Ausnahme an die Anwendung aus, damit die zweite Ressource nicht eingetragen wird. Sie können Transaktionen zwar weiterhin mit einer einzigen XA-Ressource verwenden, aber es kann keine zweite Transaktionsressource in einer Transaktion eingetragen werden. Atomare Web-Service-Transaktionen (Web Services Atomic Transactions) können nicht verwendet werden, weil sie immer Protokolldatensätze schreiben.
-Dcom.ibm.tx.jta.disable2PC=true
- wsAtomicTransaction-1.2
- Weitere Features, die Transaktionen verwenden und vom Anwendungsverhalten abhängig sind
Netzeinschränkungen
- appClientSupport-1.0
- appSecurityClient-1.0
- ejbRemote-3.2
In einigen Situationen, z. B. bei der SSL-Beendigung im Router, stützt sich Liberty zum Beschreiben von Aspekten der ursprünglichen Clientanforderung auf HTTP-Header. Wenn Sie SSL in einer PaaS-Umgebung verwenden, müssen die Header vom PaaS-Router festgelegt werden. In IBM Bluemix sind diese Header bereits festgelegt, sodass Sie das Feature ssl-1.0 und alle abhängigen Features ohne Änderungen verwenden können. Um das erwartete Verhalten in anderen PaaS-Umgebungen zu erzielen, müssen Sie den Router möglicherweise so konfigurieren, dass er diese Header festlegt. Informationen hierzu finden Sie unter NGINX and WebSphere Application Server.
- ssl-1.0
- Weitere Features, die von ssl-1.0 abhängig und unter Features, die dieses Feature aktivieren im Abschnitt Secure Socket Layer aufgelistet sind.
Liberty-Swagger-Prozessor
In einer Cloud Foundry-Umgebung prüft der Swagger-Prozessor in Liberty, einschließlich der zugehörigen Schnittstelle das Vorhandensein der Umgebungsvariablen VCAP_APPLICATION. Er verwendet das erste Element des uris-Arrays als API-Host.