Zero downtime uploads / Rollback in IIS

Non sono sicuro se questo è il modo giusto di porre questa domanda, ma qui è sostanzialmente quello che mi piacerebbe fare:

1.) Invia un changeset a un sito in IIS.
2.) Non interrompere gli utenti.
3.) Essere in grado di tornare indietro senza sforzo.

Quindi, ci sono alcune cose che so che devono accadere:

1.) Sessione fuori Proc - gestita
2.) Cache Fuori Proc - gestita

Quindi le domande che rimangono:
1.) Come posso evitare di interrompere gli utenti? Se carico semplicemente i file nel cestino, l'app ricicla e impiega più di 10 secondi per tornare online
2.) Come faccio a tornare indietro senza sforzo?

Stavo pensando che una possibile soluzione sarebbe quella di avere due siti istituiti in IIS, uno pubblico e uno privato. I caricamenti diventano privati ​​e si scaldano. Dopo il riscaldamento, i siti vengono scambiati. Un rollback implica solo il passaggio a privato senza un caricamento.

Sembra teoricamente sano, ma non sono sicuro della meccanica. Qualche idea?

Ecco come affronterei questo problema: tieni presente che non l'ho mai fatto prima, sono solo concetti che ho testato un po 'nel mio ambiente di sviluppo. Dovresti essere in grado di impostare un framework abbastanza robusto usando questo e alcuni script nella tua lingua preferita. Fondamentalmente installeremo un ambiente di bilanciamento del carico del ghetto e lo useremo per passare dal nuovo sito al vecchio sito.

Per farlo, avrai bisogno di:

