Выбор правильного подхода для веб-развертывания
При работе со средством веб-развертывания служб IIS версии 2.0 или более поздней версии можно использовать три main подходов, которые можно использовать для размещения упакованных веб-приложений на веб-сервере. Вы можете сделать одно из двух:
- Разверните приложение из удаленного расположения, нацелив службу веб-Deployment Agent (также называемую "удаленным агентом") на целевом сервере.
- Развертывание приложения из удаленного расположения с помощью веб-развертывания по запросу (также известного как "временный агент").
- Разверните приложение из удаленного расположения, нацелив обработчик веб-развертывания IIS на целевой сервер.
- Разверните приложение, вручную скопировав веб-пакет на целевой сервер и импортировав его с помощью диспетчера IIS.
Способ настройки целевых веб-серверов будет зависеть от того, какой подход к развертыванию вы хотите использовать. Этот раздел поможет вам решить, какой подход к развертыванию подходит вам.
В этой таблице показаны main преимущества и недостатки каждого подхода к развертыванию, а также сценарии, которые чаще всего подходят для каждого из них.
| Подход | Преимущества | Недостатки | Типичные сценарии |
|---|---|---|---|
| Удаленный агент | Это легко настроить. Он подходит для регулярных обновлений веб-приложений и содержимого. | Пользователь должен быть администратором на целевом сервере. пользователь не может предоставить альтернативные учетные данные. | Среды разработки. Тестовые среды. |
| Временный агент | Нет необходимости устанавливать веб-развертывание на целевом компьютере. Последняя версия веб-развертывания используется автоматически. | Пользователь должен быть администратором на целевом сервере. Пользователь не может предоставить альтернативные учетные данные. | Среды разработки. Тестовые среды. |
| Обработчик веб-развертывания | Пользователи без прав администратора могут развертывать содержимое. Он подходит для регулярных обновлений веб-приложений и содержимого. | Это гораздо сложнее в настройке. | Промежуточные среды. Рабочие среды интрасети. Размещенные среды. |
| Автономное развертывание | Это очень легко настроить. Он подходит для изолированных сред. | Администратор сервера должен каждый раз вручную копировать и импортировать веб-пакет. | Рабочие среды с выходом в Интернет. Изолированные сетевые среды. |
Использование удаленного агента
При установке веб-развертывания с использованием параметров по умолчанию на целевом сервере служба веб-Deployment Agent ("удаленный агент") устанавливается и запускается автоматически. По умолчанию удаленный агент предоставляет конечную точку HTTP по этому адресу:
http://[server]/MSDEPLOYAGENTSERVICE
Примечание
Вы можете заменить [server] именем компьютера веб-сервера, IP-адресом веб-сервера или именем узла, которое разрешается в веб-сервер.
Администраторы сервера могут развертывать веб-пакеты из удаленного расположения, например компьютера разработчика или сервера сборки, указав этот адрес конечной точки. Например, предположим, что Мэтт Хинк (Matt Hink) из Компании Fabrikam, Inc. создал проект веб-приложения ContactManager.Mvc на своем компьютере разработчика. В процессе сборки создается веб-пакет вместе с файлом .deploy.cmd , содержащим команды веб-развертывания, необходимые для установки пакета. Если Мэтт является администратором сервера TESTWEB1, он может развернуть веб-приложение на тестовом веб-сервере, выполнив следующую команду на своем компьютере разработчика:
ContactManager.Mvc.deploy.cmd /y /m:http://TESTWEB1/MSDEPLOYAGENTSERVICE a/:NTLM
Фактически исполняемый файл веб-развертывания может вывести адрес конечной точки удаленного агента, если указать имя компьютера, поэтому Мэтту нужно ввести только следующее:
ContactManager.Mvc.deploy.cmd /y /m:TESTWEB1 /a:NTLM
Примечание
Дополнительные сведения о синтаксисе командной строки веб-развертывания и файлах .deploy.cmd см. в разделе Практическое руководство. Установка пакета развертывания с помощью файла deploy.cmd.
Удаленный агент предлагает простой способ развертывания содержимого из удаленного расположения, и этот подход может хорошо работать при развертывании одним щелчком мыши или автоматическом развертывании. Однако пользователь, выполняющий команду развертывания, также должен быть администратором домена или членом локальной группы администраторов на целевом сервере. Кроме того, удаленный агент не поддерживает обычную проверку подлинности, поэтому вы не можете передать альтернативные учетные данные в командной строке.
Удаленный агент предоставляет полезный подход к развертыванию в сценариях разработки или тестирования, где разработчики нередко имеют полный контроль администратора над тестовой серверной средой, а приложения обычно перестраиваются и развертываются очень часто. Однако этот подход обычно менее приемлем для промежуточной или рабочей среды.
Полный пример сценария, в котором используется подход удаленного агента, см. в разделе Сценарий: настройка тестовой среды для веб-развертывания.
Использование временного агента
Временный подход к развертыванию агента аналогичен подходу к удаленному агенту. Однако, в отличие от удаленного агента, вам не нужно устанавливать веб-развертывание на целевом веб-сервере. Вместо этого при выполнении развертывания веб-развертывание установит временную версию службы агента веб-развертывания на целевом сервере и будет использовать ее для развертывания содержимого в IIS. После завершения развертывания удаляются все временные файлы.
Если вы хотите использовать параметр поставщика временного агента, добавьте флаг /g в команду развертывания:
ContactManager.Mvc.deploy.cmd /y /m:TESTWEB1 /g:true
Примечание
Временный агент нельзя использовать, если служба агента веб-развертывания установлена на конечном компьютере, даже если служба не запущена.
Преимущество этого подхода заключается в том, что вам не нужно поддерживать установку веб-развертывания на целевых серверах. Кроме того, вам не нужно убедиться, что на исходном и целевом компьютерах установлена одинаковая версия веб-развертывания. Однако этот подход имеет те же основные ограничения, что и подход к удаленному агенту, а именно, что для развертывания содержимого необходимо быть локальным администратором на целевом сервере, и поддерживается только проверка подлинности NTLM. Для использования временного агента также требуется гораздо больше начальной настройки среды назначения.
Дополнительные сведения об использовании временного агента см. в разделах Практическое руководство. Установка пакета развертывания с помощью файла deploy.cmd и Веб-развертывание по запросу.
Использование обработчика веб-развертывания
Для IIS 7 и более поздних версий веб-развертывание предлагает альтернативный подход к развертыванию с помощью обработчика веб-развертывания IIS. Обработчик веб-развертывания тесно интегрирован со службой управления веб-службами IIS (WMSvc), которая позволяет пользователям управлять веб-сайтами IIS из удаленных расположений.
По умолчанию удаленный агент предоставляет конечную точку HTTP по этому адресу:
https://[server]:8172/MSDeploy.axd
Примечание
Вы можете заменить [server] именем компьютера веб-сервера, IP-адресом веб-сервера или именем узла, которое разрешается в веб-сервер.
Большое преимущество обработчика веб-развертывания по сравнению с удаленным агентом и временным агентом заключается в том, что вы можете настроить СЛУЖБЫ IIS, чтобы разрешить пользователям без прав администратора развертывать приложения и содержимое на определенных веб-сайтах IIS. Обработчик веб-развертывания также поддерживает обычную проверку подлинности, поэтому вы можете указать альтернативные учетные данные в качестве параметров в командах веб-развертывания. Основным недостатком является то, что изначально обработчик веб-развертывания гораздо сложнее при настройке.
В случае пользователей, не являющихся администраторами, служба веб-управления (WMSvc) разрешает пользователю подключаться к СЛУЖБАм IIS только с помощью подключения на уровне сайта, а не на уровне сервера. Чтобы получить доступ к определенному сайту, можно включить строку запроса для конкретного сайта в адрес конечной точки:
https://[server]:8172/MSDeploy.axd?site=DemoSite
Например, предположим, что процесс сборки настроен для автоматического развертывания веб-приложения в промежуточной среде после каждой успешной сборки. Если вы использовали удаленный агент, необходимо сделать удостоверение процесса сборки администратором на целевых серверах. В отличие от этого, используя подход обработчика веб-развертывания, вы можете предоставить пользователю без прав администратора (в данном случае 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=%ContactManagerPublishPassword%,
authtype='Basic',
-verb:sync
-setParamFile:"…\ContactManager.Mvc.SetParameters.xml"
-allowUntrusted
Примечание
Дополнительные сведения об операциях и синтаксисе командной строки веб-развертывания см. в разделе Справочник по командной строке веб-развертывания. Дополнительные сведения об использовании файла .deploy.cmd см. в разделе Практическое руководство. Установка пакета развертывания с помощью файла deploy.cmd.
Обработчик веб-развертывания предоставляет полезный подход к развертыванию в промежуточных средах, размещенных средах и рабочих средах на основе интрасети, где удаленный доступ к серверу доступен, но учетные данные администратора отсутствуют.
Полный пример сценария, использующего обработчик веб-развертывания, см. в разделе Сценарий: настройка промежуточной среды для веб-развертывания.
Использование автономного развертывания
В некоторых случаях невозможно или нецелесообразно развертывать приложения и содержимое на веб-сайте IIS из удаленного расположения. Например, исходный и конечный компьютеры могут находиться в изолированных сетях или сегментах сети, или политика брандмауэра может не разрешать удаленный доступ.
В таких сценариях вы по-прежнему можете использовать возможности упаковки и публикации веб-развертывания. вы просто не можете использовать их из удаленного расположения. Вместо этого администратор на целевом сервере должен скопировать веб-пакет на сервер и импортировать его через диспетчер IIS.
Автономный подход к развертыванию обычно полезен в рабочих средах с выходом в Интернет, где серверы в сети периметра могут иметь ограниченное подключение к компьютерам во внутренней сети.
Полный пример сценария, использующего автономный подход к развертыванию, см. в разделе Сценарий: Настройка рабочей среды для веб-развертывания.
Дополнительные материалы
Дополнительные сведения об операциях командной строки и синтаксисе веб-развертывания см. в справочнике по командной строке веб-развертывания. Дополнительные сведения об использовании файла .deploy.cmd см. в разделе Практическое руководство. Установка пакета развертывания с помощью файла deploy.cmd.
Более общие рекомендации по различным способам развертывания веб-пакетов с удаленного компьютера см. в статье Использование удаленного веб-развертывания. Дополнительные сведения об использовании веб-развертывания по запросу см. в разделе Веб-развертывание по запросу.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по