Поделиться через

Выбор правильного подхода для веб-развертывания

Джейсон Ли

При работе с Internet Information Services (IIS) Web Deployment Tool (Web Deploy) 2.0 или более поздней версии существует три основных подхода к переносу упакованных веб-приложений на веб-сервер. Вы можете сделать одно из двух:

  • Разверните приложение из удаленного расположения, нацелившись на службу агента веб-развертывания (также известную как «удаленный агент») на целевом сервере.
  • Разверните приложение из удаленного местоположения с помощью Web Deploy On Demand (также известного как «временный агент»).
  • Разверните приложение из удаленного расположения, нацелившись на обработчик развертывания IIS Web Deploy на целевом сервере.
  • Разверните приложение, вручную скопировав веб-пакет на целевой сервер и импортировав его с помощью диспетчера IIS.

Способ настройки целевых веб-серверов будет зависеть от того, какой подход к развертыванию вы хотите использовать. Этот раздел поможет вам решить, какой подход к развертыванию подходит именно вам.

В этой таблице показаны основные преимущества и недостатки каждого подхода к развертыванию, а также сценарии, которые наиболее часто подходят для каждого подхода.

Подход Преимущества Недостатки Типичные сценарии
Удаленный агент Он прост в настройке. Он подходит для регулярных обновлений веб-приложений и контента. Пользователь должен быть администратором на целевом сервере. Пользователь не может предоставить альтернативные учетные данные. Среды разработки. Тестовые среды.
Временный агент Нет необходимости устанавливать Web Deploy на целевой компьютер. Автоматически используется последняя версия Web Deploy. Пользователь должен быть администратором на целевом сервере. Пользователь не может предоставить альтернативные учетные данные. Среды разработки. Тестовые среды.
Обработчик веб-развертывания Пользователи, не являющиеся администраторами, могут развертывать содержимое. Он подходит для регулярных обновлений веб-приложений и контента. Его намного сложнее настроить. Промежуточная среда. Производственные среды интрасети. Размещенные среды.
Автономное развертывание Он очень прост в настройке. Он подходит для изолированных помещений. Администратор сервера должен каждый раз вручную копировать и импортировать веб-пакет. Производственные среды с выходом в Интернет. Изолированные сетевые среды.

Использование удаленного агента

При установке Web Deploy с настройками по умолчанию на целевом сервере автоматически устанавливается и запускается служба Web Deployment Agent Service («удаленный агент»). По умолчанию удаленный агент предоставляет конечную точку HTTP по следующему адресу:

http://[server]/MSDEPLOYAGENTSERVICE

Замечание

Вы можете заменить [server] на имя компьютера вашего веб-сервера, IP-адрес вашего веб-сервера или имя хоста, которое разрешается в ваш веб-сервер.

Администраторы сервера могут развертывать веб-пакеты из удаленного расположения, например с компьютера разработчика или сервера сборки, указав этот адрес конечной точки. Например, предположим, что Мэтт Хинк (Matt Hink) из компании Fabrikam, Inc. создал проект веб-приложения ContactManager.Mvc на своем компьютере разработчика. В процессе сборки создается веб-пакет вместе с файлом .deploy.cmd , содержащим команды Web Deploy, необходимые для установки пакета. Если Мэтт является администратором сервера на сервере TESTWEB1, он может развернуть веб-приложение на тестовом веб-сервере, выполнив следующую команду на своем компьютере разработчика:

ContactManager.Mvc.deploy.cmd /y /m:http://TESTWEB1/MSDEPLOYAGENTSERVICE a/:NTLM

На самом деле, исполняемый файл Web Deploy может определить адрес конечной точки удаленного агента, если вы укажете имя машины, поэтому Мэтту нужно ввести только следующее:

ContactManager.Mvc.deploy.cmd /y /m:TESTWEB1 /a:NTLM

Замечание

Дополнительные сведения о синтаксисе командной строки Web Deploy и файлах .deploy.cmd см. в разделе Практическое руководство: установка пакета развертывания с помощью файла deploy.cmd.

Удаленный агент предлагает простой способ развертывания содержимого из удаленного расположения, и этот подход может хорошо работать как при развертывании одним щелчком мыши, так и при автоматическом развертывании. Однако пользователь, выполняющий команду развертывания, также должен быть либо администратором домена, либо членом локальной группы администраторов на целевом сервере. Кроме того, удаленный агент не поддерживает базовую проверку подлинности, поэтому вы не можете передать альтернативные учетные данные в командной строке.

Удаленный агент обеспечивает полезный подход к развертыванию в сценариях разработки или тестирования, где разработчики нередко имеют полный контроль администратора над средой тестового сервера, а приложения обычно перестраиваются и развертываются очень часто. Однако этот подход обычно менее приемлем для промежуточных или производственных сред.

Полный пример сценария, в котором используется подход удаленного агента, см. в статье Сценарий: настройка тестовой среды для веб-развертывания.

Использование временного агента

Подход временного агента к развертыванию аналогичен подходу удаленного агента. Однако, в отличие от подхода удаленного агента, вам не нужно устанавливать Web Deploy на целевом веб-сервере. Вместо этого при развертывании Web Deploy установит временную версию службы агента веб-развертывания на целевом сервере и будет использовать ее для развертывания содержимого в IIS. Когда развертывание завершено, все временные файлы удаляются.

Если вы хотите использовать параметр поставщика временного агента, добавьте флаг /g в команду развертывания:

ContactManager.Mvc.deploy.cmd /y /m:TESTWEB1 /g:true

Замечание

Вы не можете использовать временный агент, если служба агента веб-развертывания установлена на целевом компьютере, даже если эта служба не запущена.