• Modulo IIS Application Request Routing (ARR)
• Strumento di distribuzione Web IIS (msdeploy)
• 3 diversi siti Web IIS (con 3 diversi indirizzi IP - solo l'utilizzo di porte o intestazioni host potrebbe non funzionare qui)

Installa ARR per cominciare.

Installa i 3 siti Web in IIS:

• Il sito Web 1 sarà il sito a cui gli utenti si connettono effettivamente, diciamo http://192.168.1.1/. Questo è anche il sito ARR. Basta impostare una directory vuota a cui puntare e inserirla nel proprio pool di app. Configurare il pool di app in modo che non scada in timeout secondo queste istruzioni .
• I siti Web 2 e 3 saranno i siti che ospitano effettivamente i tuoi contenuti. Questi devono trovarsi sui propri IP e, a causa del funzionamento di ARR, su una porta diversa rispetto al sito Web 1. Diciamo che lo sono http://192.168.1.2:8080e http://192.168.1.3:8080. Dovrebbero anche trovarsi nei loro pool di app e puntare a directory diverse sul file system (ma in genere entrambe le directory hanno lo stesso contenuto)

Dopo aver installato ARR, ci sarà una nuova categoria in Gestione IIS chiamata "Server Farms": fai clic con il pulsante destro del mouse e crea una nuova farm.

• dagli un nome che sia significativo per te
• aggiungi Webserver 2 e Webserver 3 come server: assicurati di fare clic sul pulsante "Impostazioni avanzate", apri la categoria "applicationRequestRouting" e cambia il protocollo http su 8080 per ciascun server
• Completa la procedura guidata: ti verrà chiesto se desideri creare le regole di riscrittura URL: fai clic su Sì
• Ora hai una server farm - per completare la configurazione, vai alla farm e fai clic sul pulsante Configurazione proxy - attiva "inverti riscrivi host nelle intestazioni di risposta" e applica le modifiche
• In Gestione IIS, vai alla categoria del server di livello principale e fai clic sul pulsante Riscrivi URL, ci sarà una regola creata per la tua fattoria
  • fai doppio clic sulla regola per accedere alle impostazioni
  • aprire la casella Condizioni
  • aggiungere una nuova condizione per {SERVER_PORT}non corrisponde a 8080
  • applicare le modifiche

A questo punto hai le basi di ciò di cui abbiamo bisogno per soddisfare la tua richiesta. Se vai a http://192.168.1.1/ottenere il tuo sito Web dal sito Web 1 o dal sito Web 2, ma sarà completamente senza soluzione di continuità che ci siano altri siti.

Ora cosa puoi fare quando vuoi distribuire una nuova versione della tua applicazione è:

• drainstop 1 dei server nella tua farm (negli strumenti della server farm, vai su "Monitoraggio e gestione", scegli un server e scegli "Rendi il server non disponibile con grazia")
• distribuire la nuova versione del sito sul sistema offline
• riscalda il sito offline utilizzando il suo IP / porta alternativi
• rendere nuovamente disponibile il sito per la farm
• ripetere il processo per l'altro server

Lo strumento di distribuzione Web entra in gioco quando si parla di voler scrivere tutto questo. È semplicissimo creare un pacchetto per l'applicazione e distribuirlo dalla riga di comando. È inoltre possibile ripristinare facilmente quel pacchetto in caso di problemi. ARR è anche programmabile tramite script usando le Microsoft.Web.Administrationdll.

Un'altra cosa - se sei effettivamente su Windows 2008 R2 (che è IIS 7.5) dai un'occhiata al modulo di riscaldamento delle applicazioni - dovrebbe rendere più facile anche il riscaldamento di questa parte di te.

MattB l'ha colpito fuori dall'acqua. +1 risponderò con maggiori dettagli ma non sto cercando di prendere i suoi punti. Aggiungerò a quello che ha detto.

Ho una configurazione simile a quella che ha descritto e funziona benissimo. ARR è la strada da percorrere, anche su un singolo server.

Tuttavia, aggiungerei un paio di cose.

Crea i 2 siti, come raccomandato da Matt. Chiamali in qualche modo come yoursite.com01 e yoursite.com02.

Crea 2 regole di riscrittura URL. Uno per www.tuodominio.com e un altro staging.tuodominio.com. Per la produzione, utilizzare {HTTP_HOST} con un valore di (^ www.tuodominio.com $) | (il tuo IP). (o qualunque associazione preferiate) Per la stadiazione, utilizzare {HTTP_HOST} con un valore di (^ staging.tuodominio.com $). Chiama le regole yoursite.com e staging.yoursite.com.

Bind Rule = yoursite.com to site = yoursite.com01 e rule = staging.yoursite.com to site = yoursite.com02.

Installa FTP su staging.yoursite.com.

Il traffico di produzione ora sta andando a Rule = staging.yoursite.com e Site = yoursite.com01. Stagging al contrario.

Puoi eseguire la messa in scena in qualsiasi momento, test, pre-spinup, fare test ad altre persone, ecc. Durante il giorno, non importa. Distribuisci ogni volta sullo stesso account FTP. Funziona alla grande con i server di build.

Quindi, quando sei pronto per essere pubblicato, apporta solo 3 modifiche: - sposta l'associazione FTP da yoursite.com02 a yoursite.com01 - cambia URL Riscrivi regola yoursite.com per puntare a yoursite.com02 - cambia URL Riscrivi Staging regola. yoursite.com per puntare a yoursite.com01

Ora hai zero downtime, commutazione istantanea, con funzionalità di rollback immediato!

L'unico aspetto da considerare è lo stato della sessione fuori processo. Assicurarsi che il server di stato accetti entrambi gli ID sito in modo da non perdere lo stato della sessione durante lo scambio.

Si noti inoltre che questo è solo web e non database.

Per gli script, utilizzare l'editor di configurazione. Apporta le modifiche desiderate e fai clic su "Genera script". Ti fornirà il codice C #, appcmd o AHAdmin.

L'ho messo in atto per alcuni mesi con un front-end di una pagina Web per scambiare istanze e non mi guardo mai indietro. Rende le implementazioni così rinfrescanti rispetto alle implementazioni tradizionali.