Disponible avec une licence Workflow Manager.
Un serveur proxy inverse est un ordinateur généralement déployé sur un réseau de périmètre (appelé également zone démilitarisée (DMZ) ou sous-réseau filtré) qui gère des requêtes provenant d’Internet et les transmet aux machines de votre réseau interne. Le proxy inverse masque l’identité des ordinateurs derrière le pare-feu de votre organisation en transmettant des requêtes entrantes pour protéger les ordinateurs internes de toute attaque directe provenant des utilisateurs d’Internet.
ArcGIS Workflow Manager Server peut éventuellement être configuré pour utiliser le serveur proxy inverse de votre organisation. Si votre organisation n’utilise pas de serveur proxy inverse ou si vous ne souhaitez pas configurer un proxy inverse avec Workflow Manager Server, configurez Workflow Manager avec un portail ArcGIS Enterprise.
Ajouter Workflow Manager Server à un serveur proxy inverse
Workflow Manager Server requiert un acheminement de demandes basé sur chemin d’accès entre deux ports en arrière-plan : 6443 pour les connexions ArcGIS Server et 13443 pour les connexions Workflow Manager Server.
ArcGIS Web Adaptor procède à un acheminement dans le cadre de sa configuration par défaut, de manière à pouvoir placer le proxy inverse de couche 3/4 ou de couche 7 devant ArcGIS Web Adaptor dans le chemin de réseau pour l’accès client. Si vous décidez de ne pas utiliser ArcGIS Web Adaptor dans le chemin réseau, le proxy inverse de couche 7 est requis pour acheminer des demandes entre les clients et Workflow Manager Server.
En savoir plus sur les types d’équilibreurs de charge
Proxy inverse de couche 3/4
Les proxies inverses de couche 3/4 transmettent le trafic de protocole WebSocket par défaut sans configuration supplémentaire requise. Les proxies inverses de couche 3/4 impliquent d’installer ArcGIS Web Adaptor pour acheminer correctement les cibles en arrière-plan.
Proxy inverse de couche 7
Dans les exemples suivants, https://example.domain.com/server fait office d’URL de service, FQDN1 et FQDN2 étant les noms d’hôte de la cible en arrière-plan. Si vous utilisez une seule machine Workflow Manager Server, le groupe cible ne contient qu’un seul hôte.
Configuration avec ArcGIS Web Adaptor dans le chemin réseau
Dans cet exemple, les hôtes en arrière-plan FQDN1 et FQDN2 hébergent un ArcGIS Web Adaptor nommé server. Workflow Manager implique de transmettre le trafic WebSocket à travers le proxy inverse à partir des clients de connexion. Le trafic peut être équilibré à l’aide d’un algorithme round-robin avec contrôles d’intégrité configurés sur les cibles en arrière-plan. Il s’agit de s’assurer que le serveur Web transmet le trafic comme prévu.
Un exemple de configuration permettant d’activer le protocole WebSocket dans une configuration Apache httpd est présenté ci-dessous :
RewriteEngine On
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteRule ^/server/workflow/(.*)? "balancer://wss_webadaptor_endpoint/$1" [P,L]
<Proxy balancer://wss_webadaptor_endpoint>
BalancerMember wss://FQDN1/server
BalancerMember wss://FQDN2/server
</Proxy>https://example.domain.com/server est utilisé ci-après en tant qu’URL de services et FQDN en tant que nom d’hôte de la machine pour acheminer le trafic vers les hôtes de l’adaptateur Web :
ProxyPass /server balancer://webadaptor_endpoint/server
ProxyPassReverse /server balancer://webadaptor_endpoint/server
<Proxy balancer://webadaptor_endpoint>
BalancerMember https://FQDN1/server
BalancerMember https://FQDN2/server
</Proxy>Configuration sans ArcGIS Web Adaptor dans le chemin réseau
Si vous décidez de ne pas utiliser ArcGIS Web Adaptor dans le chemin réseau, un proxy inverse de couche 7 est requis pour acheminer des demandes entre les clients et Workflow Manager. Les en-têtes X-Forwarded-Host et X-Forwarded-Request-Context doivent être définis sur les demandes en proxy avec la valeur de l’en-tête Host du client d’origine.
Un exemple de configuration permettant d’activer le protocole WebSocket dans une configuration Apache httpd est présenté ci-dessous :
RewriteEngine On
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteRule ^/server/workflow/(.*)? "balancer://workflow_endpoint_wss/$1" [P,L]
<Proxy balancer://workflow_endpoint_wss>
BalancerMember wss://FQDN1:13443
BalancerMember wss://FQDN2:13443
</Proxy>Lorsque vous définissez les cibles en arrière-plan, les règles basées sur chemin d’accès doivent être mises en œuvre sur l’équilibreur de charge pour envoyer le trafic vers les serveurs Web ArcGIS Server et Workflow Manager.
https://example.domain.com/server est utilisé ci-après en tant qu’URL de services et FQDN en tant que nom d’hôte de la machine dans l’exemple de règles d’acheminement basées sur chemin d’accès. Les demandes du client adressées à https://example.domain.com/server/workflow/* doivent être redirigées vers https://FQDN:13443/workflow, alors que les demandes adressées aux sous-chemins de niveau supérieur ou autres de https://example.domain.com/server/* doivent être redirigées vers https://FQDN:6443/arcgis:
Un exemple de configuration permettant d’ajouter des règles d’acheminement basées sur chemin d’accès est présenté ci-après pour les demandes de transfert adressées par le client :
ProxyPass /server/workflow balancer://workflow_manager_endpoint/workflow
ProxyPassReverse /server/workflow balancer://workflow_manager_endpoint/workflow
ProxyPass /server balancer://server_endpoint/arcgis
ProxyPassReverse /server balancer://server_endpoint/arcgis
<Proxy balancer://server_endpoint>
BalancerMember https://FQDN1:6443
BalancerMember https://FQDN2:6443
</Proxy>
<Proxy balancer://workflow_manager_endpoint>
BalancerMember https://FQDN1:13443
BalancerMember https://FQDN2:13443
</Proxy>Vous avez un commentaire à formuler concernant cette rubrique ?