Migration von Amazon Linux AMI (AL1) zu AL2 oder AL2023 - AWS Elastic Beanstalk
Unterschiede und KompatibilitätMigrationsprozessHilfreiche ReferenzenÜberlegungen für alle Linux-PlattformenPlattformspezifische Überlegungen

Migration von Amazon Linux AMI (AL1) zu AL2 oder AL2023

Wenn Ihre Elastic-Beanstalk-Anwendung auf einer Amazon-Linux-AMI-Plattform basiert, erfahren Sie in diesem Abschnitt, wie Sie die Umgebungen der Anwendung zu Amazon Linux 2 oder Amazon Linux 2023 migrieren. Plattformzweige der vorherigen Generation, die auf Amazon Linux AMI basieren, wurden inzwischen eingestellt.

Es wird dringend empfohlen, zu Amazon Linux 2023 zu migrieren, da es aktueller ist als Amazon Linux 2. Der Support für das Betriebssystem Amazon Linux 2 wird eher eingestellt als der Support für Amazon Linux 2023. Dementsprechend profitieren Sie bei einer Migration zu Amazon Linux 2023 von einem längeren Supportzeitraum.

Zu beachten ist, dass zwischen den Plattformen Elastic Beanstalk Amazon Linux 2 und Amazon Linux 2023 ein hohes Maß an Kompatibilität besteht. In einigen Bereichen gibt es jedoch Unterschiede: die Voreinstellung für die Option Instance Metadata Service Version 1 (IMDSv1), Unterstützung für das Instance-Tool pkg-repo und einige Apache-HTTPd-Konfigurationen. Weitere Informationen finden Sie unter Amazon Linux 2023.

Unterschiede und Kompatibilität

Für die AL2023/AL2-basierten Plattformzweige wird keine Abwärtskompatibilität mit einer bestehenden Anwendung garantiert. Ebenfalls zu beachten: Selbst wenn der Anwendungscode in der neuen Plattformversion erfolgreich bereitgestellt wird, kann er sich aufgrund von Betriebssystem- und Laufzeitunterschieden möglicherweise anders verhalten.

Obwohl Amazon Linux AMI und AL2023/AL2 den gleichen Linux-Kernel teilen, unterscheiden sie sich in folgenden Aspekten: im Initialisierungssystem, in den libc-Versionen, in der Compiler-Toolkette und in verschiedenen Paketen. Weitere Informationen finden Sie unter Amazon Linux 2 – Häufig gestellte Fragen.

Beim Elastic-Beanstalk-Service wurden auch plattformspezifische Versionen von Laufzeit, Build-Tools und anderen Abhängigkeiten aktualisiert.

Daher empfehlen wir Ihnen, sich Zeit zu nehmen, Ihre Anwendung gründlich in einer Entwicklungsumgebung zu testen und notwendige Anpassungen vorzunehmen.

Allgemeiner Migrationsprozess

Wenn Sie für die Produktion bereit sind, erfordert Elastic Beanstalk eine Blau/Grün-Bereitstellung, um das Upgrade durchzuführen. Im Folgenden finden Sie die allgemeinen bewährten Schritte, die für die Migration mit einem Blau/Grün-Bereitstellungsverfahren empfohlen werden.

Vorbereitung der Tests für die Migration

Bevor Sie die Anwendung bereitstellen und mit dem Testen beginnen, sollten Sie sich die Informationen im Abschnitt Überlegungen für alle Linux-Plattformen weiter unten in diesem Thema durchlesen. Lesen Sie außerdem die für Ihre Plattform geltenden Informationen im folgenden Abschnitt Plattformspezifische Überlegungen. Notieren Sie sich die spezifischen Informationen, die (möglicherweise) für Ihre Anwendung und Konfiguration gelten.

Übergeordnete Migrationsschritte

  1. Erstellen Sie eine neue Umgebung, die auf einem AL2- oder AL2023-Plattformzweig basiert. Es wird empfohlen, zu einem AL2023-Plattformzweig zu migrieren.

  2. Stellen Sie die Anwendung in der AL2023/AL2-Zielumgebung bereit.

    Ihre vorhandene Produktionsumgebung bleibt aktiv und unberührt, während Sie Tests durchführen und Anpassungen an der neuen Umgebung vornehmen.

  3. Testen Sie die Anwendung gründlich in der neuen Umgebung.

  4. Wenn die neue AL2023/AL2-Zielumgebung bereit für die Produktion ist, tauschen Sie die CNAMEs der beiden Umgebungen aus, um den Datenverkehr an die neue Umgebung umzuleiten.

