Considérations relatives aux environnements de plateforme sous forme de service pour la configuration de Liberty
Les environnements PaaS tels qu'IBM® Bluemix, Pivotal Cloud Foundry et OpenShift Enterprise, permettent de gérer et de surveiller les instances d'application mais ils possèdent également certaines restrictions. En raison des caractéristiques inhérentes aux environnements de plateforme sous forme de service (PaaS), certaines fonctions Liberty sont redondantes ou se comportent différemment et ne sont donc pas prises en charge.
Restrictions concernant la gestion de serveur Liberty
Les fonctions associées aux collectivités Liberty ne s'appliquent pas à un environnement PaaS dans la mesure où toutes les instances de machine virtuelle Java de serveur Liberty sont démarrées, arrêtées et gérées par l'infrastructure PaaS. La fonction Centre d'administration de Liberty n'est pas conçue pour une utilisation dans un environnement PaaS, sous lequel une application peut être configurée pour utiliser plusieurs instances de machine virtuelle Java sans contrôleur de collectivité. Dans cette topologie, une demande au Centre d'administration pourrait être transmise à n'importe quelle instance en cours et être uniquement visible sur le serveur sur lequel s'exécute la demande.
- 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
Restrictions liées aux systèmes de fichiers
La plupart des environnements PaaS ne fournissent pas de système de fichiers local persistant pour leurs applications. Pour Liberty, cela a une incidence tant sur les applications que sur les composants dans le serveur qui consignent des données localement et s'attendent à une persistance des données après un redémarrage de la machine virtuelle Java du serveur.
Le gestionnaire de transactions Liberty consigne les fichiers journaux sur le système de fichiers local lorsque plusieurs gestionnaires de ressources sont impliqués dans la transaction. Si les journaux ne sont pas disponibles après une défaillance d'une machine virtuelle Java et son redémarrage, les transactions ne peuvent pas être complétées automatiquement et doivent être résolues manuellement pour déverrouiller les données et assurer leur cohérence entre les divers gestionnaires de ressources. Pour éviter ce scénario, le pack de construction ou la cartouche Liberty empêchent la consignation de transactions et renvoient une exception à l'application pour empêcher la mobilisation de la seconde ressource. Par conséquent, bien que vous puissiez continuer à utiliser des transactions avec une ressource XA unique, une seconde ressource transactionnelle ne peut pas être mobilisée dans une transaction. Par ailleurs, la spécification Web Services Atomic Transactions ne peut pas être utilisée puisqu'elle consigne toujours des enregistrements de journal.
-Dcom.ibm.tx.jta.disable2PC=true
- wsAtomicTransaction-1.2
- Autres fonctions utilisant des transactions, en fonction du comportement de l'application.
Restrictions liées au réseau
- appClientSupport-1.0
- appSecurityClient-1.0
- ejbRemote-3.2
Dans certaines situations, comme une terminaison SSL sur le routeur, Liberty s'attend à des en-têtes HTTP pour décrire divers aspects de la requête client originale. Lorsque vous utilisez SSL dans un environnement PaaS, les en-têtes doivent être définis par le routeur PaaS. Sur IBM Bluemix, ces en-têtes sont déjà définis et vous pouvez donc utiliser sans aucune modification la fonction ssl-1.0 et les autres fonctions qui en dépendent. Pour aboutir au comportement prévu dans d'autres environnements PaaS, vous devrez peut-être configurer le routeur en définissant ces en-têtes comme décrit dans NGINX and WebSphere Application Server.
- ssl-1.0
- Autres fonctions dépendantes de ssl-1.0, répertoriées dans la section Fonctions, et qui activent cette fonction de Secure Socket Layer
Processeur swagger de Liberty
Dans un environnement Cloud Foundry, le processeur swagger dans Liberty, notamment son interface utilisateur, vérifie l'existence de la variable d'environnement VCAP_APPLICATION. Il utilise le premier élément de la grappe URIS comme hôte d'API.