Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Mises à jour sans interruption / Retour en arrière dans IIS

ayi

Je ne suis pas sûr que ce soit la bonne façon de poser cette question, mais voici fondamentalement ce que j’aimerais faire :
1.) Pousser un ensemble de modifications vers un site dans IIS.
2.) Ne pas interrompre les utilisateurs.
3.) Pouvoir revenir en arrière sans effort.
Il y a donc quelques choses que je sais devoir être gérées :
1.) Session hors processus — fait
2.) Cache hors processus — fait
Les questions qui restent sont donc :
1.) Comment éviter d’interrompre les utilisateurs ? Si je télécharge simplement les fichiers dans bin, l’application recycle et met plus de 10 secondes à revenir en ligne.
2.) Comment revenir en arrière sans effort ?
Je pensais qu’une solution possible serait d’avoir deux sites configurés dans IIS, un public et un privé. Les téléchargements vont vers le privé et sont préchauffés. Après le préchauffage, les sites sont échangés. Un retour en arrière consiste simplement à échanger vers le 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 ?
<hr>
Source : <a href="http://www.iis.net/expand/ApplicationRequestRouting" rel="noopener nofollow ugc">Server Fault</a>

ayi_2

Voici comment j’aborderais ce problème — gardez à l’esprit que je n’ai pas fait cela avant, ce ne sont que des concepts que j’ai un peu testés dans mon environnement de développement. Vous devriez pouvoir mettre en place un cadre assez robuste en utilisant cela et du scripting dans le langage de votre choix. En gros, nous allons configurer un environnement de répartition de charge artisanal et l’utiliser pour basculer entre le nouveau site et l’ancien.
Pour le mettre en place, vous aurez besoin de :
<ul>
<li>
Le module <a href="http://www.iis.net/expand/ApplicationRequestRouting">IIS Application Request Routing</a> (ARR)
</li>
<li>
L’outil <a href="http://www.iis.net/expand/WebDeploy">IIS Web Deployment</a> (msdeploy)
</li>
<li>
3 sites web IIS différents (avec 3 adresses IP différentes — utiliser simplement des ports ou des en-têtes d’hôte pourrait ne pas fonctionner ici)
</li>
</ul>
Installez d’abord ARR.
Configurez les 3 sites web dans IIS :
<ul>
<li>
Le site web 1 sera le site auquel vos utilisateurs se connectent réellement, disons <code>http://192.168.1.1/</code>. C’est aussi le site ARR. Configurez simplement un répertoire vide vers lequel il pointe, et placez-le dans son propre pool d’applications. Configurez le pool d’applications pour qu’il n’expire pas selon <a href="http://technet.microsoft.com/en-us/library/ee683896(WS.10).aspx">ces instructions</a>.
</li>
<li>
Les sites web 2 et 3 seront les sites qui hébergent réellement votre contenu. Ils doivent avoir leurs propres adresses IP et, en raison du fonctionnement d’ARR, être sur un port différent du site web 1. Disons qu’ils sont <code>http://192.168.1.2:8080</code> et <code>http://192.168.1.3:8080</code>. Ils devraient aussi être dans leurs propres pools d’applications et pointer vers des répertoires différents sur le système de fichiers (mais les deux répertoires ont le même contenu en général).
</li>
</ul>
Après avoir installé ARR, il y aura une nouvelle catégorie dans le Gestionnaire IIS appelée « Fermes de serveurs » — faites un clic droit dessus et créez une nouvelle ferme.
<ul>
<li>
Donnez-lui un nom significatif pour vous
</li>
<li>
Ajoutez le serveur web 2 et le serveur web 3 en tant que serveurs — assurez-vous de cliquer sur le bouton « Paramètres avancés », ouvrez la catégorie « applicationRequestRouting » et changez le httpPort à 8080 pour chaque serveur
</li>
<li>
Terminez l’assistant — on vous demandera si vous souhaitez créer des règles de réécriture d’URL — cliquez sur Oui
</li>
<li>
Vous avez maintenant une ferme de serveurs — pour terminer la configuration, allez dans la ferme et cliquez sur le bouton Configuration du proxy — activez « Réécriture inverse de l’hôte dans les en-têtes de réponse » et appliquez les modifications
</li>
<li>
Dans le Gestionnaire IIS, allez au niveau racine du serveur et cliquez sur le bouton Réécriture d’URL, il y aura une règle qui a été créée pour votre ferme
</li>
<li>
Double-cliquez sur la règle pour accéder aux paramètres
</li>
<li>
Ouvrez la section Conditions
</li>
<li>
Ajoutez une nouvelle condition pour <code>{SERVER_PORT}</code> ne correspond pas à 8080
</li>
<li>
Appliquez les modifications
</li>
</ul>
À ce stade, vous avez les bases de ce dont nous avons besoin pour répondre à votre demande. Si vous allez à <code>http://192.168.1.1/</code>, vous obtiendrez votre site web depuis le site 1 ou le site 2, mais ce sera totalement transparent qu’il y a d’autres sites.
Maintenant, ce que vous pouvez faire lorsque vous souhaitez déployer une nouvelle version de votre application :
<ul>
<li>
Drainez l’un des serveurs de votre ferme (dans les outils de la ferme de serveurs, allez dans « Surveillance et gestion », choisissez un serveur et choisissez « Rendre le serveur indisponible progressivement »)
</li>
<li>
Déployez votre nouvelle version du site sur le système qui est hors ligne
</li>
<li>
Préchauffez le site hors ligne en utilisant son adresse IP/port alternatif
</li>
<li>
Remettez le site disponible dans la ferme
</li>
<li>
Répétez le processus pour l’autre serveur
</li>
</ul>
L’outil Web Deployment entre en jeu lorsque vous souhaitez scripter tout cela. Il facilite grandement la création d’un package pour votre application et son déploiement depuis la ligne de commande. Vous pouvez également facilement annuler ce package s’il y a des problèmes. <a href="http://forums.iis.net/t/1156563.aspx">ARR est également scriptable</a> en utilisant les DLL <code>Microsoft.Web.Administration</code>.
Une autre chose — si vous êtes effectivement sur Windows 2008 R2 (c’est-à-dire IIS 7.5), jetez un œil au module <a href="http://www.iis.net/expand/ApplicationWarmUp">Application Warmup</a> — il devrait faciliter la partie préchauffage.