Wie man eine ASP.NET-Anwendung ohne Ausfallzeiten bereitstellt

Question

Um eine neue Version unserer Website bereitzustellen, gehen wir wie folgt vor:

1. Zipen Sie den neuen Code und laden Sie ihn auf den Server hoch.
2. Löschen Sie auf dem Live-Server den gesamten Live-Code aus dem IIS-Website-Verzeichnis.
3. Entpacken Sie die neue Code-Zipdatei in das nun leere IIS-Verzeichnis

Dieser Vorgang ist skriptgesteuert und geht recht schnell vonstatten, dennoch kann es zu einer Ausfallzeit von 10-20 Sekunden kommen, wenn die alten Dateien gelöscht und die neuen Dateien bereitgestellt werden.

Gibt es Vorschläge für eine Methode mit 0 Sekunden Ausfallzeit?

Answer 1

Sie benötigen 2 Server und einen Load Balancer. Hier ist in Schritten:

1. Den gesamten Datenverkehr auf Server 2 umleiten
2. Einsatz auf Server 1
3. Test-Server 1
4. Den gesamten Datenverkehr auf Server 1 umleiten
5. Einsatz auf Server 2
6. Test-Server 2
7. Verkehr auf beiden Servern umleiten

Aber auch in diesem Fall kommt es zu Neustarts der Anwendung und zum Verlust von Sitzungen, wenn Sie "sticky sessions" verwenden. Wenn Sie Datenbanksitzungen oder einen Statusserver haben, sollte alles in Ordnung sein.

Answer 2

Le site Microsoft Web Deployment Tool unterstützt dies bis zu einem gewissen Grad:

Aktiviert die Windows-Transaktionsdatei System (TxF) Unterstützung. Wenn die TxF-Unterstützung aktiviert ist, sind Dateioperationen atomar, d.h. sie sind entweder erfolgreich oder vollständig fehlschlagen. Dies gewährleistet, dass Daten Datenintegrität und verhindert, dass Daten oder Dateien in einer "halben" oder "falschen" Datei existieren. beschädigten Zustand. In MS Deploy ist TxF standardmäßig deaktiviert.

Es scheint, dass die Transaktion für die gesamte Synchronisierung gilt. Außerdem ist TxF eine Funktion von Windows Server 2008, daher funktioniert diese Transaktionsfunktion nicht mit früheren Versionen.

Ich glaube, es ist möglich, Ihr Skript für 0-Downtime mit Ordnern als Versionen und die IIS-Metabasis zu ändern:

• für einen vorhandenen Pfad/eine vorhandene URL:
  • 道 : \web\app\v2.0\
  • url : http://app
• Kopieren Sie die neue (oder geänderte) Website auf den Server unter
  • \web\app\v2.1\
• Ändern Sie die IIS-Metabasis, um den Website-Pfad zu ändern
  • von \web\app\2.0\
  • zu \web\app\v2.1\

Diese Methode bietet die folgenden Vorteile:

• Falls die neue Version ein Problem hat, können Sie einfach auf v2.0 zurückgehen.
• Für die Bereitstellung auf mehreren physischen oder virtuellen Servern können Sie Ihr Skript für die Dateiverteilung verwenden. Sobald alle Server über die neue Version verfügen, können Sie mit dem Microsoft Web Deployment Tool die Metadatenbanken aller Server gleichzeitig ändern.

Answer 3

Sie können eine ausfallfreie Bereitstellung auf einem einzigen Server erreichen, indem Sie Application Request Routing in IIS als Software-Lastausgleich zwischen zwei lokalen IIS-Sites auf verschiedenen Ports einsetzen. Dies ist bekannt als blue green deployment strategy wenn nur einer der beiden Standorte zu einem bestimmten Zeitpunkt im Load Balancer verfügbar ist. Stellen Sie die "ausgefallene" Site bereit, wärmen Sie sie auf und nehmen Sie sie in den Load Balancer auf (in der Regel durch Bestehen eines Application Request Routing-Gesundheitschecks), und nehmen Sie dann die ursprüngliche Site, die in Betrieb war, aus dem "Pool" heraus (wiederum durch Fehlschlagen ihres Gesundheitschecks).

Eine vollständige Anleitung finden Sie hier.

