2015-03-16 2 views
5

Qual è il modo migliore per distribuire le modifiche a un sito Web (sostituire le DLL e altri file richiesti)?Il modo migliore per distribuire il sito Web - Arresto del pool di app o arresto del sito Web

Il sito Web deve essere arrestato e avviato o il pool di applicazioni deve essere arrestato e avviato?

Ho letto che quando un sito Web viene arrestato, ha ancora lo stato dell'applicazione caricato in memoria. In questo caso verrà servita la vecchia richiesta? Le dll possono essere sostituite senza problemi? Come viene ricaricato il contenuto quando viene avviato il sito Web?

Quando il pool di applicazioni viene arrestato, continuerà a servire le vecchie richieste? Se sì, come viene offerta la vecchia richiesta considerando che il sito Web contiene ora le DLL modificate?

risposta

4

Qual è il modo migliore per distribuire le modifiche a un sito Web (sostituire le DLL e altri file richiesti)?

Il modo migliore è utilizzare Web Deploy per automatizzare il processo. Confronta automaticamente i file e sostituisce solo ciò che è necessario ed elimina ciò che non è necessario, rendendolo molto veloce, efficiente e affidabile.

Il sito Web deve essere arrestato e avviato o il pool di applicazioni deve essere arrestato e avviato?

In genere non è necessario. Tuttavia, se si desidera impedire l'accesso al sito Web durante un aggiornamento e l'aggiornamento dovrebbe richiedere più di qualche secondo, è possibile interrompere il sito Web e avviarne un altro che utilizza gli stessi collegamenti IIS con "Applicazione in manutenzione". " Messaggio.

Ho letto che quando un sito Web viene arrestato, ha ancora lo stato dell'applicazione caricato in memoria. In questo caso verrà servita la vecchia richiesta? Le dll possono essere sostituite senza problemi? Come viene ricaricato il contenuto quando viene avviato il sito Web?

Il protocollo HTTP è senza stato. Quindi, la maggior parte dei contenuti che vengono aggiornati verranno ricaricati dai nuovi file sul server.

Ci sono alcune eccezioni.

Se si utilizza out-of-process session state, lo stato verrà mantenuto anche se l'applicazione viene ricompilata e ricaricata. In genere, i dati che hai in stato di sessione sono qualcosa che vuoi sopravvivere a un aggiornamento, però.

Se si utilizza la memorizzazione nella cache (System.Web.Caching o System.Runtime.Caching), i dati memorizzati nella cache rimarranno se si è specificato di renderlo "Non rimovibile". In genere, utilizzo un singolo file per l'applicazione come dipendenza dalla cache , quindi quando il file viene modificato (o sostituito) sul server, la cache verrà ripristinata.

La memorizzazione nella cache di output non ha dipendenze della cache. Normalmente sopravvive fino al riavvio del pool di applicazioni. Tuttavia, è possibile vedere this answer per un modo manuale di reimpostarlo senza reimpostare il pool di applicazioni.

I cookie sono memorizzati sui computer client remoti. Pertanto, sopravviveranno a un aggiornamento intatto.

I file statici (immagini, css e file javascript) sono in genere memorizzati nella cache dei computer client remoti. Pertanto, quando si esegue un aggiornamento, è utile aggiungere una stringa di query alla fine di questi URL per garantire che il file memorizzato nella cache non venga utilizzato. Vedi this article per un approccio di questo tipo.

Quando il pool di applicazioni viene arrestato, continuerà a servire le vecchie richieste? Se sì, come viene offerta la vecchia richiesta considerando che il sito Web contiene ora le DLL modificate?

Come già accennato, il protocollo HTTP è senza stato. Il server non riprodurrà alcuna precedente richiesta effettuata dai client. Una volta che il cliente ha ricevuto la risposta, il server essenzialmente si dimentica di loro.

Gran parte del modo in cui il server Web gestisce un aggiornamento è determinata dal fatto che si tratti di un'applicazione Web o di un sito Web (e se un sito Web, se è stato precompilato). Se l'applicazione è in esecuzione durante un aggiornamento, gli utenti che tentano di accedervi potrebbero vedere errori.

Il mio consiglio è: non preoccuparti. Pianifica i tuoi aggiornamenti per orari non di punta. Utilizzare Web Deploy per automatizzare il processo per rendere la finestra di aggiornamento il più breve possibile. E utilizzare le tecniche di cui sopra per garantire dati memorizzati nella cache e il contenuto viene ripristinato in modo appropriato. Nella maggior parte delle applicazioni, alcuni secondi o minuti di interruzione nel mezzo della notte passano quasi inosservati.

+0

Grazie per la risposta Nel nostro caso non abbiamo alcuna finestra di manutenzione per la distribuzione in modo che il messaggio offline non sia un opzione per noi. Prendiamo batch di server da LB e quindi aspettiamo che le connessioni si esauriscano. Quando le connessioni sono molto inferiori, iniziamo distribuzione su questi server. Quindi volevo capire che in questo caso qual è il modo migliore per la distribuzione? Nel caso in cui il pool di app venga arrestato e avviato, cosa succede alle vecchie connessioni che erano ancora presenti all'avvio della distribuzione? Sarebbero stati serviti o no? – Tulika

+0

In caso di riciclo del pool di applicazioni, a causa del riciclo su richiesta, è necessario servire le vecchie connessioni. Ma voglio capire che quando ho sostituito le DLL nella cartella del sito web, come vengono servite le richieste per la vecchia connessione? sono memorizzati nella memoria? – Tulika

0

Prima di tutto non mi piace la distribuzione sul Web richiede molte cose installate e gestite sui server. è anche più complicato di quanto deve essere. (la mia opinione) stavo leggendo i tuoi commenti:

le seguenti opzioni sono necessarie per quello che vuoi fare: archettura: devi eseguire 2 stack di server del sito con un bilanciatore del carico di qualche tipo. (web front e middleware o qualsiasi altra cosa tu stia facendo)

prendere uno stack fuori linea dal firewall, lasciare l'applicazione dal vivo sull'altro lato controllare i log per assicurarsi che le transazioni siano state completate sul sito a cui si sta eseguendo la distribuzione.

fare la distribuzione:

stop Web del sito/servizio (AppPool) rimuovere tutti i file esistenti relativi a quel servizio web/sito per l'utilizzo da udpateing XCOPY per installare tutti i file (o l'estratto zip di indirizzare funziona anche avviare sito Web/servizio (AppPool) test dalla rete interna per assicurarsi che funzioni la distribuzione completata.

disattivare l'accesso a un altro sito e attivare sito (o porcili) aver completato (al bilanciamento del carico firewall. questo permetterà le transazioni esistenti per completare e renderà il vostro nuovo codice dal vivo.

c'è più articoli che dovrebbero essere guardati nella tua implementazione, ma questo dovrebbe iniziare eh, fortuna e fortuna!