Detailliertere Migrationsschritte und bewährte Methoden

Ein detaillierteres Blau/Grün-Bereitstellungsverfahren finden Sie unter Blau/Grün-Bereitstellungen mit Elastic Beanstalk.

Spezifischere Anleitungen und detaillierte bewährte Schritte finden Sie unter Blau/Grün-Methode.

Weitere Referenzen zur Planung der Migration

Die folgenden Referenzen können zusätzliche Informationen zur Planung der Migration bieten.

Überlegungen für alle Linux-Plattformen

In der folgenden Tabelle werden Überlegungen angestellt, die Sie bei der Planung einer Anwendungsmigration zu AL2023/AL2 beachten sollten. Diese Überlegungen gelten für alle Elastic-Beanstalk-Linux-Plattformen, unabhängig von bestimmten Programmiersprachen oder Anwendungsservern.

Area Änderungen und Informationen

Konfigurationsdateien

Auf AL2023/AL2-Plattformen können Sie Konfigurationsdateien wie gewohnt verwenden und alle Abschnitte funktionieren auf die gleiche Weise. Bestimmte Einstellungen funktionieren jedoch möglicherweise nicht so wie bei früheren Amazon-Linux-AMI-Plattformen. Beispiele:

  • Einige Softwarepakete, die Sie mit einer Konfigurationsdatei installieren, sind unter Umständen auf AL2023/AL2 nicht verfügbar oder ihre Namen haben sich möglicherweise geändert.

  • Einige plattformspezifische Konfigurationsoptionen wurden von ihren plattformspezifischen Namespaces in andere plattformunabhängige Namespaces verschoben.

  • Proxy-Konfigurationsdateien, die im Verzeichnis .ebextensions/nginx bereitgestellt werden, sollten in das Plattform-Hooks-Verzeichnis .platform/nginx verschoben werden. Für Details erweitern Sie den Abschnitt Reverse-Proxy-Konfiguration unter Erweitern von Elastic Beanstalk-Linux-Plattformen.

Wir raten zur Verwendung von Plattform-Hooks für die Ausführung von benutzerdefiniertem Code auf Ihren Umgebungs-Instances. Sie können in .ebextensions-Konfigurationsdateien weiterhin Befehle und Containerbefehle verwenden, aber sie sind nicht mehr so einfach in der Verwendung. Beispielsweise kann das Schreiben von Befehlsskripten in einer YAML-Datei umständlich und schwer zu testen sein.

Sie müssen weiterhin .ebextensions-Konfigurationsdateien für jedes Skript verwenden, das einen Verweis auf eine AWS CloudFormation-Ressource benötigt.

Plattform-Hooks

AL2-Plattformen bieten eine neue Möglichkeit, die Plattform Ihrer Umgebung zu erweitern, indem ausführbare Dateien zu Hook-Verzeichnissen auf den Instances der Umgebung hinzugefügt werden. Bei früheren Linux-Plattformversionen haben Sie möglicherweise benutzerdefinierte Plattform-Hooks verwendet. Diese Hooks wurden nicht für verwaltete Plattformen entwickelt und wurden nicht unterstützt, konnten aber in einigen Fällen auf nützliche Weise funktionieren. Bei AL2023/AL2-Plattformversionen funktionieren keine benutzerdefinierten Plattform-Hooks. Sie sollten alle Hooks auf die neuen Plattform-Hooks migrieren. Details erhalten Sie im Abschnitt Plattform-Hooks in Erweitern von Elastic Beanstalk-Linux-Plattformen.

Unterstützte Proxy-Server

