Auswählen der richtigen Vorgehensweise zur Webbereitstellung

von Jason Lee

Wenn Sie mit dem IIS-Webbereitstellungstool (Web Deploy) 2.0 oder höher arbeiten, gibt es drei Standard Ansätze, die Sie verwenden können, um Ihre gepackten Webanwendungen auf einen Webserver zu übertragen. Sie haben folgende Möglichkeiten:

• Stellen Sie die Anwendung von einem Remotestandort aus bereit, indem Sie auf den Web Deployment Agent-Dienst (auch als "Remote-Agent" bezeichnet) auf dem Zielserver abzielen.
• Stellen Sie die Anwendung von einem Remotestandort aus mithilfe von Web Deploy On Demand (auch als "temporärer Agent" bezeichnet) bereit.
• Stellen Sie die Anwendung von einem Remotestandort aus bereit, indem Sie auf den IIS-Webbereitstellungshandler auf dem Zielserver abzielen.
• Stellen Sie die Anwendung bereit, indem Sie das Webpaket manuell auf den Zielserver kopieren und über den IIS-Manager importieren.

Wie Sie Ihre Zielwebserver konfigurieren, hängt davon ab, welcher Ansatz für die Bereitstellung Sie verwenden möchten. Dieses Thema hilft Ihnen bei der Entscheidung, welcher Ansatz für die Bereitstellung für Sie geeignet ist.

Diese Tabelle zeigt die Standard Vor- und Nachteile jedes Bereitstellungsansatzes zusammen mit den Szenarien, die in der Regel für jeden Ansatz geeignet sind.

Verwenden des Remote-Agents

Wenn Sie Web Deploy mithilfe der Standardeinstellungen auf einem Zielserver installieren, wird der Web Deployment Agent Service (der "Remote-Agent") automatisch installiert und gestartet. Standardmäßig macht der Remote-Agent einen HTTP-Endpunkt unter der folgenden Adresse verfügbar:

http://[server]/MSDEPLOYAGENTSERVICE

Serveradministratoren können Webpakete von einem Remotestandort wie einem Entwicklercomputer oder einem Buildserver bereitstellen, indem sie diese Endpunktadresse angeben. Angenommen, Matt Hink von Fabrikam, Inc. hat das ContactManager.Mvc-Webanwendungsprojekt auf seinem Entwicklercomputer erstellt. Der Buildprozess generiert ein Webpaket zusammen mit einer Datei .deploy.cmd , die die zum Installieren des Pakets erforderlichen Web Deploy-Befehle enthält. Wenn Matt Serveradministrator auf dem TESTWEB1-Server ist, kann er die Webanwendung auf dem Testwebserver bereitstellen, indem er diesen Befehl auf seinem Entwicklercomputer ausführt:

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

Tatsächlich kann die ausführbare Web Deploy-Datei die Endpunktadresse des Remote-Agents ableiten, wenn Sie den Computernamen angeben, sodass Matt nur folgendes eingeben muss:

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

Der Remote-Agent bietet eine einfache Möglichkeit zum Bereitstellen von Inhalten von einem Remotestandort aus, und dieser Ansatz kann mit einem Klick oder automatisierter Bereitstellung gut funktionieren. Der Benutzer, der den Bereitstellungsbefehl ausführt, muss jedoch auch ein Domänenadministrator oder Mitglied der lokalen Administratorgruppe auf dem Zielserver sein. Darüber hinaus unterstützt der Remote-Agent die Standardauthentifizierung nicht, sodass Sie keine alternativen Anmeldeinformationen über die Befehlszeile übergeben können.

Der Remote-Agent bietet einen nützlichen Ansatz für die Bereitstellung in Entwicklungs- oder Testszenarien, in denen es nicht ungewöhnlich ist, dass Entwickler die vollständige Administratorkontrolle über eine Testserverumgebung haben und Anwendungen in der Regel sehr häufig neu erstellt und erneut bereitgestellt werden. Dieser Ansatz ist jedoch für Staging- oder Produktionsumgebungen in der Regel weniger akzeptabel.

Ein End-to-End-Beispiel für ein Szenario, das den Remote-Agent-Ansatz verwendet, finden Sie unter Szenario: Konfigurieren einer Testumgebung für die Webbereitstellung.

Verwenden des temporären Agents

Der Temporäre Agent-Ansatz für die Bereitstellung ähnelt dem Remote-Agent-Ansatz. Im Gegensatz zum Remote-Agent-Ansatz müssen Sie Web Deploy jedoch nicht auf dem Zielwebserver installieren. Wenn Sie die Bereitstellung ausführen, installiert Web Deploy stattdessen eine temporäre Version des Webbereitstellungs-Agent-Diensts auf dem Zielserver und verwendet diese, um Ihre Inhalte in IIS bereitzustellen. Nach Abschluss der Bereitstellung werden alle temporären Dateien entfernt.

Wenn Sie die Einstellung temporären Agent-Anbieter verwenden möchten, fügen Sie dem Bereitstellungsbefehl das Flag /g hinzu:

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

Dieser Ansatz hat den Vorteil, dass Sie keine Installationen von Web Deploy auf Ihren Zielservern verwalten müssen. Darüber hinaus müssen Sie nicht sicherstellen, dass auf den Quell- und Zielcomputern dieselbe Version von Web Deploy ausgeführt wird. Dieser Ansatz weist jedoch die gleichen prinzipalen Einschränkungen auf wie der Remote-Agent-Ansatz, nämlich dass Sie ein lokaler Administrator auf dem Zielserver sein müssen, um Inhalte bereitzustellen, und nur die NTLM-Authentifizierung wird unterstützt. Der Temporäre Agent-Ansatz erfordert auch eine viel mehr Anfängliche Konfiguration der Zielumgebung.

