Freigeben über

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 Hauptansätze, mit denen Sie Ihre verpackten Webanwendungen auf einen Webserver abrufen können. Sie haben folgende Möglichkeiten:

  • Stellen Sie die Anwendung von einem Remotestandort aus bereit, indem Sie auf den WebBereitstellungs-Agent-Dienst (auch als "Remote-Agent" bezeichnet) auf dem Zielserver abzielen.
  • Stellen Sie die Anwendung von einem entfernten Standort mithilfe von Web Deploy On Demand (auch bekannt als "Temp-Agent") bereit.
  • Stellen Sie die Anwendung von einem Remotespeicherort aus bereit, indem Sie den IIS Web Deploy Handler auf dem Zielserver verwenden.
  • Stellen Sie die Anwendung bereit, indem Sie das Webpaket manuell auf den Zielserver kopieren und über 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 dabei, zu entscheiden, welcher Ansatz für die Bereitstellung für Sie geeignet ist.

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

Vorgehensweise Vorteile Benachteiligungen Typische Szenarien
Fernagent Es ist einfach einzurichten. Es eignet sich für regelmäßige Aktualisierungen von Webanwendungen und Inhalten. Der Benutzer muss ein Administrator auf dem Zielserver sein. Der Benutzer kann keine alternativen Anmeldeinformationen angeben. Entwicklungsumgebungen. Testumgebungen:
Temporärer Agent Es ist nicht erforderlich, Web Deploy auf dem Zielcomputer zu installieren. Die neueste Version von Web Deploy wird automatisch verwendet. Der Benutzer muss ein Administrator auf dem Zielserver sein. Der Benutzer kann keine alternativen Anmeldeinformationen angeben. Entwicklungsumgebungen. Testumgebungen:
Web Deploy-Handler Nicht-Administratorbenutzer können Inhalte bereitstellen. Es eignet sich für regelmäßige Aktualisierungen von Webanwendungen und Inhalten. Es ist viel komplexer einzurichten. Stagingumgebungen. Intranet-Produktionsumgebungen. Gehostete Umgebungen.
Offline-Bereitstellung Es ist sehr einfach einzurichten. Sie eignet sich für isolierte Umgebungen. Der Serveradministrator muss das Webpaket jedes Mal manuell kopieren und importieren. Produktionsumgebungen mit Internetzugang. Isolierte Netzwerkumgebungen.

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 an dieser Adresse einen HTTP-Endpunkt verfügbar:

http://[server]/MSDEPLOYAGENTSERVICE

Hinweis

Sie können [server] durch den Computernamen Ihres Webservers, eine IP-Adresse für Ihren Webserver oder einen Hostnamen ersetzen, der auf Ihren Webserver aufgelöst wird.

Serveradministratoren können Webpakete von einem Remotestandort wie einem Entwicklercomputer oder einem Buildserver bereitstellen, indem Sie diese Endpunktadresse angeben. Angenommen, Matt Hink bei Fabrikam, Inc. hat das ContactManager.Mvc-Webanwendungsprojekt auf seinem Entwicklercomputer erstellt. Der Buildprozess generiert ein Webpaket zusammen mit einer .deploy.cmd Datei, die die zum Installieren des Pakets erforderlichen Web Deploy-Befehle enthält. Wenn Matt ein 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 Datei "Web Deploy" 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

Hinweis

Um nähere Informationen zur Befehlszeilensyntax und zu .deploy.cmd-Dateien zu erhalten, lesen Sie Wie kann man ein Deployment-Paket mit der deploy.cmd-Datei installieren.

Der Remote-Agent bietet eine einfache Möglichkeit, Inhalte von einem Remotestandort bereitzustellen, und dieser Ansatz kann gut mit einem Klick oder einer automatisierten Bereitstellung 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 keine Standardauthentifizierung, sodass Sie keine alternativen Anmeldeinformationen an die Befehlszeile übergeben können.

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

Ein End-to-End-Beispiel für ein Szenario, das den Remote-Agent-Ansatz verwendet, finden Sie unter "Scenario: Configuring a Test Environment for Web Deployment".

Verwenden des Temp-Agents

Der Temp-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 Webdiensts für den Webbereitstellungs-Agent 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 für den 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

Hinweis

Sie können den temporären Agent nicht verwenden, wenn der Webbereitstellungs-Agent-Dienst auf dem Zielcomputer installiert ist, auch wenn der Dienst nicht ausgeführt wird.

