Choix de la bonne approche pour le déploiement web

par Jason Lee

Lorsque vous utilisez l’outil de déploiement web des services Internet (IIS) (Web Deploy) 2.0 ou version ultérieure, vous pouvez utiliser trois approches main pour obtenir vos applications web empaquetées sur un serveur web. Vous pouvez :

  • Déployez l’application à partir d’un emplacement distant en ciblant le service Deployment Agent Web (également appelé « agent distant ») sur le serveur de destination.
  • Déployez l’application à partir d’un emplacement distant à l’aide de Web Deploy On Demand (également appelé « agent temporaire »).
  • Déployez l’application à partir d’un emplacement distant en ciblant le gestionnaire de déploiement web IIS sur le serveur de destination.
  • Déployez l’application en copiant manuellement le package web sur le serveur de destination et en l’important via le Gestionnaire des services Internet.

La façon dont vous configurez vos serveurs web de destination dépend de l’approche de déploiement que vous souhaitez utiliser. Cette rubrique vous aidera à déterminer l’approche de déploiement qui vous convient.

Ce tableau présente les avantages et inconvénients main de chaque approche de déploiement, ainsi que les scénarios qui conviennent le plus généralement à chaque approche.

Approche Avantages Inconvénients Scénarios typiques
Agent distant Il est facile à configurer. Il convient aux mises à jour régulières des applications web et du contenu. L’utilisateur doit être administrateur sur le serveur cible. l’utilisateur ne peut pas fournir d’autres informations d’identification. Environnements de développement. Environnements de test.
Agent temporaire Il n’est pas nécessaire d’installer Web Deploy sur l’ordinateur cible. La dernière version de Web Deploy est automatiquement utilisée. L’utilisateur doit être administrateur sur le serveur cible. L’utilisateur ne peut pas fournir d’autres informations d’identification. Environnements de développement. Environnements de test.
Gestionnaire Web Deploy Les utilisateurs non administrateurs peuvent déployer du contenu. Il convient aux mises à jour régulières des applications web et du contenu. Il est beaucoup plus complexe à mettre en place. Environnements intermédiaires. Environnements de production intranet. Environnements hébergés.
Déploiement hors connexion Il est très facile à mettre en place. Il convient aux environnements isolés. L’administrateur de serveur doit copier et importer manuellement le package web à chaque fois. Environnements de production accessibles sur Internet. Environnements réseau isolés.

Utilisation de l’agent distant

