AWS App Runner wird ab dem 30. April 2026 nicht mehr für Neukunden geöffnet sein. Wenn Sie App Runner verwenden möchten, melden Sie sich vor diesem Datum an. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter [Änderung der AWS App Runner Verfügbarkeit](https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html). 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. # App Runner-Dienst basiert auf Quellcode *Sie können AWS App Runner damit Dienste erstellen und verwalten, die auf zwei grundlegend unterschiedlichen Typen von Dienstquellen basieren: *Quellcode und Quell-Image*.* Unabhängig vom Quelltyp kümmert sich App Runner um das Starten, Ausführen, Skalieren und den Lastenausgleich Ihres Dienstes. Sie können die CI/CD Funktionen von App Runner nutzen, um Änderungen an Ihrem Quell-Image oder Code nachzuverfolgen. Wenn App Runner eine Änderung entdeckt, erstellt es automatisch die neue Version (für den Quellcode) und stellt sie für Ihren App Runner-Dienst bereit. In diesem Kapitel werden Dienste beschrieben, die auf Quellcode basieren. Informationen zu Diensten, die auf einem Quell-Image basieren, finden Sie unter[App Runner-Dienst, der auf einem Quellbild basiert](service-source-image.md). Quellcode ist Anwendungscode, den App Runner für Sie erstellt und bereitstellt. Sie verweisen App Runner auf ein [Quellverzeichnis](#service-source-code.source-directory) in einem Code-Repository und wählen eine geeignete *Laufzeit* aus, die einer Programmierplattformversion entspricht. App Runner erstellt ein Image, das auf dem Basis-Image der Runtime und Ihrem Anwendungscode basiert. Anschließend wird ein Dienst gestartet, der einen auf diesem Image basierenden Container ausführt. App Runner bietet praktische plattformspezifische *verwaltete* Laufzeiten. Jede dieser Laufzeiten erstellt ein Container-Image aus Ihrem Quellcode und fügt Ihrem Image Laufzeitabhängigkeiten hinzu. Sie müssen keine Container-Konfiguration und keine Build-Anweisungen wie ein Dockerfile angeben. In den Unterthemen dieses Kapitels werden die verschiedenen Plattformen behandelt, die App Runner unterstützt — *verwaltete Plattformen, die verwaltete* Laufzeiten für verschiedene Programmierumgebungen und Versionen bereitstellen. **Topics** + [Anbieter von Quellcode-Repositorys](#service-source-code.providers) + [Quellverzeichnis](#service-source-code.source-directory) + [Von App Runner verwaltete Plattformen](#service-source-code.managed-platforms) + [Ende der Unterstützung für verwaltete Runtime-Versionen](#service-source-code.managed-platforms.eos) + [Verwaltete Runtime-Versionen und der App Runner-Build](#service-source-code.build-detail) + [Verwenden der Python-Plattform von](service-source-code-python.md) + [Verwenden der Node.js-Plattform von](service-source-code-nodejs.md) + [Verwendung der Java-Plattform](service-source-code-java.md) + [Verwenden der -.NET-Plattform](service-source-code-net6.md) + [Verwenden der -PHP-Plattform](service-source-code-php.md) + [Verwenden der -Ruby-Plattform](service-source-code-ruby.md) + [Verwenden der Go-Plattform von](service-source-code-go1.md) ## Anbieter von Quellcode-Repositorys App Runner stellt Ihren Quellcode bereit, indem er ihn aus einem Quellcode-Repository liest. App Runner unterstützt zwei Quellcode-Repository-Anbieter: [GitHub](https://github.com/)und [Bitbucket](https://bitbucket.org/). ### Bereitstellung über Ihren Quellcode-Repository-Anbieter Um Ihren Quellcode aus einem Quellcode-Repository für einen App Runner-Dienst bereitzustellen, stellt App Runner eine Verbindung zu diesem Dienst her. Wenn Sie die App Runner-Konsole verwenden, um [einen Dienst zu erstellen](manage-create.md), geben Sie Verbindungsdetails und ein Quellverzeichnis für App Runner an, um Ihren Quellcode bereitzustellen. **Verbindungen** Sie geben Verbindungsdetails im Rahmen der Diensterstellung an. Wenn Sie die App Runner-API oder die verwenden AWS CLI, ist eine Verbindung eine separate Ressource. Zunächst erstellen Sie die Verbindung mithilfe der [CreateConnection](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateConnection.html)API-Aktion. Anschließend geben Sie den ARN der Verbindung während der Diensterstellung mithilfe der [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API-Aktion an. **Quellverzeichnis** Wenn Sie einen Service erstellen, geben Sie auch ein Quellverzeichnis an. Standardmäßig verwendet App Runner das Stammverzeichnis Ihres Repositorys als Quellverzeichnis. Das Quellverzeichnis ist der Speicherort in Ihrem Quellcode-Repository, in dem der Quellcode und die Konfigurationsdateien Ihrer Anwendung gespeichert werden. Die Befehle build und start werden ebenfalls vom Quellverzeichnis aus ausgeführt. Wenn Sie die App Runner-API oder die verwenden AWS CLI , um einen Service zu erstellen oder zu aktualisieren, geben Sie das Quellverzeichnis in den Aktionen [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)und der [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API an. Weitere Informationen finden Sie im nachfolgenden [Quellverzeichnis](#service-source-code.source-directory)-Abschnitt. Weitere Informationen zur Erstellung des App Runner-Dienstes finden Sie unter[Einen App Runner-Dienst erstellen](manage-create.md). Weitere Informationen zu App Runner-Verbindungen finden Sie unter[App Runner-Verbindungen verwalten](manage-connections.md). ## Quellverzeichnis Wenn Sie einen App Runner-Dienst erstellen, können Sie das Quellverzeichnis zusammen mit dem Repository und dem Branch angeben. Setzen Sie den Wert des Felds **Quellverzeichnis** auf den Repository-Verzeichnispfad, in dem der Quellcode und die Konfigurationsdateien der Anwendung gespeichert sind. App Runner führt die Befehle Build und Start über den von Ihnen angegebenen Quellverzeichnispfad aus. Geben Sie den Wert für den Quellverzeichnispfad als absoluten Wert aus dem Stammverzeichnis des Repositorys ein. Wenn Sie keinen Wert angeben, wird standardmäßig das Verzeichnis der obersten Ebene des Repositorys verwendet, das auch als Repository-Stammverzeichnis bezeichnet wird. Sie haben auch die Möglichkeit, neben dem Repository-Verzeichnis der obersten Ebene auch andere Quellverzeichnispfade anzugeben. Dies unterstützt eine Monorepo-Repository-Architektur, was bedeutet, dass der Quellcode für mehrere Anwendungen in einem Repository gespeichert wird. Um mehrere App Runner-Dienste von einem einzigen Monorepo aus zu erstellen und zu unterstützen, geben Sie bei der Erstellung der einzelnen Dienste unterschiedliche Quellverzeichnisse an. **Anmerkung** Wenn Sie dasselbe Quellverzeichnis für mehrere App Runner-Dienste angeben, werden beide Dienste einzeln bereitgestellt und ausgeführt. Wenn Sie sich dafür entscheiden, eine `apprunner.yaml` Konfigurationsdatei zur Definition Ihrer Serviceparameter zu verwenden, platzieren Sie diese im Quellverzeichnisordner des Repositorys. Wenn die Option „**Deployment-Trigger**“ auf „**Automatisch**“ gesetzt ist, lösen die Änderungen, die Sie im Quellverzeichnis vornehmen, eine automatische Bereitstellung aus. * Nur die Änderungen im Quellverzeichnispfad* lösen eine automatische Bereitstellung aus. Es ist wichtig zu verstehen, wie sich der Speicherort des Quellverzeichnisses auf den Umfang einer automatischen Bereitstellung auswirkt. Weitere Informationen finden Sie unter *Automatisierte Bereitstellungen unter[Bereitstellungsmethoden](manage-deploy.md#manage-deploy.methods).* **Anmerkung** Wenn Ihr App Runner-Dienst die verwalteten PHP-Runtimes verwendet und Sie ein anderes Quellverzeichnis als das Standard-Root-Repository angeben möchten, ist es wichtig, die richtige PHP-Laufzeitversion zu verwenden. Weitere Informationen finden Sie unter [Verwenden der -PHP-Plattform](service-source-code-php.md). ## Von App Runner verwaltete Plattformen Von App Runner verwaltete Plattformen bieten verwaltete Laufzeiten für verschiedene Programmierumgebungen. Jede verwaltete Laufzeit macht es einfach, Container zu erstellen und auszuführen, die auf einer Version einer Programmiersprache oder Laufzeitumgebung basieren. Wenn Sie eine verwaltete Runtime verwenden, startet App Runner mit einem verwalteten Runtime-Image. Dieses Image basiert auf dem [Amazon Linux Docker-Image](https://hub.docker.com/_/amazonlinux) und enthält ein Sprach-Runtime-Paket sowie einige Tools und beliebte Abhängigkeitspakete. App Runner verwendet dieses verwaltete Runtime-Image als Basis-Image und fügt Ihren Anwendungscode hinzu, um ein Docker-Image zu erstellen. Anschließend wird dieses Image bereitgestellt, um Ihren Webservice in einem Container auszuführen. Sie geben eine Laufzeit für Ihren App Runner-Dienst an, wenn Sie [einen Dienst mithilfe der App Runner-Konsole oder des [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API-Vorgangs erstellen](manage-create.md). Sie können auch eine Laufzeit als Teil Ihres Quellcodes angeben. Verwenden Sie das `runtime` Schlüsselwort in einer [App Runner-Konfigurationsdatei](config-file.md), die Sie in Ihr Code-Repository aufnehmen. Die Benennungskonvention einer verwalteten Laufzeit lautet*

