Aucun téléchargement / annulation de temps d'arrêt dans IIS

Je ne sais pas si c'est la bonne façon de poser cette question, mais voici essentiellement ce que j'aimerais faire:

1.) Envoyez un ensemble de modifications à un site dans IIS.
2.) N'interrompez pas les utilisateurs.
3.) Être capable de reculer sans effort.

Donc, je sais que certaines choses doivent se produire:

1.) Session hors proc - gérée
2.) Cache hors proc - gérée

Donc, les questions qui restent:
1.) Comment puis-je éviter d'interrompre les utilisateurs? Si je télécharge simplement les fichiers dans la corbeille, l'application se recycle et prend plus de 10 secondes pour revenir en ligne
2.) Comment restaurer sans effort?

Je pensais qu'une solution possible serait d'avoir deux sites installés dans IIS, un public et un privé. Les téléchargements deviennent privés et s'échauffent. Après l'échauffement, les sites sont échangés. Un retour en arrière implique uniquement le passage à privé sans téléchargement.

Cela semble solide en théorie, mais je ne suis pas sûr de la mécanique. Des idées?

Voici comment j'aborderais ce problème - gardez à l'esprit que je ne l'ai pas fait auparavant, ce sont juste des concepts que j'ai testés un peu dans mon environnement de développement. Vous devriez être en mesure de configurer un cadre assez robuste en utilisant cela et certains scripts dans la langue de votre choix. Fondamentalement, nous allons configurer un environnement d'équilibrage de charge du ghetto et l'utiliser pour basculer entre le nouveau site et l'ancien site.

Pour le configurer, vous aurez besoin de:

