Comment déployer une application ASP.NET avec zéro temps d'arrêt

Question

Pour déployer une nouvelle version de notre site Web, procédez comme suit:

1. Compressez le nouveau code et chargez-le sur le serveur.
2. Sur le serveur actif, supprimez tout le code actif du répertoire du site Web IIS.
3. Extrayez le nouveau fichier zip de code dans le répertoire IIS maintenant vide

Ce processus est entièrement scripté et se produit assez rapidement, mais il peut toujours y avoir un temps d'arrêt de 10 à 20 secondes lorsque les anciens fichiers sont supprimés et les nouveaux fichiers en cours de déploiement.

Des suggestions sur une méthode d’arrêt de 0 seconde?

Answer 1

Vous avez besoin de 2 serveurs et d'un équilibreur de charge. Voici les étapes:

1. Tout le trafic sur le serveur 2
2. Déployer sur le serveur 1
3. Test Server 1
4. Tout le trafic sur le serveur 1
5. Déployer sur le serveur 2
6. Test Server 2
7. Activer le trafic sur les deux serveurs

En fait, même dans ce cas, vous aurez toujours des redémarrages d’application et une perte de sessions si vous utilisez des "sessions collantes". Si vous avez des sessions de base de données ou un serveur d'état, tout devrait bien se passer.

Answer 2

Le L’Outil de déploiement Web Microsoft prend en charge ceci dans une certaine mesure:

  

Active le fichier transactionnel Windows   Prise en charge du système (TxF). Lorsque le support TxF   est activé, les opérations sur les fichiers sont   atomique; c'est-à-dire qu'ils réussissent   ou échouer complètement. Cela garantit des données   intégrité et empêche les données ou les fichiers   d’exister dans un " à mi-chemin " ou   État corrompu. Dans MS Deploy, TxF est   désactivé par défaut.

Il semble que la transaction concerne la synchronisation complète. De plus, TxF étant une fonctionnalité de Windows Server 2008, cette fonctionnalité de transaction ne fonctionnera pas avec les versions antérieures.

Je pense qu'il est possible de modifier votre script pour une période d'indisponibilité de 0 en utilisant des dossiers en tant que versions et la métabase IIS:

• pour un chemin / url existant:
  • chemin : \ web \ app \ v2.0 \
  • url : http: // application
• Copier le nouveau site Web (ou modifié) sur le serveur sous
  • \ web \ app \ v2.1 \
• Modifier la métabase IIS pour modifier le chemin du site Web
  • à partir de \ web \ app \ 2.0 \
  • à \ web \ app \ v2.1 \

Cette méthode offre les avantages suivants:

• Si la nouvelle version rencontre un problème, vous pouvez facilement revenir à la v2.0
• Pour déployer sur plusieurs serveurs physiques ou virtuels, vous pouvez utiliser votre script pour le déploiement de fichiers. Une fois que tous les serveurs ont la nouvelle version, vous pouvez modifier simultanément les métabase de tous les serveurs à l’aide de Microsoft Web Deployment Tool.

Answer 3

Vous pouvez obtenir un déploiement sans interruption sur un seul serveur en utilisant le routage des demandes d’application dans IIS en tant qu’équilibreur de charge logicielle entre deux sites IIS locaux situés sur des ports différents. Cette stratégie est connue sous le nom de stratégie de déploiement bleue verte dans laquelle un seul des deux sites est disponible dans l'équilibreur de charge à un moment donné. Déployez-le sur le site "en panne", réchauffez-le et transférez-le dans l'équilibreur de charge (généralement en passant une vérification de l'état de santé du routage des demandes d'application), puis sortez le "site" original du "pool". (encore une fois en faisant échouer son bilan de santé).

Vous trouverez un tutoriel complet ici.

Answer 4

Je suis passé par là récemment et la solution que j'ai proposée consistait à installer deux sites dans IIS et à basculer entre eux.

Pour ma configuration, j'avais un répertoire Web pour chaque site A et B, comme suit: c: \ Intranet \ Live A \ Interface c: \ Intranet \ Live B \ Interface

Dans IIS, j'ai deux sites identiques (mêmes ports, authentification, etc.), chacun avec son propre pool d'applications. L'un des sites est en cours d'exécution (A) et l'autre est arrêté (B). le live a aussi l'en-tête live host.

Lorsqu'il s'agit de déployer pour vivre, je publie simplement sur le site de STOPPED. Étant donné que je peux accéder au site B à l'aide de son port, je peux préchauffer le site afin que le premier utilisateur ne provoque pas le démarrage d'une application. Puis, en utilisant un fichier de commandes, je copie l'en-tête de l'hôte actif sur B, arrête A et démarre B.

Answer 5