*. App Runner aktualisiert die Laufzeit für Ihren Dienst bei jeder Bereitstellung oder jedem Service-Update auf die neueste Version. Wenn Ihre Anwendung eine bestimmte Version einer verwalteten Laufzeit benötigt, können Sie diese mithilfe des `runtime-version` Schlüsselworts in der [App Runner-Konfigurationsdatei](config-file.md) angeben. Sie können sich auf eine beliebige Versionsebene beschränken, einschließlich einer Haupt- oder Nebenversion. App Runner aktualisiert die Laufzeit Ihres Dienstes nur auf niedrigerer Ebene. ## Ende der Unterstützung für verwaltete Runtime-Versionen Wenn der offizielle Anbieter oder die Community einer verwalteten Sprachlaufzeit eine Version offiziell als End of Life (EOL) deklariert, erklärt App Runner daraufhin den Versionsstatus auf *Ende* des Support. Wenn Ihr Service auf einer verwalteten Runtime-Version läuft, für die das Ende des Support erreicht ist, gelten die folgenden Richtlinien und Empfehlungen. **Ende des Support für eine Sprach-Runtime-Version:** + **Bestehende Dienste** werden weiterhin ausgeführt und Datenverkehr bereitgestellt, auch wenn sie eine Laufzeit verwenden, für die das Ende des Support erreicht ist. Sie werden jedoch auf Laufzeiten ausgeführt, die nicht unterstützt werden und für die keine Updates, Sicherheitspatches oder technischen Support mehr verfügbar sind. + **Updates für bestehende Dienste**, die End-of-Support-Laufzeiten verwenden, sind weiterhin zulässig, wir empfehlen jedoch nicht, die End-of-Support-Laufzeiten für einen Dienst weiterhin zu verwenden. + **Neue Dienste** können nicht mit den Laufzeiten erstellt werden, die das Ende des Support erreicht haben. **Erforderliche Aktionen für Sprach-Runtime-Versionen mit dem Status „Ende des Support“:** + Wenn Ihr Service **auf einem Quell-Image basiert**, sind für diesen Service keine weiteren Maßnahmen Ihrerseits erforderlich. + Wenn Ihr Service **auf Quellcode basiert**, aktualisieren Sie Ihre Servicekonfiguration, um eine unterstützte Runtime-Version zu verwenden. Wählen Sie dazu in der [App Runner-Konsole](https://console.aws.amazon.com/apprunner) eine unterstützte Runtime-Version aus, aktualisieren Sie das `runtime` Feld in der Konfigurationsdatei [apprunner.yaml](config-file.md) oder verwenden Sie die [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API-Operationen [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)/oder die IaC-Tools, um den Parameter festzulegen. `runtime` Eine Liste der unterstützten Laufzeiten finden Sie auf der Seite mit den *Release-Informationen* für jede bestimmte Laufzeit in diesem Kapitel. + Alternativ können Sie zur **Container-Image-Quellenoption** von App Runner wechseln. Weitere Details finden Sie unter [Bildbasierter Dienst](service-source-image.md). **Anmerkung** Wenn Sie von Node.js 12, 14 oder 16 zu **Node.js 22** oder von Python 3.7 oder 3.8 zu Python 3.11 wechseln, beachten Sie, dass Node.js 22 und **Python 3.11** einen überarbeiteten App Runner-Build-Prozess verwenden, der schnellere und effizientere Builds ermöglicht. Um die Kompatibilität vor dem Upgrade sicherzustellen, empfehlen wir Ihnen, die [Anleitungen zum Build-Prozess](#service-source-code.build-detail) im nächsten Abschnitt zu lesen. In der folgenden Tabelle sind die von App Runner verwalteten Runtime-Versionen aufgeführt, für die das Ende des Support festgelegt wurde. | **Runtime-Versionen** | **Datum des Endes des Support für App Runner** | | --- | --- | | Python 3.8 [Unterstützte Laufzeiten](service-source-code-python-releases.md) | 1. Dezember 2025 | | Python 3.7 [Unterstützte Laufzeiten](service-source-code-python-releases.md) | 1. Dezember 2025 | | Node.js 18 [Unterstützte Laufzeiten](service-source-code-nodejs-releases.md) | 1. Dezember 2025 | | Node.js 16 [Unterstützte Laufzeiten](service-source-code-nodejs-releases.md) | 1. Dezember 2025 | | Node.js 14 [Unterstützte Laufzeiten](service-source-code-nodejs-releases.md) | 1. Dezember 2025 | | Node.js 12 [Unterstützte Laufzeiten](service-source-code-nodejs-releases.md) | 1. Dezember 2025 | | .NET 6 \$1 | 1. Dezember 2025 | | PHP 8.1 \$1 | 31. Dezember 2025 | | Rubin 3.1 \$1 | 1. Dezember 2025 | | Gehe 1 \$1 | 1. Dezember 2025 | **\$1** App Runner wird keine neuen Sprachversionen für die mit einem Sternchen (\$1) markierten Laufzeiten veröffentlichen. Diese Laufzeiten sind die folgenden: .NET, PHP, Ruby und Go. Wenn Sie einen codebasierten Dienst für diese Laufzeiten konfiguriert haben, empfehlen wir eine der folgenden Aktionen: + Falls zutreffend, stellen Sie Ihre Dienstkonfiguration auf eine andere unterstützte verwaltete Laufzeit um. + Alternativ können Sie ein benutzerdefiniertes Container-Image mit Ihrer bevorzugten Runtime-Version erstellen und es mit der [Bildbasierter Dienst](service-source-image.md) Option von App Runner bereitstellen. Sie können Ihr Bild in Amazon ECR hosten. ## Verwaltete Runtime-Versionen und der App Runner-Build App Runner bietet einen aktualisierten Build-Prozess für Anwendungen, die auf den Laufzeiten der neueren Hauptversionen ausgeführt werden. Dieser überarbeitete Erstellungsprozess ist schneller und effizienter. Außerdem wird ein endgültiges Image mit geringerem Platzbedarf erstellt, das nur Ihren Quellcode, Build-Artefakte und Laufzeiten enthält, die für die Ausführung Ihrer Anwendung erforderlich sind. Wir bezeichnen den neueren Build-Prozess als den *überarbeiteten App Runner-Build* und den ursprünglichen Build-Prozess als den *ursprünglichen App Runner-Build*. Um grundlegende Änderungen an früheren Versionen von Runtime-Plattformen zu vermeiden, wendet App Runner den überarbeiteten Build nur auf bestimmte Runtime-Versionen an, in der Regel auf neu veröffentlichte Hauptversionen. Wir haben der `apprunner.yaml` Konfigurationsdatei eine neue Komponente hinzugefügt, um den überarbeiteten Build für einen ganz bestimmten Anwendungsfall abwärtskompatibel zu machen und um auch mehr Flexibilität bei der Konfiguration des Builds Ihrer Anwendung zu bieten. Dies ist der optionale [`pre-run`](config-file-ref.md#config-file-ref.run)Parameter. In den folgenden Abschnitten erklären wir, wann dieser Parameter zusammen mit anderen nützlichen Informationen zu den Builds verwendet werden sollte. Die folgende Tabelle zeigt, welche Version des App Runner-Builds für bestimmte verwaltete Runtime-Versionen gilt. Wir werden dieses Dokument weiterhin aktualisieren, um Sie über unsere aktuellen Laufzeiten auf dem Laufenden zu halten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code.html) **Anmerkung** Einige der aufgelisteten Laufzeiten beinhalten ein Datum, an dem **der Support endet**. Weitere Informationen finden Sie unter [Ende der Unterstützung für verwaltete Runtime-Versionen](#service-source-code.managed-platforms.eos). **Wichtig** **Python 3.11** — Wir haben spezifische Empfehlungen für die Build-Konfiguration von Diensten, die die verwaltete Python 3.11-Runtime verwenden. Weitere Informationen finden Sie [Callouts für bestimmte Runtime-Versionen](service-source-code-python.md#service-source-code-python.callouts) im Thema *Python-Plattform*. ### Weitere Informationen zu App Runner-Builds und -Migration Wenn Sie Ihre Anwendung auf eine neuere Runtime migrieren, die den überarbeiteten Build verwendet, müssen Sie möglicherweise Ihre Build-Konfiguration geringfügig ändern. Um den Kontext für Migrationsüberlegungen zu schaffen, beschreiben wir zunächst die allgemeinen Prozesse sowohl für den ursprünglichen App Runner-Build als auch für den überarbeiteten Build. Im Anschluss finden Sie einen Abschnitt, in dem spezifische Merkmale Ihres Dienstes beschrieben werden, für die möglicherweise einige Konfigurationsupdates erforderlich sind. #### Der ursprüngliche App Runner-Build Der ursprüngliche App Runner-Anwendungsentwicklungsprozess nutzt den AWS CodeBuild Service. Die ersten Schritte basieren auf Bildern, die vom Service kuratiert wurden. CodeBuild Es folgt ein Docker-Build-Prozess, der das entsprechende verwaltete Runtime-Image von App Runner als Basis-Image verwendet. Die allgemeinen Schritte sind die folgenden: 1. Führen Sie `pre-build` Befehle in einem CodeBuild -kuratierten Bild aus. Die `pre-build` Befehle sind optional. Sie können nur in der `apprunner.yaml` Konfigurationsdatei angegeben werden. 1. Führen Sie die `build` Befehle mit CodeBuild demselben Bild aus dem vorherigen Schritt aus. Die `build` Befehle sind erforderlich. Sie können in der App Runner-Konsole, der App Runner-API oder in der `apprunner.yaml` Konfigurationsdatei angegeben werden. 1. Führen Sie einen Docker-Build aus, um ein Image zu generieren, das auf dem von App Runner verwalteten Runtime-Image für Ihre spezifische Plattform und Laufzeitversion basiert. 1. Kopieren Sie das `/app` Verzeichnis aus dem Image, das wir in **Schritt 2** generiert haben. Das Ziel ist das Image, das auf dem von App Runner verwalteten Runtime-Image basiert, das wir in **Schritt 3** generiert haben. 1. Führen Sie die `build` Befehle erneut auf dem generierten, von App Runner verwalteten Runtime-Image aus. Wir führen die Build-Befehle erneut aus, um Build-Artefakte aus dem Quellcode in dem `/app` Verzeichnis zu generieren, das wir in **Schritt 4** in das Verzeichnis kopiert haben. Dieses Image wird später von App Runner bereitgestellt, um Ihren Webservice in einem Container auszuführen. Die `build` Befehle sind erforderlich. Sie können in der App Runner-Konsole, der App Runner-API oder in der `apprunner.yaml` Konfigurationsdatei angegeben werden. 1. Führen Sie die `post-build` Befehle im CodeBuild Bild aus **Schritt 2** aus. Die `post-build` Befehle sind optional. Sie können nur in der `apprunner.yaml` Konfigurationsdatei angegeben werden. Nach Abschluss des Builds stellt App Runner das generierte verwaltete Runtime-Image von App Runner aus **Schritt 5** bereit, um Ihren Webservice in einem Container auszuführen. #### Der überarbeitete App Runner-Build Der überarbeitete Build-Prozess ist schneller und effizienter als der ursprüngliche Build-Prozess, der im vorherigen Abschnitt beschrieben wurde. Dadurch entfällt die Duplizierung der Build-Befehle, die im Build der vorherigen Version aufgetreten sind. Außerdem wird ein endgültiges Image mit geringerem Platzbedarf erstellt, das nur Ihren Quellcode, Build-Artefakte und Laufzeiten enthält, die für die Ausführung Ihrer Anwendung erforderlich sind. Dieser Build-Prozess verwendet einen mehrstufigen Docker-Build. Die allgemeinen Prozessschritte sind die folgenden: 1. **Erstellungsphase** — Startet einen Docker-Build-Prozess, der `build` Befehle `pre-build` und Befehle auf den App Runner-Build-Images ausführt. 1. Kopieren Sie den Quellcode der Anwendung in das `/app` Verzeichnis. **Anmerkung** Dieses `/app` Verzeichnis wird in jeder Phase des Docker-Builds als Arbeitsverzeichnis bezeichnet. 1. `pre-build`-Befehle ausführen Die `pre-build` Befehle sind optional. Sie können nur in der `apprunner.yaml` Konfigurationsdatei angegeben werden. 1. Führen Sie die `build` Befehle aus. Die `build` Befehle sind erforderlich. Sie können in der App Runner-Konsole, der App Runner-API oder in der `apprunner.yaml` Konfigurationsdatei angegeben werden. 1. **Paketierungsphase** — Generiert das endgültige Container-Image für den Kunden, das ebenfalls auf dem App Runner-Run-Image basiert. 1. Kopieren Sie das `/app` Verzeichnis aus der vorherigen **Build-Phase** in das neue Run-Image. Dazu gehören der Quellcode Ihrer Anwendung und die Build-Artefakte aus der vorherigen Phase. 1. Führen Sie die `pre-run` Befehle aus. Wenn Sie das Runtime-Image außerhalb des `/app` Verzeichnisses mithilfe der `build` Befehle ändern müssen, fügen Sie diesem Segment der `apprunner.yaml` Konfigurationsdatei dieselben oder die erforderlichen Befehle hinzu. Dies ist ein neuer Parameter, der eingeführt wurde, um den überarbeiteten App Runner-Build zu unterstützen. Die `pre-run` Befehle sind optional. Sie können nur in der `apprunner.yaml` Konfigurationsdatei angegeben werden. **Hinweise** Die `pre-run` Befehle werden nur vom überarbeiteten Build unterstützt. Fügen Sie sie nicht der Konfigurationsdatei hinzu, wenn Ihr Service Laufzeitversionen verwendet, die den ursprünglichen Build verwenden. Wenn Sie mit den `build` Befehlen nichts außerhalb des `/app` Verzeichnisses ändern müssen, müssen Sie keine `pre-run` Befehle angeben. 1. **Post-Build-Phase** — Diese Phase wird nach der *Build-Phase* fortgesetzt und führt `post-build` Befehle aus. 1. Führen Sie die `post-build` Befehle innerhalb des Verzeichnisses aus`/app`. Die `post-build` Befehle sind optional. Sie können nur in der `apprunner.yaml` Konfigurationsdatei angegeben werden. Nach Abschluss des Builds stellt App Runner dann das Run-Image bereit, um Ihren Webservice in einem Container auszuführen. **Anmerkung** Lassen Sie sich bei der Konfiguration des Build-Prozesses nicht zu den `env` Einträgen im Abschnitt Ausführen verleiten. `apprunner.yaml` Auch wenn sich der `pre-run` Befehlsparameter, auf den in **Schritt 2 (b)** verwiesen wird, im Abschnitt Run befindet, verwenden Sie den `env` Parameter im Abschnitt Run nicht, um Ihren Build zu konfigurieren. Die `pre-run` Befehle verweisen nur auf die `env` Variablen, die im Abschnitt Build der Konfigurationsdatei definiert sind. Weitere Informationen finden Sie [Abschnitt „Ausführen“](config-file-ref.md#config-file-ref.run) im *Kapitel App Runner-Konfigurationsdatei*. #### Berücksichtigung der Serviceanforderungen für die Migration Wenn Ihre Anwendungsumgebung eine dieser beiden Anforderungen erfüllt, müssen Sie Ihre Build-Konfiguration überarbeiten, indem Sie `pre-run` Befehle hinzufügen. + Wenn Sie mit den `build` Befehlen etwas außerhalb des `/app` Verzeichnisses ändern müssen. + Wenn Sie die `build` Befehle zweimal ausführen müssen, um die erforderliche Umgebung zu erstellen. Dies ist eine sehr ungewöhnliche Anforderung. Die überwiegende Mehrheit der Builds wird dies nicht tun. **Änderungen außerhalb des `/app` Verzeichnisses** + Der [überarbeitete App Runner-Build](#service-source-code.build-detail.v2) geht davon aus, dass Ihre Anwendung keine Abhängigkeiten außerhalb des `/app` Verzeichnisses hat. + Die Befehle, die Sie entweder mit der `apprunner.yaml` Datei, der App Runner-API oder der App Runner-Konsole bereitstellen, müssen Build-Artefakte im `/app` Verzeichnis generieren. + Sie können die `post-build` Befehle`pre-build`, und ändern`build`, um sicherzustellen, dass sich alle Build-Artefakte im `/app` Verzeichnis befinden. + Wenn Ihre Anwendung erfordert, dass der Build das generierte Image für Ihren Service außerhalb des `/app` Verzeichnisses weiter modifiziert, können Sie die neuen `pre-run` Befehle in der verwenden`apprunner.yaml`. Weitere Informationen finden Sie unter [App Runner-Dienstoptionen mithilfe einer Konfigurationsdatei einrichten](config-file.md). **Die `build` Befehle zweimal ausführen** + Der [ursprüngliche App Runner-Build](#service-source-code.build-detail.v1) führt die `build` Befehle zweimal aus, zuerst in **Schritt 2**, dann erneut in **Schritt 5.** Der überarbeitete App Runner-Build behebt diese Redundanz und führt die `build` Befehle nur einmal aus. Falls für Ihre Anwendung eine ungewöhnliche Anforderung besteht, dass die `build` Befehle zweimal ausgeführt werden müssen, bietet der überarbeitete App Runner-Build die Möglichkeit, dieselben Befehle mithilfe des `pre-run` Parameters anzugeben und erneut auszuführen. Dabei wird das gleiche Double-Build-Verhalten beibehalten. # Verwenden der Python-Plattform von **Wichtig** App Runner wird die Unterstützung für **Python 3.7** und **Python 3.8** am 1. Dezember 2025 beenden. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). Die AWS App Runner Python-Plattform bietet verwaltete Laufzeiten. Jede Laufzeit macht es einfach, Container mit Webanwendungen zu erstellen und auszuführen, die auf einer Python-Version basieren. Wenn Sie eine Python-Laufzeit verwenden, startet App Runner mit einem verwalteten Python-Runtime-Image. Dieses Image basiert auf dem [Amazon Linux Docker-Image](https://hub.docker.com/_/amazonlinux) und enthält das Runtime-Paket für eine Version von Python sowie einige Tools und beliebte Abhängigkeitspakete. App Runner verwendet dieses verwaltete Runtime-Image als Basis-Image und fügt Ihren Anwendungscode hinzu, um ein Docker-Image zu erstellen. Anschließend wird dieses Image bereitgestellt, um Ihren Webservice in einem Container auszuführen. Sie geben eine Laufzeit für Ihren App Runner-Dienst an, wenn Sie [einen Dienst mithilfe der App Runner-Konsole oder des [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API-Vorgangs erstellen](manage-create.md). Sie können auch eine Laufzeit als Teil Ihres Quellcodes angeben. Verwenden Sie das `runtime` Schlüsselwort in einer [App Runner-Konfigurationsdatei](config-file.md), die Sie in Ihr Code-Repository aufnehmen. Die Benennungskonvention einer verwalteten Laufzeit lautet*

