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.