Redirection d'un sous-site du même domaine vers un autre IIS en utilisant HTTPS

Cela est possible dans IIS à l'aide des plugins ARR et URLrewrite pris en charge. Ils s'installent en tant qu'outils intégrés dans l'interface graphique de IIS Manager.

Si vous installez le dernier paquet ARR, URLrewrite est inclus dans le paquet. La documentation en ligne est quelque peu insuffisante, mais avec un peu de bricolage, ce que vous voulez faire est réalisable sans trop de problèmes.

Même si l'interface est très conviviale, je vous conseille de vous assurer que vous sauvegardez régulièrement votre applicationHost.config pendant les tests, car l'interface peut parfois présenter des erreurs. C'est le cas au moins avec ARR v2.5, qui était celui que j'ai utilisé pour faire ce test. Vous disposez alors de configurations de travail en texte que vous pouvez copier/coller à chaque fois que vous décidez de nettoyer votre configuration. Cela vous fera gagner beaucoup de temps.

Dans le fichier applicationHost.Config, recherchez particulièrement ces éléments XML :

<rewrite>
...
</rewrite>
<webFarms>
...
</webFarms>

La section webfarms est l'endroit où se trouvent les emplacements de contenu définis dans l'interface. Il s'agit essentiellement de la configuration d'un équilibreur de charge à proxy inverse où une ferme est une connexion de service virtuel à un ou plusieurs nœuds dorsaux. De même, la section de réécriture est l'endroit où vous trouvez vos conditions pour quel contenu doit être récupéré à partir de quelle ferme.

Voici un extrait de configuration réelle qui ne correspond pas entièrement à votre cas d'utilisation mais qui peut néanmoins servir d'inspiration. Il est possible que vous n'ayez qu'à modifier la deuxième règle de réécriture pour qu'elle corresponde à votre scénario. Le cas d'utilisation présenté est celui où l'IIS est utilisé comme proxy de passage vers deux fermes de backend, le contenu dynamique est servi à partir de la "htmlFarm", tandis que les demandes de contenu statique prédéfini comme les images proviennent de la "imageFarm". La sélection se fait sur la base du début de l'URI. Si l'URI commence par /images/, il est considéré comme un contenu statique et acheminé vers "imageFarm", sinon il est acheminé vers "htmlFarm". Dans les deux cas, IIS se présente au client comme le seul et unique serveur web. Un simple contrôle de santé est également effectué de deux manières différentes, une pour chaque ferme. C'était juste à titre expérimental et je l'inclus juste comme un bruit résiduel qui pourrait néanmoins vous être utile.

<rewrite>
        <globalRules>
            <clear />
            <rule name="Route all to htmlFarm" patternSyntax="ECMAScript">
                <match url=".*" />
                <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                    <add input="{HTTP_HOST}" pattern="(.*\.)?site01.com" />
                </conditions>
                <action type="Rewrite" url="http://htmlFarm/{R:0}" />
            </rule>
            <rule name="Route /images/* to imageFarm" stopProcessing="false">
                <match url="images/.*" />
                <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
                <action type="Rewrite" url="http://imageFarm/{R:0}" />
            </rule>

        </globalRules>
</rewrite>
....
<webFarms>
    <webFarm name="htmlFarm" enabled="true">
        <server address="192.168.50.77" enabled="true">
            <applicationRequestRouting weight="100" />
        </server>
        <server address="192.168.50.78" enabled="true" />
        <applicationRequestRouting>
            <loadBalancing algorithm="WeightedRoundRobin" />
            <healthCheck url="http://site01.com" responseMatch="Testing" />
        </applicationRequestRouting>
    </webFarm>
    <webFarm name="imageFarm" enabled="true">
        <server address="192.168.50.81" enabled="true">
            <applicationRequestRouting weight="100" />
        </server>
        <server address="192.168.50.82" enabled="true">
            <applicationRequestRouting weight="100" />
        </server>
        <applicationRequestRouting>
            <healthCheck url="http://site01.com/images/test.txt" responseMatch="WillTest" />
            <loadBalancing algorithm="WeightedRoundRobin" />
        </applicationRequestRouting>
    </webFarm>
    <applicationRequestRouting>
        <hostAffinityProviderList>
            <add name="Microsoft.Web.Arr.HostNameRoundRobin" />
            <add name="Microsoft.Web.Arr.HostNameMemory" />
        </hostAffinityProviderList>
    </applicationRequestRouting>
</webFarms>

Encore une fois, cela ne correspond pas à votre cas d'utilisation, mais néanmoins : une limitation de l'ARR est que même si un nœud IIS avec ARR peut fournir une redondance pour le backend, il sera en lui-même un point de défaillance unique. Pour surmonter ce problème, il faut au moins deux nœuds IIS/ARR configurés de manière identique avec NLB, ou un équilibreur de charge séparé en amont. En d'autres termes, des fronts Web comme d'habitude :-)

Nous avons fini par abandonner IIS/ARR pour Apache, mais plutôt par un accident politique qui a provoqué une grande crise d'humour au bureau. Je ne privilégie pas vraiment l'un par rapport à l'autre, car je trouve que les deux fonctionnent très, très bien. Cependant, la surveillance dans Apache est épouvantable en comparaison directe avec IIS, et je ne souhaite en aucun cas que ce commentaire soit une flamme pour quoi que ce soit. Il s'agit simplement de mon expérience directe, avec tout le respect que je dois à d'autres opinions éventuellement différentes sur le sujet.

Bonne chance !