AL2023/AL2-Plattformversionen unterstützen die gleichen Reverse-Proxy-Server wie jede Plattform, die in den entsprechenden Amazon-Linux-AMI Plattformversionen unterstützt wird. Alle AL2023/AL2-Plattformversionen nutzen nginx als standardmäßigen Reverse-Proxy-Server, mit Ausnahme der ECS- und Docker-Plattformen. Die Plattformen Tomcat, Node.js, PHP und Python unterstützen ebenfalls Apache HTTPD als Alternative. Alle Plattformen ermöglichen eine einheitliche Konfiguration des Proxy-Servers wie in diesem Abschnitt beschrieben. Die Konfiguration des Proxy-Servers ist jedoch ein wenig anders als auf dem Amazon-Linux-AMI. Dies sind die Unterschiede für alle Plattformen:

  • Standard ist nginx – Der Standard-Proxy-Server für alle AL2023/AL2-Plattformversionen ist nginx. Bei Amazon-Linux-AMI-Plattformversionen von Tomcat, PHP und Python war der Standard-Proxy-Server Apache HTTPD.

  • Konsistenter Namespace – Alle AL2023/AL2-Plattformversionen nutzen den Namespace aws:elasticbeanstalk:environment:proxy, um den Proxy-Server zu konfigurieren. Bei Amazon-Linux-AMI-Plattformversionen war dies eine Entscheidung pro Plattform und Node.js verwendete einen anderen Namespace.

  • Speicherort der Konfigurationsdatei – Sie sollten Proxy-Konfigurationsdateien bei allen AL2023/AL2-Plattformversionen in den Verzeichnissen .platform/nginx und .platform/httpd ablegen. Auf Amazon-Linux-AMI-Plattformversionen waren diese Speicherorte .ebextensions/nginx bzw. .ebextensions/httpd.

Informationen zu plattformspezifischen Proxy-Konfigurationsänderungen finden Sie unter Plattformspezifische Überlegungen. Um weitere Informationen zur Proxy-Konfiguration auf AL2023/AL2-Plattformen zu erhalten, erweitern Sie den Abschnitt Reverse-Proxy-Konfiguration unter Erweitern von Elastic Beanstalk-Linux-Plattformen.

Proxy-Konfigurationsänderungen

Einige Änderungen an der Proxy-Konfiguration gelten einheitlich für alle Plattformen, zusätzlich zu den plattformspezifischen Änderungen der Proxy-Konfiguration. Es ist wichtig, sich auf beide zu beziehen, damit Ihre Umgebungen genau konfiguriert werden können.

Instance-Profil

Bei AL2023/AL2-Plattformen muss ein Instance-Profil konfiguriert werden. Die Umgebung wird ohne Profil möglicherweise zunächst erfolgreich erstellt, kurz nach der Erstellung können in der Umgebung aber Fehler auftreten, wenn Aktionen, die ein Instance-Profil erfordern, fehlschlagen. Details hierzu finden Sie unter Elastic Beanstalk Instance-Profile verwalten.

Erweiterter Zustand

AL2023/AL2-Plattformversionen ermöglichen standardmäßig eine bessere Integrität. Dies ist eine Änderung, wenn Sie nicht die Elastic-Beanstalk-Konsole zum Erstellen von Umgebungen verwenden. Die Konsole ermöglicht standardmäßig möglichst eine erweiterte Integrität, unabhängig von der Plattformversion. Details hierzu finden Sie unter Erweiterte Zustandsberichte und Überwachung.

Benutzerdefiniertes AMI

Wenn Ihre Umgebung ein benutzerdefiniertes AMI verwendet, erstellen Sie mithilfe einer Amazon-Linux-2-Plattform für Elastic Beanstalk ein neues, auf AL2023/AL2 basierendes AMI für die neue Umgebung.

Benutzerdefinierte Plattformen

Die verwalteten AMIs der AL2023/AL2-Plattformversionen unterstützen keine benutzerdefinierten Plattformen.

Plattformspezifische Überlegungen

In diesem Abschnitt werden Migrationsüberlegungen behandelt, die für bestimmte Elastic-Beanstalk-Linux-Plattformen spezifisch sind.

Die Docker-Plattformzweigfamilie auf Basis von Amazon Linux AMI (AL1) umfasst drei Plattformzweige. Für jede empfiehlt sich ein anderer Migrationspfad.

AL1-Plattformzweig Migrationspfad zu AL2023/AL2

Multi-Container-Docker (verwaltet von Amazon ECS) auf Amazon Linux AMI (AL1)
ECS-basierte Docker-AL2023/AL2-Plattformzweige

Die ECS-basierten Docker-AL2023/AL2-Plattformzweige bieten einen unkomplizierten Migrationspfad für Umgebungen, die auf dem Plattformzweig Multi-Container-Docker auf AL1 ausgeführt werden.

  • Wie der vorherige Zweig Multi-Container-Docker auf AL1 nutzen die AL2023/AL2-Plattformzweige Amazon ECS, um die Bereitstellung mehrerer Docker-Container in einem Amazon-ECS-Cluster in einer Elastic-Beanstalk-Umgebung zu koordinieren.

  • Die AL2023/AL2-Plattformzweige unterstützen alle Funktionen des vorherigen Zweigs Multi-Container-Docker auf AL1.

  • Außerdem unterstützen die AL2023/AL2-Plattformzweige die gleiche Datei Dockerrun.aws.json v2.

