Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Verwendung der Elastic Beanstalk .NET Windows-Plattform
In diesem Thema wird beschrieben, wie Sie Ihre ASP.NET- und .NET Core-Windows-Webanwendungen auf Elastic Beanstalk konfigurieren, erstellen und ausführen.
AWS Elastic Beanstalk unterstützt eine Reihe von Plattformen für verschiedene Versionen des.NET-Programmierframeworks und Windows Server. Eine komplette Liste finden Sie unter [.NET on Windows Server mit IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) im Dokument *AWS Elastic Beanstalk -Plattformen*.
Elastic Beanstalk bietet [Konfigurationsoptionen](command-options.md), mit denen Sie die Software anpassen können, die auf den EC2 Instances in Ihrer Elastic Beanstalk Beanstalk-Umgebung ausgeführt wird. Sie können die für Ihre Anwendung erforderlichen Umgebungsvariablen konfigurieren, die Protokollrotation an Amazon S3 aktivieren und .NET-Framework-Einstellungen festlegen.
In der Elastic Beanstalk-Konsole sind Konfigurationsoptionen für das [Ändern der Konfiguration einer ausgeführten Umgebung](environment-configuration-methods-after.md) verfügbar. Um zu verhindern, dass die Umgebungskonfiguration beim Beenden verloren geht, können Sie [gespeicherte Konfigurationen](environment-configuration-savedconfig.md) verwenden, um Ihre Einstellungen zu speichern und sie später für eine andere Umgebung zu übernehmen.
Zum Speichern der Einstellungen im Quellcode können Sie [Konfigurationsdateien](ebextensions.md) einschließen. Die Einstellungen in Konfigurationsdateien werden jedes Mal verwendet, wenn Sie eine Umgebung erstellen oder Ihre Anwendung bereitstellen. Mit Konfigurationsdateien können Sie auch Pakete installieren, Skripts ausführen und andere Instance-Anpassungen bei Bereitstellungen vornehmen.
Die in der Elastic Beanstalk-Konsole angewendeten Einstellungen überschreiben die entsprechenden Einstellungen in Konfigurationsdateien, wenn vorhanden. So sind Standardeinstellungen in Konfigurationsdateien möglich, die Sie mit umgebungsspezifischen Einstellungen in der Konsole überschreiben können. Für weitere Informationen zur Rangfolge und zu anderen Methoden zum Ändern der Einstellungen siehe [Konfigurationsoptionen](command-options.md).
## Konfigurieren Ihrer .NET-Umgebung in der Elastic Beanstalk-Konsole
Mit der Elastic Beanstalk-Konsole können Sie die Protokollrotation für Amazon S3 aktivieren, Variablen konfigurieren, die die Anwendung in der Umgebung lesen kann, und die .NET-Framework-Einstellungen ändern.
**So konfigurieren Sie Ihre .NET-Umgebung in der Elastic Beanstalk-Konsole**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
1. Wählen Sie im Navigationsbereich **Configuration (Konfiguration)** aus.
1. Wählen Sie in der Konfigurationskategorie **Updates, monitoring and logging ** (Updates, Überwachung und Protokolle) die Option **Edit** (Bearbeiten) aus.
### Container-Optionen
+ **Target .NET runtime (.NET-Ziellaufzeit)** – Legen Sie den Wert `2.0` fest, um CLR v2 auszuführen.
+ **Enable 32-bit applications (32-Bit-Anwendungen aktivieren)** – Legen Sie den Wert `True` fest, um 32-Bit-Anwendungen auszuführen.
### Protokolloptionen
Im Abschnitt mit den Protokolloptionen sind zwei Einstellungen vorhanden:
+ **Instance profile (Instance-Profil)** – Gibt das Instance-Profil an, das zum Zugriff auf den entsprechenden Amazon S3-Bucket der Anwendung berechtigt ist.
+ **Rotation der Protokolldateien nach Amazon S3 aktivieren** — Gibt an, ob Protokolldateien für die EC2 Amazon-Instances Ihrer Anwendung in den Amazon S3-Bucket kopiert werden, der Ihrer Anwendung zugeordnet ist.
### Umgebungseigenschaften
Im Abschnitt **Umgebungseigenschaften** können Sie die Umgebungskonfigurationseinstellungen für die EC2 Amazon-Instances angeben, auf denen Ihre Anwendung ausgeführt wird. Diese Einstellungen werden als Schlüssel-Wert-Paare an die Anwendung weitergeleitet. Verwenden Sie `System.GetEnvironmentVariable`, um diese zu lesen. Identische Schlüssel können in `web.config` und als Umgebungseigenschaften vorhanden sein. Verwenden Sie den `System.Configuration`-Namespace zum Lesen von Werten aus `web.config`.
```
NameValueCollection appConfig = ConfigurationManager.AppSettings;
string endpoint = appConfig["API_ENDPOINT"];
```
Weitere Informationen finden Sie unter [Umgebungsvariablen und andere Softwareeinstellungen](environments-cfg-softwaresettings.md).
## Der Namespace aws:elasticbeanstalk:container:dotnet:apppool
Mithilfe einer [Konfigurationsdatei](ebextensions.md) können Sie im Rahmen der Bereitstellung Konfigurationsoptionen festlegen und andere Instance-Konfigurationsaufgaben ausführen. Die Konfigurationsoptionen können [plattformspezifisch](command-options-specific.md) sein oder für [alle Plattformen](command-options-general.md) im Elastic Beanstalk-Service als Ganzes gelten. *Die Konfigurationsoptionen sind in Namespaces organisiert.*
Über die .NET-Plattform werden Optionen im Namespace `aws:elasticbeanstalk:container:dotnet:apppool` festgelegt, mithilfe derer Sie die .NET-Laufzeitumgebung konfigurieren können.
In der folgenden Beispielkonfigurationsdatei werden die Einstellungen der einzelnen Optionen angezeigt, die in diesem Namespace verfügbar sind:
**Example .ebextensions/dotnet-settings.config**
```
option_settings:
aws:elasticbeanstalk:container:dotnet:apppool:
Target Runtime: 2.0
Enable 32-bit Applications: True
```
Elastic Beanstalk bietet zahlreiche Konfigurationsoptionen für die Anpassung Ihrer Umgebung. Neben den Konfigurationsdateien können Sie die Konfigurationsoptionen auch unter Verwendung der Konsole, gespeicherter Konfigurationen, der EB CLI oder der AWS CLI einrichten. Weitere Informationen finden Sie unter [Konfigurationsoptionen](command-options.md).
# Migration über die Hauptversionen der Elastic Beanstalk-Windows Server-Plattform hinweg
AWS Elastic Beanstalk hatte mehrere Hauptversionen seiner Windows Server-Plattform. Diese Seite geht auf die wichtigsten Verbesserungen für jede Hauptversion und darauf ein, was Sie bedenken müssen, bevor Sie auf eine neuere Version migrieren.
Die Windows Server-Plattform liegt derzeit in Version 2 (v2) vor. Wenn Ihre Anwendung eine Version der Windows Server-Plattform vor v2 verwendet, empfehlen wir die Migration auf v2.
## Neues in den Hauptversionen der Windows Server-Plattform
### Windows Server-Plattform V2
Version 2 (v2) der Elastic Beanstalk Windows Server Plattform wurde [im Februar 2019 veröffentlicht](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2019-02-21-windows-v2.html). Mit V2 ist das Verhalten der Windows Server-Plattform in mehreren wichtigen Punkten demjenigen der Linux-basierten Plattformen von Elastic Beanstalk ähnlicher. V2 ist vollständig abwärtskompatibel zu v1, wodurch die Migration von v1 ganz einfach ist.
Die Windows Server-Plattform unterstützt jetzt Folgendes:
+ *Versioning* – Jede Version erhält eine neue Versionsnummer, und Sie können auf frühere Versionen (die noch verfügbar sind) verweisen, wenn Sie Umgebungen erstellen und verwalten.
+ *Erweiterter Zustandsbericht* – Weitere Informationen finden Sie unter [Verbesserte Gesundheitsberichterstattung und Überwachung in Elastic Beanstalk](health-enhanced.md).
+ Bereitstellungen, die *unveränderlich* und *fortlaufend mit zusätzlichem Batch* sind – Weitere Informationen zu Bereitstellungsrichtlinien finden Sie unter [Anwendungen in Elastic Beanstalk-Umgebungen bereitstellen](using-features.deploy-existing-version.md).
+ *Unveränderliche Updates* – Weitere Informationen zu den Update-Typen finden Sie unter [Konfigurationsänderungen](environments-updating.md).
+ *Verwaltete Plattformaktualisierungen* – Weitere Informationen finden Sie unter [Verwaltete Plattformaktualisierungen](environment-platform-update-managed.md).
**Anmerkung**
Die neuen Bereitstellungs- und Update-Funktionen sind vom erweiterten Zustandsbericht abhängig. Um sie verwenden zu können, müssen Sie den erweiterten Zustandsbericht aktivieren. Details hierzu finden Sie unter [Aktivieren der erweiterten Elastic-Beanstalk-Integritätsberichte](health-enhanced-enable.md).
### Windows Server-Plattform V1
Version 1.0.0 (v1) der Elastic Beanstalk-Windows Server-Plattform wurde im Oktober 2015 veröffentlicht. In dieser Version ändert sich die Reihenfolge, in der die Elastic Beanstalk-Prozesse Befehle in [Konfigurationsdateien](ebextensions.md) bei der Erstellung und Aktualisierungen der Umgebung verarbeitet werden.
Vorherige Plattformversionen haben keine Versionsnummer im Lösungs-Stack-Namen:
+ Windows Server 2012 R2 mit 64 Bit und IIS 8.5
+ Windows Server Core 2012 R2 mit 64 Bit und IIS 8.5
+ Windows Server 2012 mit 64 Bit und IIS 8
+ Windows Server 2008 R2 mit 64 Bit und IIS 7.5
In früheren Versionen war die Verarbeitungsreihenfolge für Konfigurationsdateien inkonsistent. Während der Umgebungserstellung wurde `Container Commands` ausgeführt, nachdem die Anwendungsquelle für IIS bereitgestellt wurde. Bei einer Bereitstellung in einer ausgeführten Umgebung werden Container-Befehle ausgeführt, bevor die neue Version bereitgestellt wird. Bei einer Skalierung nach oben werden Konfigurationsdateien nicht verarbeitet.
Darüber hinaus wird IIS gestartet, bevor Container-Befehle ausgeführt werden. Dieses Verhalten hat einige Kunden zur Implementierung von Umgehungslösungen in Container-Befehlen veranlasst, wobei der IIS-Server angehalten wird, bevor Befehle ausgeführt werden, und nach Abschluss wieder gestartet wird.
Version 1 behebt die Inkonsistenzen. Damit ist das Verhalten der Windows Server-Plattform demjenigen der Linux-basierten Plattformen von Elastic Beanstalk ähnlicher. Bei der v1-Plattform führt Elastic Beanstalk immer Container-Befehle vor dem Start des IIS-Servers aus.
Die Lösungs-Stacks der v1-Plattform haben ein `v1` nach der Windows Server-Version:
+ Windows Server 2012 R2 v1.1.0 mit 64 Bit und IIS 8.5
+ Windows Server Core 2012 R2 v1.1.0 mit 64 Bit und IIS 8.5
+ Windows Server 2012 v1.1.0 mit 64 Bit und IIS 8
+ Windows Server 2008 R2 v1.1.0 mit 64 Bit und IIS 7.5
Außerdem extrahiert die v1-Plattform den Inhalt Ihres Anwendungs-Quell-Bundles in `C:\staging\`, bevor Container-Befehle ausgeführt werden. Nachdem die Container-Befehle abgeschlossen wurden, wird der Inhalt dieses Ordners als ZIP-Datei komprimiert und für IIS bereitgestellt. In diesem Workflow können Sie den Inhalt Ihres Anwendungs-Quell-Bundles mit Befehlen oder einem Skript vor der Bereitstellung ändern.
## Migration von früheren Hauptversionen der Windows Server-Plattform
Lesen Sie diesen Abschnitt mit Hinweisen zur Migration, bevor Sie Ihre Umgebung aktualisieren. Weitere Informationen zur Aktualisierung Ihrer Umgebungsplattform auf eine neuere Version finden Sie unter [Aktualisieren der Plattformversion für die Elastic Beanstalk-Umgebung](using-features.platform.upgrade.md).
### Kopieren von V1 in V2
.NET Core 1.x und 2.0 werden von der v2-Plattform von Windows Server nicht unterstützt. Wenn Sie Ihre Anwendung von Windows Server v1 auf v2 migrieren und Ihre Anwendung eine dieser .NET Core-Versionen nutzt, aktualisieren Sie Ihre Anwendung auf eine .NET-Core Version, die von v2 unterstützt wird. Eine Liste der unterstützten Versionen finden Sie unter [.NET mit Windows Server und IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) in den *AWS Elastic Beanstalk Plattformen*.
Wenn Ihre Anwendung ein benutzerdefiniertes Amazon Machine Image (AMI) verwendet, erstellen Sie ein neues benutzerdefiniertes AMI basierend auf einer Windows Server-Plattform v2 AMI. Weitere Informationen hierzu finden Sie unter [Verwenden eines benutzerdefinierten Amazon Machine Images (AMI) in Ihrer Elastic Beanstalk Beanstalk-Umgebung](using-features.customenv.md).
**Anmerkung**
Welche Bereitstellungs- und Update-Funktionen in Windows Server v2 neu sind, ist vom erweiterten Zustandsbericht abhängig. Wenn Sie eine Umgebung auf v2 migrieren, ist der erweiterte Zustandsbericht deaktiviert. Sie müssen sie aktivieren, um diese Funktionen verwenden zu können. Details hierzu finden Sie unter [Aktivieren der erweiterten Elastic-Beanstalk-Integritätsberichte](health-enhanced-enable.md).
### Von Pre-V1-Versionen
Wenn Sie Ihre Anwendung von einem Windows Server-Lösungs-Stack vor v1 migrieren und derzeit Containerbefehle verwenden, müssen Sie zusätzlich zu den Überlegungen, die auf eine Migration von v1 zutreffen, alle Befehle entfernen, die Sie hinzugefügt haben, um die Verarbeitungsinkonsistenzen beim Migrieren auf eine neuere Version zu umgehen. Ab v1 werden Container-Befehle garantiert vollständig ausgeführt, bevor die Anwendungsquelle bereitgestellt und bevor IIS gestartet wird. Auf diese Weise können Sie Änderungen an der Quelle in `C:\staging` durchführen und IIS-Konfigurationsdateien in diesem Schritt ohne Probleme ändern.
Sie können beispielsweise die verwenden, AWS CLI um eine DLL-Datei von Amazon S3 in Ihre Anwendungsquelle herunterzuladen:
`.ebextensions\copy-dll.config`
```
container_commands:
copy-dll:
command: aws s3 cp s3://amzn-s3-demo-bucket/dlls/large-dll.dll .\lib\
```
Weitere Informationen zur Verwendung von Konfigurationsdateien finden Sie unter [Erweiterte Umgebungsanpassung mit Konfigurationsdateien (`.ebextensions`)](ebextensions.md).
# Ausführen mehrerer Anwendungen und ASP.NET Core-Anwendungen mit einem Bereitstellungsmanifest
Sie können mit einem Bereitstellungsmanifest Elastic Beanstalk anweisen, wie Ihre Anwendung bereitgestellt werden soll. Wenn Sie diese Methode verwenden, müssen Sie kein `MSDeploy` für eine einzelne ASP.NET-Anwendung generieren, die im Root-Pfad Ihrer Website ausgeführt wird. Stattdessen können Sie eine Manifestdatei verwenden, um mehrere Anwendungen auf verschiedenen Pfaden auszuführen. Alternativ können Sie Elastic Beanstalk anweisen, die App mit ASP.NET Core bereitzustellen und auszuführen. Sie können ein Bereitstellungsmanifest auch zum Konfigurieren eines Anwendungspools verwenden, in dem Sie Ihre Anwendungen ausführen.
Bereitstellungsmanifeste fügen Unterstützung für [.NET Core-Anwendungen](#dotnet-manifest-dotnetcore) zu Elastic Beanstalk hinzu. Sie können eine .NET Framework-Anwendung ohne Bereitstellungsmanifest bereitstellen. .NET-Core-Anwendungen benötigen jedoch ein Bereitstellungsmanifest, um auf Elastic Beanstalk ausgeführt zu werden. Wenn Sie ein Bereitstellungsmanifest verwenden, können Sie ein Website-Archiv für jede erstellen und die Website-Archive dann in einem zweiten ZIP-Archiv mit dem Bereitstellungsmanifest bündeln.
Bereitstellungsmanifeste bieten auch die Möglichkeit, [mehrere Anwendungen auf verschiedenen Pfaden auszuführen](#dotnet-manifest-multiapp). Ein Bereitstellungsmanifest definiert eine Reihe von Bereitstellungszielen, jeweils mit einem Website-Archiv und einem Pfad, auf dem IIS es ausführen soll. Sie können beispielsweise einen Web-API auf dem `/api`-Pfad ausführen, um asynchrone Anfragen zu verarbeiten, und eine Web-App auf dem Stammpfad ausführen, die die API in Anspruch nimmt.
Sie können ein Bereitstellungsmanifest verwenden, um [IIS-Websites mit benutzerdefinierten Bindungen und physischen Pfaden zu konfigurieren](#dotnet-manifest-websites). Auf diese Weise können Sie Websites einrichten, die bestimmte Ports oder Hostnamen abhören, bevor Sie Ihre Anwendungen bereitstellen.
Sie können ein Bereitstellungsmanifest auch verwenden, um [mehrere Anwendungen mit Anwendungspools in IIS oder Kestrel auszuführen](#dotnet-manifest-apppool). Sie können einen Anwendungspool so konfigurieren, dass Ihre Anwendungen in regelmäßigen Abständen neu gestartet werden, 32-Bit-Anwendungen ausführen oder eine bestimmte Version der .NET Framework-Laufzeit verwenden.
Für eine vollständige Anpassung können Sie [Ihre eigenen Deployment-Skripts in Windows schreiben](#dotnet-manifest-custom) PowerShell und Elastic Beanstalk mitteilen, welche Skripts ausgeführt werden müssen, um Ihre Anwendung zu installieren, zu deinstallieren und neu zu starten.
Bereitstellungsmanifeste und verwandte Funktionen erfordern als Windows Server-Plattformkonfiguration [Version 1.2.0 oder höher](dotnet-v2migration.md).
Detaillierte Informationen zu allen verfügbaren Konfigurationsoptionen, Eigenschaften und erweiterten Funktionen wie dem Überspringen von IIS-Resets finden Sie in der Schemareferenz für das [Deployment-Manifest](dotnet-manifest-schema.md).
**Topics**
+ [.NET Core-Apps](#dotnet-manifest-dotnetcore)
+ [Ausführen mehrerer Anwendungen](#dotnet-manifest-multiapp)
+ [Konfigurieren Sie IIS-Websites](#dotnet-manifest-websites)
+ [Verwenden von Application Request Routing (ARR)](#dotnet-manifest-arr)
+ [Konfigurieren der Anwendungspools](#dotnet-manifest-apppool)
+ [Definieren von benutzerdefinierten Bereitstellungen](#dotnet-manifest-custom)
+ [Schemareferenz für das Bereitstellungsmanifest](dotnet-manifest-schema.md)
## .NET Core-Apps
Sie können ein Bereitstellungsmanifest verwenden, um .NET-Core-Anwendungen auf Elastic Beanstalk auszuführen. .NET-Core-Version ist eine plattformübergreifende Version von .NET, die ein Befehlszeilentool (`dotnet`) enthält. Sie können damit eine Anwendung generieren, lokal ausführen und für die Veröffentlichung vorbereiten.
Zum Ausführen einer .NET-Core-Anwendung auf Elastic Beanstalk können Sie `dotnet publish` ausführen und die Ausgabe in ein ZIP-Archiv (ohne enthaltene Verzeichnisse) packen. Platzieren Sie das Website-Archiv in einem Quell-Bundle mit einem Bereitstellungsmanifest mit einem Bereitstellungsziel des Typs `aspNetCoreWeb`.
Das folgende Bereitstellungsmanifest führt eine .NET Core-Anwendung von einem Website-Archiv mit dem Namen `dotnet-core-app.zip` auf dem Stammpfad aus.
**Example aws-windows-deployment-manifest.json — .NET-Kern**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
Bündeln Sie das Manifest und Website-Archiv in einem ZIP-Archiv zum Erstellen eines Quell-Bundle.
**Example dotnet-core-bundle.zip**
```
.
|-- aws-windows-deployment-manifest.json
`-- dotnet-core-app.zip
```
Die Website-Archiv enthält den kompilierten Anwendungscode, Abhängigkeiten und `web.config`-Dateien.
**Example dotnet-core-app.zip**
```
.
|-- Microsoft.AspNetCore.Hosting.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.dll
|-- Microsoft.AspNetCore.Http.Abstractions.dll
|-- Microsoft.AspNetCore.Http.Extensions.dll
|-- Microsoft.AspNetCore.Http.Features.dll
|-- Microsoft.AspNetCore.Http.dll
|-- Microsoft.AspNetCore.HttpOverrides.dll
|-- Microsoft.AspNetCore.Server.IISIntegration.dll
|-- Microsoft.AspNetCore.Server.Kestrel.dll
|-- Microsoft.AspNetCore.WebUtilities.dll
|-- Microsoft.Extensions.Configuration.Abstractions.dll
|-- Microsoft.Extensions.Configuration.EnvironmentVariables.dll
|-- Microsoft.Extensions.Configuration.dll
|-- Microsoft.Extensions.DependencyInjection.Abstractions.dll
|-- Microsoft.Extensions.DependencyInjection.dll
|-- Microsoft.Extensions.FileProviders.Abstractions.dll
|-- Microsoft.Extensions.FileProviders.Physical.dll
|-- Microsoft.Extensions.FileSystemGlobbing.dll
|-- Microsoft.Extensions.Logging.Abstractions.dll
|-- Microsoft.Extensions.Logging.dll
|-- Microsoft.Extensions.ObjectPool.dll
|-- Microsoft.Extensions.Options.dll
|-- Microsoft.Extensions.PlatformAbstractions.dll
|-- Microsoft.Extensions.Primitives.dll
|-- Microsoft.Net.Http.Headers.dll
|-- System.Diagnostics.Contracts.dll
|-- System.Net.WebSockets.dll
|-- System.Text.Encodings.Web.dll
|-- dotnet-core-app.deps.json
|-- dotnet-core-app.dll
|-- dotnet-core-app.pdb
|-- dotnet-core-app.runtimeconfig.json
`-- web.config
```
## Ausführen mehrerer Anwendungen
Sie können mehrere Anwendungen mit einem Bereitstellungsmanifest ausführen, indem Sie mehrere Bereitstellungsziele definieren.
Das folgende Bereitstellungsmanifest konfiguriert zwei .NET Core-Anwendungen. Die `WebApiSampleApp` Anwendung implementiert eine einfache Web-API und bedient asynchrone Anfragen im `/api` Pfad. Die `DotNetSampleApp`-Anwendung ist eine Webanwendung, die Anfragen im Root-Pfad bedient.
**Example aws-windows-deployment-manifest.json — mehrere Apps**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "WebAPISample",
"parameters": {
"appBundle": "WebApiSampleApp.zip",
"iisPath": "/api"
}
},
{
"name": "DotNetSample",
"parameters": {
"appBundle": "DotNetSampleApp.zip",
"iisPath": "/"
}
}
]
}
}
```
Eine Beispielanwendung mit mehreren Anwendungen finden Sie hier:
+ **Bereitstellbares Quellpaket** [— -v2.zip dotnet-multiapp-sample-bundle](samples/dotnet-multiapp-sample-bundle-v2.zip)
+ **Quellcode** [- -v2.zip dotnet-multiapp-sample-source](samples/dotnet-multiapp-sample-source-v2.zip)
## Konfigurieren Sie IIS-Websites
Mithilfe des Bereitstellungsmanifests können Sie IIS-Websites mit benutzerdefinierten Bindungen und physischen Pfaden konfigurieren. Dies ist nützlich, wenn Sie Websites einrichten müssen, die bestimmte Ports abhören, benutzerdefinierte Hostnamen verwenden oder Inhalte aus bestimmten Verzeichnissen bereitstellen.
Das folgende Bereitstellungsmanifest konfiguriert eine benutzerdefinierte IIS-Website, die HTTP mit einer bestimmten Portnummer und einem benutzerdefinierten physischen Pfad abhört:
**Example aws-windows-deployment-manifest.json — Konfiguration der IIS-Website**
```
{
"manifestVersion": 1,
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
}
]
}
]
},
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"appBundle": "dotnet-core-app.zip",
"iisWebSite": "MyCustomSite",
"iisPath": "/"
}
}
]
}
}
```
In diesem Beispiel:
+ Eine Website mit dem Namen MyCustomSite "" wird mit einem benutzerdefinierten physischen Pfad erstellt
+ Die Website hat eine HTTP-Bindung an Port 8080 mit einem bestimmten Hostnamen
+ Die ASP.NET Core-Anwendung wird mithilfe des Parameters auf dieser benutzerdefinierten Website bereitgestellt `iisWebSite`
## Verwenden von Application Request Routing (ARR)
Die Module Application Request Routing (ARR) und URL Rewrite sind vorinstalliert und in Elastic Beanstalk Windows verfügbar. AMIs Diese Module ermöglichen erweiterte Routing-Szenarien und URL-Manipulation über die IIS-Konfiguration mithilfe von EExtensions oder Anwendungskonfiguration.
Das folgende Beispiel zeigt ein einfaches Bereitstellungsmanifest, das eine Website mit einem benutzerdefinierten Port konfiguriert, kombiniert mit einer EExtensions-Konfiguration, die das grundlegende ARR-Routing einrichtet:
**Example aws-windows-deployment-manifest.json — Einfache ARR-Einrichtung**
```
{
"manifestVersion": 1,
"iisConfig": {
"websites": [
{
"name": "ARRSite",
"physicalPath": "C:\\inetpub\\wwwroot\\arrsite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "localhost"
}
]
}
]
},
"deployments": {
"aspNetCoreWeb": [
{
"name": "BackendApp",
"parameters": {
"appBundle": "backend-app.zip",
"iisWebSite": "ARRSite",
"iisPath": "/backend"
}
}
]
}
}
```
Die ARR-Konfiguration erfolgt über EExtensions. Die folgende Konfiguration richtet grundlegende ARR-Routing-Regeln ein:
**Example .ebextensions/arr-config.config — Grundlegende ARR-Konfiguration**
```
files:
"C:\\temp\\configure-arr.ps1":
content: |
# Enable ARR proxy at server level
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/proxy' -Name 'enabled' -Value 'True'
# Clear any existing global rules to avoid conflicts
Clear-WebConfiguration -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/rewrite/globalRules'
# Add global rule to route all requests to backend
Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
-Filter 'system.webServer/rewrite/globalRules' `
-Name '.' `
-Value @{
name = 'Route_to_Backend'
stopProcessing = 'True'
match = @{ url = '^(?!backend/)(.*)' }
action = @{
type = 'Rewrite'
url = 'http://localhost:8080/backend/{R:1}'
}
}
container_commands:
01_configure_arr:
command: powershell -ExecutionPolicy Bypass -File "C:\\temp\\configure-arr.ps1"
waitAfterCompletion: 0
```
Diese Konfiguration erstellt eine Website auf Port 8080 und richtet ARR so ein, dass alle eingehenden Anfragen an die Backend-Anwendung weitergeleitet werden, die auf dieser Site ausgeführt wird.
## Konfigurieren der Anwendungspools
Sie können mehrere Anwendungen in Ihrer Windows-Umgebung unterstützen. Es stehen zwei Ansätze zur Verfügung:
+ Sie können das out-of-process Hosting-Modell mit dem Kestrel-Webserver verwenden. Bei diesem Modell konfigurieren Sie mehrere Anwendungen für die Ausführung in einem Anwendungspool.
+ Sie können das In-Process-Hosting-Modell verwenden. Bei diesem Modell verwenden Sie mehrere Anwendungspools, um mehrere Anwendungen mit nur einer Anwendung in jedem Pool auszuführen. Wenn Sie den IIS-Server verwenden und mehrere Anwendungen ausführen müssen, müssen Sie diesen Ansatz verwenden.
Um Kestrel für die Ausführung mehrerer Anwendungen in einem Anwendungspool zu konfigurieren, fügen Sie `hostingModel="OutofProcess"` zur Datei `web.config` hinzu. Betrachten Sie die folgenden Beispiele:
**Example web.config — für das Kestrel-Hosting-Modell out-of-process**
```
```
**Example aws-windows-deployment-manifest.json — mehrere Anwendungen**
```
{
"manifestVersion": 1,
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {"archive": "site1.zip",
"iisPath": "/"
}
},
{"name": "Web-app2",
"parameters": {"archive": "site2.zip",
"iisPath": "/app2"
}
}
]
}
}
```
IIS unterstützt nicht mehrere Anwendungen in einem Anwendungspool, da es das In-Process-Hosting-Modell verwendet. Daher müssen Sie mehrere Anwendungen konfigurieren, indem Sie jede Anwendung einem Anwendungspool zuweisen. Mit anderen Worten: Weisen Sie einem Anwendungspool nur eine Anwendung zu.
Sie können IIS so konfigurieren, dass verschiedene Anwendungspools in der Datei `aws-windows-deployment-manifest.json` verwendet werden. Nehmen Sie die folgenden Aktualisierungen vor, wenn Sie auf die nächste Beispieldatei verweisen:
+ Fügen Sie einen Abschnitt `iisConfig` hinzu, der einen Unterabschnitt mit dem Namen `appPools` enthält.
+ Listen Sie im Block `appPools` die Anwendungspools auf.
+ Definieren Sie im Abschnitt `deployments` einen Abschnitt `parameters` für jede Anwendung.
+ Für jede Anwendung gibt der Abschnitt `parameters` ein Archiv, einen Pfad zum Ausführen und einen `appPool` an, in dem die Ausführung erfolgt.
Das folgende Bereitstellungsmanifest konfiguriert zwei Anwendungspools, die ihre Anwendung alle 10 Minuten neu starten. Sie hängen ihre Anwendungen auch an eine .NET Framework-Webanwendung an, die unter dem angegebenen Pfad ausgeführt wird.
**Example aws-windows-deployment-manifest.json — eine Anwendung pro Anwendungspool**
```
{
"manifestVersion": 1,
"iisConfig": {"appPools": [
{"name": "MyFirstPool",
"recycling": {"regularTimeInterval": 10}
},
{"name": "MySecondPool",
"recycling": {"regularTimeInterval": 10}
}
]
},
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {
"archive": "site1.zip",
"iisPath": "/",
"appPool": "MyFirstPool"
}
},
{"name": "Web-app2",
"parameters": {
"archive": "site2.zip",
"iisPath": "/app2",
"appPool": "MySecondPool"
}
}
]
}
}
```
## Definieren von benutzerdefinierten Bereitstellungen
Für noch mehr Kontrolle können Sie eine Anwendungsbereitstellung komplett anpassen, indem Sie eine *benutzerdefinierte Bereitstellung* definieren.
Dieses Deployment-Manifest weist Elastic Beanstalk an, PowerShell Skripts im 32-Bit-Modus auszuführen. Es spezifiziert drei Skripte: ein `install` Skript (`siteInstall.ps1`), das beim Start und bei der Bereitstellung von Instances ausgeführt wird, ein `uninstall` Skript (`siteUninstall.ps1`), das vor der Installation neuer Versionen während der Bereitstellung ausgeführt wird, und ein `restart` Skript (`siteRestart.ps1`), das ausgeführt wird, wenn Sie [App Server neu starten in der Managementkonsole](environments-dashboard-actions.md) auswählen. AWS
**Example aws-windows-deployment-manifest.json — benutzerdefinierte Bereitstellung**
```
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "Custom site",
"architecture" : 32,
"scripts": {
"install": {
"file": "siteInstall.ps1"
},
"restart": {
"file": "siteRestart.ps1"
},
"uninstall": {
"file": "siteUninstall.ps1"
}
}
}
]
}
}
```
Fügen Sie alle Artefakte hinzu, die erforderlich sind, um die Anwendung in Ihrem Quell-Bundle mit dem Manifest und Skripts auszuführen.
**Example C ustom-site-bundle — .zip**
```
.
|-- aws-windows-deployment-manifest.json
|-- siteInstall.ps1
|-- siteRestart.ps1
|-- siteUninstall.ps1
`-- site-contents.zip
```
# Schemareferenz für das Bereitstellungsmanifest
Das Deployment-Manifest ist eine JSON-Datei, die definiert, wie Elastic Beanstalk Ihre Windows-Anwendungen bereitstellen und konfigurieren soll. Dieser Abschnitt enthält eine umfassende Referenz für alle unterstützten Eigenschaften und Konfigurationsoptionen im Manifestschema.
## Manifest-Struktur
Das Bereitstellungsmanifest folgt einem bestimmten JSON-Schema mit der folgenden Struktur auf oberster Ebene:
**Example Grundlegende Manifeststruktur**
```
{
"manifestVersion": 1,
"skipIISReset": false,
"iisConfig": {
"websites": [...],
"appPools": [...]
},
"deployments": {
"msDeploy": [...],
"aspNetCoreWeb": [...],
"custom": [...]
}
}
```
### Eigenschaften der obersten Ebene
`manifestVersion` (Erforderlich)
*Typ*: Zahl
*Standard*: 1
*Gültige Werte: 1*
Gibt die Version des Manifestschemas an. Derzeit wird nur Version 1 unterstützt.
`skipIISReset` (optional)
*Typ*: Boolesch
*Standard:* false
Steuert, ob IIS während der Anwendungsbereitstellung zurückgesetzt wird. Dieses Flag betrifft sowohl Bereitstellungstypen als `msDeploy` auch `aspNetCoreWeb` Bereitstellungstypen.
*Verhalten:*
+ *Nicht angegeben oder `false` (Standard):* IIS-Resets werden bei Installations-, Deinstallations- und Aktualisierungsvorgängen durchgeführt. Dies ist das traditionelle Verhalten.
+ *`true`:* IIS-Resets werden bei Bereitstellungsvorgängen übersprungen.
*Vorteile:*
+ *Geringere Ausfallzeiten* — Bei Anwendungen kommt es während der Bereitstellung zu kürzeren Serviceunterbrechungen.
+ *Schnellere Bereitstellungen* — Eliminiert die Zeit, die IIS benötigt, um vollständig neu zu starten und neu zu initialisieren.
Bei Verwendung `skipIISReset` führt der [RestartAppServer](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RestartAppServer.html)Vorgang unabhängig von dieser Flag-Einstellung einen IIS-Reset durch.
*Beispiel:*
```
{
"manifestVersion": 1,
"skipIISReset": true,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
`deployments` (Erforderlich)
*Typ:* Objekt
Enthält die Bereitstellungskonfigurationen für Ihre Anwendungen. Dieses Objekt kann `custom` Bereitstellungstypen `msDeploy``aspNetCoreWeb`, und enthalten.
`iisConfig` (optional)
*Typ:* Objekt
Definiert IIS-Konfigurationseinstellungen, die vor der Bereitstellung von Anwendungen angewendet werden sollen. Unterstützt sowohl die Website- als auch die Anwendungspoolkonfiguration.
## IIS-Konfiguration
In `iisConfig` diesem Abschnitt können Sie IIS-Einstellungen konfigurieren, bevor Sie Ihre Anwendungen bereitstellen. Dazu gehören die Einrichtung von Anwendungspools mit bestimmten Konfigurationen und die Konfiguration von IIS-Websites mit benutzerdefinierten Bindungen.
### IIS-Websites
IIS-Websites ermöglichen es Ihnen, benutzerdefinierte Website-Einstellungen, einschließlich physischer Pfade und Netzwerkbindungen, zu konfigurieren, bevor Sie Ihre Anwendungen bereitstellen.
**Wichtige Überlegungen zur Erstellung verschiedener IIS-Websites**
*Reihenfolge der Einrichtung der Website:* Websites werden sequentiell in der Reihenfolge konfiguriert, in der sie im `websites` Array erscheinen. Die Plattform verarbeitet jede Website-Konfiguration der Reihe nach. Achten Sie daher auf die richtige Reihenfolge, wenn Sie Abhängigkeiten zwischen Websites haben.
*Firewall und Portzugriff:* Nur Port 80 wird durch die standardmäßige Windows-Firewallkonfiguration von Elastic Beanstalk automatisch verfügbar gemacht. Wenn Sie Websites so konfigurieren, dass sie nicht standardmäßige Ports verwenden, müssen Sie mithilfe von EExtensions oder benutzerdefinierten Deployment-Skripten benutzerdefinierte Firewall-Regeln definieren, um externen Zugriff auf diese Ports zu ermöglichen.
**Example Konfiguration der Website**
```
{
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
},
{
"protocol": "https",
"port": 8443
}
]
}
]
}
}
```Eigenschaften der Website
`name` (Erforderlich)
*Typ:* Zeichenfolge
Der Name der IIS-Website. Dieser Name wird zur Identifizierung der Website im IIS-Manager verwendet und muss innerhalb der IIS-Konfiguration eindeutig sein.
`physicalPath` (Erforderlich)
*Typ:* Zeichenfolge
Der physische Pfad auf dem Server, auf dem die Website-Dateien gespeichert sind. Dieser Pfad muss für den IIS-Arbeitsprozess zugänglich sein.
`bindings` (Erforderlich)
*Typ*: Array
*Mindestanzahl der Artikel:* 1
Eine Reihe von Bindungskonfigurationen, die definieren, wie die Website auf Netzwerkanfragen reagiert. Jede Bindung spezifiziert ein Protokoll, einen Port und einen optionalen Hostnamen.
#### Webseiten-Bindungen
Website-Bindungen definieren die Netzwerkendpunkte, an denen Ihre IIS-Website auf eingehende Anfragen wartet.
`protocol` (Erforderlich)
*Typ:* Zeichenfolge
*Gültige Werte:* „http“, „https“
Das für die Bindung verwendete Protokoll.
`port` (Erforderlich)
*Typ*: Ganzzahl
*Gültiger Bereich: 1-65535*
Die Portnummer, über die die Website Anfragen abhört.
`hostName` (optional)
*Typ:* Zeichenfolge
Der Hostname (Domainname) für die Bindung.
### Anwendungspools
Anwendungspools bieten eine Isolierung zwischen Anwendungen und ermöglichen es Ihnen, Laufzeiteinstellungen für Anwendungsgruppen zu konfigurieren.
**Example Konfiguration des Anwendungspools**
```
{
"iisConfig": {
"appPools": [
{
"name": "MyAppPool",
"enable32Bit": false,
"managedPipelineMode": "Integrated",
"managedRuntimeVersion": "v4.0",
"queueLength": 1000,
"cpu": {
"limitPercentage": 80,
"limitAction": "Throttle",
"limitMonitoringInterval": 5
},
"recycling": {
"regularTimeInterval": 1440,
"requestLimit": 10000,
"memory": 1048576,
"privateMemory": 524288
}
}
]
}
}
```Eigenschaften des Anwendungspools
`name` (Erforderlich)
*Typ:* Zeichenfolge
Der Name des Anwendungspools. Dieser Name wird verwendet, um in Bereitstellungskonfigurationen auf den Pool zu verweisen.
`enable32Bit` (optional)
*Typ*: Boolesch
Ermöglicht die Ausführung einer 32-Bit-Anwendung auf einer 64-Bit-Version von Windows. Wird `true` für ältere Anwendungen, die 32-Bit-Kompatibilität erfordern, auf gesetzt.
`managedPipelineMode` (optional)
*Typ:* Zeichenfolge
*Gültige Werte:* „Integrated“, „Classic“
Gibt den Modus zur Anforderungsverarbeitung für den Anwendungspool an.
`managedRuntimeVersion` (optional)
*Typ:* Zeichenfolge
*Gültige Werte:* „Kein verwalteter Code“, „v2.0", „v4.0"
Gibt die .NET Framework-Version für den Anwendungspool an.
`queueLength` (optional)
*Typ*: Ganzzahl
Maximale Anzahl von Anfragen, die HTTP.sys für den Anwendungspool in die Warteschlange stellt, bevor weitere Anfragen zurückgewiesen werden.
#### CPU-Konfiguration
Das `cpu` Objekt konfiguriert die CPU-Nutzungslimits und die Überwachung für den Anwendungspool.
`limitPercentage` (optional)
*Typ*: Zahl
Maximaler Prozentsatz der CPU-Zeit, den Arbeitsprozesse im Anwendungspool verbrauchen können.
`limitAction` (optional)
*Typ:* Zeichenfolge
*Gültige Werte:* "NoAction„, „KillW3WP“, „Throttle“, "“ ThrottleUnderLoad
Aktion, die ergriffen werden soll, wenn das CPU-Limit erreicht ist.
`limitMonitoringInterval` (optional)
*Typ*: Zahl
Reset-Zeitraum (in Minuten) für CPU-Überwachungs- und Drosselungsgrenzwerte.
#### Konfiguration recyceln
Das `recycling` Objekt konfiguriert, wann und wie Worker-Prozesse im Anwendungspool wiederverwendet werden.
`regularTimeInterval` (optional)
*Typ*: Ganzzahl
Zeitintervall (in Minuten), nach dem der Anwendungspool wiederverwendet wird. Auf 0 setzen, um das zeitbasierte Recycling zu deaktivieren.
`requestLimit` (optional)
*Typ*: Ganzzahl
Maximale Anzahl von Anfragen, die der Anwendungspool vor dem Recycling verarbeitet.
`memory` (optional)
*Typ*: Ganzzahl
Menge an virtuellem Speicher (in Kilobyte), die das Recycling von Arbeitsprozessen auslöst.
`privateMemory` (optional)
*Typ*: Ganzzahl
Menge an privatem Speicher (in Kilobyte), der das Recycling von Arbeitsprozessen auslöst.
## Bereitstellungstypen
Das `deployments` Objekt enthält Arrays von Bereitstellungskonfigurationen für verschiedene Anwendungstypen. Jeder Bereitstellungstyp hat spezifische Eigenschaften und Anwendungsfälle.
### MSDeploy Bereitstellungen
MSDeploy Bereitstellungen werden für herkömmliche.NET-Framework-Anwendungen verwendet, die mit Web Deploy () MSDeploy bereitgestellt werden können.
**Example MSDeploy Bereitstellungskonfiguration**
```
{
"deployments": {
"msDeploy": [
{
"name": "WebApp",
"description": "Main web application",
"parameters": {
"appBundle": "webapp.zip",
"iisPath": "/",
"appPool": "DefaultAppPool"
}
}
]
}
}
```MSDeploy Eigenschaften der Bereitstellung
`name` (Erforderlich)
*Typ:* Zeichenfolge
Eindeutiger Name für die Bereitstellung. Dieser Name muss für alle Bereitstellungen im Manifest eindeutig sein.
`description` (optional)
*Typ:* Zeichenfolge
Für Menschen lesbare Beschreibung der Bereitstellung.
`parameters` (Erforderlich)
*Typ:* Objekt
Konfigurationsparameter für den MSDeploy Vorgang.
`scripts` (optional)
*Typ:* Objekt
PowerShell Skripts, die in verschiedenen Phasen des Bereitstellungslebenszyklus ausgeführt werden.
#### MSDeploy Parameter
`appBundle` (Erforderlich)
*Typ:* Zeichenfolge
Pfad zum Anwendungspaket (ZIP-Datei) relativ zur Manifestdatei. Dieses Paket enthält die Anwendungsdateien, die bereitgestellt werden sollen.
`iisWebSite` (optional)
*Typ:* Zeichenfolge
*Standard:* „Standardwebsite“
Die IIS-Website, auf der die Anwendung bereitgestellt werden soll. Standardmäßig werden Anwendungen auf der „Standardwebsite“ bereitgestellt. Optional können Sie einen anderen Namen für die Website angeben, z. B. einen, der im `iisConfig.websites` Abschnitt konfiguriert wurde.
`iisPath` (optional)
*Typ:* Zeichenfolge
*Standard:* „/“
Virtueller Verzeichnispfad in IIS, in dem die Anwendung bereitgestellt wird. Verwenden Sie „/“ für den Stammpfad oder „/api“ für ein Unterverzeichnis.
`appPool` (optional)
*Typ:* Zeichenfolge
Name des Anwendungspools, in dem diese Anwendung ausgeführt werden soll.
### ASP.NET Core-Bereitstellungen
ASP.NET Core-Bereitstellungen wurden speziell für .NET Core- und .NET 5\$1-Anwendungen entwickelt.
**Example Konfiguration der ASP.NET Core-Bereitstellung**
```
{
"deployments": {
"aspNetCoreWeb": [
{
"name": "CoreAPI",
"description": "ASP.NET Core Web API",
"parameters": {
"appBundle": "coreapi.zip",
"iisPath": "/api",
"appPool": "CoreAppPool"
}
}
]
}
}
```
ASP.NET Core-Bereitstellungen verwenden dieselbe Eigenschaftsstruktur wie MSDeploy Bereitstellungen, wobei der Hauptunterschied in der für die Anwendung verwendeten Laufzeitumgebung und dem Hostingmodell besteht.ASP.NET Core-Bereitstellungsparameter
`appBundle` (Erforderlich)
*Typ:* Zeichenfolge
Pfad zum Anwendungspaket relativ zur Manifestdatei. Dies kann entweder ein ZIP-Archiv oder ein Verzeichnispfad sein, der die veröffentlichte ASP.NET Core-Anwendung enthält.
`iisWebSite` (optional)
*Typ:* Zeichenfolge
*Standard:* „Standardwebsite“
Die IIS-Website, auf der die ASP.NET Core-Anwendung bereitgestellt werden soll. Standardmäßig werden Anwendungen auf der „Standardwebsite“ bereitgestellt. Optional können Sie einen anderen Namen für die Website angeben, z. B. einen, der im `iisConfig.websites` Abschnitt konfiguriert wurde.
`iisPath` (optional)
*Typ:* Zeichenfolge
*Standard:* „/“
Virtueller Verzeichnispfad in IIS für die ASP.NET Core-Anwendung.
`appPool` (optional)
*Typ:* Zeichenfolge
Anwendungspool für die ASP.NET Core-Anwendung. Der Pool wird entsprechend für das ASP.NET Core-Hosting konfiguriert.
### Benutzerdefinierte Bereitstellungen
Benutzerdefinierte Bereitstellungen bieten mithilfe PowerShell von Skripten die vollständige Kontrolle über den Bereitstellungsprozess. Dieser Bereitstellungstyp ist für komplexe Szenarien nützlich, die eine benutzerdefinierte Installation, Konfiguration oder Bereitstellungslogik erfordern.
**Example Benutzerdefinierte Bereitstellungskonfiguration**
```
{
"deployments": {
"custom": [
{
"name": "CustomService",
"description": "Custom Windows service deployment",
"architecture": 32,
"scripts": {
"install": {
"file": "install-service.ps1"
},
"restart": {
"file": "restart-service.ps1"
},
"uninstall": {
"file": "uninstall-service.ps1",
"ignoreErrors": true
}
}
}
]
}
}
```Benutzerdefinierte Bereitstellungseigenschaften
`name` (Erforderlich)
*Typ:* Zeichenfolge
Eindeutiger Name für die benutzerdefinierte Bereitstellung.
`description` (optional)
*Typ:* Zeichenfolge
Beschreibung der benutzerdefinierten Bereitstellung.
`architecture` (optional)
*Typ*: Ganzzahl
*Standard:* 32
*Gültige Werte:* 32, 64
Die Architekturspezifikation für den Ausführungsmodus von Powershell-Skripten
`scripts` (Erforderlich)
*Typ:* Objekt
PowerShell Skripten, die das Bereitstellungsverhalten definieren. Benutzerdefinierte Bereitstellungen unterstützen im Vergleich zu anderen Bereitstellungstypen zusätzliche Skripttypen.
## Bereitstellungsskripte
PowerShell Bereitstellungsskripten sind Skripten, die zu bestimmten Zeitpunkten während des Bereitstellungszyklus ausgeführt werden. Verschiedene Bereitstellungstypen unterstützen unterschiedliche Gruppen von Skriptereignissen.
### Skriptereignisse
Die folgenden Skriptereignisse sind je nach Bereitstellungstyp verfügbar:Standardbereitstellungsskripts (MSDeploy und aspNetCore Web)
`preInstall`
Wird ausgeführt, bevor die Anwendung installiert oder aktualisiert wird.
`postInstall`
Wird ausgeführt, nachdem die Anwendung installiert oder aktualisiert wurde.
`preRestart`
Wird ausgeführt, bevor die Anwendung neu gestartet wird.
`postRestart`
Wird ausgeführt, nachdem die Anwendung neu gestartet wurde.
`preUninstall`
Wird ausgeführt, bevor die Anwendung deinstalliert wird.
`postUninstall`
Wird ausgeführt, nachdem die Anwendung deinstalliert wurde.Benutzerdefinierte Bereitstellungsskripten (nur benutzerdefinierte Bereitstellungen)
`install`
Primäres Installationsskript für benutzerdefinierte Bereitstellungen. Dieses Skript ist für die Installation der Anwendung oder des Dienstes verantwortlich.
`restart`
Skript zum Neustarten der Anwendung oder des Dienstes. Wird aufgerufen, wenn die Umgebung neu gestartet wird.
`uninstall`
Skript zur Deinstallation der Anwendung oder des Dienstes. Wird beim Beenden der Umgebung oder beim Entfernen der Anwendung aufgerufen.
### Eigenschaften des Skripts
Jedes Skript ist als Objekt mit den folgenden Eigenschaften definiert:
`file` (Erforderlich)
*Typ:* Zeichenfolge
Pfad zur PowerShell Skriptdatei relativ zur Manifestdatei. Das Skript sollte eine `.ps1` Erweiterung haben.
`ignoreErrors` (optional)
*Typ*: Boolesch
*Standard:* false
Wenn diese Option auf gesetzt ist`true`, wird die Bereitstellung auch dann fortgesetzt, wenn das Skript fehlschlägt. Verwenden Sie diese Option für unkritische Skripts oder Bereinigungsvorgänge.
**Example Beispiel für eine Skriptkonfiguration**
```
{
"scripts": {
"preInstall": {
"file": "backup-config.ps1",
"ignoreErrors": true
},
"postInstall": {
"file": "configure-app.ps1"
}
}
}
```
# Verwenden von EC2 Fast Launch mit Windows-Plattformzweigen
Die EC2 Schnellstartfunktion reduziert die Startzeiten von Windows-Instances in Ihren Elastic Beanstalk Beanstalk-Umgebungen. In diesem Thema erfahren Sie, wie Sie diese Funktion in Ihren Elastic Beanstalk Beanstalk-Umgebungen verwenden können. Beginnend mit der Windows-Plattformversion 2.16.2, veröffentlicht am [22. Januar 2025,](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-01-22-windows.html) enthalten Elastic Beanstalk-Plattformversionen Basisversionen AMIs mit EC2 aktiviertem Fast Launch.
## Standardmäßige Verfügbarkeit von Fast Launch EC2
Die neuesten Versionen der Elastic Beanstalk Windows-Plattform enthalten eine Basisversion AMIs mit automatisch aktiviertem EC2 Fast Launch, ohne dass zusätzliche Kosten anfallen. Wenn jedoch neuere Plattformversionen veröffentlicht werden, bleibt EC2 Fast Launch möglicherweise nicht automatisch auf der Basis AMIs älterer Plattformversionen aktiviert.
Wir empfehlen, auf die neueste Windows-Plattformversion zu aktualisieren, um die Basisversion AMIs mit automatisch aktiviertem EC2 Fast Launch zu verwenden. Wenn Sie jedoch Ihre bestehende Plattformversion weiterhin verwenden müssen, können Sie EC2 Fast Launch auf dem Basis-AMI Ihrer Umgebung manuell aktivieren. Detaillierte Anweisungen finden Sie unter [Manuelles Konfigurieren von EC2 Fast Launch](#dotnet-ec2fastlaunch-manual).
## Manuelles Konfigurieren von EC2 Fast Launch
**Anmerkung**
Die manuelle Aktivierung von EC2 Fast Launch kann im Vergleich zur Verwendung von Plattformversionen mit automatisch aktiviertem EC2 Fast Launch zusätzliche Kosten verursachen. Weitere Informationen zu den EC2 Fast Launch-Kosten finden Sie auf der Seite [Kosten für EC2 Fast Launch verwalten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-manage-costs.html) im * EC2 Amazon-Benutzerhandbuch*.
Gehen Sie wie folgt vor, um EC2 Fast Launch auf einem Windows-Basis-AMI zu aktivieren, das von Ihrer Elastic Beanstalk Beanstalk-Umgebung verwendet wird:
**So aktivieren Sie EC2 Fast Launch manuell für Ihre Elastic Beanstalk Beanstalk-Umgebung**
1. Identifizieren Sie das Basis-AMI Ihrer Umgebung:
Folgen Sie den Schritten unter [Benutzerdefiniertes AMI erstellen](using-features.customenv.md), um die Basis-AMI-ID Ihrer Umgebung zu ermitteln. Beachten Sie, dass Sie kein benutzerdefiniertes AMI erstellen müssen — Sie müssen nur die Schritte befolgen, um Ihre aktuelle Basis-AMI-ID zu finden.
1. Aktivieren Sie EC2 Fast Launch auf dem AMI:
Verwenden Sie die Anweisungen unter [Enable EC2 Fast Launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-configure.html) im * EC2 Amazon-Benutzerhandbuch*, um EC2 Fast Launch für Ihr AMI zu konfigurieren.