Преимущество этого подхода заключается в том, что вам не нужно поддерживать установки Web Deploy на целевых серверах. Кроме того, нет необходимости гарантировать, что исходный и конечный компьютеры работают под управлением одной и той же версии Web Deploy. Однако этот подход имеет те же принципиальные ограничения, что и подход удаленного агента, а именно, что для развертывания содержимого необходимо быть локальным администратором на целевом сервере, и поддерживается только проверка подлинности NTLM. Подход с временным агентом также требует гораздо большей начальной настройки целевой среды.

Дополнительные сведения об использовании временного агента см . в разделах Установка пакета развертывания с помощью файла deploy.cmd и Развертывание через Интернет по запросу.

Использование обработчика Web Deploy

Для IIS 7 и более поздних версий Web Deploy предлагает альтернативный подход к развертыванию с помощью обработчика IIS Web Deploy. Web Deploy Handler тесно интегрирован со службой веб-управления IIS (WMSvc), которая предназначена для того, чтобы пользователи могли управлять веб-сайтами IIS из удаленных расположений.

По умолчанию удаленный агент предоставляет конечную точку HTTP по следующему адресу:

https://[server]:8172/MSDeploy.axd

Замечание

Вы можете заменить [server] на имя компьютера вашего веб-сервера, IP-адрес вашего веб-сервера или имя хоста, которое разрешается в ваш веб-сервер.

Большое преимущество Web Deploy Handler по сравнению с удаленным агентом и временным агентом заключается в том, что вы можете настроить IIS таким образом, чтобы разрешить пользователям, не являющимся администраторами, развертывать приложения и контент на определенных веб-сайтах IIS. Web Deploy Handler также поддерживает базовую аутентификацию, поэтому вы можете указать альтернативные учетные данные в качестве параметров в командах Web Deploy. Основным недостатком является то, что Web Deploy Handler изначально намного сложнее в настройке и настройке.

В случае пользователей, не являющихся администраторами, веб-служба управления (WMSvc) позволит пользователю подключаться к IIS только с помощью подключения на уровне сайта, а не на уровне сервера. Чтобы получить доступ к определенному сайту, вы можете включить строку запроса, специфичную для сайта, в адрес конечной точки:

https://[server]:8172/MSDeploy.axd?site=DemoSite

Предложение Например, предположим, что процесс сборки настроен на автоматическое развертывание веб-приложения в промежуточной среде после каждой успешной сборки. Если вы использовали подход с удаленным агентом, вам потребуется сделать удостоверение процесса сборки администратором на целевых серверах. В отличие от этого, используя подход Web Deploy Handler, можно предоставить пользователю, не являющемуся администратором (в данном случае FABRIKAM\stagingdeployer ), разрешение только на определенный веб-сайт IIS, а процесс сборки может предоставить эти учетные данные для развертывания веб-пакета. Обратите внимание, что в следующем примере используется %ContactManagerPublishPassword%, то есть извлекается значение пароля из переменной среды. Для успешного выполнения скрипта %ContactManagerPublishPassword% переменная должна быть определена с правильным значением.

msdeploy.exe 
  -source:package='…\ContactManager.Mvc.zip' 
  -dest:auto,
        computerName='https://STAGEWEB1:8172/MSDeploy.axd?site=DemoSite',
        userName='FABRIKAM\stagingdeployer',
        password=,
        authtype='Basic', 
  -verb:sync 
  -setParamFile:"…\ContactManager.Mvc.SetParameters.xml"   
  -allowUntrusted

Замечание

Дополнительные сведения об операциях командной строки и синтаксисе Web Deploy см. в разделе Справочник по командной строке Web Deploy. Дополнительные сведения об использовании файла .deploy.cmd см. в разделе Практическое руководство: установка пакета развертывания с помощью файла deploy.cmd.

Web Deploy Handler обеспечивает полезный подход к развертыванию в промежуточных средах, размещенных средах и производственных средах на основе интрасети, где удаленный доступ к серверу доступен, но учетные данные администратора отсутствуют.

Полный пример сценария, в котором используется обработчик веб-развертывания, см. в разделе Сценарий: настройка промежуточной среды для веб-развертывания.

Использование автономного развертывания

В некоторых случаях развертывание приложений и содержимого на веб-сайте IIS из удаленного расположения невозможно или нецелесообразно. Например, исходный и конечный компьютеры могут находиться в изолированных сетях или сегментах сети, или политика брандмауэра может не разрешать удаленный доступ.

В подобных сценариях вы по-прежнему можете использовать возможности упаковки и публикации Web Deploy; Вы просто не можете использовать их из удаленного места. Вместо этого администратор на целевом сервере должен скопировать веб-пакет на сервер и импортировать его с помощью диспетчера IIS.

Вместо этого администратор на целевом сервере должен скопировать веб-пакет на сервер и импортировать его с помощью диспетчера IIS.

Автономный подход к развертыванию обычно полезен в производственных средах с выходом в Интернет, где серверы в демилитаризованной зоне могут иметь ограниченное подключение к компьютерам во внутренней сети.

Полный пример сценария, в котором используется подход к автономному развертыванию, см. в разделе Сценарий: настройка рабочей среды для веб-развертывания.

Дальнейшее чтение

Дополнительные сведения об операциях командной строки и синтаксисе Web Deploy см. в разделе Справочник по командной строке Web Deploy. Дополнительные сведения об использовании файла .deploy.cmd см. в разделе Практическое руководство: установка пакета развертывания с помощью файла deploy.cmd.

Более общие рекомендации по развертыванию веб-пакетов с удаленного компьютера см. в разделе Использование удаленного веб-развертывания. Дополнительные сведения об использовании Web Deploy On Demand см. в разделе Web Deploy On Demand.

НазадДалее

  • Last updated on