Migration über die Hauptversionen der Elastic Beanstalk-Windows Server-Plattform hinweg - AWS Elastic Beanstalk

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.

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. 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:

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.

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 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.

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 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 Image (AMI).

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.

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://DOC-EXAMPLE-BUCKET/dlls/large-dll.dll .\lib\

Weitere Informationen zur Verwendung von Konfigurationsdateien finden Sie unter Erweiterte Umgebungsanpassung mit Konfigurationsdateien (.ebextensions).