Der Vorteil dieses Ansatzes besteht darin, dass Sie keine Installationen von Web Deploy auf Ihren Zielservern verwalten müssen. Darüber hinaus müssen Sie nicht sicherstellen, dass die Quell- und Zielcomputer dieselbe Version von Web Deploy ausführen. Dieser Ansatz leidet jedoch unter den gleichen Prinzipalbeschränkungen 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 Temp-Agent-Ansatz erfordert auch viel mehr Anfängliche Konfiguration der Zielumgebung.

Weitere Informationen zur Verwendung des temporären Agents finden Sie unter How to: Install a Deployment Package Using the deploy.cmd File and Web Deploy On Demand.

Verwenden des Web Deploy Handlers

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

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

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

Hinweis

Sie können [server] durch den Computernamen Ihres Webservers, eine IP-Adresse für Ihren Webserver oder einen Hostnamen ersetzen, der auf Ihren Webserver aufgelöst wird.

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 Nicht-Administratorbenutzer 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 bereitstellen können. Der Hauptnachteil ist, dass der Web Deploy-Handler anfänglich viel komplizierter einzurichten und zu konfigurieren ist.

Im Fall von Nicht-Administratorbenutzern ermöglicht der Webdienst (Web Management Service, WMSvc) nur das Herstellen einer Verbindung mit IIS mithilfe einer Verbindung auf Standortebene anstelle einer Verbindung auf Serverebene. Um auf eine bestimmte Website zuzugreifen, können Sie eine websitespezifische Abfragezeichenfolge in die Endpunktadresse einschließen:

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

Vorschlag Angenommen, ein Buildprozess ist so konfiguriert, dass eine Webanwendung nach jedem erfolgreichen Build automatisch in einer Stagingumgebung bereitgestellt wird. Wenn Sie den Remote-Agent-Ansatz verwendet haben, müssen Sie die Identität des Build-Prozesses als Administrator auf Ihren Zielservern festlegen. Im Gegensatz dazu können Sie mithilfe des Web Deploy Handler-Ansatzes einem Nichtadministratorbenutzer – FABRIKAM\stagingdeployer in diesem Fall – nur die Berechtigung für eine bestimmte IIS-Website erteilen, und der Buildprozess kann diese Anmeldeinformationen bereitstellen, um das Webpaket bereitzustellen. Beachten Sie das folgende Beispiel, das %ContactManagerPublishPassword% verwendet und den Passwortwert aus einer Umgebungsvariable abruft. 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=,
        authtype='Basic', 
  -verb:sync 
  -setParamFile:"…\ContactManager.Mvc.SetParameters.xml"   
  -allowUntrusted

Hinweis

Weitere Informationen zu Befehlszeilenvorgängen und -syntax von Web Deploy finden Sie unter Web Deploy Command Line Reference. Weitere Informationen zur Verwendung der .deploy.cmd-Datei finden Sie unter So installieren Sie ein Bereitstellungspaket mit der deploy.cmd-Datei.

Der Web Deploy-Handler 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, administratoranmeldeinformationen jedoch nicht.

Ein End-to-End-Beispiel für ein Szenario, das den Ansatz "Web Deploy Handler" verwendet, finden Sie unter "Scenario: Configuring a Staging Environment for Web Deployment".

Verwenden der Offline-Bereitstellung

In einigen Fällen ist es nicht möglich oder praktisch, Anwendungen und Inhalte von einem Remotestandort an einer IIS-Website bereitzustellen. Beispielsweise können sich die Quell- und Zielcomputer in isolierten Netzwerken oder Netzwerksegmenten befinden, oder die Firewallrichtlinie darf keinen Remotezugriff zulassen.

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 IIS-Manager importieren.

Stattdessen muss ein Administrator auf dem Zielserver das Webpaket auf den Server kopieren und über IIS-Manager importieren.

Der Ansatz für die Offlinebereitstellung ist in der Regel in in internetorientierten Produktionsumgebungen nützlich, in denen Server in einem Umkreisnetzwerk möglicherweise eingeschränkte Konnektivität mit Computern im internen Netzwerk haben.

Ein End-to-End-Beispiel für ein Szenario, das den Offlinebereitstellungsansatz verwendet, finden Sie unter "Szenario: Configuring a Production Environment for Web Deployment".

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 .deploy.cmd-Datei finden Sie unter So installieren Sie ein Bereitstellungspaket mit der deploy.cmd-Datei.

Allgemeinere Anleitungen zu den verschiedenen Möglichkeiten, wie Sie Webpakete von einem Remotecomputer bereitstellen können, finden Sie unter Verwenden von Web Deploy Remote. Weitere Informationen zur Verwendung von Web Deploy On Demand finden Sie unter Web Deploy On Demand.

ZurückWeiter