Answer 4

Ich habe das vor kurzem erlebt, und die Lösung, die ich gefunden habe, war, zwei Sites in IIS einzurichten und zwischen ihnen zu wechseln.

Bei meiner Konfiguration hatte ich ein Webverzeichnis für jede A- und B-Site wie folgt: c: \Intranet\Live A \Interface c: \Intranet\Live B \Interface

In IIS habe ich zwei identische Sites (gleiche Ports, Authentifizierung usw.) mit jeweils einem eigenen Anwendungspool. Eine der Sites läuft (A) und die andere ist angehalten (B). Die aktive Site hat auch den Live-Host-Header.

Wenn ich die Website live schalten will, veröffentliche ich sie einfach auf der STOPPED-Site. Da ich auf die B-Site über ihren Port zugreifen kann, kann ich die Site vorwärmen, damit der erste Benutzer keinen Anwendungsstart verursacht. Dann kopiere ich mit einer Batch-Datei den Live-Host-Header nach B, stoppe A und starte B.

Answer 5

OK, da jeder die Antwort, die ich 2008 geschrieben habe, herunterstuft*...

Ich werde Ihnen sagen, wie wir es jetzt im Jahr 2014 machen. Wir verwenden keine Websites mehr, weil wir jetzt ASP.NET MVC verwenden.

Wir brauchen sicherlich keinen Load Balancer und zwei Server, um dies zu tun, das ist in Ordnung, wenn Sie 3 Server für jede Website, die Sie pflegen, haben, aber es ist total overkill für die meisten Websites.

Außerdem verlassen wir uns nicht auf den neuesten Assistenten von Microsoft - zu langsam, zu viel versteckte Magie und zu anfällig dafür, seinen Namen zu ändern.

So machen wir es:

1. Wir haben einen Post-Build-Schritt, der die generierten DLLs in einen 'bin-pub'-Ordner kopiert.

2. Wir verwenden Beyond Compare (ein hervorragendes Tool**), um geänderte Dateien zu überprüfen und mit dem Produktionsserver zu synchronisieren (über FTP, da dies weitgehend unterstützt wird).

3. Wir haben eine sichere URL auf der Website, die eine Schaltfläche enthält, mit der alles in "bin-pub" nach "bin" kopiert wird (vorher wird ein Backup erstellt, um ein schnelles Rollback zu ermöglichen). An diesem Punkt startet sich die Anwendung neu. Dann prüft unser ORM, ob es Tabellen oder Spalten gibt, die hinzugefügt werden müssen, und erstellt sie.

Das sind nur Millisekunden Ausfallzeit. Der Neustart der Anwendung kann ein oder zwei Sekunden dauern, aber während des Neustarts werden die Anfragen gepuffert, so dass es praktisch keine Ausfallzeit gibt.

Der gesamte Bereitstellungsprozess dauert zwischen 5 Sekunden und 30 Minuten, je nachdem, wie viele Dateien geändert werden und wie viele Änderungen zu überprüfen sind.

Auf diese Weise müssen Sie nicht die gesamte Website in ein anderes Verzeichnis kopieren, sondern nur den bin-Ordner. Außerdem haben Sie die vollständige Kontrolle über den Prozess und wissen genau, was sich ändert.

**Wir machen immer einen kurzen Blick auf die Änderungen, die wir bereitstellen - als doppelte Überprüfung in letzter Minute, damit wir wissen, was wir testen müssen und falls etwas nicht funktioniert, sind wir bereit. Wir verwenden Beyond Compare, weil man damit Dateien einfach über FTP vergleichen kann. Ich würde das nie ohne BC machen, man hat keine Ahnung, was man da überschreibt.

*Scrollen Sie nach unten, um es zu sehen :( Übrigens würde ich keine Websites mehr empfehlen, weil sie langsamer zu bauen sind und mit halb kompilierten temporären Dateien schwer abstürzen können. Wir haben sie in der Vergangenheit verwendet, weil sie eine flexiblere Datei-für-Datei-Bereitstellung ermöglichten. Kleinere Probleme lassen sich sehr schnell beheben, und man kann genau sehen, was man bereitstellt (natürlich nur, wenn man Beyond Compare verwendet - ansonsten kann man es vergessen).