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-Funktion von App Runner verwenden, 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 unterApp Runner-Dienst, der auf einem Quellbild basiert.
Quellcode ist Anwendungscode, den App Runner für Sie erstellt und bereitstellt. Sie verweisen App Runner auf ein Quellverzeichnis 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.
Themen
- Anbieter von Quellcode-Repositorys
- Quellverzeichnis
- Von App Runner verwaltete Plattformen
- Verwaltete Runtime-Versionen und der App Runner-Build
- Verwenden der Python-Plattform von
- Verwenden der Node.js-Plattform von
- Verwendung der Java-Plattform
- Verwenden der -.NET-Plattform
- Verwenden der -PHP-Plattform
- Verwenden der -Ruby-Plattform
- Verwenden der Go-Plattform von
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
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, 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 CreateConnectionAPI-Aktion. Anschließend geben Sie den ARN der Verbindung während der Diensterstellung mithilfe der CreateServiceAPI-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 AWS CLI zum Erstellen oder Aktualisieren eines Dienstes verwenden, geben Sie das Quellverzeichnis in den Aktionen CreateServiceund der UpdateServiceAPI an. Weitere Informationen finden Sie im nachfolgenden Quellverzeichnis-Abschnitt.
Weitere Informationen zur Erstellung des App Runner-Dienstes finden Sie unterEinen App Runner-Dienst erstellen. Weitere Informationen zu App Runner-Verbindungen finden Sie unterApp Runner-Verbindungen verwalten.
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 unterBereitstellungsmethoden.
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.
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
Sie geben eine Laufzeit für Ihren App Runner-Dienst an, wenn Sie einen Dienst mithilfe der App Runner-Konsole oder des CreateServiceAPI-Vorgangs erstellen. Sie können auch eine Laufzeit als Teil Ihres Quellcodes angeben. Verwenden Sie das runtime
Schlüsselwort in einer App Runner-Konfigurationsdatei, die Sie in Ihr Code-Repository aufnehmen. Die Benennungskonvention einer verwalteten Laufzeit lautet. <language-name><major-version>
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 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.
Verwaltete Runtime-Versionen und der App Runner-Build
App Runner bietet jetzt einen aktualisierten Build-Prozess für Ihre Anwendungen. Derzeit wird der neue Build für Dienste aufgerufen, die auf den verwalteten Laufzeiten Python 3.11 und Node.js 18 ausgeführt werden, der zuletzt am 29. Dezember 2023 veröffentlicht wurde. Dieser überarbeitete Build-Prozess 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-runParameter. 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.
Plattform | Ursprünglicher Aufbau | Überarbeiteter Aufbau |
---|---|---|
Python – Informationen zur Veröffentlichung |
|
|
Node.js – Informationen zur Veröffentlichung |
|
|
Corretto — Informationen zur Veröffentlichung |
|
|
|
||
|
||
|
||
|
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 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:
-
Führen Sie
pre-build
Befehle in einem CodeBuild -kuratierten Bild aus.Die
pre-build
Befehle sind optional. Sie können nur in derapprunner.yaml
Konfigurationsdatei angegeben werden. -
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 derapprunner.yaml
Konfigurationsdatei angegeben werden. -
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.
-
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. -
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 derapprunner.yaml
Konfigurationsdatei angegeben werden. -
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 derapprunner.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:
-
Erstellungsphase — Startet einen Docker-Build-Prozess, der
build
Befehlepre-build
und Befehle auf den App Runner-Build-Images ausführt.-
Kopieren Sie den Quellcode der Anwendung in das
/app
Verzeichnis.Anmerkung
Dieses
/app
Verzeichnis wird in jeder Phase des Docker-Builds als Arbeitsverzeichnis bezeichnet. -
pre-build
-Befehle ausführenDie
pre-build
Befehle sind optional. Sie können nur in derapprunner.yaml
Konfigurationsdatei angegeben werden. -
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 derapprunner.yaml
Konfigurationsdatei angegeben werden.
-
-
Paketierungsphase — Generiert das endgültige Container-Image für den Kunden, das ebenfalls auf dem App Runner-Run-Image basiert.
-
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. -
Führen Sie die
pre-run
Befehle aus. Wenn Sie das Runtime-Image außerhalb des/app
Verzeichnisses mithilfe derbuild
Befehle ändern müssen, fügen Sie diesem Segment derapprunner.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 derapprunner.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 keinepre-run
Befehle angeben.
-
-
-
Post-Build-Phase — Diese Phase wird nach der Build-Phase fortgesetzt und führt
post-build
Befehle aus.-
Führen Sie die
post-build
Befehle innerhalb des Verzeichnisses aus/app
.Die
post-build
Befehle sind optional. Sie können nur in derapprunner.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 von den env
Einträgen im Abschnitt „Ausführen“ in die apprunner.yaml
Irre führen. 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“ 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 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
Befehlepre-build
, und ändernbuild
, 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 neuenpre-run
Befehle in der verwendenapprunner.yaml
. Weitere Informationen finden Sie unter App Runner-Dienstoptionen mithilfe einer Konfigurationsdatei einrichten.
Die build
Befehle zweimal ausführen
-
Der ursprüngliche App Runner-Build 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 diebuild
Befehle nur einmal aus. Falls für Ihre Anwendung eine ungewöhnliche Anforderung besteht, dass diebuild
Befehle zweimal ausgeführt werden müssen, bietet der überarbeitete App Runner-Build die Möglichkeit, dieselben Befehle mithilfe despre-run
Parameters anzugeben und erneut auszuführen. Dabei wird das gleiche Double-Build-Verhalten beibehalten.