Utilisation d'hôtes virtuels

Vous pouvez utiliser des hôtes virtuels si vous souhaitez une isolation entre les applications et les noeuds finaux qui les desservent.

Un seul serveur d'application répond souvent aux demandes de plusieurs hôtes et configurations de port différents. Cela est dû à de multiples raisons, comme le fait qu'il s'exécute sur une machine dotée de plusieurs interfaces réseau sous différents noms ou qu'il est routé depuis un serveur HTPP, un proxy, ou un équilibreur de charge. Dans ce cas, vous pouvez si vous le souhaitez contrôler l'application qui peut être contactée depuis un hôte spécifique. Les hôtes virtuels fournissent cette fonctionnalité. Elle fait correspondre le nom d'hôte demandé et le numéro de port (tel que déterminé à partir de l'en-tête d'hôte HTTP) par rapport à la liste d'alias d'hôte configurée.

Dans WebSphere Application Server Liberty, la configuration par défaut est suffisante. L'hôte virtuel par défaut (default_host) fait correspondre les demandes de n'importe quelle association d'hôte et de port entrant, puis les transfère vers le conteneur d'application par défaut.

La liste ci-après illustre les principaux éléments de configuration lorsque vous configurez des hôtes virtuels.
  • Valeur d'ID de l'élément de configuration virtualHost.
  • Configuration du sous-élément hostAlias.
  • Configuration du sous-élément allowFromEndpoint (le cas échéant).
  • Configuration d'hôte virtuel dans le fichier ibm-web-bnd.xml ou ibm-web-bnd.xmi de WAR.
  • Valeur d'attribut de l'hôte de httpEndpoint.
  • Valeur d'attribut de l'ID de httpEndpoint.

Isolation de deux applications

L'exemple ci-après illustre l'une des utilisations les plus courantes de l'hébergement virtuel afin de permettre de comprendre la configuration nécessaire. Il montre comment configurer deux applications qui s'exécutent sur des ports différents. Plus loin, cet exemple illustre une application qui est uniquement disponible sur l'interface localhost.
<httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" />
<httpEndpoint id="alternateEndpoint" host="*" httpPort="9081" />

<virtualHost id="application-1">
    <hostAlias>your_host_name:9080</hostAlias>
</virtualHost>

<virtualHost id="application-2">
    <hostAlias>localhost:9081</hostAlias>
</virtualHost>

<enterpriseApplication location="myApp.ear" name="App1"/>
<webApplication location="myApp2.war" name="App2" />

L'élément defaultHttpEndpoint expose toutes les interfaces sur le port 9080, et l'élément alternateEndpoint expose toutes les interfaces sur le port 9081.

Si App1 a un fichier WAR avec un fichier ibm-web-bnd.xml qui indique <virtual-host name="application-1"/>, cette application est accessible uniquement à l'adresse your_host_name:9080/app1_context_root.

Si App2 (qui est un fichier WAR) comporte un fichier ibm-web-bnd.xml qui spécifie <virtual-host name="application-2"/>, cette application est accessible uniquement à l'adresse localhost:9081/app2_context_root.

Si une troisième application a été déployée et qu'elle n'a indiqué aucun hôte virtuel spécifique, dans cette configuration, cette application est accessible uniquement s'il s'agissait d'une demande par proxy contenant un en-tête HOST qui spécifie un port différent. Par exemple, si la demande a été effectuée vers un proxy sur le port 80, ce dernier n'est répertorié dans aucune spécification hostAlias, de sorte que la demande est routée vers l'hôte virtuel default_host.

Isolation des applications en fonction de l'hôte ou du port demandé

L'hôte virtuel par défaut dans Liberty est également utilisé pour les communications JMX. Si vous souhaitez isoler des communications JMX du trafic d'applications, vous devez procéder comme suit.
  1. Choisissez votre nom d'hôte virtuel et mettez à jour votre application afin de référencer le nouvel hôte (qui n'est pas celui par défaut). Ajoutez un élément virtual-host dans le fichier ibm-web-bnd.xml ou ibm-web-bnd.xmi du fichier WAR.
    <?xml version="1.0" encoding="UTF-8"?>
    <web-bnd
        xmlns="http://websphere.ibm.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://websphere.ibm.com/xmk/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-web-bnd_1_0.xsd"
        version="1.0" />
    
        <virtual-host name="proxiedRequests" />
    
    </web-bnd>
  2. Ajoutez un élément virtualHost dans votre fichier server.xml. Le nom doit correspondre à ce qui est spécifié dans l'application, et il doit définir les éléments hostAliases qui sont routés vers le nouvel hôte virtuel.
    Remarque : Le nom d'hôte et le port qui correspondent sont ceux qui ont été initialement demandés par l'utilisateur, lesquels peuvent ou non correspondre à l'hôte et au port utilisés par Liberty. L'exemple ci-après illustre un élément d'hôte virtuel ajouté dans votre fichier server.xml.
    <virtualHost id="proxiedRequests">
        <hostAlias>external.host.name:80</hostAlias>
        <hostAlias>external.host.name:443</hostAlias>
    </virtualHost>

    Si des demandes proviennent d'un proxy, cette configuration route elle-même toute demande effectuée sur l'hôte et le port du proxy vers l'hôte virtuel "proxiedRequests".

Restriction de l'accès en fonction du noeud final d'origine

Si vous voulez restreindre l'accès aux applications par défaut/système qui utilisent le noeud final defaultHttpEndpoint, vous devez effectuer suivre plusieurs étapes.
  1. Définissez un autre noeud final httpEndpoint. L'exemple ci-après illustre un autre noeud final httpEndpoint.
    <httpEndpoint id="localHostOnly" host="localhost" httpPort="9081" httpsPort="9444"/>

    Ce noeud final http indique host="localhost," ce qui signifie que les ports 9081 et 9444 sont exposés uniquement dans l'interface localhost.

  2. Mettez à jour les définitions virtualHost afin de spécifier l'attribut allowFromEndpointRef. Lorsque cet attribut est spécifié, un virtualHost accepte les demandes uniquement en provenance du noeud final spécifié. Exemple :
    <virtualHost id="default_host" allowFromEndpointRef="localHostOnly">
        <hostAlias>*:9081</hostAlias>
        <hostAlias>*:9444</hostAlias>
    </virtualHost>
    
    </virtualHost id="proxiedRequests">
        <hostAlias>*:9080</hostAlias>
        <hostAlias>*:9443</hostAlias>
        <hostAlias>external.host.name:80</hostAlias>
        <hostAlias>external.host.name:443</hostAlias>
    </virtualHost>
    Avec cette configuration :
    • L'hôte virtuel default_host accepte désormais les demandes qui sont adressées uniquement à localhost:9081 et localhost:9444 et qui proviennent également du noeud final localHostOnly. Toute autre demande vers les ports 9081 et 9444 est refusée. Par exemple, une demande en provenance du noeud final defaultHttpEndpoing par défaut avec des en-têtes Host qui font référence à localhost:9081 est refusée.
    • L'hôte virtuel proxiedRequests accepte désormais toute demande qui est émise vers les ports 9080 ou 9443 (qui sont les ports par défaut utilisés par le noeud final defaultHttpEndpoint), en plus de celles qui comportent un en-tête faisant référence au nom d'hôte externe du proxy et aux ports 80 ou 443.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_virtual_hosts
Nom du fichier : cwlp_virtual_hosts.html