Lorsque vous installez Web Deploy à l’aide des paramètres par défaut sur un serveur de destination, le service Deployment Agent Web (l'« agent distant ») est automatiquement installé et démarré. Par défaut, l’agent distant expose un point de terminaison HTTP à cette adresse :

http://[server]/MSDEPLOYAGENTSERVICE

Notes

Vous pouvez remplacer [serveur] par le nom de l’ordinateur de votre serveur web, une adresse IP pour votre serveur web ou un nom d’hôte qui est résolu en votre serveur web.

Les administrateurs de serveur peuvent déployer des packages web à partir d’un emplacement distant, comme un ordinateur de développement ou un serveur de build, en spécifiant cette adresse de point de terminaison. Par exemple, supposons que Matt Hink chez Fabrikam, Inc. ait créé le projet d’application web ContactManager.Mvc sur sa machine de développement. Le processus de génération génère un package web, ainsi qu’un fichier .deploy.cmd qui contient les commandes Web Deploy requises pour installer le package. Si Matt est administrateur de serveur sur le serveur TESTWEB1, il peut déployer l’application web sur le serveur web de test en exécutant cette commande sur son ordinateur de développement :

ContactManager.Mvc.deploy.cmd /y /m:http://TESTWEB1/MSDEPLOYAGENTSERVICE a/:NTLM

En fait, l’exécutable Web Deploy peut déduire l’adresse de point de terminaison de l’agent distant si vous fournissez le nom de l’ordinateur. Par conséquent, Matt doit uniquement taper ceci :

ContactManager.Mvc.deploy.cmd /y /m:TESTWEB1 /a:NTLM

Notes

Pour plus d’informations sur la syntaxe de ligne de commande web deploy et les fichiers .deploy.cmd , consultez Guide pratique pour installer un package de déploiement à l’aide du fichier deploy.cmd.

L’agent distant offre un moyen simple de déployer du contenu à partir d’un emplacement distant, et cette approche peut fonctionner correctement avec un déploiement en un clic ou automatisé. Toutefois, l’utilisateur qui exécute la commande de déploiement doit également être un administrateur de domaine ou un membre du groupe Administrateurs locaux sur le serveur de destination. De plus, l’agent distant ne prend pas en charge l’authentification de base. Vous ne pouvez donc pas passer d’autres informations d’identification sur la ligne de commande.

L’agent distant fournit une approche utile du déploiement dans des scénarios de développement ou de test, où il n’est pas rare que les développeurs disposent d’un contrôle administrateur total sur un environnement de serveur de test, et où les applications sont généralement reconstruites et redéployées très fréquemment. Toutefois, cette approche est généralement moins acceptable pour les environnements intermédiaires ou de production.

Pour obtenir un exemple de bout en bout d’un scénario qui utilise l’approche de l’agent distant, consultez Scénario : Configuration d’un environnement de test pour le déploiement web.

Utilisation de l’agent temporaire

L’approche de déploiement de l’agent temporaire est similaire à l’approche de l’agent distant. Toutefois, contrairement à l’approche de l’agent distant, vous n’avez pas besoin d’installer Web Deploy sur le serveur web de destination. Au lieu de cela, lorsque vous effectuez le déploiement, Web Deploy installe une version temporaire du service d’agent de déploiement web sur le serveur de destination et l’utilise pour déployer votre contenu sur IIS. Une fois le déploiement terminé, tous les fichiers temporaires sont supprimés.

Si vous souhaitez utiliser le paramètre fournisseur de l’agent temporaire, ajoutez l’indicateur /g à votre commande de déploiement :

ContactManager.Mvc.deploy.cmd /y /m:TESTWEB1 /g:true

Notes

Vous ne pouvez pas utiliser l’agent temporaire si le service de l’agent de déploiement web est installé sur l’ordinateur de destination, même si le service n’est pas en cours d’exécution.

L’avantage de cette approche est que vous n’avez pas besoin de gérer les installations de Web Deploy sur vos serveurs de destination. En outre, vous n’avez pas besoin de vous assurer que les ordinateurs source et de destination exécutent la même version de Web Deploy. Toutefois, cette approche souffre des mêmes limitations de principal que l’approche de l’agent distant, à savoir que vous devez être un administrateur local sur le serveur de destination pour déployer du contenu, et que seule l’authentification NTLM est prise en charge. L’approche de l’agent temporaire nécessite également une configuration initiale beaucoup plus importante de l’environnement de destination.

Pour plus d’informations sur l’utilisation de l’agent temporaire, consultez How to: Install a Deployment Package Using the deploy.cmd File and Web Deploy On Demand.

Utilisation du gestionnaire Web Deploy

Pour IIS 7 et versions ultérieures, Web Deploy offre une autre approche de déploiement via le gestionnaire IIS Web Deploy. Le gestionnaire Web Deploy est étroitement intégré au service de gestion web IIS (WMSvc), qui est conçu pour permettre aux utilisateurs de gérer des sites web IIS à partir d’emplacements distants.

Par défaut, l’agent distant expose un point de terminaison HTTP à cette adresse :

https://[server]:8172/MSDeploy.axd

Notes

Vous pouvez remplacer [serveur] par le nom de l’ordinateur de votre serveur web, une adresse IP pour votre serveur web ou un nom d’hôte qui est résolu en votre serveur web.

Le grand avantage du gestionnaire Web Deploy par rapport à l’agent distant et à l’agent temporaire est que vous pouvez configurer IIS pour permettre aux utilisateurs non administrateurs de déployer des applications et du contenu sur des sites web IIS spécifiques. Le gestionnaire Web Deploy prend également en charge l’authentification de base. Vous pouvez donc fournir d’autres informations d’identification en tant que paramètres dans vos commandes Web Deploy. Le principal inconvénient est que le gestionnaire Web Deploy est au départ beaucoup plus compliqué à configurer et à configurer.

Dans le cas d’utilisateurs non-administrateurs, le service de gestion web (WMSvc) autorise uniquement l’utilisateur à se connecter à IIS à l’aide d’une connexion au niveau du site, plutôt que d’une connexion au niveau du serveur. Pour accéder à un site particulier, vous pouvez inclure une chaîne de requête spécifique au site dans l’adresse du point de terminaison :

https://[server]:8172/MSDeploy.axd?site=DemoSite

Suggestion Par exemple, supposons qu’un processus de génération soit configuré pour déployer automatiquement une application web dans un environnement intermédiaire après chaque génération réussie. Si vous avez utilisé l’approche de l’agent distant, vous devez faire de l’identité du processus de génération un administrateur sur vos serveurs de destination. En revanche, à l’aide de l’approche de gestionnaire Web Deploy, vous pouvez accorder à un utilisateur non-administrateur (FABRIKAM\stagingdeployer dans ce cas) l’autorisation sur un site web IIS spécifique uniquement, et le processus de génération peut fournir ces informations d’identification pour déployer le package web. Notez que l’exemple suivant utilise %ContactManagerPublishPassword%, qui extrait la valeur de mot de passe d’une variable d’environnement. Pour exécuter correctement le script, %ContactManagerPublishPassword% la variable doit être définie avec la valeur correcte.

msdeploy.exe 
  -source:package='…\ContactManager.Mvc.zip' 
  -dest:auto,
        computerName='https://STAGEWEB1:8172/MSDeploy.axd?site=DemoSite',
        userName='FABRIKAM\stagingdeployer',
        password=%ContactManagerPublishPassword%,
        authtype='Basic', 
  -verb:sync 
  -setParamFile:"…\ContactManager.Mvc.SetParameters.xml"   
  -allowUntrusted

Notes

Pour plus d’informations sur les opérations de ligne de commande et la syntaxe de Web Deploy, consultez Informations de référence sur la ligne de commande Web Deploy. Pour plus d’informations sur l’utilisation du fichier .deploy.cmd , consultez Guide pratique pour installer un package de déploiement à l’aide du fichier deploy.cmd.

Le gestionnaire Web Deploy fournit une approche utile du déploiement dans les environnements intermédiaires, les environnements hébergés et les environnements de production intranet, où l’accès à distance au serveur est disponible, mais pas les informations d’identification d’administrateur.

Pour obtenir un exemple de bout en bout d’un scénario qui utilise l’approche du gestionnaire Web Deploy, consultez Scénario : Configuration d’un environnement intermédiaire pour le déploiement web.

Utilisation du déploiement hors connexion

Dans certains cas, il n’est pas possible ou pratique de déployer des applications et du contenu sur un site web IIS à partir d’un emplacement distant. Par exemple, les ordinateurs source et de destination peuvent se trouver dans des réseaux ou des segments réseau isolés, ou la stratégie de pare-feu peut ne pas autoriser l’accès à distance.

Dans de tels scénarios, vous pouvez toujours utiliser les fonctionnalités d’empaquetage et de publication de Web Deploy ; vous ne pouvez tout simplement pas les utiliser à partir d’un emplacement distant. Au lieu de cela, un administrateur sur le serveur de destination doit copier le package web sur le serveur et l’importer via le Gestionnaire des services Internet.

Au lieu de cela, un administrateur sur le serveur de destination doit copier le package web sur le serveur et l’importer via le Gestionnaire des services Internet.

L’approche de déploiement hors connexion est généralement utile dans les environnements de production accessibles sur Internet, où les serveurs d’un réseau de périmètre peuvent avoir une connectivité limitée avec les ordinateurs du réseau interne.

Pour obtenir un exemple de bout en bout d’un scénario qui utilise l’approche de déploiement hors connexion, consultez Scénario : Configuration d’un environnement de production pour le déploiement web.

En savoir plus

Pour plus d’informations sur les opérations de ligne de commande et la syntaxe de Web Deploy, consultez Informations de référence sur la ligne de commande Web Deploy. Pour plus d’informations sur l’utilisation du fichier .deploy.cmd , consultez Guide pratique pour installer un package de déploiement à l’aide du fichier deploy.cmd.

Pour obtenir des conseils plus généraux sur les différentes façons dont vous pouvez déployer des packages web à partir d’un ordinateur distant, consultez Utilisation du déploiement web à distance. Pour plus d’informations sur l’utilisation de Web Deploy On Demand, consultez Web Deploy On Demand.