Я видел много похожих вопросов (и ответов) по этому поводу, но, похоже, ни один не относится к той же ситуации, с которой я столкнулся. Что странно, потому что я не думаю, что это что-то особенное, так что простите меня, если я не искал достаточно.
Тем не мение. У меня есть два веб-сайта, которые находятся на двух IIS7, один из которых обращен к глобальной сети, а другой - к локальной сети. WAN уже поддерживает только HTTPS. Я хочу добавить второй веб-сайт, но в том же домене HTTPS и сертификате SSL, чтобы он стал дочерним сайтом, например: https://www.domain.com/subsite Как я могу перенаправить или переписать первый IIS на второй, чтобы это сработало? Я не думаю, что есть стандартная функция IIS, которая может это сделать. Сервер ISA в настоящее время недоступен. Но, может быть, существует другое расширение для IIS?
Сделано это много раз на Apache, и я собираюсь отказаться от IIS для Apache.
Это возможно в IIS с помощью поддерживаемых плагинов ARR и URLrewrite. Они устанавливаются как интегрированные инструменты в графическом интерфейсе IIS Manager.
Если вы установите последний пакет ARR, вы получите пакет URLrewrite. Онлайн-документация несколько отсутствует, но, немного поработав, то, что вы хотите сделать, можно сделать без особых хлопот.
Даже если графический интерфейс довольно дружелюбен, я предлагаю регулярно сохранять файл applicationHost.config во время тестирования, поскольку графический интерфейс иногда дает сбои. Это верно, по крайней мере, с ARR v2.5, который я использовал при этом. Затем у вас есть рабочие текстовые конфигурации, которые вы можете копировать / вставлять каждый раз, когда решите очистить свою конфигурацию. Это сэкономит вам много времени.
В applicationHost.Config особенно ищите эти XML-элементы:
<rewrite>
...
</rewrite>
<webFarms>
...
</webFarms>
Раздел веб-ферм - это место, где в конечном итоге попадают ваши местоположения контента, определенные в графическом интерфейсе, по сути, это конфигурация для балансировщика нагрузки обратного прокси, где ферма представляет собой подключение виртуальной службы к одному или нескольким внутренним узлам. Точно так же в разделе перезаписи вы найдете свои условия, для которых контент должен быть извлечен из какой фермы.
Далее следует отрывок из фактической конфигурации, который не полностью соответствует вашему варианту использования, но, тем не менее, может служить источником вдохновения. Возможно, вам нужно только отредактировать второе правило перезаписи, чтобы оно соответствовало вашему сценарию. Представленный вариант использования относится к случаям, когда IIS используется в качестве сквозного прокси для двух серверных ферм, динамический контент обслуживается из «htmlFarm», в то время как запросы предопределенного статического контента, такого как изображения, из «imageFarm». Выбор осуществляется на основе начала URI. Если URI начинается с / images /, он рассматривается как статический контент и направляется на «imageFarm», иначе он направляется на «htmlFarm». В любом случае IIS представляется клиенту как единственный веб-сервер. Простая проверка работоспособности также выполняется двумя разными способами, по одному для каждой фермы. Это был просто эксперимент, и я просто включил его как остаточный шум, который, тем не менее, может быть вам полезен.
<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>
Опять же, не в вашем случае использования, но тем не менее: ограничение в ARR состоит в том, что даже если узел IIS с ARR может обеспечить избыточность для бэкэнда, он сам по себе будет единственной точкой отказа. Для решения этой проблемы вам понадобятся два или более идентично настроенных узла IIS / ARR с NLB или отдельный балансировщик нагрузки. Другими словами, веб-интерфейсы как обычно :-)
В конечном итоге мы отказались от IIS / ARR для Apache, но в большей степени из-за политической случайности, которая вызвала серьезную вспышку офисного юмора. Я действительно не предпочитаю ни одно из них, так как считаю, что оба работают и работают очень, очень хорошо. Однако мониторинг в Apache ужасен по сравнению с IIS, и я никоим образом не хочу, чтобы этот комментарий был пламенем для чего-либо. Это просто мой непосредственный опыт со всем уважением к другим, возможно, различным мнениям по этому поводу.
Удачи!