Hinweise für PaaS-Umgebungen (Platform as a Service) für die Konfiguration von Liberty
In PaaS-Umgebungen (Platform-as-a-service), wie z. B. IBM Cloud, 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 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 das Admin Center an eine der aktiven Instanzen weitergeleitet werden 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
Die meisten PaaS-Umgebungen können eine Anforderung entschlüsseln, indem sie SSL für verschlüsselte eingehende Anforderungen am HTTP-Router beenden. Diese verschlüsselten Anforderungen können HTTPS oder wss sein. Die entschlüsselte Anforderung wird anschließend als entschlüsselte HTTP- oder wss-Anforderung an den Anwendungsserver übergeben. Einige Anwendungen sind so konfiguriert, dass nur verschlüsselte Anforderungen auf sie zugreifen können. Sie können diese Konfiguration in der Datei web.xml der Anwendung definieren, indem Sie das Element "transport-guarantee" oder das Element "transportGuarantee" über die Annotation @HttpConstraint verwenden. Einige Liberty-Features werden als Anwendungen implementiert, die ein sicheres Transportprotokoll voraussetzen. Hierzu gehören der REST-Connector, das Admin Center und API Discovery.
In einer Umgebung, in der SSL beendet wurde, wird ein Mechanismus für den Router als Angabe für den Anwendungsserver benötigt, dass die ursprüngliche Anforderung vom Client verschlüsselt war. Dieser Mechanismus stellt sicher, dass die Anwendungsanforderung immer noch ausgeführt werden kann. In DataPower wird ein privater WebSphere-Header verwendet, um SSL zu beenden. Dies ist z. B. der Fall, wenn DataPower mit IBM Cloud oder in IBM HTTP Server verwendet wird. Ab Fixpack 16.0.0.4, wenn andere HTTP-Router verwendet werden, kann der Router den Header "X-Forwarded-Proto" setzen, um das Protokoll der ursprünglichen Anforderun g anzugeben. Wenn die Anforderung ursprünglich verschlüsselt war, gibt der Header das HTTPS- oder das wss-Protokoll an. Der Liberty-Server ermöglicht anschließend den Zugriff auf Anwendungen, die ein sicheres Transportprotokoll benötigen.
Für die folgenden Features ist es erforderlich, dass der Router HTTP-Header definiert, um anzugeben, dass SSL beendet wurde:
- ssl-1.0
- Weitere von ssl-1.0 abhängige Features sind im Abschnitt Features that enable this feature unter Secure Socket Layer aufgelistet.
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.