Блог

У меня есть веб-приложение, размещенное в Windows Azure. Мы хотим использовать SSL для производственного развертывания, и у нас есть пользовательское доменное имя и SSL-сертификат для домена, и все это настроено и корректно работает в рабочей среде.

Веб-роль в настоящее время имеет как конечную точку HTTP, так и конечную точку HTTPS, но мы хотели бы отключить конечную точку HTTP и просто использовать HTTPS в рабочей среде.

Если мы удалим конечную точку HTTP, мой вопрос таков: каков наилучший способ работы с конечной точкой HTTPS для промежуточного развертывания в Azure? Каждый раз, когда вы выполняете новое промежуточное развертывание в Azure, оно предоставляет вам новое временное доменное имя для службы. При промежуточном развертывании следует ли нам вообще не использовать SSL-сертификат и просто пропустить все предупреждения браузера, или есть способ использовать SSL при промежуточном развертывании, когда доменное имя меняется при каждом развертывании? Или когда мы переключаемся на производство, есть ли способ просто «отключить» конечную точку (HTTP) в развертывании Azure?

Моей первоначальной мыслью было создать два пакета с разными конечными точками, но я не верю, что Azure позволит вам выполнять «горячую замену» между prod и промежуточными развертываниями, если у них разные конфигурации конечных точек.

Для одного из наших проектов мы используем модуль перезаписи URL, который по умолчанию устанавливается в Azure. Это отлично работает. Раздел в web.config автоматически перенаправляет весь HTTP-трафик на HTTPS:

 <rule name="HTTP to HTTPS redirect" stopProcessing="true">
  <match url="(.*)" />
    <conditions>
      <add input="{HTTPS}" pattern="off" ignoreCase="true" />
    </conditions>
  <action type="Redirect" redirectType="Found" url="https://{HTTP_HOST}/{R:1}" />
</rule>
  

Для промежуточной среды лучше всего использовать тот же сертификат, что и для рабочей. Это позволяет легко выполнять «горячую замену» между рабочей и промежуточной версиями, и вы можете проверить в своем браузере, является ли сертификат правильным. Недостатком является то, что вам придется нажать «перейти на веб-сайт» во время тестирования промежуточного развертывания.

Обратите внимание, что, хотя модуль перезаписи URL-адресов всегда доступен в Azure, для DevFabric вам придется загрузить и установить его на вашем компьютере разработчика. Загрузка доступна на http://www.iis.com .

Для этого сценария мы создали 2 разных развертывания служб в Azure, в обоих из которых есть рабочая промежуточная среда. Следовательно, мы используем производственный экземпляр в обеих службах, который сохраняет статический URL.
Между развертываниями служб нет горячей замены, но когда сборка продвигается из одного развертывания служб, она устанавливается во вторых службах, промежуточное развертывание, а затем выполняется горячая замена. Надеюсь, я ясно выразился.

Мы оставляем порты 80 и 443 открытыми при производственных и промежуточных развертываниях, но используем пользовательский HttpModule для перенаправления HTTP-трафика на HTTPS на основе параметра конфигурации Azure. Если значение конфигурации равно «Production», весь трафик принудительно передается по протоколу HTTPS. В противном случае обрабатывается трафик как HTTP, так и HTTPS. Это было важно для нас, потому что мы не хотели, чтобы наши пользователи путались, когда HTTP-запросы отклонялись только потому, что они забыли добавить к URL-адресу префикс https: //. Есть ли особая причина, по которой вам нужно отключить конечную точку HTTP?