En utilisant la classe ServerManager de Microsoft.Web.Administration, vous pouvez développer votre propre agent de déploiement.

Le truc consiste à changer le chemin PhysicalPath du répertoire virtuel, ce qui entraîne un commutateur atomique en ligne entre les anciennes et les nouvelles applications Web.

Sachez que cela peut entraîner l'exécution d'anciens et nouveaux AppDomains en parallèle!

Le problème est de savoir comment synchroniser les modifications apportées aux bases de données, etc.

En recherchant l'existence d'AppDomains avec d'anciens ou de nouveaux PhysicalPaths, il est possible de détecter la fin des anciens AppDomain (s) et si les nouveaux AppDomain (s) ont démarré.

Pour forcer un AppDomain à démarrer, vous devez envoyer une requête HTTP (IIS 7.5 prend en charge la fonctionnalité de démarrage automatique)

.

Vous avez maintenant besoin d’un moyen de bloquer les requêtes pour le nouvel AppDomain. J'utilise un mutex nommé, créé et appartenant à l'agent de déploiement, attendu par Application_Start de la nouvelle application Web, puis publié par l'agent de déploiement une fois les mises à jour effectuées.

(J'utilise un fichier marqueur dans l'application Web pour activer le comportement d'attente du mutex) Une fois que la nouvelle application Web est en cours d'exécution, je supprime le fichier de marqueur.

Answer 6

OK, puisque tout le monde vote contre la réponse que j'avais écrite en 2008 * ...

Je vais vous dire comment nous procédons maintenant en 2014. Nous n'utilisons plus de sites Web, car nous utilisons ASP.NET MVC maintenant.

Nous n’avons certainement pas besoin d’un équilibreur de charge et de deux serveurs, c’est bien si vous avez 3 serveurs pour chaque site Web que vous gérez, mais c’est excessif pour la plupart des sites Web.

De plus, nous ne comptons pas sur le dernier assistant de Microsoft: trop de magie cachée et trop lente, et trop susceptible de changer de nom.

Voici comment nous procédons:

1. Nous avons une étape de post-génération qui copie les DLL générées dans un dossier 'bin-pub'.

2. Nous utilisons Beyond Compare (ce qui est excellent **) pour vérifier et synchroniser les fichiers modifiés (via FTP car largement pris en charge) jusqu'au serveur de production

3. Nous avons sur le site Web une URL sécurisée contenant un bouton qui copie tout le contenu de "bin-pub" dans "bin" (en effectuant d'abord une sauvegarde pour permettre une restauration rapide). À ce stade, l'application redémarre d'elle-même. Ensuite, notre ORM vérifie si des tables ou des colonnes doivent être ajoutées et les crée.

Cela ne représente que des millisecondes d'indisponibilité. Le redémarrage de l'application peut prendre une seconde ou deux, mais lors du redémarrage, les demandes sont mises en mémoire tampon afin qu'il n'y ait aucun temps mort.

L'ensemble du processus de déploiement prend entre 5 secondes et 30 minutes, selon le nombre de fichiers modifiés et le nombre de modifications à examiner.

Ainsi, vous ne devez pas copier un site Web entier dans un répertoire différent, mais uniquement dans le dossier bin. Vous avez également un contrôle total sur le processus et vous savez exactement ce qui change.

** Nous faisons toujours un tour d'horizon rapide des changements que nous déployons. Nous effectuons une double vérification de dernière minute afin de savoir quoi tester et si quelque chose se brise, nous sommes prêts. Nous utilisons Beyond Compare car il vous permet de différer facilement les fichiers via FTP. Je ne le ferais jamais sans la Colombie-Britannique, vous n’avez aucune idée de ce que vous écrasez.

* Faites défiler vers le bas pour le voir :( BTW, je ne recommanderais plus les sites Web, car ils sont plus lents à créer et peuvent planter avec des fichiers temporaires semi-compilés. Nous les utilisions auparavant car ils permettaient des fichiers plus agiles Déploiement par fichier. Vous résolvez très rapidement un problème mineur et vous pouvez voir exactement ce que vous déployez (si vous utilisez Beyond Compare bien sûr - sinon, oubliez-le).

Answer 7

Les seules méthodes à zéro arrêt auxquelles je peux penser impliquent l'hébergement sur au moins deux serveurs.

Answer 8

Je voudrais préciser un peu la réponse de George, comme suit, pour un serveur unique:

1. Utiliser un projet de déploiement Web pour pré-compiler le site dans une seule DLL
2. Compressez le nouveau site et chargez-le sur le serveur
3. Décompressez-le dans un nouveau dossier situé dans un dossier doté des autorisations appropriées pour le site. Ainsi, les fichiers décompressés hériteront des autorisations correctement (par exemple, e: \ web, avec les sous-dossiers v20090901, v20090916, etc.)
4. Utilisez le Gestionnaire des services Internet pour modifier le nom du dossier contenant le site
5. Conservez l'ancien dossier quelques instants pour pouvoir y revenir en cas de problème

L’étape 4 entraînera le recyclage du processus de travail IIS.

Il ne s’agit que de zéro temps d’interruption si vous n’utilisez pas de sessions InProc; utilisez plutôt le mode SQL si vous le pouvez (mieux encore, évitez complètement l’état de la session).

Bien sûr, c'est un peu plus compliqué lorsqu'il y a plusieurs serveurs et / ou modifications de bases de données ....

Answer 9

Pour développer la réponse de sklivvz, qui reposait sur un équilibreur de charge (ou simplement une copie de secours sur le même serveur)

1. Dirigez tout le trafic sur le site / serveur 2
2. Attendez éventuellement un peu pour vous assurer que le moins d'utilisateurs possible disposent de flux de travail en attente sur la version déployée
3. Déployez sur le site / serveur 1 et réchauffez-le autant que possible
4. Exécuter les migrations de base de données de manière transactionnelle (s'efforce de rendre cela possible)
5. dirige immédiatement tout le trafic sur le site / serveur 1
6. Déployer sur le site / serveur 2
7. Trafic direct vers les deux sites / serveurs

Il est possible d’introduire un peu de test de fumée en créant un instantané / une copie de base de données, mais ce n’est pas toujours faisable.

Si possible et si nécessaire, utilisez les "différences de routage", telles que différentes URL de client hébergé: s (customerX.myapp.net) ou différents utilisateurs, à déployer dans un premier temps sur un groupe inconnu de cobayes. Si rien n’échoue, communiquez-le à tout le monde.

Étant donné que des migrations de bases de données sont impliquées, il est souvent impossible de revenir à une version précédente.

Il existe des moyens de rendre les applications plus agréables dans ces scénarios, tels que l’utilisation de files d’événements et de mécanismes de lecture, mais étant donné que nous parlons de déployer des modifications sur quelque chose qui est en cours d’utilisation, il n’ya vraiment pas de solution à toute épreuve.

Answer 10

Voici comment je le fais:

Configuration minimale requise absolue:
 1 serveur avec

• 1 équilibreur de charge / proxy inverse (par exemple, nginx) s'exécutant sur le port 80
• 2 chroot-jails ou conteneurs docker ASP / NET / proxy inverse mono / fastcgi à l'écoute sur 2 ports TCP différents
   (ou même juste deux applications de proxy inverse sur 2 ports TCP différents sans aucun bac à sable)

Flux de travail:

démarrer la transaction myupdate

try
    Web-Service: Tell all applications on all web-servers to go into primary read-only mode 
    Application switch to primary read-only mode, and responds 
    Web sockets begin notifying all clients 
    Wait for all applications to respond

    wait (custom short interval)

    Web-Service: Tell all applications on all web-servers to go into secondary read-only mode 
    Application switch to secondary read-only mode (data-entry fuse)
    Updatedb - secondary read-only mode (switches database to read-only)

    Web-Service: Create backup of database 
    Web-Service: Restore backup to new database
    Web-Service: Update new database with new schema 

    Deploy new application to apt-repository 
    (for windows, you will have to write your own custom deployment web-service)
    ssh into every machine in array_of_new_webapps
    run apt-get update
    then either 
    apt-get dist-upgrade
    OR
    apt-get install <packagename>
    OR 
    apt-get install --only-upgrade <packagename>
    depending on what you need
    -- This deploys the new application to all new chroots (or servers/VMs)

    Test: Test new application under test.domain.xxx
    -- everything that fails should throw an exception here
    commit myupdate;

    Web-Service: Tell all applications to send web-socket request to reload the pages to all clients at time x (+/- random number)
    @client: notify of reload and that this causes loss of unsafed data, with option to abort 

    @ time x:  Switch load balancer from array_of_old_webapps to array_of_new_webapps 
    Decomission/Recycle array_of_old_webapps, etc.

catch
        rollback myupdate 
        switch to read-write mode
        Web-Service: Tell all applications to send web-socket request to unblock read-only mode
end try 

Answer 11

Je suggérerais de conserver les anciens fichiers et de les écraser. De cette façon, les temps d'arrêt sont limités aux temps de réécriture sur un seul fichier et il ne manque jamais qu'un fichier à la fois.

Vous n'êtes pas sûr que cela soit utile dans une " application Web " cependant (je pense que vous dites que c’est ce que vous utilisez), c’est pourquoi nous utilisons toujours les "sites Web". Egalement avec " sites Web " le déploiement ne redémarre pas votre site et ne supprime pas toutes les sessions utilisateur.