Introduction
Cet article traite d'un cas d'utilisation basique que vous pourriez avoir dans un environnement de pré-production. Tous les composants ArcGIS Enterprise (Portal, Server et Data Store) existent sur une seule machine dans un réseau interne. Le proxy inverse BIG-IP permet de présenter le système à un autre réseau (qui peut être un réseau client interne ou un réseau public) avec tout le trafic client acheminé via l'appliance BIG-IP.
Cet article est divisé en trois sections principales. La première section est destinée aux administrateurs ArcGIS Enterprise et les oriente vers leurs tâches dans la langue et les termes qu'ils comprennent. La deuxième section est destinée à l'administrateur BIG-IP, en espérant lui parler dans la langue et les termes qu'il comprend. La dernière section aborde des options supplémentaires et des détails appropriés aux deux groupes d'administrateurs.
L'objectif de cet article est d'aider les administrateurs ArcGIS et F5 à travailler ensemble en décrivant un ensemble de procédures éprouvées autour desquelles collaborer. Cet article ne cherche pas à permettre aux administrateurs ArcGIS de configurer eux-mêmes F5 (ou vice versa). Il est supposé que les administrateurs ArcGIS sont des experts en ArcGIS et s'appuient sur la documentation Esri pour les détails. De même, il est supposé que les administrateurs F5 sont des experts en BIG-IP et s'appuient sur la documentation F5 pour les détails.
Bien que le cas d'utilisation soit « basique », l'entreprise n'est pas « simple ». Le succès nécessite l'intégration de technologies et de connaissances provenant de plusieurs domaines spécialisés (technologie Esri, technologie F5, réseautique, certificats, etc.). Si les procédures de cet article ne sont pas assez claires pour une action dans votre contexte organisationnel, cela peut indiquer qu'un soutien consultatif externe serait bénéfique.
Cet article est construit sur les spécificités du cas d'utilisation suivantes :
- Utilisation du BIG-IP de F5 comme un « OSI Layer 7 » ou « proxy complet »
- Utilisation d'ArcGIS Enterprise où le Web Adaptor est déployé avec IIS sur le système d'exploitation Windows
Instructions pour l'administrateur ArcGIS
Le rôle de l'administrateur ArcGIS est de déployer ArcGIS Enterprise afin qu'il soit prêt à être proxifié par le proxy inverse BIG-IP de F5. L'objectif du déploiement est illustré dans le diagramme ci-dessous.
Selon les exigences spécifiques, il peut ne pas être nécessaire de déployer des Web Adaptors lors de l'utilisation d'un proxy inverse. Cependant, il est recommandé de le faire pour les raisons suivantes :
- L'utilisation des Web Adaptors réduit la complexité de configuration dans le proxy inverse BIG-IP.
- Les Web Adaptors vous permettent de valider la justesse du système ArcGIS Enterprise indépendamment du proxy inverse ; cela peut être très utile en cas de dépannage.
- Bien que les Web Adaptors puissent être déployés sur des systèmes basés sur Linux utilisant un serveur Web Java, la fréquence du déploiement sous Windows avec IIS explique pourquoi ce guide initial se concentre sur ce modèle.
Étape Un : Décisions de conception et communication avec les administrateurs F5
Dans cette configuration, les clients accéderont à ArcGIS Enterprise via le proxy inverse. Le proxy inverse présente un CNAME (« alias DNS », montré en vert dans le diagramme ci-dessous) qui termine les sessions HTTPS des clients. Il réinitie ensuite de nouvelles sessions HTTPS depuis lui-même vers le serveur web qui héberge les web adaptors. Le serveur web présente généralement un certificat avec le nom du sujet correspondant à l'enregistrement A (le nom d'hôte, montré en rouge dans le diagramme) qui termine les sessions HTTPS entrantes depuis le proxy inverse BIG-IP.
Avant de déployer votre système, vous devez prendre les décisions suivantes :
- Quel est le CNAME (« alias DNS ») sous lequel le proxy inverse représentera le système ArcGIS Enterprise ?
- Quels sont les « contextes » (« noms des Web Adaptors », montrés en bleu dans le diagramme) pour Portal for ArcGIS et les sites ArcGIS Server ?
Vous devrez probablement coopérer avec vos administrateurs F5 pour convenir du CNAME et vous assurer qu'ils disposent d'un certificat TLS approprié pour terminer les communications HTTPS sur ce CNAME. En même temps, vous pouvez partager avec eux le nom (l'ENREGISTREMENT A) de la machine sur laquelle votre serveur web fonctionnera et vers laquelle les requêtes doivent être transmises.
Étape Deux : Déployer un serveur web avec certificat TLS
Il est utile de déployer votre serveur web et de le configurer avec un certificat TLS pour le trafic HTTPS avant toute intervention directe avec ArcGIS Enterprise. Cela vous permet de vous assurer que HTTPS fonctionne avec votre serveur web, et permet aux administrateurs F5 de configurer tôt le proxy inverse pour ce serveur web. Cela permet une validation précoce du certificat TLS et des chemins HTTPS.
Configurer HTTPS sur votre serveur web
Les étapes de configuration pour activer HTTPS varient selon la marque du serveur web. Comme IIS est un serveur web très courant, Esri a fourni des instructions pour sa configuration HTTPS dans son guide d'installation du Web Adaptor : https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/enable-https-on-your-web-server-server-.htm.
Lorsque vous activez HTTPS sur votre serveur web, vous devrez fournir un certificat TLS. Parmi d'autres attributs, les certificats ont des Sujets et des Noms Alternatifs du Sujet (SAN). Le Sujet du certificat doit correspondre au nom que le proxy inverse BIG-IP utilisera pour adresser le serveur web. C'est souvent l'ENREGISTREMENT A (machine1.domain.local dans le diagramme). Le SAN est une liste de noms alternatifs. Une bonne pratique pour les SAN consiste à inclure :
- Le nom du Sujet (par exemple, machine1.domain.local)
- La version courte du nom du sujet (par exemple, machine1)
- Le CNAME que présentera le proxy inverse (par exemple, gis.domain.com), si possible
Selon l'autorité de certification et les politiques de votre organisation, il se peut que vous puissiez ou non inclure le CNAME dans le SAN. L'avantage est que cela vous permet une plus grande capacité à valider ArcGIS Enterprise indépendamment du proxy inverse.
Valider
Une fois votre serveur web configuré pour HTTPS, vous devez valider votre configuration. D'abord, validez en naviguant directement vers votre serveur web dans un navigateur en utilisant le protocole HTTPS. Ensuite, si vos administrateurs F5 ont configuré le proxy inverse BIG-IP pour rediriger le trafic vers votre serveur web, vous pouvez alors naviguer vers l'endpoint du serveur virtuel du proxy inverse dans un navigateur, également en utilisant HTTPS. Dans chaque cas, vous voulez confirmer qu'aucun avertissement concernant le certificat n'apparaît et que la page cible s'affiche correctement.
Typiquement, les serveurs web ont une page par défaut qui est renvoyée lorsque vous accédez à la racine du serveur. C'est une bonne option. Une meilleure option est de déployer une page web qui vous permet de voir plus clairement ce qui se passe. Les pages showHeaders (une pour ASPX/IIS et une pour JSP : https://github.com/dannykrouk/showHeaders) renverront beaucoup d'informations utiles comme montré ci-dessous :
Envisagez de déployer et d'utiliser la page showHeaders sur votre serveur web et utilisez-la comme cible pour vos tests tant sur votre serveur web que sur le proxy inverse. Si vous déployez la page à la racine de votre serveur web, vous pouvez tester avec ces requêtes :
Étape Trois : Déployer et configurer ArcGIS Enterprise
Le déploiement ArcGIS Enterprise ici est un « déploiement base sur machine unique » (https://enterprise.arcgis.com/en/get-started/latest/windows/base-arcgis-enterprise-deployment.htm#ESRI_SECTION1_690F8D4A3ABE4FB8AE926C118E9F8299).
Installer et configurer les bases
La documentation pour vous guider à travers les étapes d'installation est disponible sur le site web d'Esri : https://enterprise.arcgis.com/en/documentation/install/.
Dans cet article, le nom du Web Adaptor de Portal for ArcGIS (le « contexte ») est « /portal » et le nom du Web Adaptor du Hosting Server est « /server ». Lorsque vous fédérez votre site Hosting Server avec votre Portal for ArcGIS, vous pouvez utiliser le Web Adaptor à la fois pour l'URL des services et l'URL d'administration (https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-servers.htm), tant que vous n'utilisez pas l'authentification Web Tier. Si vous utilisez l'authentification Web Tier, votre URL d'administration doit suivre ce modèle : https://machine1.domain.local:6443/arcgis.
Valider les bases ; « Vérification de confiance du système »
Une fois que vos Web Adaptors sont configurés et que votre Hosting Server est fédéré, vous devriez effectuer une brève « vérification de confiance du système » pour vous assurer que les fonctions principales fonctionnent correctement.
Une vérification typique de confiance du système impliquerait :
- Connexion à /portaladmin
- Valider la fédération
- Publier un service
- Partager le service
La « confiance » établie avec ces étapes est que le système déployé ne présente aucun défaut fondamental de configuration qui empêcherait son fonctionnement de base.
Tout ce que vous créez (par exemple un service publié) lors de la vérification de confiance du système doit être supprimé avant de continuer.
Configuration finale pour le Reverse Proxy
L'étape finale de configuration consiste à configurer le WebContextURL pour le Portal et le Hosting Server. Cette propriété indique à chaque serveur Esri le nom par lequel les clients l'adresseront via le reverse proxy BIG-IP.
Portal for ArcGIS : https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-portal-for-arcgis.htm#ESRI_SECTION1_7C753FB1F19349A398E5FFCC6079A821
{
"WebContextURL": "https://gis.domain.com/portal"
}ArcGIS for Server : https://enterprise.arcgis.com/en/server/latest/deploy/linux/using-a-reverse-proxy-server-with-arcgis-server.htm#ESRI_SECTION1_13680C9069E14B1F8AE5793BE1ED25A6
{
"WebContextURL": "https://gis.domain.com/server"
}Étape quatre : Validation du système
La quatrième et dernière étape pour l'administrateur ArcGIS est la « validation du système », indépendante du reverse proxy BIG-IP. Si vous validez ainsi, et que quelque chose ne fonctionne pas lorsque les requêtes passent par le reverse proxy, alors c'est la configuration du reverse proxy qui nécessite une attention. Si vous ne validez pas ainsi, il peut être beaucoup plus compliqué d'établir la source du problème.
Modifier temporairement la résolution de nom sur la machine serveur web
L'astuce pour cette validation est de convaincre temporairement le système que le CNAME (gis.domain.com) se trouve sur la machine ArcGIS Enterprise (machine1.domain.local). Si vous avez les permissions d'administrateur local sur la machine machine1.domain.local, vous pouvez modifier le fichier hosts. Si machine1.domain.local a l'adresse IP 10.0.0.10, alors l'entrée dans le fichier hosts ressemblerait à ceci :
10.0.0.10 gis.domain.com
Cela signifie « gis.domain.com peut être trouvé à 10.0.0.10 ».
Lorsque vous avez terminé votre modification de ce fichier (qui se trouve généralement ici : C:\Windows\System32\drivers\etc\hosts), ouvrez une invite de commande et confirmez que votre réglage est effectif avec ping :
C:\>ping gis.domain.com
Envoi d'une requête 'ping' vers gis.domain.com [10.0.0.10] avec 32 octets de données :
Réponse de <Adresse IP de machine1> : octets=32 temps=22ms TTL=124
…
Le résultat de la commande ping doit être l'adresse IP dans votre fichier hosts, la valeur indiquée en surbrillance ci-dessus pour plus de clarté.
Tester dans un navigateur sur la machine serveur web
Maintenant, ouvrez un navigateur web sur machine1.domain.local et exécutez à nouveau votre « vérification de confiance du système », cette fois en adressant le système par son CNAME (https://gis.domain.com/portal/home/).
Si votre système fonctionne correctement ainsi, annulez la modification du fichier hosts et demandez aux administrateurs F5 de compléter leur travail de configuration.
Instructions pour l'administrateur F5
D'un point de vue BIG-IP, il s'agit d'une configuration simple. Le système ArcGIS Enterprise comprend plusieurs composants. Mais, du point de vue du reverse proxy, il y a un seul nœud serveur web back-end écoutant sur HTTPS/443. L'élément de configuration qui peut différer des autres systèmes est qu'ArcGIS Enterprise exige que le reverse proxy inclue un en-tête X-Forwarded-Host.
À un niveau élevé, votre configuration proxy terminera tout le trafic HTTPS vers le CNAME gis.domain.com et réinitialisera HTTPS vers le nœud back-end unique, machine1.domain.local. Le serveur web à cette adresse supporte deux « contextes », un pour chaque composant majeur du système ArcGIS Enterprise (Portal for ArcGIS et ArcGIS Server) : /portal et /server.
Comme décrit dans l'introduction de cet article, nous supposons que vous avez trois réseaux associés à votre proxy BIG-IP : un réseau client, un réseau serveur et votre réseau d'administration.
Cet article suppose que vous êtes un expert en administration BIG-IP et avez seulement besoin d'indications sur les étapes pour configurer ce serveur virtuel et ce pool back-end dans l'ordre optimal.
Étape un : Proxy du serveur web
Le CNAME pour ce système devrait avoir été établi avec vous ou communiqué. Un certificat TLS correspondant à ce CNAME doit également être fourni. L'autorité de certification doit être une autorité reconnue par les clients de ce système.
Installer le certificat TLS
Installez le certificat TLS pour le serveur virtuel dans BIG-IP (par exemple, Sujet gis.domain.com)
Système > Gestion des certificats > Gestion des certificats Traffic > Liste des certificats SSL > Importer un certificat SSL
Créer un profil SSL client
Créez un profil client pour terminer les connexions TLS client sur le certificat pour le nom gis.domain.com.
Trafic local > Profils > SSL > Client > Créer
Créer un pool avec un moniteur simple
Créez un pool back-end pour le serveur web (par exemple https://machine1.domain.local/) avec un moniteur simple pour déterminer si la ressource nœud est « active » ou « inactive ».
Trafic local > Pools > Liste des pools > Créer
<\/span><\/H3> <\/P>Créer un profil de services HTTP (Ajouter l'en-tête X-Forwarded-Host)<\/H3>L'en-tête X-Forwarded-Host permet à ArcGIS Enterprise de connaître la valeur de l'en-tête Host qui est arrivé sur BIG-IP. Le système ArcGIS Enterprise vérifiera cette valeur par rapport à sa configuration pour s'assurer que les clients l'ont adressé de manière appropriée. Si l'en-tête X-Forwarded-Host n'est pas présent, ou contient une valeur incorrecte, ArcGIS Enterprise émettra une redirection HTTP pour indiquer comment il pense qu'il doit être adressé. Cela peut entraîner des boucles de redirection. Dans le cas où ArcGIS Enterprise détecte une boucle de redirection, il la rompra et renverra une erreur.<\/P>Un en-tête X-Forwarded-Host peut être inclus avec un iRule :<\/P>when HTTP_REQUEST {
HTTP::header insert X-Forwarded-Host [HTTP::host]
}<\/PRE> <\/P>Cette directive prend la valeur de l'en-tête Host de la requête entrante et la définit comme valeur de l'en-tête X-Forwarded-Host pour le pool par défaut.<\/P>Créer le serveur virtuel<\/H3>Trafic local > Serveurs virtuels > Créer<\/P>Sélectionnez « Standard » pour le type de serveur virtuel. Spécifiez votre profil SSL (Client) que vous avez créé précédemment avec votre certificat SSL. En spécifiant un profil Serveur, l'objectif de configuration est d'établir un tunnel TLS vers le backend. Cela peut être accompli avec le paramètre par défaut « serverssl » dans BIG-IP. Réglez « Traduction d'adresse source » sur Auto Map.<\/P>
<\/span><\/P> Dans l'onglet Ressources, sélectionnez votre pool que vous avez créé auparavant.<\/P>
<\/span><\/P> <\/P>Étape deux : Valider le proxy vers ArcGIS Enterprise<\/H2>Il y a deux étapes pour valider l'efficacité de cette configuration. <\/P>Valider la confiance et les en-têtes<\/H3>En supposant que la page showHeaders.aspx a été déployée sur le serveur web backend, utilisez un navigateur web pour naviguer vers https:\/\/gis.domain.com\/showHeaders.aspx<\/A>. Le navigateur ne doit afficher aucun avertissement de confiance du certificat. Le corps de la réponse de la page doit démontrer l'efficacité de l'aspect en-tête X-Forwarded-Host de votre configuration.<\/P> 
<\/span><\/P> <\/P>À ce stade, avec le passage des en-têtes confirmé jusqu'au backend, il n'est plus nécessaire d'utiliser l'outil showHeaders.aspx. Si votre système est destiné à la PRODUCTION, ou tout environnement où les informations exposées ne doivent pas être divulguées, cet outil doit être supprimé.<\/P>
TestThe instructions stipulated "system confidence checks" and validations throughout the deployment/configuration process. These measures were meant to determine whether it was reasonable to continue to the next step in the instructions. These measures do not prove that the system is acceptable. By the end, we assume that the entire system functions. In other words, these tests establish that the system has functional coherence.
Passing the system on for acceptance testing is the appropriate next step. The goal of acceptance testing is to measure the deployed system against the business goals it must support.
Health Checking
The Simple Monitoring included in the instructions to the F5 administrators allows the BIG-IP to stop forwarding requests to the ArcGIS Enterprise system if the node (i.e., machine1.domain.local) is down or inaccessible. For a system like this, with only one back-end Pool member, this (a Simple Monitor) is the full extent of the recommended health checking.
In principle, BIG-IP can be configured with out-of-band health checks that ask the ArcGIS Enterprise software to confirm its health or validate that specific HTTPS requests succeed with particular response payloads. For example, the Portal for ArcGIS component of ArcGIS Enterprise exposes this endpoint:
https://developers.arcgis.com/rest/enterprise-administration/portal/health-check-portal.htm. In a single node system, the response to a health check problem essentially eliminates all access to the system. The upside of this is that the reverse proxy can provide a generic error to clients that the system is down. The downside of this is that a temporary problem, partial problem, or misinterpretation through the health check eliminates all access to the system when it might be still serviceable for many use cases. The probability of false negatives (unhealthy findings) associated with formal/complex health checks may result in less system reliability to end users relative to the false positives (healthy findings) associated with the simple node monitoring. In other words, for a single-node system complexity is the enemy of reliability; stick to a Simple Monitor.
Credits
This article was produced based on the work of Roger Schlogel, a consultant with Esri's Professional Services.