*. Gültige Namen und Versionen der Python-Laufzeit finden Sie unter[Informationen zur Python-Runtime-Version](service-source-code-python-releases.md). App Runner aktualisiert die Laufzeit für Ihren Dienst bei jeder Bereitstellung oder jedem Service-Update auf die neueste Version. Wenn Ihre Anwendung eine bestimmte Version einer verwalteten Laufzeit benötigt, können Sie diese mithilfe des `runtime-version` Schlüsselworts in der [App Runner-Konfigurationsdatei](config-file.md) angeben. Sie können sich auf eine beliebige Versionsebene beschränken, einschließlich einer Haupt- oder Nebenversion. App Runner aktualisiert die Laufzeit Ihres Dienstes nur auf niedrigerer Ebene. Versionssyntax für Python-Laufzeiten: `major[.minor[.patch]]` Beispiel: `3.8.5` Die folgenden Beispiele demonstrieren das Sperren von Versionen: + `3.8`— Sperren Sie die Haupt- und Nebenversionen. App Runner aktualisiert nur Patch-Versionen. + `3.8.5`— Auf eine bestimmte Patch-Version festlegen. App Runner aktualisiert Ihre Runtime-Version nicht. **Topics** + [Python-Laufzeitkonfiguration](#service-source-code-python.config) + [Callouts für bestimmte Runtime-Versionen](#service-source-code-python.callouts) + [Python-Laufzeitbeispiele](#service-source-code-python.examples) + [Informationen zur Python-Runtime-Version](service-source-code-python-releases.md) ## Python-Laufzeitkonfiguration Wenn Sie sich für eine verwaltete Laufzeit entscheiden, müssen Sie mindestens auch Befehle zum Erstellen und Ausführen konfigurieren. Sie konfigurieren sie bei der [Erstellung](manage-create.md) oder [Aktualisierung](manage-configure.md) Ihres App Runner-Dienstes. Sie können dies mit einer der folgenden Methoden tun: + **Verwenden der App Runner-Konsole** — Geben Sie die Befehle im Abschnitt **Build konfigurieren** des Erstellungsprozesses oder der Registerkarte Konfiguration an. + **Verwenden der App Runner-API** — Rufen Sie den [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API-Vorgang [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)oder auf. Geben Sie die Befehle mithilfe der `StartCommand` Elemente `BuildCommand` und des [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)Datentyps an. + **Mithilfe einer [Konfigurationsdatei](config-file.md)** — Geben Sie einen oder mehrere Build-Befehle in bis zu drei Build-Phasen sowie einen einzelnen Run-Befehl an, der zum Starten Ihrer Anwendung dient. Es gibt zusätzliche optionale Konfigurationseinstellungen. Die Bereitstellung einer Konfigurationsdatei ist optional. Wenn Sie einen App Runner-Dienst mithilfe der Konsole oder der API erstellen, geben Sie an, ob App Runner Ihre Konfigurationseinstellungen direkt bei der Erstellung oder aus einer Konfigurationsdatei bezieht. ## Callouts für bestimmte Runtime-Versionen **Anmerkung** App Runner führt jetzt einen aktualisierten Build-Prozess für Anwendungen aus, die auf den folgenden Laufzeitversionen basieren: Python 3.11, Node.js 22 und Node.js 18. Wenn Ihre Anwendung auf einer dieser Runtime-Versionen ausgeführt wird, finden Sie weitere Informationen [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail) zum überarbeiteten Build-Prozess unter. Anwendungen, die alle anderen Runtime-Versionen verwenden, sind nicht betroffen und sie verwenden weiterhin den ursprünglichen Build-Prozess. ### Python 3.11 (überarbeiteter App Runner-Build) Verwenden Sie die folgenden Einstellungen in der Datei *apprunner.yaml* für die verwaltete Python 3.11-Laufzeit. + Stellen Sie den Schlüssel im oberen Bereich auf `runtime` ein `python311` **Example** ``` runtime: python311 ``` + Verwenden Sie `pip3` statt von`pip`, um Abhängigkeiten zu installieren. + Verwenden Sie den `python3` Interpreter anstelle von. `python` + Führen Sie das `pip3` Installationsprogramm als `pre-run` Befehl aus. Python installiert Abhängigkeiten außerhalb des `/app` Verzeichnisses. Da App Runner den überarbeiteten App Runner-Build für Python 3.11 ausführt, geht alles verloren, was außerhalb des `/app` Verzeichnisses über Befehle im Build-Abschnitt der `apprunner.yaml` Datei installiert wurde. Weitere Informationen finden Sie unter [Der überarbeitete App Runner-Build](service-source-code.md#service-source-code.build-detail.v2). **Example** ``` run: runtime-version: 3.11 pre-run: - pip3 install pipenv - pipenv install - python3 copy-global-files.py command: pipenv run gunicorn django_apprunner.wsgi --log-file - ``` Weitere Informationen finden Sie auch im [Beispiel einer erweiterten Konfigurationsdatei für Python 3.11 weiter unten](#service-source-code-python.examples.extended-v2) in diesem Thema. ## Python-Laufzeitbeispiele Die folgenden Beispiele zeigen App Runner-Konfigurationsdateien zum Erstellen und Ausführen eines Python-Dienstes. Das letzte Beispiel ist der Quellcode für eine vollständige Python-Anwendung, die Sie in einem Python-Laufzeitdienst bereitstellen können. **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist *3.7.7* und*3.11*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Python-Laufzeitversion finden Sie unter[Informationen zur Python-Runtime-Version](service-source-code-python-releases.md). ### Minimale Python-Konfigurationsdatei Dieses Beispiel zeigt eine minimale Konfigurationsdatei, die Sie mit einer von Python verwalteten Laufzeit verwenden können. Informationen zu den Annahmen, die App Runner mit einer minimalen Konfigurationsdatei trifft, finden Sie unter[Beispiele für Konfigurationsdateien](config-file-examples.md#config-file-examples.managed). Python 3.11 verwendet die `python3` Befehle `pip3` und. Weitere Informationen finden Sie im [Beispiel einer erweiterten Konfigurationsdatei für Python 3.11 weiter unten](#service-source-code-python.examples.extended-v2) in diesem Thema. **Example apprunner.yaml** ``` version: 1.0 runtime: python3 build: commands: build: - pip install pipenv - pipenv install run: command: python app.py ``` ### Erweiterte Python-Konfigurationsdatei Dieses Beispiel zeigt die Verwendung aller Konfigurationsschlüssel mit einer von Python verwalteten Laufzeit. **Anmerkung** Die in diesen Beispielen verwendete Laufzeitversion ist*3.7.7*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Python-Laufzeitversion finden Sie unter[Informationen zur Python-Runtime-Version](service-source-code-python-releases.md). Python 3.11 verwendet die `python3` Befehle `pip3` und. Weitere Informationen finden Sie im Beispiel einer erweiterten Konfigurationsdatei für Python 3.11 weiter unten in diesem Thema. **Example apprunner.yaml** ``` version: 1.0 runtime: python3 build: commands: pre-build: - wget -c https://s3.amazonaws.com/amzn-s3-demo-bucket/test-lib.tar.gz -O - | tar -xz build: - pip install pipenv - pipenv install post-build: - python manage.py test env: - name: DJANGO_SETTINGS_MODULE value: "django_apprunner.settings" - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 3.7.7 command: pipenv run gunicorn django_apprunner.wsgi --log-file - network: port: 8000 env: MY_APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" secrets: - name: my-secret value-from: "arn:aws:secretsmanager:us-east-1:123456789012:secret:testingstackAppRunnerConstr-kJFXde2ULKbT-S7t8xR:username::" - name: my-parameter value-from: "arn:aws:ssm:us-east-1:123456789012:parameter/parameter-name" - name: my-parameter-only-name value-from: "parameter-name" ``` ### Erweiterte Python-Konfigurationsdatei — Python 3.11 (verwendet überarbeiteten Build) Dieses Beispiel zeigt die Verwendung aller Konfigurationsschlüssel mit einer verwalteten Python 3.11-Laufzeit in der`apprunner.yaml`. Dieses Beispiel enthält einen `pre-run` Abschnitt, da diese Version von Python den überarbeiteten App Runner-Build verwendet. Der `pre-run` Parameter wird nur vom überarbeiteten App Runner-Build unterstützt. Fügen Sie diesen Parameter nicht in Ihre Konfigurationsdatei ein, wenn Ihre Anwendung Runtime-Versionen verwendet, die vom ursprünglichen App Runner-Build unterstützt werden. Weitere Informationen finden Sie unter [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail). **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist*3.11*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Python-Laufzeitversion finden Sie unter[Informationen zur Python-Runtime-Version](service-source-code-python-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: python311 build: commands: pre-build: - wget -c https://s3.amazonaws.com/amzn-s3-demo-bucket/test-lib.tar.gz -O - | tar -xz build: - pip3 install pipenv - pipenv install post-build: - python3 manage.py test env: - name: DJANGO_SETTINGS_MODULE value: "django_apprunner.settings" - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 3.11 pre-run: - pip3 install pipenv - pipenv install - python3 copy-global-files.py command: pipenv run gunicorn django_apprunner.wsgi --log-file - network: port: 8000 env: MY_APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" secrets: - name: my-secret value-from: "arn:aws:secretsmanager:us-east-1:123456789012:secret:testingstackAppRunnerConstr-kJFXde2ULKbT-S7t8xR:username::" - name: my-parameter value-from: "arn:aws:ssm:us-east-1:123456789012:parameter/parameter-name" - name: my-parameter-only-name value-from: "parameter-name" ``` ### Vollständige Python-Anwendungsquelle Dieses Beispiel zeigt den Quellcode für eine vollständige Python-Anwendung, die Sie in einem Python-Runtime-Service bereitstellen können. **Example requirements.txt** ``` pyramid==2.0 ``` **Example server.py** ``` from wsgiref.simple_server import make_server from pyramid.config import Configurator from pyramid.response import Response import os def hello_world(request): name = os.environ.get('NAME') if name == None or len(name) == 0: name = "world" message = "Hello, " + name + "!\n" return Response(message) if __name__ == '__main__': port = int(os.environ.get("PORT")) with Configurator() as config: config.add_route('hello', '/') config.add_view(hello_world, route_name='hello') app = config.make_wsgi_app() server = make_server('0.0.0.0', port, app) server.serve_forever() ``` **Example apprunner.yaml** ``` version: 1.0 runtime: python3 build: commands: build: - pip install -r requirements.txt run: command: python server.py ``` # Informationen zur Python-Runtime-Version **Wichtig** App Runner wird die Unterstützung für **Python 3.7** und **Python 3.8** am 1. Dezember 2025 beenden. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). In diesem Thema werden die vollständigen Informationen zu den Python-Laufzeitversionen aufgeführt, die App Runner unterstützt. **Unterstützte Runtime-Versionen — überarbeiteter App Runner-Build** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code-python-releases.html) **Hinweise** **Python 3.11** — Wir haben spezifische Empfehlungen für die Build-Konfiguration von Diensten, die die verwaltete Python 3.11-Runtime verwenden. Weitere Informationen finden Sie [Callouts für bestimmte Runtime-Versionen](service-source-code-python.md#service-source-code-python.callouts) im Thema *Python-Plattform*. App Runner bietet einen überarbeiteten Build-Prozess für bestimmte Hauptlaufzeiten, die in jüngerer Zeit veröffentlicht wurden. Aus diesem Grund finden Sie in bestimmten Abschnitten dieses Dokuments Verweise auf den *überarbeiteten App Runner-Build* *und den ursprünglichen App Runner-Build*. Weitere Informationen finden Sie unter [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail). **Unterstützte Runtime-Versionen — originaler App Runner-Build** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code-python-releases.html) **Anmerkung** App Runner bietet einen überarbeiteten Build-Prozess für bestimmte Hauptlaufzeiten, die in jüngerer Zeit veröffentlicht wurden. Aus diesem Grund finden Sie in bestimmten Abschnitten dieses Dokuments Verweise auf den *überarbeiteten App Runner-Build* *und den ursprünglichen App Runner-Build*. Weitere Informationen finden Sie unter [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail). # Verwenden der Node.js-Plattform von **Wichtig** App Runner wird die Unterstützung für **Node.js 12**, **Node.js 14**, **Node.js 16** und **Node.js 18** am 1. Dezember 2025 einstellen. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). Die Plattform AWS App Runner Node.js bietet verwaltete Laufzeiten. Jede Laufzeit macht es einfach, Container mit Webanwendungen zu erstellen und auszuführen, die auf einer Version von Node.js basieren. Wenn Sie eine Node.js Runtime verwenden, startet App Runner mit einem verwalteten Node.js Runtime-Image. Dieses Image basiert auf dem [Amazon Linux Docker-Image](https://hub.docker.com/_/amazonlinux) und enthält das Runtime-Paket für eine Version von Node.js und einige Tools. App Runner verwendet dieses verwaltete Runtime-Image als Basis-Image und fügt Ihren Anwendungscode hinzu, um ein Docker-Image zu erstellen. Anschließend wird dieses Image bereitgestellt, um Ihren Webservice in einem Container auszuführen. Sie geben eine Laufzeit für Ihren App Runner-Dienst an, wenn Sie [einen Dienst mithilfe der App Runner-Konsole oder des [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API-Vorgangs erstellen](manage-create.md). Sie können auch eine Laufzeit als Teil Ihres Quellcodes angeben. Verwenden Sie das `runtime` Schlüsselwort in einer [App Runner-Konfigurationsdatei](config-file.md), die Sie in Ihr Code-Repository aufnehmen. Die Benennungskonvention einer verwalteten Laufzeit lautet*

*. Gültige Laufzeitnamen und Versionen von Node.js finden Sie unter[Informationen zur Runtime-Version von Node.js](service-source-code-nodejs-releases.md). App Runner aktualisiert die Laufzeit für Ihren Dienst bei jeder Bereitstellung oder jedem Service-Update auf die neueste Version. Wenn Ihre Anwendung eine bestimmte Version einer verwalteten Laufzeit benötigt, können Sie diese mithilfe des `runtime-version` Schlüsselworts in der [App Runner-Konfigurationsdatei](config-file.md) angeben. Sie können sich auf eine beliebige Versionsebene beschränken, einschließlich einer Haupt- oder Nebenversion. App Runner aktualisiert die Laufzeit Ihres Dienstes nur auf niedrigerer Ebene. Versionssyntax für die Laufzeiten von Node.js: `major[.minor[.patch]]` Beispiel: `22.14.0` Die folgenden Beispiele veranschaulichen das Sperren von Versionen: + `22.14`— Sperren Sie die Haupt- und Nebenversionen. App Runner aktualisiert nur Patch-Versionen. + `22.14.0`— Auf eine bestimmte Patch-Version festlegen. App Runner aktualisiert Ihre Runtime-Version nicht. **Topics** + [Laufzeitkonfiguration von Node.js](#service-source-code-nodejs.config) + [Callouts für bestimmte Runtime-Versionen](#service-source-code-nodejs.callouts) + [Beispiele für die Laufzeit von Node.js](#service-source-code-nodejs.examples) + [Informationen zur Runtime-Version von Node.js](service-source-code-nodejs-releases.md) ## Laufzeitkonfiguration von Node.js Wenn Sie sich für eine verwaltete Runtime entscheiden, müssen Sie mindestens auch Build- und Run-Befehle konfigurieren. Sie konfigurieren sie bei der [Erstellung](manage-create.md) oder [Aktualisierung](manage-configure.md) Ihres App Runner-Dienstes. Sie können dies mit einer der folgenden Methoden tun: + **Verwenden der App Runner-Konsole** — Geben Sie die Befehle im Abschnitt **Build konfigurieren** des Erstellungsprozesses oder der Registerkarte Konfiguration an. + **Verwenden der App Runner-API** — Rufen Sie den [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API-Vorgang [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)oder auf. Geben Sie die Befehle mithilfe der `StartCommand` Elemente `BuildCommand` und des [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)Datentyps an. + **Mithilfe einer [Konfigurationsdatei](config-file.md)** — Geben Sie einen oder mehrere Build-Befehle in bis zu drei Build-Phasen sowie einen einzelnen Run-Befehl an, der zum Starten Ihrer Anwendung dient. Es gibt zusätzliche optionale Konfigurationseinstellungen. Die Bereitstellung einer Konfigurationsdatei ist optional. Wenn Sie einen App Runner-Dienst mithilfe der Konsole oder der API erstellen, geben Sie an, ob App Runner Ihre Konfigurationseinstellungen direkt bei der Erstellung oder aus einer Konfigurationsdatei bezieht. Speziell bei den Laufzeiten von Node.js können Sie den Build und die Laufzeit auch mithilfe einer JSON-Datei konfigurieren, die `package.json` im Stammverzeichnis Ihres Quell-Repositorys benannt ist. Mithilfe dieser Datei können Sie die Engine-Version von Node.js, die Abhängigkeitspakete und verschiedene Befehle (Befehlszeilenanwendungen) konfigurieren. Paketmanager wie npm oder yarn interpretieren diese Datei als Eingabe für ihre Befehle. Beispiel: + **npm install**installiert Pakete, die durch den `devDependencies` Knoten `dependencies` und in `package.json` definiert sind. + **npm start**oder **npm run start** führt den durch den `scripts/start` Knoten in definierten Befehl aus`package.json`. Im Folgenden sehen Sie ein Beispiel für eine `package.json`-Datei. ### package.json ``` { "name": "node-js-getting-started", "version": "0.3.0", "description": "A sample Node.js app using Express 4", "engines": { "node": "22.14.0" }, "scripts": { "start": "node index.js", "test": "node test.js" }, "dependencies": { "cool-ascii-faces": "^1.3.4", "ejs": "^2.5.6", "express": "^4.15.2" }, "devDependencies": { "got": "^11.3.0", "tape": "^4.7.0" } } ``` Weitere Informationen `package.json` dazu finden Sie unter [Erstellen einer package.json-Datei](https://docs.npmjs.com/creating-a-package-json-file) auf der *npm* Docs-Website. **Tipps** Wenn Ihre `package.json` Datei einen **start** Befehl definiert, können Sie ihn als **run** Befehl in Ihrer App Runner-Konfigurationsdatei verwenden, wie das folgende Beispiel zeigt. **Example** package.json ``` { "scripts": { "start": "node index.js" } } ``` apprunner.yaml ``` run: command: npm start ``` Wenn Sie **npm install** in Ihrer Entwicklungsumgebung ausführen, erstellt npm die Datei. `package-lock.json` Diese Datei enthält einen Snapshot der Paketversionen, die npm gerade installiert hat. Wenn npm anschließend Abhängigkeiten installiert, verwendet es genau diese Versionen. Wenn Sie Garn installieren, wird eine `yarn.lock` Datei erstellt. Übergeben Sie diese Dateien in Ihr Quellcode-Repository, um sicherzustellen, dass Ihre Anwendung mit den Versionen der Abhängigkeiten installiert wird, mit denen Sie sie entwickelt und getestet haben. Sie können auch eine App Runner-Konfigurationsdatei verwenden, um die Version von Node.js und den Startbefehl zu konfigurieren. Wenn Sie dies tun, überschreiben diese Definitionen die Definitionen in`package.json`. Ein Konflikt zwischen der `node` Version in `package.json` und dem `runtime-version` Wert in der App Runner-Konfigurationsdatei führt dazu, dass die App Runner-Buildphase fehlschlägt. ## Callouts für bestimmte Runtime-Versionen ### Node.js 22 und Node.js 18 (überarbeiteter App Runner-Build) App Runner führt jetzt einen aktualisierten Build-Prozess für Anwendungen aus, die auf den folgenden Laufzeitversionen basieren: Python 3.11, Node.js 22 und Node.js 18. Wenn Ihre Anwendung auf einer dieser Runtime-Versionen ausgeführt wird, finden Sie weitere Informationen [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail) zum überarbeiteten Build-Prozess unter. Anwendungen, die alle anderen Runtime-Versionen verwenden, sind nicht betroffen, und sie verwenden weiterhin den ursprünglichen Build-Prozess. ## Beispiele für die Laufzeit von Node.js Die folgenden Beispiele zeigen App Runner-Konfigurationsdateien zum Erstellen und Ausführen eines Node.js -Dienstes. **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist*22.14.0*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Laufzeitversion von Node.js finden Sie unter[Informationen zur Runtime-Version von Node.js](service-source-code-nodejs-releases.md). ### Minimale Konfigurationsdatei Node.js Dieses Beispiel zeigt eine Minimalkonfigurationsdatei, die Sie mit einer verwalteten Laufzeit von Node.js verwenden können. Informationen zu den Annahmen, die App Runner mit einer minimalen Konfigurationsdatei trifft, finden Sie unter[Beispiele für Konfigurationsdateien](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: nodejs22 build: commands: build: - npm install --production run: command: node app.js ``` ### Erweiterte Konfigurationsdatei Node.js Dieses Beispiel zeigt die Verwendung aller Konfigurationsschlüssel mit einer verwalteten Laufzeit von Node.js. **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist*22.14.0*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Laufzeitversion von Node.js finden Sie unter[Informationen zur Runtime-Version von Node.js](service-source-code-nodejs-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: nodejs22 build: commands: pre-build: - npm install --only=dev - node test.js build: - npm install --production post-build: - node node_modules/ejs/postinstall.js env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 22.14.0 command: node app.js network: port: 8000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Erweiterte Konfigurationsdatei Node.js — Node.js 22 (verwendet einen überarbeiteten Build) Dieses Beispiel zeigt die Verwendung aller Konfigurationsschlüssel mit einer von Node.js verwalteten Laufzeit in der`apprunner.yaml`. Dieses Beispiel enthält einen `pre-run` Abschnitt, da diese Version von Node.js den überarbeiteten App Runner-Build verwendet. Der `pre-run` Parameter wird nur vom überarbeiteten App Runner-Build unterstützt. Fügen Sie diesen Parameter nicht in Ihre Konfigurationsdatei ein, wenn Ihre Anwendung Runtime-Versionen verwendet, die vom ursprünglichen App Runner-Build unterstützt werden. Weitere Informationen finden Sie unter [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail). **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist*22.14.0*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Laufzeitversion von Node.js finden Sie unter[Informationen zur Runtime-Version von Node.js](service-source-code-nodejs-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: nodejs22 build: commands: pre-build: - npm install --only=dev - node test.js build: - npm install --production post-build: - node node_modules/ejs/postinstall.js env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 22.14.0 pre-run: - node copy-global-files.js command: node app.js network: port: 8000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### App Node.js mit Grunt Dieses Beispiel zeigt, wie eine Node.js -Anwendung konfiguriert wird, die mit Grunt entwickelt wurde. [Grunt](https://gruntjs.com/) ist ein JavaScript Task-Runner über die Befehlszeile. Es führt sich wiederholende Aufgaben aus und verwaltet die Prozessautomatisierung, um menschliche Fehler zu reduzieren. Die Plugins Grunt und Grunt werden mit npm installiert und verwaltet. Sie konfigurieren Grunt, indem Sie die `Gruntfile.js` Datei in das Stammverzeichnis Ihres Quell-Repositorys aufnehmen. **Example package.json** ``` { "scripts": { "build": "grunt uglify", "start": "node app.js" }, "devDependencies": { "grunt": "~0.4.5", "grunt-contrib-jshint": "~0.10.0", "grunt-contrib-nodeunit": "~0.4.1", "grunt-contrib-uglify": "~0.5.0" }, "dependencies": { "express": "^4.15.2" }, } ``` **Example Gruntfile.js** ``` module.exports = function(grunt) { // Project configuration. grunt.initConfig({ pkg: grunt.file.readJSON('package.json'), uglify: { options: { banner: '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n' }, build: { src: 'src/<%= pkg.name %>.js', dest: 'build/<%= pkg.name %>.min.js' } } }); // Load the plugin that provides the "uglify" task. grunt.loadNpmTasks('grunt-contrib-uglify'); // Default task(s). grunt.registerTask('default', ['uglify']); }; ``` **Example apprunner.yaml** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist. *22.14.0* Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Laufzeitversion von Node.js finden Sie unter[Informationen zur Runtime-Version von Node.js](service-source-code-nodejs-releases.md). ``` version: 1.0 runtime: nodejs22 build: commands: pre-build: - npm install grunt grunt-cli - npm install --only=dev - npm run build build: - npm install --production run: runtime-version: 22.14.0 command: node app.js network: port: 8000 env: APP_PORT ``` # Informationen zur Runtime-Version von Node.js **Wichtig** App Runner wird den Support für **Node.js 12**, **Node.js 14**, **Node.js 16** und **Node.js 18** am 1. Dezember 2025 einstellen. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). **Anmerkung** Die Standardrichtlinie von App Runner sieht vor, dass eine Laufzeit als veraltet eingestuft wird, wenn für eine wichtige Komponente der Laufzeit der Community Long-Term Support (LTS) ausläuft und keine Sicherheitsupdates mehr verfügbar sind. In einigen Fällen kann App Runner das Verfallen einer Laufzeit für einen begrenzten Zeitraum hinauszögern, und zwar über das end-of-support Datum der von der Laufzeit unterstützten Sprachversion hinaus. Ein Beispiel für einen solchen Fall könnte die Erweiterung des Supports für eine Runtime sein, um Kunden Zeit für die Migration zu geben. In diesem Thema werden die vollständigen Informationen zu den Runtime-Versionen von Node.js aufgeführt, die App Runner unterstützt. **Unterstützte Runtime-Versionen — überarbeiteter App Runner-Build** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code-nodejs-releases.html) **Anmerkung** App Runner bietet einen überarbeiteten Build-Prozess für bestimmte Haupt-Runtimes, die in jüngerer Zeit veröffentlicht wurden. Aus diesem Grund finden Sie in bestimmten Abschnitten dieses Dokuments Verweise auf den *überarbeiteten App Runner-Build* *und den ursprünglichen App Runner-Build*. Weitere Informationen finden Sie unter [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail). **Unterstützte Runtime-Versionen — überarbeiteter App Runner-Build** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code-nodejs-releases.html) **Unterstützte Runtime-Versionen — originaler App Runner-Build** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code-nodejs-releases.html) # Verwendung der Java-Plattform Die AWS App Runner Java-Plattform bietet verwaltete Laufzeiten. Jede Laufzeit macht es einfach, Container mit Webanwendungen zu erstellen und auszuführen, die auf einer Java-Version basieren. Wenn Sie eine Java-Runtime verwenden, startet App Runner mit einem verwalteten Java-Runtime-Image. Dieses Image basiert auf dem [Amazon Linux Docker-Image](https://hub.docker.com/_/amazonlinux) und enthält das Runtime-Paket für eine Version von Java und einige Tools. App Runner verwendet dieses verwaltete Runtime-Image als Basis-Image und fügt Ihren Anwendungscode hinzu, um ein Docker-Image zu erstellen. Anschließend stellt es dieses Image bereit, um Ihren Webservice in einem Container auszuführen. Sie geben eine Laufzeit für Ihren App Runner-Dienst an, wenn Sie [einen Dienst mithilfe der App Runner-Konsole oder des [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API-Vorgangs erstellen](manage-create.md). Sie können auch eine Laufzeit als Teil Ihres Quellcodes angeben. Verwenden Sie das `runtime` Schlüsselwort in einer [App Runner-Konfigurationsdatei](config-file.md), die Sie in Ihr Code-Repository aufnehmen. Die Benennungskonvention einer verwalteten Laufzeit lautet*

*. Derzeit basieren alle unterstützten Java-Laufzeiten auf Amazon Corretto. Gültige Namen und Versionen der Java-Laufzeit finden Sie unter. [Informationen zur Java-Runtime-Version](service-source-code-java-releases.md) App Runner aktualisiert die Laufzeit für Ihren Dienst bei jeder Bereitstellung oder jedem Service-Update auf die neueste Version. Wenn Ihre Anwendung eine bestimmte Version einer verwalteten Laufzeit benötigt, können Sie diese mithilfe des `runtime-version` Schlüsselworts in der [App Runner-Konfigurationsdatei](config-file.md) angeben. Sie können sich auf eine beliebige Versionsebene beschränken, einschließlich einer Haupt- oder Nebenversion. App Runner aktualisiert die Laufzeit Ihres Dienstes nur auf niedrigerer Ebene. Versionssyntax für Amazon Corretto-Laufzeiten: | **Laufzeit** | **Syntax** | **Beispiel** | | --- | --- | --- | | corretto11 | `11.0[.openjdk-update[.openjdk-build[.corretto-specific-revision]]]` | `11.0.13.08.1` | | corretto8 | `8[.openjdk-update[.openjdk-build[.corretto-specific-revision]]]` | `8.312.07.1` | Die folgenden Beispiele veranschaulichen das Sperren von Versionen: + `11.0.13`— Sperrt die Open JDK-Update-Version. App Runner aktualisiert nur Open JDK- und Amazon Corretto-Builds auf niedrigerer Ebene. + `11.0.13.08.1`— Auf eine bestimmte Version festlegen. App Runner aktualisiert Ihre Runtime-Version nicht. **Topics** + [Konfiguration der Java-Laufzeit](#service-source-code-java.config) + [Beispiele für Java-Runtime](#service-source-code-java.examples) + [Informationen zur Java-Runtime-Version](service-source-code-java-releases.md) ## Konfiguration der Java-Laufzeit Wenn Sie sich für eine verwaltete Runtime entscheiden, müssen Sie mindestens auch Build- und Run-Befehle konfigurieren. Sie konfigurieren sie bei der [Erstellung](manage-create.md) oder [Aktualisierung](manage-configure.md) Ihres App Runner-Dienstes. Sie können dies mit einer der folgenden Methoden tun: + **Verwenden der App Runner-Konsole** — Geben Sie die Befehle im Abschnitt **Build konfigurieren** des Erstellungsprozesses oder der Registerkarte Konfiguration an. + **Verwenden der App Runner-API** — Rufen Sie den [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API-Vorgang [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)oder auf. Geben Sie die Befehle mithilfe der `StartCommand` Elemente `BuildCommand` und des [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)Datentyps an. + **Mithilfe einer [Konfigurationsdatei](config-file.md)** — Geben Sie einen oder mehrere Build-Befehle in bis zu drei Build-Phasen sowie einen einzelnen Run-Befehl an, der zum Starten Ihrer Anwendung dient. Es gibt zusätzliche optionale Konfigurationseinstellungen. Die Bereitstellung einer Konfigurationsdatei ist optional. Wenn Sie einen App Runner-Dienst mithilfe der Konsole oder der API erstellen, geben Sie an, ob App Runner Ihre Konfigurationseinstellungen direkt bei der Erstellung oder aus einer Konfigurationsdatei bezieht. ## Beispiele für Java-Runtime Die folgenden Beispiele zeigen App Runner-Konfigurationsdateien zum Erstellen und Ausführen eines Java-Dienstes. Das letzte Beispiel ist der Quellcode für eine vollständige Java-Anwendung, die Sie auf einem Corretto 11-Laufzeitdienst bereitstellen können. **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist. *11.0.13.08.1* Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Java-Runtime-Version finden Sie unter[Informationen zur Java-Runtime-Version](service-source-code-java-releases.md). ### Minimale Corretto 11-Konfigurationsdatei Dieses Beispiel zeigt eine minimale Konfigurationsdatei, die Sie mit einer von Corretto 11 verwalteten Runtime verwenden können. Informationen zu den Annahmen, die App Runner mit einer minimalen Konfigurationsdatei trifft, finden Sie unter. **Example apprunner.yaml** ``` version: 1.0 runtime: corretto11 build: commands: build: - mvn clean package run: command: java -Xms256m -jar target/MyApp-1.0-SNAPSHOT.jar . ``` ### Erweiterte Corretto 11-Konfigurationsdatei Dieses Beispiel zeigt, wie Sie alle Konfigurationsschlüssel mit einer von Corretto 11 verwalteten Laufzeit verwenden können. **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist. *11.0.13.08.1* Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Java-Runtime-Version finden Sie unter[Informationen zur Java-Runtime-Version](service-source-code-java-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: corretto11 build: commands: pre-build: - yum install some-package - scripts/prebuild.sh build: - mvn clean package post-build: - mvn clean test env: - name: M2 value: "/usr/local/apache-maven/bin" - name: M2_HOME value: "/usr/local/apache-maven/bin" run: runtime-version: 11.0.13.08.1 command: java -Xms256m -jar target/MyApp-1.0-SNAPSHOT.jar . network: port: 8000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Vollständige Corretto 11-Anwendungsquelle Dieses Beispiel zeigt den Quellcode für eine vollständige Java-Anwendung, die Sie auf einem Corretto 11-Laufzeitdienst bereitstellen können. **Example src/main/java/com/HelloWorld/HelloWorld.java** ``` package com.HelloWorld; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class HelloWorld { @RequestMapping("/") public String index(){ String s = "Hello World"; return s; } } ``` **Example src/main/java/com/HelloWorld/Main.java** ``` package com.HelloWorld; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class Main { public static void main(String[] args) { SpringApplication.run(Main.class, args); } } ``` **Example apprunner.yaml** ``` version: 1.0 runtime: corretto11 build: commands: build: - mvn clean package run: command: java -Xms256m -jar target/HelloWorldJavaApp-1.0-SNAPSHOT.jar . network: port: 8080 ``` **Example pom.xml** ``` 4.0.0 org.springframework.boot spring-boot-starter-parent 2.3.1.RELEASE com.HelloWorld HelloWorldJavaApp 1.0-SNAPSHOT 11 org.springframework.boot spring-boot-starter-data-rest org.springframework.boot spring-boot-starter-test test org.junit.vintage junit-vintage-engine org.springframework.boot spring-boot-maven-plugin org.apache.maven.plugins maven-compiler-plugin 3.8.0 11 ``` # Informationen zur Java-Runtime-Version In diesem Thema werden die vollständigen Informationen zu den Java-Runtime-Versionen aufgeführt, die App Runner unterstützt. **Unterstützte Runtime-Versionen — originaler App Runner-Build** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code-java-releases.html) **Anmerkung** App Runner bietet einen überarbeiteten Build-Prozess für bestimmte Hauptlaufzeiten, die in jüngerer Zeit veröffentlicht wurden. Aus diesem Grund finden Sie in bestimmten Abschnitten dieses Dokuments Verweise auf den *überarbeiteten App Runner-Build* *und den ursprünglichen App Runner-Build*. Weitere Informationen finden Sie unter [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail). # Verwenden der -.NET-Plattform **Wichtig** App Runner wird die Unterstützung für **.NET 6** am 1. Dezember 2025 beenden. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). AWS App Runner Die.NET-Plattform bietet verwaltete Laufzeiten. Jede Laufzeit macht es einfach, Container mit Webanwendungen zu erstellen und auszuführen, die auf einer .NET-Version basieren. Wenn Sie eine.NET-Runtime verwenden, startet App Runner mit einem verwalteten.NET-Runtime-Image. Dieses Image basiert auf dem [Amazon Linux Docker-Image](https://hub.docker.com/_/amazonlinux) und enthält das Runtime-Paket für eine Version von.NET sowie einige Tools und beliebte Abhängigkeitspakete. App Runner verwendet dieses verwaltete Runtime-Image als Basis-Image und fügt Ihren Anwendungscode hinzu, um ein Docker-Image zu erstellen. Anschließend wird dieses Image bereitgestellt, um Ihren Webservice in einem Container auszuführen. Sie geben eine Laufzeit für Ihren App Runner-Dienst an, wenn Sie [einen Dienst mithilfe der App Runner-Konsole oder des [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API-Vorgangs erstellen](manage-create.md). Sie können auch eine Laufzeit als Teil Ihres Quellcodes angeben. Verwenden Sie das `runtime` Schlüsselwort in einer [App Runner-Konfigurationsdatei](config-file.md), die Sie in Ihr Code-Repository aufnehmen. Die Benennungskonvention einer verwalteten Laufzeit lautet*

*. Gültige Namen und Versionen von .NET-Runtime finden Sie unter[Informationen zur Veröffentlichung von.NET-Runtime](service-source-code-dotnet-releases.md). App Runner aktualisiert die Laufzeit für Ihren Dienst bei jeder Bereitstellung oder jedem Service-Update auf die neueste Version. Wenn Ihre Anwendung eine bestimmte Version einer verwalteten Laufzeit benötigt, können Sie diese mithilfe des `runtime-version` Schlüsselworts in der [App Runner-Konfigurationsdatei](config-file.md) angeben. Sie können sich auf eine beliebige Versionsebene beschränken, einschließlich einer Haupt- oder Nebenversion. App Runner aktualisiert die Laufzeit Ihres Dienstes nur auf niedrigerer Ebene. Versionssyntax für .NET-Laufzeiten: `major[.minor[.patch]]` Beispiel: `6.0.9` Die folgenden Beispiele veranschaulichen das Sperren von Versionen: + `6.0`— Sperren Sie die Haupt- und Nebenversionen. App Runner aktualisiert nur Patch-Versionen. + `6.0.9`— Auf eine bestimmte Patch-Version festlegen. App Runner aktualisiert Ihre Runtime-Version nicht. **Topics** + [.NET-Laufzeitkonfiguration](#service-source-code-net6.config) + [.NET-Runtime-Beispiele](#service-source-code-net6.examples) + [Informationen zur Veröffentlichung von.NET-Runtime](service-source-code-dotnet-releases.md) ## .NET-Laufzeitkonfiguration Wenn Sie sich für eine verwaltete Runtime entscheiden, müssen Sie mindestens auch Build- und Run-Befehle konfigurieren. Sie konfigurieren sie bei der [Erstellung](manage-create.md) oder [Aktualisierung](manage-configure.md) Ihres App Runner-Dienstes. Sie können dies mit einer der folgenden Methoden tun: + **Verwenden der App Runner-Konsole** — Geben Sie die Befehle im Abschnitt **Build konfigurieren** des Erstellungsprozesses oder der Registerkarte Konfiguration an. + **Verwenden der App Runner-API** — Rufen Sie den [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API-Vorgang [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)oder auf. Geben Sie die Befehle mithilfe der `StartCommand` Elemente `BuildCommand` und des [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)Datentyps an. + **Mithilfe einer [Konfigurationsdatei](config-file.md)** — Geben Sie einen oder mehrere Build-Befehle in bis zu drei Build-Phasen sowie einen einzelnen Run-Befehl an, der zum Starten Ihrer Anwendung dient. Es gibt zusätzliche optionale Konfigurationseinstellungen. Die Bereitstellung einer Konfigurationsdatei ist optional. Wenn Sie einen App Runner-Dienst mithilfe der Konsole oder der API erstellen, geben Sie an, ob App Runner Ihre Konfigurationseinstellungen direkt bei der Erstellung oder aus einer Konfigurationsdatei bezieht. ## .NET-Runtime-Beispiele Die folgenden Beispiele zeigen App Runner-Konfigurationsdateien zum Erstellen und Ausführen eines .NET-Dienstes. Das letzte Beispiel ist der Quellcode für eine vollständige.NET-Anwendung, die Sie in einem.NET-Runtime-Service bereitstellen können. **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist*6.0.9*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte.NET-Runtime-Version finden Sie unter[Informationen zur Veröffentlichung von.NET-Runtime](service-source-code-dotnet-releases.md). ### Minimale .NET-Konfigurationsdatei Dieses Beispiel zeigt eine Minimalkonfigurationsdatei, die Sie mit einer verwalteten.NET-Laufzeit verwenden können. Informationen zu den Annahmen, die App Runner mit einer minimalen Konfigurationsdatei trifft, finden Sie unter[Beispiele für Konfigurationsdateien](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: dotnet6 build: commands: build: - dotnet publish -c Release -o out run: command: dotnet out/HelloWorldDotNetApp.dll ``` ### Erweiterte.NET-Konfigurationsdatei Dieses Beispiel zeigt die Verwendung aller Konfigurationsschlüssel mit einer verwalteten.NET-Laufzeit. **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist*6.0.9*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte.NET-Runtime-Version finden Sie unter[Informationen zur Veröffentlichung von.NET-Runtime](service-source-code-dotnet-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: dotnet6 build: commands: pre-build: - scripts/prebuild.sh build: - dotnet publish -c Release -o out post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 6.0.9 command: dotnet out/HelloWorldDotNetApp.dll network: port: 5000 env: APP_PORT env: - name: ASPNETCORE_URLS value: "http://*:5000" ``` ### Vollständige .NET-Anwendungsquelle Dieses Beispiel zeigt den Quellcode für eine vollständige.NET-Anwendung, die Sie in einem.NET-Runtime-Service bereitstellen können. **Anmerkung** Führen Sie den folgenden Befehl aus, um eine einfache.NET 6-Web-App zu erstellen: ` dotnet new web --name HelloWorldDotNetApp -f net6.0` Fügen Sie der `apprunner.yaml` erstellten.NET 6-Web-App die hinzu. **Example HelloWorldDotNetApp** ``` version: 1.0 runtime: dotnet6 build: commands: build: - dotnet publish -c Release -o out run: command: dotnet out/HelloWorldDotNetApp.dll network: port: 5000 env: APP_PORT env: - name: ASPNETCORE_URLS value: "http://*:5000" ``` # Informationen zur Veröffentlichung von.NET-Runtime **Wichtig** App Runner wird den Support für **.NET 6** am 1. Dezember 2025 beenden. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). In diesem Thema werden die vollständigen Informationen zu den.NET-Runtime-Versionen aufgeführt, die App Runner unterstützt. **Unterstützte Runtime-Versionen — originaler App Runner-Build** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code-dotnet-releases.html) **Anmerkung** App Runner bietet einen überarbeiteten Build-Prozess für bestimmte Haupt-Runtimes, die in jüngerer Zeit veröffentlicht wurden. Aus diesem Grund finden Sie in bestimmten Abschnitten dieses Dokuments Verweise auf den *überarbeiteten App Runner-Build* *und den ursprünglichen App Runner-Build*. Weitere Informationen finden Sie unter [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail). # Verwenden der -PHP-Plattform **Wichtig** App Runner wird die Unterstützung für **PHP 8.1** am 31. Dezember 2025 beenden. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). Die AWS App Runner PHP-Plattform bietet verwaltete Laufzeiten. Sie können jede Laufzeit verwenden, um Container mit Webanwendungen zu erstellen und auszuführen, die auf einer PHP-Version basieren. Wenn Sie eine PHP-Runtime verwenden, startet App Runner mit einem verwalteten PHP-Runtime-Image. Dieses Image basiert auf dem [Amazon Linux Docker-Image](https://hub.docker.com/_/amazonlinux) und enthält das Runtime-Paket für eine Version von PHP und einige Tools. App Runner verwendet dieses verwaltete Runtime-Image als Basis-Image und fügt Ihren Anwendungscode hinzu, um ein Docker-Image zu erstellen. Anschließend wird dieses Image bereitgestellt, um Ihren Webservice in einem Container auszuführen. Sie geben eine Laufzeit für Ihren App Runner-Dienst an, wenn Sie [einen Dienst mithilfe der App Runner-Konsole oder des [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API-Vorgangs erstellen](manage-create.md). Sie können auch eine Laufzeit als Teil Ihres Quellcodes angeben. Verwenden Sie das `runtime` Schlüsselwort in einer [App Runner-Konfigurationsdatei](config-file.md), die Sie in Ihr Code-Repository aufnehmen. Die Benennungskonvention einer verwalteten Laufzeit lautet*

*. Gültige PHP-Laufzeitnamen und -versionen finden Sie unter[Informationen zur PHP-Runtime-Version](service-source-code-php-releases.md). App Runner aktualisiert die Laufzeit für Ihren Dienst bei jeder Bereitstellung oder jedem Service-Update auf die neueste Version. Wenn Ihre Anwendung eine bestimmte Version einer verwalteten Laufzeit benötigt, können Sie diese mithilfe des `runtime-version` Schlüsselworts in der [App Runner-Konfigurationsdatei](config-file.md) angeben. Sie können sich auf eine beliebige Versionsebene beschränken, einschließlich einer Haupt- oder Nebenversion. App Runner aktualisiert die Laufzeit Ihres Dienstes nur auf niedrigerer Ebene. Versionssyntax für PHP-Laufzeiten: `major[.minor[.patch]]` Beispiel: `8.1.10` Im Folgenden finden Sie Beispiele für das Sperren von Versionen: + `8.1`— Sperren Sie die Haupt- und Nebenversionen. App Runner aktualisiert nur Patch-Versionen. + `8.1.10`— Auf eine bestimmte Patch-Version festlegen. App Runner aktualisiert Ihre Runtime-Version nicht. **Wichtig** Wenn Sie das [Quellverzeichnis](service-source-code.md#service-source-code.source-directory) des Code-Repositorys für Ihren App Runner-Dienst an einem anderen Ort als dem Standard-Repository-Stammverzeichnis angeben möchten, muss Ihre verwaltete PHP-Runtime-Version PHP `8.1.22` oder höher sein. Ältere PHP-Runtime-Versionen verwenden `8.1.22` möglicherweise nur das Standard-Root-Quellverzeichnis. **Topics** + [PHP-Laufzeitkonfiguration](#service-source-code-php.config) + [Kompatibilität](#service-source-code-php.compatibility) + [Beispiele für PHP-Runtime](#service-source-code-php.examples) + [Informationen zur PHP-Runtime-Version](service-source-code-php-releases.md) ## PHP-Laufzeitkonfiguration Wenn Sie sich für eine verwaltete Runtime entscheiden, müssen Sie mindestens auch Build- und Run-Befehle konfigurieren. Sie konfigurieren sie bei der [Erstellung](manage-create.md) oder [Aktualisierung](manage-configure.md) Ihres App Runner-Dienstes. Sie können dies mit einer der folgenden Methoden tun: + **Verwenden der App Runner-Konsole** — Geben Sie die Befehle im Abschnitt **Build konfigurieren** des Erstellungsprozesses oder der Registerkarte Konfiguration an. + **Verwenden der App Runner-API** — Rufen Sie den [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API-Vorgang [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)oder auf. Geben Sie die Befehle mithilfe der `StartCommand` Elemente `BuildCommand` und des [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)Datentyps an. + **Mithilfe einer [Konfigurationsdatei](config-file.md)** — Geben Sie einen oder mehrere Build-Befehle in bis zu drei Build-Phasen sowie einen einzelnen Run-Befehl an, der zum Starten Ihrer Anwendung dient. Es gibt zusätzliche optionale Konfigurationseinstellungen. Die Bereitstellung einer Konfigurationsdatei ist optional. Wenn Sie einen App Runner-Dienst mithilfe der Konsole oder der API erstellen, geben Sie an, ob App Runner Ihre Konfigurationseinstellungen direkt bei der Erstellung oder aus einer Konfigurationsdatei bezieht. ## Kompatibilität Sie können Ihre App Runner-Dienste auf der PHP-Plattform mit einem der folgenden Webserver ausführen: + Apache HTTP Server + NGINX Apache HTTP Serverund NGINX sind mit PHP-FPM kompatibel. Sie können das *Apache HTTP Server*und mit einer *NGINX*der folgenden Optionen starten: + [Supervisord](http://supervisord.org/introduction.html#supervisor-components/) — Weitere Informationen zum Ausführen von Supervisord finden Sie unter [Supervisord ausführen](http://supervisord.org/running.html#running-supervisord). *supervisord* + Startskript Beispiele zur Konfiguration Ihres App Runner-Dienstes mit der PHP-Plattform mithilfe von *Apache HTTP Server* oder *NGINX* finden Sie unter. [Vollständige PHP-Anwendungsquelle](#service-source-code-php.examples.end2end) ### Dateistruktur Der `index.php` muss im `public` Ordner unter dem `root` Verzeichnis des Webservers installiert sein. **Anmerkung** Wir empfehlen, die `supervisord.conf` Dateien `startup.sh` oder im Stammverzeichnis des Webservers zu speichern. Stellen Sie sicher, dass der `start` Befehl auf den Speicherort verweist, an dem die `startup.sh` `supervisord.conf` Oder-Dateien gespeichert sind. Das Folgende ist ein Beispiel für die Dateistruktur, wenn Sie verwenden *supervisord*. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ supervisord.conf ``` Das Folgende ist ein Beispiel für die Dateistruktur, wenn Sie ein *Startskript* verwenden. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` Wir empfehlen, diese Dateistrukturen im [Quellverzeichnis](service-source-code.md#service-source-code.source-directory) des Code-Repositorys zu speichern, das für den App Runner-Dienst vorgesehen ist. ``` // ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` **Wichtig** Wenn Sie das [Code-Repository-Quellverzeichnis](service-source-code.md#service-source-code.source-directory) für Ihren App Runner-Dienst an einem anderen Ort als dem Standard-Repository-Stammverzeichnis angeben möchten, muss Ihre von PHP verwaltete Runtime-Version PHP `8.1.22` oder höher sein. Ältere PHP-Runtime-Versionen verwenden `8.1.22` möglicherweise nur das Standard-Root-Quellverzeichnis. App Runner aktualisiert die Laufzeit für Ihren Dienst bei jeder Bereitstellung oder jedem Service-Update auf die neueste Version. Ihr Dienst verwendet standardmäßig die neuesten Laufzeiten, es sei denn, Sie haben die Versionssperre mit dem `runtime-version` Schlüsselwort in der [App Runner-Konfigurationsdatei](config-file.md) angegeben. ## Beispiele für PHP-Runtime Im Folgenden finden Sie Beispiele für App Runner-Konfigurationsdateien, die zum Erstellen und Ausführen eines PHP-Dienstes verwendet werden. ### Minimale PHP-Konfigurationsdatei Das folgende Beispiel ist eine Minimalkonfigurationsdatei, die Sie mit einer von PHP verwalteten Laufzeit verwenden können. Weitere Hinweise zu einer Minimalkonfigurationsdatei finden Sie unter[Beispiele für Konfigurationsdateien](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - echo example build command for PHP run: command: ./startup.sh ``` ### Erweiterte PHP-Konfigurationsdatei Das folgende Beispiel verwendet alle Konfigurationsschlüssel mit einer von PHP verwalteten Laufzeit. **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist*8.1.10*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte PHP-Laufzeitversion finden Sie unter[Informationen zur PHP-Runtime-Version](service-source-code-php-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: pre-build: - scripts/prebuild.sh build: - echo example build command for PHP post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 8.1.10 command: ./startup.sh network: port: 5000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Vollständige PHP-Anwendungsquelle Die folgenden Beispiele zeigen den Quellcode von PHP-Anwendungen, den Sie verwenden können, um ihn mithilfe von *Apache HTTP Server*oder in einem PHP-Laufzeitdienst bereitzustellen *NGINX*. Bei diesen Beispielen wird davon ausgegangen, dass Sie die Standarddateistruktur verwenden. #### Ausführen der PHP-Plattform Apache HTTP Server mit supervisord **Example Dateistruktur** + Die `supervisord.conf` Datei kann an einer beliebigen Stelle im Repository gespeichert werden. Stellen Sie sicher, dass der `start` Befehl auf den Speicherort der `supervisord.conf` Datei verweist. + Das `index.php` muss in dem `public` Ordner unter dem `root` Verzeichnis installiert sein. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ supervisord.conf ``` **Example supervisord.conf** ``` [supervisord] nodaemon=true [program:httpd] command=httpd -DFOREGROUND autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 [program:php-fpm] command=php-fpm -F autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 ``` **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - PYTHON=python2 amazon-linux-extras install epel - yum -y install supervisor run: command: supervisord network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` #### Ausführen der PHP-Plattform Apache HTTP Server mit startup script **Example Dateistruktur** + Die `startup.sh` Datei kann an einer beliebigen Stelle im Repository gespeichert werden. Stellen Sie sicher, dass der `start` Befehl auf den Speicherort der `startup.sh` Datei verweist. + Das `index.php` muss in dem `public` Ordner unter dem `root` Verzeichnis installiert sein. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` **Example startup.sh** ``` #!/bin/bash set -o monitor trap exit SIGCHLD # Start apache httpd -DFOREGROUND & # Start php-fpm php-fpm -F & wait ``` **Anmerkung** Achte darauf, die `startup.sh` Datei als ausführbare Datei zu speichern, bevor du sie in ein Git-Repository übergibst. Verwenden Sie `chmod +x startup.sh` diese Option, um die Ausführungsberechtigung für Ihre `startup.sh` Datei festzulegen. Wenn Sie die `startup.sh` Datei nicht als ausführbare Datei speichern, geben Sie den Befehl `chmod +x startup.sh` als `build` Befehl in Ihre `apprunner.yaml` Datei ein. **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - echo example build command for PHP run: command: ./startup.sh network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` #### Ausführen der PHP-Plattform NGINX mit supervisord **Example Dateistruktur** + Die `supervisord.conf` Datei kann an einer beliebigen Stelle im Repository gespeichert werden. Stellen Sie sicher, dass der `start` Befehl auf den Speicherort der `supervisord.conf` Datei verweist. + Das `index.php` muss in dem `public` Ordner unter dem `root` Verzeichnis installiert sein. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ supervisord.conf ``` **Example supervisord.conf** ``` [supervisord] nodaemon=true [program:nginx] command=nginx -g "daemon off;" autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 [program:php-fpm] command=php-fpm -F autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 ``` **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - PYTHON=python2 amazon-linux-extras install epel - yum -y install supervisor run: command: supervisord network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` #### Ausführen der PHP-Plattform NGINX mit startup script **Example Dateistruktur** + Die `startup.sh` Datei kann an einer beliebigen Stelle im Repository gespeichert werden. Stellen Sie sicher, dass der `start` Befehl auf den Speicherort der `startup.sh` Datei verweist. + Das `index.php` muss in dem `public` Ordner unter dem `root` Verzeichnis installiert sein. ``` / ├─ public/ │ ├─ index.php ├─ apprunner.yaml ├─ startup.sh ``` **Example startup.sh** ``` #!/bin/bash set -o monitor trap exit SIGCHLD # Start nginx nginx -g 'daemon off;' & # Start php-fpm php-fpm -F & wait ``` **Anmerkung** Achte darauf, die `startup.sh` Datei als ausführbare Datei zu speichern, bevor du sie in ein Git-Repository übergibst. Verwenden Sie `chmod +x startup.sh` diese Option, um die Ausführungsberechtigung für Ihre `startup.sh` Datei festzulegen. Wenn Sie die `startup.sh` Datei nicht als ausführbare Datei speichern, geben Sie den Befehl `chmod +x startup.sh` als `build` Befehl in Ihre `apprunner.yaml` Datei ein. **Example apprunner.yaml** ``` version: 1.0 runtime: php81 build: commands: build: - echo example build command for PHP run: command: ./startup.sh network: port: 8080 env: APP_PORT ``` **Example index.php** ``` First PHP App "); ?> ``` # Informationen zur PHP-Runtime-Version **Wichtig** App Runner wird den Support für **PHP 8.1** am 31. Dezember 2025 beenden. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). In diesem Thema werden die vollständigen Informationen zu den PHP-Laufzeitversionen aufgeführt, die App Runner unterstützt. **Unterstützte Runtime-Versionen — originaler App Runner-Build** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code-php-releases.html) **Anmerkung** App Runner bietet einen überarbeiteten Build-Prozess für bestimmte Hauptlaufzeiten, die in jüngerer Zeit veröffentlicht wurden. Aus diesem Grund finden Sie in bestimmten Abschnitten dieses Dokuments Verweise auf den *überarbeiteten App Runner-Build* *und den ursprünglichen App Runner-Build*. Weitere Informationen finden Sie unter [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail). # Verwenden der -Ruby-Plattform **Wichtig** App Runner wird den Support für **Ruby 3.1** am 1. Dezember 2025 beenden. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). Die AWS App Runner Ruby-Plattform bietet verwaltete Laufzeiten. Jede Laufzeit macht es einfach, Container mit Webanwendungen zu erstellen und auszuführen, die auf einer Ruby-Version basieren. Wenn Sie eine Ruby-Runtime verwenden, startet App Runner mit einem verwalteten Ruby-Runtime-Image. Dieses Image basiert auf dem [Amazon Linux Docker-Image](https://hub.docker.com/_/amazonlinux) und enthält das Runtime-Paket für eine Version von Ruby und einige Tools. App Runner verwendet dieses verwaltete Runtime-Image als Basis-Image und fügt Ihren Anwendungscode hinzu, um ein Docker-Image zu erstellen. Anschließend wird dieses Image bereitgestellt, um Ihren Webservice in einem Container auszuführen. Sie geben eine Laufzeit für Ihren App Runner-Dienst an, wenn Sie [einen Dienst mithilfe der App Runner-Konsole oder des [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API-Vorgangs erstellen](manage-create.md). Sie können auch eine Laufzeit als Teil Ihres Quellcodes angeben. Verwenden Sie das `runtime` Schlüsselwort in einer [App Runner-Konfigurationsdatei](config-file.md), die Sie in Ihr Code-Repository aufnehmen. Die Benennungskonvention einer verwalteten Laufzeit lautet*

*. Gültige Namen und Versionen der Ruby-Runtime finden Sie unter[Informationen zur Ruby-Runtime-Version](service-source-code-ruby-releases.md). App Runner aktualisiert die Laufzeit für Ihren Dienst bei jeder Bereitstellung oder jedem Service-Update auf die neueste Version. Wenn Ihre Anwendung eine bestimmte Version einer verwalteten Laufzeit benötigt, können Sie diese mithilfe des `runtime-version` Schlüsselworts in der [App Runner-Konfigurationsdatei](config-file.md) angeben. Sie können sich auf eine beliebige Versionsebene beschränken, einschließlich einer Haupt- oder Nebenversion. App Runner aktualisiert die Laufzeit Ihres Dienstes nur auf niedrigerer Ebene. Versionssyntax für Ruby-Laufzeiten: `major[.minor[.patch]]` Beispiel: `3.1.2` Die folgenden Beispiele demonstrieren das Sperren von Versionen: + `3.1`— Sperren Sie die Haupt- und Nebenversionen. App Runner aktualisiert nur Patch-Versionen. + `3.1.2`— Auf eine bestimmte Patch-Version festlegen. App Runner aktualisiert Ihre Runtime-Version nicht. **Topics** + [Ruby-Laufzeitkonfiguration](#service-source-code-ruby.config) + [Beispiele für Ruby-Runtime](#service-source-code-ruby.examples) + [Informationen zur Ruby-Runtime-Version](service-source-code-ruby-releases.md) ## Ruby-Laufzeitkonfiguration Wenn Sie sich für eine verwaltete Runtime entscheiden, müssen Sie mindestens auch Build- und Run-Befehle konfigurieren. Sie konfigurieren sie bei der [Erstellung](manage-create.md) oder [Aktualisierung](manage-configure.md) Ihres App Runner-Dienstes. Sie können dies mit einer der folgenden Methoden tun: + **Verwenden der App Runner-Konsole** — Geben Sie die Befehle im Abschnitt **Build konfigurieren** des Erstellungsprozesses oder der Registerkarte Konfiguration an. + **Verwenden der App Runner-API** — Rufen Sie den [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API-Vorgang [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)oder auf. Geben Sie die Befehle mithilfe der `StartCommand` Elemente `BuildCommand` und des [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)Datentyps an. + **Mithilfe einer [Konfigurationsdatei](config-file.md)** — Geben Sie einen oder mehrere Build-Befehle in bis zu drei Build-Phasen sowie einen einzelnen Run-Befehl an, der zum Starten Ihrer Anwendung dient. Es gibt zusätzliche optionale Konfigurationseinstellungen. Die Bereitstellung einer Konfigurationsdatei ist optional. Wenn Sie einen App Runner-Dienst mithilfe der Konsole oder der API erstellen, geben Sie an, ob App Runner Ihre Konfigurationseinstellungen direkt bei der Erstellung oder aus einer Konfigurationsdatei bezieht. ## Beispiele für Ruby-Runtime Die folgenden Beispiele zeigen App Runner-Konfigurationsdateien zum Erstellen und Ausführen eines Ruby-Dienstes. ### Minimale Ruby-Konfigurationsdatei Dieses Beispiel zeigt eine minimale Konfigurationsdatei, die Sie mit einer von Ruby verwalteten Runtime verwenden können. Informationen zu den Annahmen, die App Runner mit einer minimalen Konfigurationsdatei trifft, finden Sie unter[Beispiele für Konfigurationsdateien](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: ruby31 build: commands: build: - bundle install run: command: bundle exec rackup --host 0.0.0.0 -p 8080 ``` ### Erweiterte Ruby-Konfigurationsdatei Dieses Beispiel zeigt die Verwendung aller Konfigurationsschlüssel mit einer von Ruby verwalteten Laufzeit. **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist*3.1.2*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Ruby-Runtime-Version finden Sie unter[Informationen zur Ruby-Runtime-Version](service-source-code-ruby-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: ruby31 build: commands: pre-build: - scripts/prebuild.sh build: - bundle install post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 3.1.2 command: bundle exec rackup --host 0.0.0.0 -p 4567 network: port: 4567 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Vollständige Ruby-Anwendungsquelle Diese Beispiele zeigen den Quellcode für eine vollständige Ruby-Anwendung, die Sie in einem Ruby-Runtime-Service bereitstellen können. **Example server.rb** ``` # server.rb require 'sinatra' get '/' do 'Hello World!' end ``` **Example config.ru** ``` # config.ru require './server' run Sinatra::Application ``` **Example Gemfile** ``` # Gemfile source 'https://rubygems.org (https://rubygems.org/)' gem 'sinatra' gem 'puma' ``` **Example apprunner.yaml** ``` version: 1.0 runtime: ruby31 build: commands: build: - bundle install run: command: bundle exec rackup --host 0.0.0.0 -p 4567 network: port: 4567 env: APP_PORT ``` # Informationen zur Ruby-Runtime-Version **Wichtig** App Runner wird den Support für **Ruby 3.1** am 1. Dezember 2025 beenden. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). In diesem Thema werden die vollständigen Informationen zu den Ruby-Runtime-Versionen aufgeführt, die App Runner unterstützt. **Unterstützte Runtime-Versionen — originaler App Runner-Build** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code-ruby-releases.html) **Anmerkung** App Runner bietet einen überarbeiteten Build-Prozess für bestimmte Hauptlaufzeiten, die in jüngerer Zeit veröffentlicht wurden. Aus diesem Grund finden Sie in bestimmten Abschnitten dieses Dokuments Verweise auf den *überarbeiteten App Runner-Build* *und den ursprünglichen App Runner-Build*. Weitere Informationen finden Sie unter [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail). # Verwenden der Go-Plattform von **Wichtig** App Runner wird die Unterstützung für **Go 1.18** am 1. Dezember 2025 beenden. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). Die AWS App Runner Go-Plattform bietet verwaltete Laufzeiten. Jede Laufzeit macht es einfach, Container mit Webanwendungen zu erstellen und auszuführen, die auf einer Go-Version basieren. Wenn Sie eine Go-Runtime verwenden, beginnt App Runner mit einem verwalteten Go-Runtime-Image. Dieses Image basiert auf dem [Amazon Linux Docker-Image](https://hub.docker.com/_/amazonlinux) und enthält das Runtime-Paket für eine Version von Go und einige Tools. App Runner verwendet dieses verwaltete Runtime-Image als Basis-Image und fügt Ihren Anwendungscode hinzu, um ein Docker-Image zu erstellen. Anschließend wird dieses Image bereitgestellt, um Ihren Webservice in einem Container auszuführen. Sie geben eine Laufzeit für Ihren App Runner-Dienst an, wenn Sie [einen Dienst mithilfe der App Runner-Konsole oder des [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API-Vorgangs erstellen](manage-create.md). Sie können auch eine Laufzeit als Teil Ihres Quellcodes angeben. Verwenden Sie das `runtime` Schlüsselwort in einer [App Runner-Konfigurationsdatei](config-file.md), die Sie in Ihr Code-Repository aufnehmen. Die Benennungskonvention einer verwalteten Laufzeit lautet*

*. Gültige Namen und Versionen von Go-Runtime finden Sie unter[Informationen zur Go Runtime-Version](service-source-code-go-releases.md). App Runner aktualisiert die Laufzeit für Ihren Service bei jeder Bereitstellung oder jedem Service-Update auf die neueste Version. Wenn Ihre Anwendung eine bestimmte Version einer verwalteten Laufzeit benötigt, können Sie diese mithilfe des `runtime-version` Schlüsselworts in der [App Runner-Konfigurationsdatei](config-file.md) angeben. Sie können sich auf eine beliebige Versionsebene beschränken, einschließlich einer Haupt- oder Nebenversion. App Runner aktualisiert die Laufzeit Ihres Dienstes nur auf niedrigerer Ebene. Versionssyntax für Go-Laufzeiten: `major[.minor[.patch]]` Beispiel: `1.18.7` Die folgenden Beispiele demonstrieren das Sperren von Versionen: + `1.18`— Sperren Sie die Haupt- und Nebenversionen. App Runner aktualisiert nur Patch-Versionen. + `1.18.7`— Auf eine bestimmte Patch-Version festlegen. App Runner aktualisiert Ihre Runtime-Version nicht. **Topics** + [Gehen Sie zur Laufzeitkonfiguration](#service-source-code-go1.config) + [Gehen Sie zu Runtime-Beispielen](#service-source-code-go1.examples) + [Informationen zur Go Runtime-Version](service-source-code-go-releases.md) ## Gehen Sie zur Laufzeitkonfiguration Wenn Sie sich für eine verwaltete Runtime entscheiden, müssen Sie mindestens auch Build- und Run-Befehle konfigurieren. Sie konfigurieren sie bei der [Erstellung](manage-create.md) oder [Aktualisierung](manage-configure.md) Ihres App Runner-Dienstes. Sie können dies mit einer der folgenden Methoden tun: + **Verwenden der App Runner-Konsole** — Geben Sie die Befehle im Abschnitt **Build konfigurieren** des Erstellungsprozesses oder der Registerkarte Konfiguration an. + **Verwenden der App Runner-API** — Rufen Sie den [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API-Vorgang [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)oder auf. Geben Sie die Befehle mithilfe der `StartCommand` Elemente `BuildCommand` und des [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)Datentyps an. + **Mithilfe einer [Konfigurationsdatei](config-file.md)** — Geben Sie einen oder mehrere Build-Befehle in bis zu drei Build-Phasen sowie einen einzelnen Run-Befehl an, der zum Starten Ihrer Anwendung dient. Es gibt zusätzliche optionale Konfigurationseinstellungen. Die Bereitstellung einer Konfigurationsdatei ist optional. Wenn Sie einen App Runner-Dienst mithilfe der Konsole oder der API erstellen, geben Sie an, ob App Runner Ihre Konfigurationseinstellungen direkt bei der Erstellung oder aus einer Konfigurationsdatei bezieht. ## Gehen Sie zu Runtime-Beispielen Die folgenden Beispiele zeigen App Runner-Konfigurationsdateien zum Erstellen und Ausführen eines Go-Dienstes. ### Minimale Go-Konfigurationsdatei Dieses Beispiel zeigt eine minimale Konfigurationsdatei, die Sie mit einer von Go verwalteten Runtime verwenden können. Informationen zu den Annahmen, die App Runner mit einer minimalen Konfigurationsdatei trifft, finden Sie unter[Beispiele für Konfigurationsdateien](config-file-examples.md#config-file-examples.managed). **Example apprunner.yaml** ``` version: 1.0 runtime: go1 build: commands: build: - go build main.go run: command: ./main ``` ### Erweiterte Go-Konfigurationsdatei Dieses Beispiel zeigt die Verwendung aller Konfigurationsschlüssel mit einer von Go verwalteten Laufzeit. **Anmerkung** Die Runtime-Version, die in diesen Beispielen verwendet wird, ist*1.18.7*. Sie können sie durch eine Version ersetzen, die Sie verwenden möchten. Die neueste unterstützte Go-Runtime-Version finden Sie unter[Informationen zur Go Runtime-Version](service-source-code-go-releases.md). **Example apprunner.yaml** ``` version: 1.0 runtime: go1 build: commands: pre-build: - scripts/prebuild.sh build: - go build main.go post-build: - scripts/postbuild.sh env: - name: MY_VAR_EXAMPLE value: "example" run: runtime-version: 1.18.7 command: ./main network: port: 3000 env: APP_PORT env: - name: MY_VAR_EXAMPLE value: "example" ``` ### Vollständige Go-Anwendungsquelle Diese Beispiele zeigen den Quellcode für eine vollständige Go-Anwendung, die Sie in einem Go-Runtime-Service bereitstellen können. **Example main.go** ``` package main import ( "fmt" "net/http" ) func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "

Welcome to App Runner

") }) fmt.Println("Starting the server on :3000...") http.ListenAndServe(":3000", nil) } ``` **Example apprunner.yaml** ``` version: 1.0 runtime: go1 build: commands: build: - go build main.go run: command: ./main network: port: 3000 env: APP_PORT ``` # Informationen zur Go Runtime-Version **Wichtig** App Runner wird die Unterstützung für **Go 1.18** am 1. Dezember 2025 beenden. Empfehlungen und weitere Informationen finden Sie unter[Ende der Unterstützung für verwaltete Runtime-Versionen](service-source-code.md#service-source-code.managed-platforms.eos). In diesem Thema werden die vollständigen Informationen zu den Go-Runtime-Versionen aufgeführt, die App Runner unterstützt. **Unterstützte Runtime-Versionen — originaler App Runner-Build** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/apprunner/latest/dg/service-source-code-go-releases.html) **Anmerkung** App Runner bietet einen überarbeiteten Build-Prozess für bestimmte Hauptlaufzeiten, die in jüngerer Zeit veröffentlicht wurden. Aus diesem Grund finden Sie in bestimmten Abschnitten dieses Dokuments Verweise auf den *überarbeiteten App Runner-Build* *und den ursprünglichen App Runner-Build*. Weitere Informationen finden Sie unter [Verwaltete Runtime-Versionen und der App Runner-Build](service-source-code.md#service-source-code.build-detail).