Ok donc je suis arrivé jusqu'ici - je ne poste pas ceci comme une modification à la question, au cas où, bien que cela semble être sur la bonne voie, il pourrait y avoir un meilleur moyen que celui sur lequel j'ai travaillé . Je laisserais la démocratie décider!
En utilisant ce lien, j'ai pu déterminer le format du fichier XML qui devrait être utilisé avec le setParamFilecommutateur pour msdeploy. J'avais également, par le passé, trouvé le format du XML declareParamFile en utilisant l'interface graphique intégrée dans IIS après l'installation de l'outil de déploiement Web.
Donc, étant donné un site appelé «SiteA», avec deux entrées de liaison dans le fichier applicationHost.config comme suit:
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
<binding protocol="https" bindingInformation="*:443:" />
</bindings>
(Ce qui signifie, spécifiquement - toute adresse IP sur le port 80 et toute adresse IP sur le port 443)
Le certificat réel utilisé n'est pas stocké dans applicationHost.Config, mais à la place dans la configuration pour Http.sys (selon cet article ). Lorsque msdeploy prépare un package pour le site, il intègre ces informations - ce qui pourrait ne pas être une bénédiction comme je le mentionne à la fin.
La première étape consiste à déclarer un fichier xml de paramètres que nous utiliserons pour paramétrer un seul package pour les serveurs live cibles:
<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>
Notez les valeurs d'attribut 'match =' sur les deux entrées de paramètres internes. Cela garantit que la liaison correcte est remplacée. Il s'agit d'une expression régulière (comme décrit dans cet article technet ) qui sélectionne les valeurs de liaison existantes qui doivent être modifiées avec la valeur de paramètre qui sera transmise dans un instant.
Nous l'enregistrons sous declareparameters.xml.
Avec cela en place, nous pouvons maintenant générer un package paramétré, à partir de notre boîte de transfert, à partir duquel nous pouvons ensuite déployer, à l'aide de cette ligne de commande (c'est pour «l'image» d'un IIS entier dans lequel notre SiteA est présent):
msdeploy -verb:sync
-source:WebServer,computerName=localhost
-dest:package="parameterised.zip"
-declareParamFile:declareparameters.xml
Si le site Web se trouve sur un autre serveur Web, remplacez «localhost» par le nom de ce serveur Web. Le service Web Deploy Agent doit être exécuté sur la machine cible pour que cela fonctionne.
Maintenant, nous déclarons un fichier xml de paramètres qui fournira réellement des valeurs de paramètres pour un déploiement sur un serveur en direct:
<parameters>
<setParameter name="SiteA-http" value="[fixedIPAddress]:80:"/>
<setParameter name="SiteA-https" value="[fixedIPAddress]:443:"/>
</parameters>
Et nous enregistrons cela comme
[targetServerName]parameters.xml
(dans mon cas, j'ai deux serveurs cibles, donc chacun obtient ses propres paramètres xml avec un nom de fichier différent et des adresses IP légèrement différentes dans chacun).
Enfin, nous pouvons effectuer le déploiement paramétré sur le (s) serveur (s) cible (s) avec cette ligne de commande:
msdeploy -verb:sync
-source:package="parameterised.zip"
-dest:WebServer,computerName="[targetServerName]"
-setParamFile=[targetServerName]parameters.xml
Alors maintenant, nous pouvons changer les adresses IP de la liaison Http ou Https et, si les originaux sont suffisamment différents, nous pouvons paramétrer n'importe quel nombre de liaisons individuelles qui pourraient être nécessaires pour ce site.
Cela a un inconvénient jusqu'à présent - donc toutes les réponses alternatives sont appréciées s'il vous plaît - la configuration SSL est copiée de la machine source dans le package - ce qui signifie que pour que la configuration SSL sur le site en direct soit correcte lors du déploiement, à la fois la machine intermédiaire et le ou les serveurs en direct doivent utiliser exactement les mêmes certificats SSL.
Ce qui serait génial, c'est que la boîte de transfert puisse utiliser un certificat auto-signé ou interne pour la vérification de l'intégrité, puis que le véritable certificat SSL soit appliqué sur le déploiement réel - encore une fois, paramétré à partir des fichiers XML.