Weitere Informationen zur Verwendung des temporären Agents finden Sie unter Vorgehensweise: Installieren eines Bereitstellungspakets mithilfe der Datei deploy.cmd und Web Deploy On Demand.

Verwenden des Webbereitstellungshandlers

Für IIS 7 bietet Web Deploy einen alternativen Bereitstellungsansatz über den IIS-Webbereitstellungshandler. Der Web Deploy-Handler ist eng in den IIS-Webverwaltungsdienst (WMSvc) integriert, der es Benutzern ermöglicht, IIS-Websites von Remotestandorten aus zu verwalten.

Standardmäßig macht der Remote-Agent einen HTTP-Endpunkt unter der folgenden Adresse verfügbar:

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

Der große Vorteil des Web deploy-Handlers gegenüber dem Remote-Agent und dem temporären Agent besteht darin, dass Sie IIS so konfigurieren können, dass Benutzer, die keine Administrator sind, Anwendungen und Inhalte auf bestimmten IIS-Websites bereitstellen können. Der Web Deploy-Handler unterstützt auch die Standardauthentifizierung, sodass Sie alternative Anmeldeinformationen als Parameter in Ihren Web Deploy-Befehlen angeben können. Der größte Nachteil ist, dass die Einrichtung und Konfiguration des Webbereitstellungshandlers zunächst viel komplizierter ist.

Bei Nicht-Administratorbenutzern ermöglicht der Webverwaltungsdienst (WMSvc) dem Benutzer nur, eine Verbindung mit IIS über eine Verbindung auf Standortebene und nicht über eine Verbindung auf Serverebene herzustellen. Um auf einen bestimmten Standort zuzugreifen, können Sie eine standortspezifische Abfragezeichenfolge in die Endpunktadresse einschließen:

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

Vorschlag Angenommen, ein Buildprozess ist so konfiguriert, dass nach jedem erfolgreichen Build automatisch eine Webanwendung in einer Stagingumgebung bereitgestellt wird. Wenn Sie den Remote-Agent-Ansatz verwendet haben, müssen Sie die Buildprozessidentität als Administrator auf Ihren Zielservern festlegen. Im Gegensatz dazu können Sie mithilfe des Webbereitstellungshandler-Ansatzes einem Benutzer ohne Administrator (in diesem Fall FABRIKAM\stagingdeployer ) die Berechtigung nur für eine bestimmte IIS-Website erteilen, und der Buildprozess kann diese Anmeldeinformationen zum Bereitstellen des Webpakets bereitstellen. Beachten Sie, dass im folgenden Beispiel verwendet wird %ContactManagerPublishPassword%, wobei der Kennwortwert aus einer Umgebungsvariable abgerufen wird. Um das Skript erfolgreich auszuführen, %ContactManagerPublishPassword% muss die Variable mit dem richtigen Wert definiert werden.

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

Der Webbereitstellungshandler bietet einen nützlichen Ansatz für die Bereitstellung in Stagingumgebungen, gehosteten Umgebungen und intranetbasierten Produktionsumgebungen, in denen der Remotezugriff auf den Server verfügbar ist, aber keine Administratoranmeldeinformationen.

Ein End-to-End-Beispiel für ein Szenario, das den Ansatz des Webbereitstellungshandlers verwendet, finden Sie unter Szenario: Konfigurieren einer Stagingumgebung für die Webbereitstellung.

Verwenden der Offlinebereitstellung

In einigen Fällen ist es nicht möglich oder praktisch, Anwendungen und Inhalte auf einer IIS-Website von einem Remotestandort aus bereitzustellen. Beispielsweise können sich die Quell- und Zielcomputer in isolierten Netzwerken oder Netzwerksegmenten befinden, oder die Firewallrichtlinie lässt den Remotezugriff möglicherweise nicht zu.

In Szenarien wie diesen können Sie weiterhin die Verpackungs- und Veröffentlichungsfunktionen von Web Deploy verwenden. Sie können sie einfach nicht von einem Remotestandort aus verwenden. Stattdessen muss ein Administrator auf dem Zielserver das Webpaket auf den Server kopieren und über den IIS-Manager importieren.

Der Offlinebereitstellungsansatz ist in der Regel in Produktionsumgebungen mit Internetzugriff nützlich, in denen Server in einem Umkreisnetzwerk möglicherweise eine eingeschränkte Konnektivität mit Computern im internen Netzwerk aufweisen.

Ein End-to-End-Beispiel für ein Szenario, das den Offlinebereitstellungsansatz verwendet, finden Sie unter Szenario: Konfigurieren einer Produktionsumgebung für die Webbereitstellung.

Weitere Informationen

Weitere Informationen zu Befehlszeilenvorgängen und Syntax von Web Deploy finden Sie unter Web Deploy Command Line Reference. Weitere Informationen zur Verwendung der Datei .deploy.cmd finden Sie unter Vorgehensweise: Installieren eines Bereitstellungspakets mithilfe der Datei deploy.cmd.

Allgemeinere Anleitungen zu den verschiedenen Möglichkeiten zum Bereitstellen von Webpaketen auf einem Remotecomputer finden Sie unter Verwenden der Remotebereitstellung im Web. Weitere Informationen zur Verwendung von Web Deploy On Demand finden Sie unter Web Deploy On Demand.