Итак, я получил это далеко - я не публикую это как редактирование вопроса, потому что нет шансов, что хотя это, кажется, на правильном пути, может быть, есть лучший способ, чем то, над чем я работал , Рисунок, который я позволил бы демократии решить!
Используя эту ссылку, я смог выяснить формат файла XML, который следует использовать с setParamFileпереключателем для msdeploy. В прошлом я также выяснял формат для XML-файла DeclareParamFile, используя встроенный графический интерфейс в IIS после установки Web Deployment Tool.
Итак, для сайта под названием «SiteA» с двумя обязательными записями в файле applicationHost.config:
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
<binding protocol="https" bindingInformation="*:443:" />
</bindings>
(Что означает, в частности - любой IP-адрес на порту 80 и любой IP-адрес на порту 443)
Фактический используемый сертификат сохраняется не в applicationHost.Config, а в конфигурации для Http.sys (согласно этой статье ). Когда msdeploy готовит пакет для сайта, он будет встраивать эту информацию - что, возможно, не является благословением, как я упоминаю в конце.
Первый шаг - объявить XML-файл параметров, который мы будем использовать для параметризации одного пакета для целевых живых серверов:
<parameters>
<!-- declare parameter for Http Binding -->
<parameter name="SiteA-http" description="SiteA Http Binding">
<parameterEntry kind="DestinationBinding" scope="SiteA" match=":80:" />
</parameter>
<!-- declare parameter for Https Binding -->
<parameter name="SiteA-https" description="SiteA Https Binding">
<parameterEntry kind="DestinationBinding" scope="SiteA" match=":443:" />
</parameter>
</parameters>
Обратите внимание на значения атрибута 'match =' в двух внутренних записях параметров. Это гарантирует, что правильная привязка будет заменена. Это Regex (как описано в этой статье Technet ), который выбирает существующие значения привязки, которые должны быть изменены, со значением параметра, которое будет передано в данный момент.
Мы сохраняем это как declareparameters.xml.
Имея это в виду, мы можем теперь создать параметризованный пакет из нашего промежуточного окна, из которого мы можем затем развернуть, используя эту командную строку (это «образ» целого IIS, в котором присутствует наш SiteA):
msdeploy -verb:sync
-source:WebServer,computerName=localhost
-dest:package="parameterised.zip"
-declareParamFile:declareparameters.xml
Если веб-сайт находится на другом веб-сервере, замените «localhost» именем этого веб-сервера. Чтобы это работало, на целевом компьютере должна быть запущена служба агента Web Deploy.
Теперь мы объявляем XML-файл параметров, который фактически предоставит значения параметров для развертывания на работающем сервере:
<parameters>
<setParameter name="SiteA-http" value="[fixedIPAddress]:80:"/>
<setParameter name="SiteA-https" value="[fixedIPAddress]:443:"/>
</parameters>
И мы сохраняем это как
[targetServerName]parameters.xml
(в моем случае у меня есть два целевых сервера, поэтому каждый получает свои собственные параметры xml с разными именами файлов и немного разными IP-адресами на каждом).
Наконец, мы можем выполнить параметризованное развертывание на целевом сервере (ах) с помощью этой командной строки:
msdeploy -verb:sync
-source:package="parameterised.zip"
-dest:WebServer,computerName="[targetServerName]"
-setParamFile=[targetServerName]parameters.xml
Так что теперь мы можем изменить IP-адреса привязки Http или Https и, если оригиналы достаточно разные, мы можем параметризовать любое количество отдельных привязок, которые могут потребоваться для этого сайта.
Пока у этого есть один недостаток - поэтому любые альтернативные ответы приветствуются - конфигурация SSL копируется с исходного компьютера в пакет - это означает, что для правильной конфигурации SSL на действующем сайте при развертывании, и промежуточный компьютер, и Живой сервер (ы) должен использовать точно такие же сертификаты SSL.
Было бы замечательно, если бы промежуточный ящик мог использовать самоподписанный или внутренний сертификат для проверки работоспособности, а затем применить настоящий сертификат SSL к фактическому развертыванию - опять же, параметризованный из файлов XML.