Weitere Informationen zum Migrieren von Anwendungen auf dem Plattformzweig Multi-Container-Docker auf Amazon Linux zum Plattformzweig Amazon ECS auf AL2023/AL2 finden Sie unter Migrieren von Multi-Container-Docker auf Amazon Linux zu ECS auf Amazon Linux 2023.

Docker auf Amazon Linux AMI (AL1)

Vorkonfigurierter Docker (Glassfish 5.0) auf Amazon Linux AMI (AL1)
Plattformzweig Docker auf AL2023/AL2

Es wird empfohlen, Ihre Anwendungen zu migrieren, wenn sie in Umgebungen ausgeführt werden, die auf dem vorkonfigurierten Docker (Glassfish 5.0) oder Docker auf Amazon Linux AMI (AL1) basieren. Die Migration erfolgt dann zu Umgebungen, die auf dem Plattformzweig Docker auf Amazon Linux 2 oder Docker auf AL2023 basieren.

Wenn Ihre Umgebung auf dem Plattformzweig mit vorkonfiguriertem Docker (Glassfish 5.0) basiert, siehe Bereitstellen einer GlassFish-Anwendung auf der Docker-Plattform: Migrationspfad zu Amazon Linux 2023.

In der folgenden Tabelle werden Migrationsinformationen für den Plattformzweig Docker auf AL2023/AL2 aufgelistet.

Area Änderungen und Informationen

Speicher

Elastic Beanstalk konfiguriert Docker so, dass Speichertreiber zum Speichern von Docker-Images und Containerdaten verwendet werden. Auf Amazon-Linux-AMI verwendete Elastic Beanstalk den Device Mapper storage driver (Device Mapper-Speichertreiber). Um die Leistung zu verbessern, stellte Elastic Beanstalk ein zusätzliches Amazon-EBS-Volume bereit. Bei AL2023/AL2-Docker-Plattformversionen nutzt Elastic Beanstalk den OverlayFS-Speichertreiber und erzielt eine noch bessere Leistung, ohne dass ein weiteres separates Volume benötigt wird.

Wenn Sie mit Amazon-Linux-AMI die Option BlockDeviceMappings des Namespace aws:autoscaling:launchconfiguration verwendet haben, um benutzerdefinierte Speicher-Volume zu einer Docker-Umgebung hinzuzufügen, haben wir Ihnen empfohlen, auch das Amazon-EBS-Volume /dev/xvdcz hinzuzufügen, das durch Elastic Beanstalk bereitgestellt wurde. Elastic Beanstalk stellt dieses Volume nicht mehr bereit, daher sollten Sie es aus Ihren Konfigurationsdateien entfernen. Details hierzu finden Sie unter Docker-Konfiguration auf Amazon Linux AMI (Vorgängerversion von Amazon Linux 2).

Private Repository-Authentifizierung

Wenn Sie eine Docker-generierte Authentifizierungsdatei bereitstellen, um eine Verbindung mit einem privaten Repository herzustellen, müssen Sie sie nicht mehr in das ältere Format konvertieren, das für das die Amazon-Linux-AMI-Docker-Plattformversionen erforderlich ist. AL2023/AL2-Docker-Plattformversionen unterstützen das neue Format. Details hierzu finden Sie unter Verwenden von Images aus einem privaten Repository.

Proxy-Server

AL2023/AL2-Docker-Plattformversionen unterstützen keine eigenständigen Container, die nicht hinter einem Proxy-Server ausgeführt werden. Bei Amazon-Linux-AMI-Docker-Plattformversionen war dies früher durch den Wert none der Option ProxyServer im Namespace aws:elasticbeanstalk:environment:proxy möglich.

In der folgenden Tabelle werden Migrationsinformationen für die AL2023/AL2-Plattformversionen auf der Go-Plattform aufgelistet.

Area Änderungen und Informationen

Übergeben eines Portwertes

