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.
Ausführen mehrerer Anwendungen und ASP.NET Kernanwendungen mit einem Bereitstellungsmanifest
Sie können mit einem Bereitstellungsmanifest Elastic Beanstalk anweisen, wie Ihre Anwendung bereitgestellt werden soll. Wenn Sie diese Methode verwendenMSDeploy, müssen Sie kein Quellpaket für eine einzelne ASP.NET Anwendung generieren, die im Stammpfad 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 auch 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 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. 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. 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. 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 Bereitstellungsskripts in Windows schreiben PowerShell und Elastic Beanstalk mitteilen, welche Skripts zur Installation, Deinstallation und zum Neustart Ihrer Anwendung ausgeführt werden sollen.
Bereitstellungsmanifeste und verwandte Funktionen erfordern als Windows Server-Plattformkonfiguration Version 1.2.0 oder höher.
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 Bereitstellungsmanifest.
Sections
.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.
Beispiel aws-windows-deployment-manifest.json – .NET Core
{
"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.
Beispiel 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.
Beispiel 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.configAusfü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 verarbeitet asynchrone Anfragen über den Pfad. /api Die DotNetSampleApp-Anwendung ist eine Webanwendung, die Anfragen im Root-Pfad bedient.
Beispiel 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 Quell-Bundle – dotnet-multiapp-sample-bundle-v2.zip
-
Quellcode – 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:
Beispiel 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-AMIs verfügbar. Diese Module ermöglichen erweiterte Routing-Szenarien und die URL-Manipulation durch die IIS-Konfiguration mithilfe von Erweiterungen oder der Anwendungskonfiguration.
Das folgende Beispiel zeigt ein einfaches Bereitstellungsmanifest, das eine Website mit einem benutzerdefinierten Port konfiguriert, kombiniert mit einer ebextensions-Konfiguration, die das grundlegende ARR-Routing einrichtet:
Beispiel aws-windows-deployment-manifest.json — Einfache ARR-Setup
{
"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 Erweiterungen. Die folgende Konfiguration richtet grundlegende ARR-Routing-Regeln ein:
Beispiel. 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: 0Diese 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 prozessinterne 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:
Beispiel web.config – für das Kestrel-Out-of-Process-Hosting-Modell
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add
name="aspNetCore"
path="*" verb="*"
modules="AspNetCoreModuleV2"
resourceType="Unspecified" />
</handlers>
<aspNetCore
processPath="dotnet"
arguments=".\CoreWebApp-5-0.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
hostingModel="OutofProcess" />
</system.webServer>
</location>
</configuration>Beispiel 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
iisConfighinzu, der einen Unterabschnitt mit dem NamenappPoolsenthält. -
Listen Sie im Block
appPoolsdie Anwendungspools auf. -
Definieren Sie im Abschnitt
deploymentseinen Abschnittparametersfür jede Anwendung. -
Für jede Anwendung gibt der Abschnitt
parametersein Archiv, einen Pfad zum Ausführen und einenappPoolan, 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.
Beispiel 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. Bei einer benutzerdefinierten Bereitstellung führt Elastic Beanstalk nur die von Ihnen bereitgestellten PowerShell Skripts aus — es führt keine IIS-Verwaltung in Ihrem Namen durch. Dies unterscheidet sich von msDeploy aspNetCoreWeb Bereitstellungen, bei denen Elastic Beanstalk IIS vor der Installation automatisch stoppt, danach startet und bei Bedarf neu startet. Bei einer benutzerdefinierten Bereitstellung platzieren Ihre Skripts den Anwendungsinhalt, konfigurieren die Umgebung (z. B. IIS) und starten die Anwendung neu.
Wichtig
In einer Webserverumgebung mit Lastenausgleich überprüft Elastic Beanstalk den Zustand der Instance, indem es den Integritätsprüfungspfad der Umgebung (/standardmäßig) auf Port 80 anfordert. Irgendetwas muss diesen Pfad bedienen, sonst wird die Umgebung fehlerhaft, obwohl jedes Bereitstellungsskript erfolgreich ist — eine häufige Ursache dafür, dass eine benutzerdefinierte Bereitstellung ohne Fehler abgeschlossen wird, die Umgebung jedoch in einem roten Zustand zurückbleibt. Bei einer eigenständigen benutzerdefinierten Bereitstellung stellen Sie Ihre Anwendung vom Stammverzeichnis der Standardwebsite aus bereit. Es ist zulässig, eine benutzerdefinierte Anwendung unter einem Unterpfad zu platzieren, wenn bereits eine andere Bereitstellung den Integritätsprüfungspfad bedient, z. B. in einem Manifest mit mehreren Anwendungen. Weitere Informationen zum Zustand der Umgebung finden Sie unter Überwachen von Umgebungen. Überwachung von Umgebungen in Elastic Beanstalk
Eine benutzerdefinierte Bereitstellung definiert bis zu drei Skripts. In der folgenden Tabelle wird jedes Skript beschrieben, wann es von Elastic Beanstalk ausgeführt wird und was Ihr Skript tun muss.
| Script | Wann Elastic Beanstalk es ausführt | Verantwortung |
|---|---|---|
uninstall |
Vor der Installation jeder neuen Anwendungsversion, also vor jeder Anwendungsbereitstellung. | Beenden Sie den Dienst oder entfernen Sie die Dateien der vorherigen Version. |
install |
Bei jeder Anwendungsbereitstellung. | Stellen Sie Dateien bereit, konfigurieren Sie IIS oder Ihren Dienst und stellen Sie die Anwendung im Integritätsprüfpfad bereit. |
restart |
Nach jeder Anwendungsbereitstellung und nach jeder Konfigurationsänderung. Wenn Sie diese Option festlegen skipIISResettrue, überspringt Elastic Beanstalk dieses Skript bei Anwendungsbereitstellungen, führt es aber trotzdem bei Konfigurationsänderungen aus. Wenn Sie App Server neu starten wählen, wird ein Vorgang auf Plattformebene ausgeführt, Ihr benutzerdefiniertes iisreset Neustartskript wird nicht aufgerufen. |
Starten Sie IIS (iisreset) oder Ihren Dienst neu, damit die neue Version live ist. |
Diese Skripts werden auch ausgeführt, wenn Elastic Beanstalk Ihre Anwendung auf einer neu gestarteten Instance bereitstellt — beispielsweise bei der ersten Erstellung der Umgebung und wenn Auto Scaling eine Instanz hinzufügt (Scale-Out) —, da jede neue Instanz die Anwendung beim Bootstrap installiert.
Das folgende Bereitstellungsmanifest weist Elastic Beanstalk an, Skripts im 32-Bit-Modus auszuführen. PowerShell Es spezifiziert ein install Skript (install.ps1), ein restart Skript (restart.ps1) und ein uninstall Skript (). uninstall.ps1 Das uninstall Skript ist true so ignoreErrors eingestellt, dass die erste Bereitstellung — wenn nichts zu entfernen ist — nicht fehlschlägt.
Beispiel aws-windows-deployment-manifest.json – benutzerdefinierte Bereitstellung
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "Custom site",
"architecture": 32,
"scripts": {
"install": {
"file": "install.ps1"
},
"restart": {
"file": "restart.ps1"
},
"uninstall": {
"file": "uninstall.ps1",
"ignoreErrors": true
}
}
}
]
}
}Fügen Sie alle Artefakte hinzu, die erforderlich sind, um die Anwendung in Ihrem Quell-Bundle mit dem Manifest und Skripts auszuführen. Elastic Beanstalk extrahiert diese Artefakte nicht für eine benutzerdefinierte Bereitstellung — Ihre Skripts müssen sie extrahieren. Im folgenden Beispiel ist der Anwendungsinhalt als gepackt. MyApp.zip
Beispiel Custom-site-bundle.zip
.
|-- aws-windows-deployment-manifest.json
|-- install.ps1
|-- restart.ps1
|-- uninstall.ps1
`-- MyApp.zip
Die folgenden Skripts zeigen eine vollständige benutzerdefinierte Bereitstellung für eine Anwendung, bei der eine Integritätsprüfung durchgeführt wurde. IIS-hosted Das install.ps1 Skript extrahiert den Anwendungsinhalt und weist den physischen Pfad der Standardwebsite darauf hin, sodass die Anwendung vom Stammpfad (/) aus bedient wird, in dem die Integritätsprüfung stattfindet.
Beispiel install.ps1
$ErrorActionPreference = "Stop"
$appPath = "C:\inetpub\MyApp"
if (Test-Path $appPath) { Remove-Item $appPath -Recurse -Force }
# Elastic Beanstalk doesn't extract your bundle for custom deployments, so extract it yourself.
# MyApp.zip ships in the bundle, alongside this script. Resolve it relative to the script's
# own location so the path is reliable regardless of the current working directory.
$scriptDir = if ($PSScriptRoot) { $PSScriptRoot } else { (Get-Location).Path }
$bundleZip = Join-Path $scriptDir "MyApp.zip"
Add-Type -AssemblyName "System.IO.Compression.FileSystem"
[IO.Compression.ZipFile]::ExtractToDirectory($bundleZip, $appPath)
# Serve from the Default Web Site root ("/"), where the health check looks.
Import-Module WebAdministration
Set-ItemProperty "IIS:\Sites\Default Web Site" -Name physicalPath -Value $appPath
iisreset.exe /restart
if ($LASTEXITCODE -ne 0) { exit 1 }Beispiel starte.ps1 neu
$ErrorActionPreference = "Stop"
iisreset.exe /restart
if ($LASTEXITCODE -ne 0) { exit 1 }Beispiel deinstalliere .ps1
# Stop IIS first. While the site is live, w3wp holds locks on files under the app directory,
# which would make the following removal fail.
iisreset.exe /stop | Out-Null
Remove-Item "C:\inetpub\MyApp" -Recurse -Force -ErrorAction SilentlyContinueBeachten Sie beim Schreiben benutzerdefinierter Bereitstellungsskripts die folgenden Punkte:
-
Führen Sie den Health Check-Pfad durch. Verweisen Sie den physischen Pfad der Standardwebsite auf Ihre Anwendung, oder stellen Sie die Installation auf andere Weise auf den Integritätsprüfungspfad bereit, sodass die Integritätsprüfung erfolgreich ist.
-
Schließt ein Standarddokument ein. Wenn das Stammverzeichnis der Website kein Standarddokument hat, wird HTTP 403
GET /zurückgegeben und die Integritätsprüfung schlägt fehl. Versenden Sie eineweb.configDatei, die ein<defaultDocument>Element festlegt, oder geben Sie Ihrer Landingpage einen Namen, der einem IIS-Standarddokumentnamen entspricht, z. B.Default.htmoderindex.htm. -
Starten Sie IIS selbst neu. Da Elastic Beanstalk kein IIS-Management für benutzerdefinierte Bereitstellungen durchführt, müssen Ihre Skripts ausgeführt werden,
iisresetdamit die Änderungen wirksam werden. -
Suchen Sie die gebündelten Dateien relativ zum Skript. Elastic Beanstalk extrahiert Ihre Skripte und gebündelten Artefakte zusammen in dasselbe Verzeichnis. Lösen Sie gebündelte Dateien gegen
$PSScriptRoot(den Ordner, der das laufende Skript enthält) auf, anstatt von einem bestimmten aktuellen Arbeitsverzeichnis auszugehen. -
Bei Fehlschlägen schlägt die Bereitstellung fehl. Stellen Sie externe Befehle ein
$ErrorActionPreference = "Stop"$LASTEXITCODEund überprüfen Sie sie. Andernfalls kann ein defektes Skript erfolgreich beendet werden, und Elastic Beanstalk behandelt die Bereitstellung als erfolgreich, obwohl die Anwendung nicht ordnungsgemäß ausgeführt wird.
Beispiel: ein selbst gehosteter Windows-Dienst
Bei einer benutzerdefinierten Bereitstellung können Sie anstelle einer IIS-hosted Site einen Windows-Dienst ausführen. Elastic Beanstalk Windows-Plattformen unterstützen die Worker-Umgebungsebene nicht. In einer Umgebung mit Lastenausgleich überprüft der Load Balancer den Integritätsprüfungspfad auf Port 80, sodass ein Windows-Dienst diese Anfrage beantworten muss, um die Umgebung intakt zu halten. Das folgende Beispiel ist ein selbst gehosteter Dienst, der Port 80 selbst überwacht und daher keine IIS-Begleitwebsite benötigt.
Anmerkung
Da Windows-Plattformen keine Worker-Tier haben, muss auch ein Dienst, der nur im Hintergrund läuft, die Integritätsprüfung in einer Umgebung mit Lastenausgleich beantworten. Lassen Sie den Dienst entweder auch den Integritätsprüfungspfad beantworten (wie hier gezeigt), oder führen Sie die Hintergrundarbeit zusammen mit einer Site aus, die ihn bereitstellt.
Das Manifest führt die Skripts im 64-Bit-Modus aus, was dem 64-Bit-C#-Compiler entspricht, der zum Erstellen des Dienstes verwendet wurde.
Beispiel aws-windows-deployment-manifest.json — Windows-Dienst
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "EbCustomService",
"architecture": 64,
"scripts": {
"install": {
"file": "serviceInstall.ps1"
},
"restart": {
"file": "serviceRestart.ps1"
},
"uninstall": {
"file": "serviceUninstall.ps1",
"ignoreErrors": true
}
}
}
]
}
}Das Paket enthält das Manifest, die drei Skripts, den Dienstquellcode und eine version.txt Datei (deren Inhalt beispielsweise die Versionszeichenfolge ist). v1 Das Installationsskript kompiliert den Service auf der Instance, sodass Sie in Ihrem Paket keine Build-Toolchain benötigen.
Beispiel Custom-service-bundle.zip
.
|-- aws-windows-deployment-manifest.json
|-- EbCustomService.cs
|-- serviceInstall.ps1
|-- serviceRestart.ps1
|-- serviceUninstall.ps1
`-- version.txtDas serviceInstall.ps1 Skript gibt Port 80 von IIS frei, kompiliert den Dienst aus der mitgelieferten Quelle mit dem mitgelieferten C#-Compiler (csc.exe), registriert ihn als Dienst und startet ihn. LocalSystem Wenn der Dienst als LocalSystem ausgeführt wird, bindet sich der Dienst http://+:80/ ohne eine URL-ACL-Reservierung, wodurch das Beispiel minimal gehalten wird. Bevorzugen Sie in der Produktion ein Konto mit den geringsten Rechten wie NetworkService und gewähren Sie ihm die Bindung explizit mit. netsh http add urlacl
Beispiel Dienst Install.ps1
# INSTALL: compile and register a self-hosted HTTP service that owns port 80.
$ErrorActionPreference = "Stop"
$svcName = "EbCustomService"
$appPath = "C:\CustomService"
$scriptDir = if ($PSScriptRoot) { $PSScriptRoot } else { (Get-Location).Path }
# Free port 80 from IIS and keep it from reclaiming the port on reboot.
Stop-Service W3SVC -Force -ErrorAction SilentlyContinue
Set-Service W3SVC -StartupType Manual -ErrorAction SilentlyContinue
# Fresh application directory.
if (Test-Path $appPath) { Remove-Item $appPath -Recurse -Force }
New-Item -ItemType Directory -Path $appPath | Out-Null
# Compile the service with the in-box .NET Framework compiler (no build tooling needed).
$csc = Join-Path $env:WINDIR "Microsoft.NET\Framework64\v4.0.30319\csc.exe"
$src = Join-Path $scriptDir "EbCustomService.cs"
$exe = Join-Path $appPath "EbCustomService.exe"
& $csc /nologo /target:exe /out:"$exe" /reference:System.ServiceProcess.dll "$src"
if ($LASTEXITCODE -ne 0) { exit 1 }
# Write the content served at "/". A real service would serve its own responses;
# here the install script writes a simple marker so the health check passes.
$version = (Get-Content (Join-Path $scriptDir "version.txt") -Raw).Trim()
Set-Content -Path (Join-Path $appPath "marker.txt") `
-Value "Custom service deployment $version succeeded" -NoNewline
# Register as a LocalSystem service so it can bind http://+:80/ without a URL ACL.
if (Get-Service $svcName -ErrorAction SilentlyContinue) {
Stop-Service $svcName -Force -ErrorAction SilentlyContinue
sc.exe delete $svcName | Out-Null
# sc.exe delete is async; poll until gone so New-Service below doesn't hit
# "service marked for deletion".
$deadline = (Get-Date).AddSeconds(30)
while ((Get-Service $svcName -ErrorAction SilentlyContinue) -and (Get-Date) -lt $deadline) {
Start-Sleep -Milliseconds 500
}
}
New-Service -Name $svcName -BinaryPathName "`"$exe`"" `
-DisplayName "EB Custom Service" -StartupType Automatic | Out-Null
Start-Service $svcNameDas serviceRestart.ps1 Skript startet den Dienst neu, sodass die neue Version live geschaltet wird.
Beispiel Dienst Restart.ps1
# RESTART: restart the service so the new version becomes live.
$ErrorActionPreference = "Stop"
$svcName = "EbCustomService"
Restart-Service $svcName -ForceDas serviceUninstall.ps1 Skript stoppt und löscht den Dienst und entfernt die Dateien der vorherigen Version. Das Manifest wird true für dieses Skript ignoreErrors auf gesetzt, da bei der ersten Bereitstellung keine Vorgängerversion zum Entfernen vorhanden ist.
Beispiel Dienst Uninstall.ps1
# UNINSTALL: stop and remove the previous version before the new install.
# The manifest sets ignoreErrors:true because the first deploy has nothing to remove.
$ErrorActionPreference = "Stop"
$svcName = "EbCustomService"
$appPath = "C:\CustomService"
if (Get-Service $svcName -ErrorAction SilentlyContinue) {
Stop-Service $svcName -Force -ErrorAction SilentlyContinue
sc.exe delete $svcName | Out-Null
# sc.exe delete is async; poll until the service is really gone so the next
# deploy's New-Service doesn't hit "service marked for deletion".
$deadline = (Get-Date).AddSeconds(30)
while ((Get-Service $svcName -ErrorAction SilentlyContinue) -and (Get-Date) -lt $deadline) {
Start-Sleep -Milliseconds 500
}
}
if (Test-Path $appPath) {
Remove-Item $appPath -Recurse -Force -ErrorAction SilentlyContinue
}Der Dienst selbst ist ein kleines C#-Programm, das ein HttpListener On hostet http://+:80/ und eine Textantwort für GET / zurückgibt. Damit wird der Load Balancer-Integritätstest erfüllt.
Beispiel EbCustomService.cs
// Minimal self-hosted HTTP Windows service. Hosts an HttpListener on http://+:80/
// and answers the load balancer's GET "/" health check with the content that the
// install script wrote to marker.txt.
using System;
using System.IO;
using System.Net;
using System.ServiceProcess;
using System.Text;
using System.Threading;
namespace EbCustomService
{
public class MarkerService : ServiceBase
{
private const string Root = @"C:\CustomService";
private HttpListener _listener;
private Thread _worker;
private volatile bool _running;
public MarkerService()
{
this.ServiceName = "EbCustomService";
}
protected override void OnStart(string[] args)
{
_running = true;
_listener = new HttpListener();
_listener.Prefixes.Add("http://+:80/");
_listener.Start();
_worker = new Thread(Loop) { IsBackground = true };
_worker.Start();
}
protected override void OnStop()
{
_running = false;
try { if (_listener != null) _listener.Stop(); } catch { }
}
private void Loop()
{
while (_running)
{
HttpListenerContext ctx;
try { ctx = _listener.GetContext(); }
catch { break; }
try
{
byte[] buf = Encoding.UTF8.GetBytes(ReadFile(Path.Combine(Root, "marker.txt")));
ctx.Response.StatusCode = 200;
ctx.Response.ContentType = "text/plain";
ctx.Response.ContentLength64 = buf.Length;
ctx.Response.OutputStream.Write(buf, 0, buf.Length);
ctx.Response.OutputStream.Close();
}
catch { }
}
}
private static string ReadFile(string p)
{
try { return File.Exists(p) ? File.ReadAllText(p) : ""; }
catch { return ""; }
}
public static void Main()
{
ServiceBase.Run(new MarkerService());
}
}
}Anmerkung
In diesem Beispiel ist die Antwort, die unter bereitgestellt / wird, eine kleine Textmarkierung (marker.txt), die für den tatsächlichen Inhalt Ihrer Anwendung steht. Ein Produktionsdienst würde stattdessen seine eigenen Antworten bereitstellen. Alles andere in diesen Skripten ist das Minimum, das für eine funktionierende benutzerdefinierte Windows-Dienstbereitstellung erforderlich ist.