Ok, así que llegué hasta aquí: no estoy publicando esto como una edición de la pregunta, en el caso de que, aunque parezca estar en el camino correcto, podría haber una mejor manera de lo que he estado trabajando. . ¡Creo que dejaría que la democracia decidiera!
Usando este enlace pude averiguar el formato del archivo XML que debería usarse con el setParamFileconmutador para msdeploy. También, en el pasado, descubrí el formato para declareParamFile XML utilizando la GUI incrustada dentro de IIS después de instalar la herramienta de implementación web.
Entonces, dado un sitio llamado 'SiteA', con dos entradas vinculantes en el archivo applicationHost.config de la siguiente manera:
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
<binding protocol="https" bindingInformation="*:443:" />
</bindings>
(Lo que significa, específicamente, cualquier dirección IP en el puerto 80 y cualquier dirección IP en el puerto 443)
El certificado real que se utiliza no se almacena en applicationHost.Config, sino en la configuración de Http.sys (de acuerdo con este artículo ). Cuando msdeploy prepara un paquete para el sitio, incorporará esa información, lo que podría no ser una bendición como menciono al final.
El primer paso es declarar un archivo xml de parámetros que usaremos para parametrizar un solo paquete para los servidores en vivo de destino:
<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>
Tenga en cuenta los valores de atributo 'match =' en las dos entradas de parámetros internos. Esto asegura que se reemplaza la unión correcta. Este es un Regex (como se describe en este artículo de Technet ) que selecciona los valores de enlace existentes que se cambiarán con el valor del parámetro que se pasará en un momento.
Guardamos esto como declareparameters.xml.
Con esto en su lugar, ahora podemos generar un paquete parametrizado, desde nuestro cuadro de etapas, desde el cual podemos implementarlo, usando esta línea de comando (esto es para 'crear imágenes' de un IIS completo dentro del cual está presente nuestro SiteA):
msdeploy -verb:sync
-source:WebServer,computerName=localhost
-dest:package="parameterised.zip"
-declareParamFile:declareparameters.xml
Si el sitio web está en un servidor web diferente, reemplace 'localhost' con el nombre de ese servidor web. El servicio del Agente de implementación web debe ejecutarse en la máquina de destino para que esto funcione.
Ahora, declaramos un archivo xml de parámetros que realmente proporcionará valores de parámetros para una implementación en un servidor en vivo:
<parameters>
<setParameter name="SiteA-http" value="[fixedIPAddress]:80:"/>
<setParameter name="SiteA-https" value="[fixedIPAddress]:443:"/>
</parameters>
Y lo guardamos como
[targetServerName]parameters.xml
(en mi caso, tengo dos servidores de destino, por lo que cada uno tiene sus propios parámetros xml con un nombre de archivo diferente e IP ligeramente diferentes en cada uno).
Finalmente, podemos realizar la implementación parametrizada en los servidores de destino con esta línea de comando:
msdeploy -verb:sync
-source:package="parameterised.zip"
-dest:WebServer,computerName="[targetServerName]"
-setParamFile=[targetServerName]parameters.xml
Así que ahora podemos cambiar las direcciones IP de los enlaces Http o Https y, si los originales son lo suficientemente diferentes, podemos parametrizar cualquier número de enlaces individuales que puedan ser necesarios para ese sitio.
Esto tiene un inconveniente hasta el momento, por lo que se agradece cualquier respuesta alternativa, la configuración de SSL se copia de la máquina de origen en el paquete, lo que significa que para que la configuración de SSL en el sitio en vivo sea correcta en la implementación, tanto la máquina de preparación como la los servidores en vivo deben usar exactamente los mismos certificados SSL.
Lo que sería genial es que el cuadro de ensayo pudiera usar un certificado autofirmado o interno para la verificación de la cordura, y luego aplicar el certificado SSL real en la implementación real, nuevamente, parametrizado a partir de los archivos XML.