Elastic Beanstalk übergibt auf AL2023/AL2-Plattformen keinen Portwert über die Umgebungsvariable PORT an den Anwendungsprozess. Sie können dieses Verhalten für Ihren Prozess simulieren, indem Sie eine PORT-Umgebungseigenschaft selbst konfigurieren. Wenn Sie jedoch mehrere Prozesse haben und darauf zählen, dass Elastic Beanstalk inkrementelle Portwerte an Ihre Prozesse übergibt (5000, 5100, 5200 usw.), sollten Sie Ihre Implementierung ändern. Für Details erweitern Sie den Abschnitt Reverse-Proxy-Konfiguration unter Erweitern von Elastic Beanstalk-Linux-Plattformen.

In der folgenden Tabelle werden Migrationsinformationen für die Corretto-Plattformzweige in der Java SE-Plattform aufgelistet.

Area Änderungen und Informationen

Corretto gegen OpenJDK

Zur Implementierung der Java Platform Standard Edition (Java SE) nutzen AL2023/AL2-Plattformzweige Amazon Corretto, eine AWS-Distribution des Open Java Development Kit (OpenJDK). Frühere Elastic-Beanstalk-Java-SE-Plattformzweige verwenden die in Amazon-Linux-AMI enthaltenen OpenJDK-Pakete.

Build-Tools

AL2023/AL2-Plattformen verfügen über neuere Versionen der Build-Tools: gradle, maven und ant.

JAR-Dateibehandlung

Wenn das Quell-Bundle (ZIP-Datei) auf AL2023/AL2-Plattformen eine einzelne JAR-Datei und keine anderen Dateien enthält, benennt Elastic Beanstalk die JAR-Datei nicht mehr in application.jar um. Die Umbenennung erfolgt nur, wenn Sie eine JAR-Datei alleine und nicht innerhalb einer ZIP-Datei übermitteln.

Übergeben eines Portwertes

Elastic Beanstalk übergibt auf AL2023/AL2-Plattformen keinen Portwert über die Umgebungsvariable PORT an den Anwendungsprozess. Sie können dieses Verhalten für Ihren Prozess simulieren, indem Sie eine PORT-Umgebungseigenschaft selbst konfigurieren. Wenn Sie jedoch mehrere Prozesse haben und darauf zählen, dass Elastic Beanstalk inkrementelle Portwerte an Ihre Prozesse übergibt (5000, 5100, 5200 usw.), sollten Sie Ihre Implementierung ändern. Für Details erweitern Sie den Abschnitt Reverse-Proxy-Konfiguration unter Erweitern von Elastic Beanstalk-Linux-Plattformen.

Java 7

Elastic Beanstalk unterstützt keinen AL2023/AL2-Java-7-Plattformzweig. Wenn Sie eine Java 7-Anwendung haben, migrieren Sie sie auf Corretto 8 oder Corretto 11.

In der folgenden Tabelle werden Migrationsinformationen für die AL2023/AL2-Plattformversionen auf der Tomcat-Plattform aufgelistet.

Area Änderungen und Informationen

Konfigurationsoptionen

Bei AL2023/AL2-Plattformversionen unterstützt Elastic Beanstalk nur eine Teilmenge der Konfigurationsoptionen und Optionswerte im Namespace aws:elasticbeanstalk:environment:proxy. Im Folgenden finden Sie Informationen zur Migration für die einzelnen Optionen.

Option Informationen zur Migration

GzipCompression

Wird bei AL2023/AL2-Plattformversionen nicht unterstützt.

ProxyServer

AL2023/AL2-Tomcat-Plattformversionen unterstützen die Proxy-Server nginx und Apache HTTPD 2.4. Apache Version 2.2 wird jedoch nicht unterstützt.

Bei Amazon-Linux-AMI-Plattformversionen war der Standard-Proxy Apache 2.4. Wenn Sie die Standard-Proxy-Einstellung verwendet und benutzerdefinierte Proxy-Konfigurationsdateien hinzugefügt haben, sollte die Proxy-Konfiguration auf AL2023/AL2 weiterhin funktionieren. Wenn Sie jedoch den Optionswert apache/2.2 verwendet haben, müssen Sie nun Ihre Proxy-Konfiguration auf Apache Version 2.4 migrieren.

Die Option XX:MaxPermSize im Namespace aws:elasticbeanstalk:container:tomcat:jvmoptions wird bei AL2023/AL2-Plattformversionen nicht unterstützt. Die JVM-Einstellung zum Ändern der Größe der permanenten Generation gilt nur für Java 7 und früher und gilt daher nicht für AL2023/AL2-Plattformversionen.

