Considérations relatives aux environnements de plateforme sous forme de service pour la configuration de Liberty
Les environnements PaaS tels qu'IBM Cloud, 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 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 peut être acheminée à n'importe quelle instance en exécution et n'est visible que 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
La plupart des environnements PaaS peuvent déchiffrer une demande en arrêtant SSL pour les demandes entrantes chiffrées sur le routeur HTTP. Ces demandes chiffrées
peuvent être de type HTTPS ou wss. La demande déchiffrée est ensuite transmise au serveur d'application en tant que demande HTTP ou
wss déchiffrée. Certaines applications sont configurées de façon à être accessible uniquement par des demandes chiffrées. Vous pouvez définir cette
configuration dans le fichier web.xml à 'aide de l'élément
transport-guarantee ou de l'élément transportGuarantee sur l'annotation @HttpConstraint.
Certaines fonctions Liberty sont implémentées en tant qu'applications exigeant un transport sécurisé (notamment le connecteur REST, le centre d'administration et l'API Discovery).
Dans un environnement où SSL s'arrête, un mécanisme est nécessaire pour que le routeur indique au serveur d'application que la demande originelle du client était
chiffrée. Ce mécanisme assure que la demande d'application puisse néanmoins aboutir. Un en-tête
WebSphere privé est utilisé pour arrêter SSL dans DataPower, par exemple quand DataPower est utilisé avec IBM Cloud, ou dans IBM HTTP Server.
A partir du groupe de correctifs 16.0.0.4, quand d'autres routeurs HTTP sont utilisés,
le routeur peut définir l'en-tête X-Forwarded-Proto pour indiquer le protocole de la demande d'origine. Si la demande était
originellement chiffrée, l'en-tête indique le protocole HTTPS ou wss. Le serveur Liberty autorise alors l'accès aux applications qui requièrent un transport
sécurisé.
Les fonctions suivantes requièrent que le routeur définisse des en-têtes HTTP pour indiquer qu'un arrêt SSL s'est produit :
- ssl-1.0
- D'autres fonctions dépendantes de ssl-1.0, comme répertorié dans la section Fonctions 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.