Ok, sono arrivato così lontano - non sto pubblicando questo come una modifica alla domanda, per la possibilità che, sebbene questo sembri essere sulla buona strada, potrebbe esserci un modo migliore di quello su cui ho lavorato . Figura che lascerei decidere alla democrazia!
Usando questo link sono stato in grado di capire il formato del file XML che dovrebbe essere usato con lo setParamFileswitch per msdeploy. Inoltre, in passato, avevo capito il formato per il declareParamFile XML utilizzando la GUI integrata in IIS dopo aver installato lo strumento di distribuzione Web.
Quindi, dato un sito chiamato 'SiteA', con due voci vincolanti nel file applicationHost.config come segue:
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
<binding protocol="https" bindingInformation="*:443:" />
</bindings>
(Il che significa, in particolare, qualsiasi indirizzo IP sulla porta 80 e qualsiasi indirizzo IP sulla porta 443)
Il certificato effettivamente utilizzato non è memorizzato in applicationHost.Config, ma nella configurazione per Http.sys (secondo questo articolo ). Quando msdeploy prepara un pacchetto per il sito, incorporerà tali informazioni, che potrebbero non essere una benedizione, come ho già detto alla fine.
Il primo passo è dichiarare un file xml di parametri che useremo per parametrizzare un singolo pacchetto per i server live di destinazione:
<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>
Nota i valori dell'attributo 'match =' sulle due voci dei parametri interni. Ciò garantisce che venga sostituita la rilegatura corretta. Questo è un Regex (come descritto in questo articolo tecnico ) che seleziona i valori di associazione esistenti che devono essere modificati con il valore del parametro che verrà passato in un momento.
Lo salviamo come declareparameters.xml.
Con questo in atto, ora possiamo generare un pacchetto con parametri, dalla nostra casella di gestione temporanea, da cui possiamo quindi distribuire, usando questa riga di comando (questo è per "immaginare" un intero IIS all'interno del quale è presente il nostro SitoA):
msdeploy -verb:sync
-source:WebServer,computerName=localhost
-dest:package="parameterised.zip"
-declareParamFile:declareparameters.xml
Se il sito Web si trova su un altro server Web, sostituire "localhost" con il nome di quel server Web. Il servizio Web Deploy Agent deve essere in esecuzione sul computer di destinazione affinché funzioni.
Ora, dichiariamo un file XML parametri che effettivamente fornire i valori dei parametri per una distribuzione a un server di vivere:
<parameters>
<setParameter name="SiteA-http" value="[fixedIPAddress]:80:"/>
<setParameter name="SiteA-https" value="[fixedIPAddress]:443:"/>
</parameters>
E lo salviamo come
[targetServerName]parameters.xml
(nel mio caso ho due server di destinazione, quindi ognuno ottiene i propri parametri xml con un nome file diverso e IP leggermente diversi in ciascuno).
Infine, possiamo eseguire la distribuzione parametrizzata sui server di destinazione con questa riga di comando:
msdeploy -verb:sync
-source:package="parameterised.zip"
-dest:WebServer,computerName="[targetServerName]"
-setParamFile=[targetServerName]parameters.xml
Quindi ora possiamo cambiare gli IP di Http o Https Binding e, se gli originali sono sufficientemente diversi, possiamo parametrizzare qualsiasi numero di singoli binding che potrebbero essere richiesti per quel sito.
Questo ha uno svantaggio finora - quindi ogni risposta alternativa è stata apprezzata per favore - la configurazione SSL viene copiata dalla macchina di origine nel pacchetto - il che significa che, al fine di configurare correttamente la configurazione SSL sul sito live durante l'implementazione, sia la macchina di staging che i server live devono utilizzare esattamente gli stessi certificati SSL.
Ciò che sarebbe fantastico sarebbe se la casella di gestione temporanea potesse utilizzare un certificato autofirmato o interno per il controllo di integrità e quindi applicare il certificato SSL reale sulla distribuzione effettiva, ancora una volta, parametrizzata dai file XML.