Anwendungspfad.

Auf AL2023/AL2-Plattformen lautet der Pfad zum Verzeichnis der Anwendung auf Amazon-EC2-Instances Ihrer Umgebung /var/app/current. Auf Amazon-Linux-AMI-Plattformen lautete er /var/lib/tomcat8/webapps.

In der folgenden Tabelle werden Migrationsinformationen für die AL2023/AL2-Plattformversionen auf der Node.js-Plattform aufgelistet.

Area Änderungen und Informationen

Installierte Node.js-Versionen

Elastic Beanstalk verwaltet auf AL2023/AL2-Plattformen mehrere Node.js-Plattformzweige und installiert auf den einzelnen Plattformversionen nur die jeweils neueste Version der Node.js-Hauptversion für den Plattformzweig. Beispielsweise wird für jede Plattformversion im Node.js 12-Plattformzweig standardmäßig nur Node.js 12.x.y installiert. Im Fall von Amazon-Linux-AMI-Plattformversionen sind auf jeder Plattformversion die verschiedenen Versionen der verschiedenen Node.js-Versionen installiert und es wird nur ein einziger Plattformzweig gewartet.

Wählen Sie den Node.js-Plattformzweig für die Node.js-Hauptversion aus, die Ihre Anwendung benötigt.

Apache HTTPD-Protokolldateinamen

Wenn Sie auf AL2023/AL2-Plattformen den Proxy-Server Apache HTTPD verwenden, heißen die HTTPD-Protokolldateien access_log und error_log, was mit allen anderen Plattformen konsistent ist, die Apache HTTPD unterstützen. Auf Amazon-Linux-AMI-Plattformversionen hießen diese Protokolldateien access.log bzw. error.log.

Weitere Details zu Namen und Speicherorten von Protokolldateien für alle Plattformen finden Sie unter Wie Elastic Beanstalk CloudWatch Logs einrichtet.

Konfigurationsoptionen

Auf AL2023/AL2-Plattformen unterstützt Elastic Beanstalk die Konfigurationsoptionen im Namespace aws:elasticbeanstalk:container:nodejs nicht. Für einige Optionen gibt es Alternativen. Im Folgenden finden Sie Informationen zur Migration für die einzelnen Optionen.

Option Informationen zur Migration

NodeCommand

Verwenden Sie ein Procfile oder das Schlüsselwort scripts in einer package.json-Datei, um das Startskript anzugeben.

NodeVersion

Verwenden Sie in einer package.json-Datei das Schlüsselwort engines, um die Node.js-Version anzugeben. Beachten Sie, dass Sie jeweils nur eine Node.js-Version angeben können, die Ihrem Plattformzweig entspricht. Wenn Sie beispielsweise den Plattformzweig Node.js 12 verwenden, können Sie nur eine 12.x.y Node.js-Version angeben. Details hierzu finden Sie unter Angeben von Node.js-Abhängigkeiten mit einer package.json-Datei.

GzipCompression

Wird bei AL2023/AL2-Plattformversionen nicht unterstützt.

ProxyServer

Bei AL2023/AL2-Node.js-Plattformversionen wurde diese Option in den Namespace aws:elasticbeanstalk:environment:proxy verschoben. Sie können zwischen nginx (Standardeinstellung) und apache wählen.

Darüber hinaus unterstützen AL2023/AL2-Node.js-Plattformversionen keine eigenständigen Anwendungen, die nicht hinter einem Proxy-Server ausgeführt werden. Bei Amazon-Linux-AMI-Node.js-Plattformversionen war dies früher durch den Wert none der Option ProxyServer im Namespace aws:elasticbeanstalk:container:nodejs möglich. Wenn in Ihrer Umgebung eine eigenständige Anwendung ausgeführt wird, aktualisieren Sie den Code so, dass dem Port zugehört wird, an den der Proxy-Server (nginx oder Apache) den Datenverkehr weiterleitet.

var port = process.env.PORT || 5000;

app.listen(port, function() {
  console.log('Server running at http://127.0.0.1:%s', port);
});

In der folgenden Tabelle werden Migrationsinformationen für die AL2023/AL2-Plattformversionen auf der PHP-Plattform aufgelistet.

Area Änderungen und Informationen

PHP-Dateiverarbeitung

