Ok, also bin ich so weit gekommen - ich poste dies nicht als Bearbeitung der Frage, da es nicht möglich ist, dass es einen besseren Weg gibt als das, woran ich gearbeitet habe, obwohl dies auf dem richtigen Weg zu sein scheint . Ich würde die Demokratie entscheiden lassen!
Über diesen Link konnte ich das Format der XML-Datei ermitteln, die mit dem setParamFileSwitch für msdeploy verwendet werden soll. In der Vergangenheit hatte ich auch das Format für das DeklarationsparamFile-XML mithilfe der eingebetteten GUI in IIS nach der Installation des Web Deployment Tools ermittelt.
Bei einer Site namens 'SiteA' mit zwei verbindlichen Einträgen in der Datei applicationHost.config wie folgt:
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
<binding protocol="https" bindingInformation="*:443:" />
</bindings>
(Was speziell bedeutet - jede IP-Adresse an Port 80 und jede IP-Adresse an Port 443)
Das tatsächlich verwendete Zertifikat wird nicht in applicationHost.Config gespeichert, sondern in der Konfiguration für Http.sys (gemäß diesem Artikel ). Wenn msdeploy ein Paket für die Site vorbereitet, werden diese Informationen eingebettet - was möglicherweise kein Segen ist, wie ich am Ende erwähne.
Der erste Schritt besteht darin, eine Parameter-XML-Datei zu deklarieren, mit der ein einzelnes Paket für die Live-Zielserver parametrisiert wird:
<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>
Beachten Sie die Attributwerte 'match =' für die beiden inneren Parametereinträge. Dies stellt sicher, dass die korrekte Bindung ersetzt wird. Dies ist ein Regex (wie in diesem Technet-Artikel beschrieben ), der die vorhandenen Bindungswerte auswählt, die mit dem Parameterwert geändert werden sollen, der in einem Moment übergeben wird.
Wir speichern dies als declareparameters.xml.
Mit dieser Funktion können wir jetzt aus unserer Staging-Box ein parametrisiertes Paket generieren, aus dem wir dann über diese Befehlszeile bereitstellen können (dies dient dazu, einen gesamten IIS abzubilden, in dem unsere SiteA vorhanden ist):
msdeploy -verb:sync
-source:WebServer,computerName=localhost
-dest:package="parameterised.zip"
-declareParamFile:declareparameters.xml
Wenn sich die Website auf einem anderen Webserver befindet, ersetzen Sie 'localhost' durch den Namen dieses Webservers. Der Web Deploy Agent-Dienst muss auf dem Zielcomputer ausgeführt werden, damit dies funktioniert.
Jetzt deklarieren wir eine Parameter-XML-Datei, die tatsächlich Parameterwerte für eine Bereitstellung auf einem Live-Server bereitstellt :
<parameters>
<setParameter name="SiteA-http" value="[fixedIPAddress]:80:"/>
<setParameter name="SiteA-https" value="[fixedIPAddress]:443:"/>
</parameters>
Und das speichern wir als
[targetServerName]parameters.xml
(In meinem Fall habe ich zwei Zielserver, daher erhält jeder seine eigenen Parameter xml mit einem anderen Dateinamen und leicht unterschiedlichen IPs in jedem).
Schließlich können wir die parametrisierte Bereitstellung auf den Zielservern mit dieser Befehlszeile durchführen:
msdeploy -verb:sync
-source:package="parameterised.zip"
-dest:WebServer,computerName="[targetServerName]"
-setParamFile=[targetServerName]parameters.xml
Jetzt können wir die IPs der HTTP- oder HTTP-Bindung ändern und, wenn die Originale ausreichend unterschiedlich sind, eine beliebige Anzahl einzelner Bindungen parametrisieren, die für diese Site erforderlich sein könnten.
Dies hat bisher einen Nachteil - daher werden alternative Antworten bitte geschätzt - die SSL-Konfiguration wird vom Quellcomputer in das Paket kopiert. Dies bedeutet, dass die SSL-Konfiguration auf der Live-Site bei der Bereitstellung sowohl auf dem Staging-Computer als auch auf dem Staging-Computer korrekt ist Die Live-Server müssen genau dieselben SSL-Zertifikate verwenden.
Es wäre großartig, wenn die Staging-Box ein selbstsigniertes oder internes Zertifikat für die Überprüfung der Integrität verwenden und dann das echte SSL-Zertifikat auf die tatsächliche Bereitstellung anwenden könnte - wiederum parametrisiert aus den XML-Dateien.