• Module IIS Application Request Routing (ARR)
• Outil de déploiement Web IIS (msdeploy)
• 3 sites Web IIS différents (avec 3 adresses IP différentes - l'utilisation de ports ou d'en-têtes d'hôte peut ne pas fonctionner ici)

Installez ARR pour commencer.

Configurez les 3 sites Web dans IIS:

• Le site Web 1 sera le site auquel vos utilisateurs se connectent, disons http://192.168.1.1/. C'est aussi le site ARR. Il suffit de configurer un répertoire vide pour que cela pointe et de le placer dans son propre pool d'applications. Configurez le pool d'applications pour ne pas expirer conformément à ces instructions .
• Les sites Web 2 et 3 seront les sites qui hébergent réellement votre contenu. Ceux-ci doivent être sur leurs propres IP et en raison de la façon dont ARR fonctionne, sur un port différent de celui du site Web 1. Disons qu'ils sont http://192.168.1.2:8080et http://192.168.1.3:8080. Ils doivent également se trouver dans leurs propres pools d'applications et pointer vers différents répertoires du système de fichiers (mais les deux répertoires ont généralement le même contenu)

Après avoir installé ARR, il y aura une nouvelle catégorie dans IIS Manager appelée "Server Farms" - faites un clic droit dessus et créez une nouvelle batterie.

• donnez-lui un nom qui soit significatif pour vous
• ajoutez Webserver 2 et Webserver 3 comme serveurs - assurez-vous de cliquer sur le bouton "paramètres avancés", ouvrez la catégorie "applicationRequestRouting" et changez le httpPort en 8080 pour chaque serveur
• Terminez l'assistant - il vous sera demandé si vous souhaitez créer des règles de réécriture d'URL - cliquez sur Oui
• Vous avez maintenant une batterie de serveurs - pour terminer la configuration, accédez à la batterie et cliquez sur le bouton Configuration du proxy - activez "inverser l'hôte de réécriture dans les en-têtes de réponse" et appliquer les modifications
• Dans le Gestionnaire des services Internet, accédez à la catégorie de serveur de niveau racine et cliquez sur le bouton Réécriture d'URL, une règle a été créée pour votre batterie de serveurs.
  • double-cliquez sur la règle pour accéder aux paramètres
  • ouvrir la boîte Conditions
  • ajouter une nouvelle condition pour {SERVER_PORT}ne correspond pas à 8080
  • appliquer les modifications

À ce stade, vous avez les bases de ce dont nous avons besoin pour répondre à votre demande. Si vous allez à http://192.168.1.1/vous obtiendrez votre site Web à partir du site Web 1 ou du site Web 2, mais il sera complètement transparent qu'il existe d'autres sites.

Maintenant, ce que vous pouvez faire lorsque vous souhaitez déployer une nouvelle version de votre application est:

• drainstop 1 des serveurs de votre batterie (dans les outils de la batterie de serveurs, allez dans "Surveillance et gestion", choisissez un serveur et choisissez "Rendre le serveur indisponible gracieusement")
• déployer votre nouvelle version du site sur le système hors ligne
• réchauffer le site hors ligne en utilisant son autre IP / port
• rendre à nouveau le site à la ferme
• répéter le processus pour l'autre serveur

L'outil de déploiement Web entre en jeu lorsque vous parlez de vouloir tout scripter. Il est très facile de créer un package pour votre application et de le déployer à partir de la ligne de commande. Vous pouvez également restaurer facilement ce package en cas de problème. ARR est également scriptable à l'aide des Microsoft.Web.AdministrationDLL.

Une autre chose - si vous êtes réellement sur Windows 2008 R2 (qui est IIS 7.5) jetez un œil au module Application Warmup - cela devrait également vous faciliter la tâche d'échauffement.

MattB l'a frappé hors de l'eau. +1 Je répondrai avec plus de détails mais je ne cherche pas à prendre ses points. J'ajouterai à ce qu'il a dit.

J'ai une configuration similaire à ce qu'il a décrit, et cela fonctionne très bien. ARR est le chemin à parcourir, même sur un seul serveur.

Cependant, je voudrais ajouter deux ou trois choses.

Créez les 2 sites, comme Matt l'a recommandé. Appelez-les quelque chose comme yoursite.com01 et yoursite.com02.

Créez 2 règles de réécriture d'URL. Un pour www.votredomaine.com et un autre pour staging.votredomaine.com. Pour la production, utilisez {HTTP_HOST} avec une valeur de (^ www.votredomaine.com $) | (votreIP). (ou la liaison que vous préférez) Pour le transfert, utilisez {HTTP_HOST} avec une valeur de (^ staging.votredomaine.com $). Appelez les règles yoursite.com et staging.yoursite.com.

Liez Rule = yoursite.com à site = yoursite.com01 et rule = staging.yoursite.com à site = yoursite.com02.

Configurez FTP sur staging.votresite.com.

Le trafic de production est désormais dirigé vers Rule = staging.yoursite.com et Site = yoursite.com01. Remuant à l'opposé.

Vous pouvez déployer à tout moment la mise en scène, tester, effectuer une pré-rotation, faire tester d'autres personnes, etc. Faites-le pendant la journée, peu importe. Déployez à chaque fois sur le même compte FTP. Fonctionne très bien avec les serveurs de build.

Ensuite, lorsque vous êtes prêt à mettre en ligne, effectuez simplement 3 modifications: - déplacez la liaison FTP de yoursite.com02 vers yoursite.com01 - modifiez la règle de réécriture d'URL yoursite.com pour pointer vers yoursite.com02 - modifiez le transfert de la règle de réécriture d'URL. yoursite.com pour pointer vers yoursite.com01

Maintenant, vous avez zéro temps d'arrêt, une commutation instantanée, avec une fonctionnalité de restauration immédiate!

Votre seul problème à considérer est votre état de session hors processus. Assurez-vous que votre serveur d'état accepte les deux identifiants de site afin de ne pas perdre l'état de la session pendant l'échange.

Notez également qu'il s'agit uniquement du Web et non d'une base de données.

Pour les scripts, utilisez l'éditeur de configuration. Apportez les modifications souhaitées, puis cliquez sur "Générer le script". Il vous donnera le code C #, appcmd ou AHAdmin.

Je l'ai depuis quelques mois avec un frontal de page Web pour permuter les instances et je ne regarde jamais en arrière. Il rend les déploiements si rafraîchissants par rapport aux déploiements traditionnels.