Auf AL2023/AL2-Plattformen werden PHP-Dateien mit PHP-FPM (einem CGI-Prozessmanager) verarbeitet. Auf Amazon-Linux-AMI-Plattformen wird mod_php (ein Apache-Modul) verwendet.

Proxy-Server

AL2023/AL2-PHP-Plattformversionen unterstützen die Proxy-Server nginx und Apache HTTPD. Standardmäßig wird nginx verwendet.

Amazon-Linux-AMI-PHP-Plattformversionen unterstützten nur Apache HTTPD. Wenn Sie benutzerdefinierte Apache-Konfigurationsdateien hinzugefügt haben, können Sie die Option ProxyServer im Namespace aws:elasticbeanstalk:environment:proxy auf apache festlegen.

In der folgenden Tabelle werden Migrationsinformationen für die AL2023/AL2-Plattformversionen auf der Python-Plattform aufgelistet.

Area Änderungen und Informationen

WSGI-Server

Auf AL2023/AL2-Plattformen ist Gunicorn der Standard-WSGI-Server. Standardmäßig überwacht Gunicorn Port 8000. Der Port kann sich von dem unterscheiden, den Ihre Anwendung auf der Amazon-Linux-AMI-Plattform verwendet hat. Wenn Sie die WSGIPath-Option des aws:elasticbeanstalk:container:python-Namespace festlegen, ersetzen Sie den Wert durch die Syntax von Gunicorn. Details hierzu finden Sie unter Namespaces der Python-Konfiguration.

Alternativ können Sie einen Procfile verwenden, um den WSGI-Server anzugeben und zu konfigurieren. Details hierzu finden Sie unter Konfigurieren des WSGI-Servers mit einer Procfile-Datei.

Anwendungspfad.

Auf AL2023/AL2-Plattformen lautet der Pfad zum Verzeichnis der Anwendung auf Amazon-EC2-Instances Ihrer Umgebung /var/app/current. Auf Amazon-Linux-AMI-Plattformen lautete er /opt/python/current/app.

Proxy-Server

AL2023/AL2-Python-Plattformversionen unterstützen die Proxy-Server nginx und Apache HTTPD. Standardmäßig wird nginx verwendet.

Amazon-Linux-AMI-Python-Plattformversionen unterstützten nur Apache HTTPD. Wenn Sie benutzerdefinierte Apache-Konfigurationsdateien hinzugefügt haben, können Sie die Option ProxyServer im Namespace aws:elasticbeanstalk:environment:proxy auf apache festlegen.

In der folgenden Tabelle werden Migrationsinformationen für die AL2023/AL2-Plattformversionen auf der Ruby-Plattform aufgelistet.

Area Änderungen und Informationen

Installierte Ruby-Versionen

Auf AL2023/AL2-Plattformen installiert Elastic Beanstalk bei den einzelnen Plattformversionen nur die neueste Version einer einzelnen Ruby-Version für den betreffenden Plattformzweig. Beispielsweise ist auf den einzelnen Plattformversionen im Ruby 2.6-Plattformzweig nur Ruby 2.6.x installiert. Auf Amazon-Linux-AMI-Plattformversionen sind die neuesten Versionen mehrerer Ruby-Versionen installiert, z. B. 2.4.x, 2.5.x und 2.6.x.

Wenn Ihre Anwendung eine Ruby-Version verwendet, die nicht dem von Ihnen verwendeten Plattformzweig entspricht, sollten Sie zu einem Plattformzweig wechseln, auf dem die richtige Ruby-Version für Ihre Anwendung installiert ist.

Anwendungsserver

Auf AL2023/AL2-Plattformen installiert Elastic Beanstalk bei allen Ruby-Plattformversionen ausschließlich den Puma-Anwendungsserver. Sie können eine Procfile-Datei verwenden, um einen anderen Anwendungsserver zu starten, und eine, Gemfile-Datei, um ihn zu installieren.

Auf der Amazon-Linux-AMI-Plattform werden zwei Varianten von Plattformzweigen für jede Ruby-Version unterstützt – Variante mit dem Puma-Anwendungsserver und eine Variante mit dem Passenger-Anwendungsserver. Wenn Ihre Anwendung Passenger verwendet, können Sie Ihre Ruby-Umgebung für die Installation und Verwendung von Passenger konfigurieren.

Weitere Informationen und Beispiele finden Sie unter Verwenden der Elastic Beanstalk-Ruby-Plattform.