App Runner-Dienst basiert auf Quellcode - AWS App Runner
Anbieter von Quellcode-RepositorysQuellverzeichnisVon App Runner verwaltete PlattformenVerwaltete Runtime-Versionen und der App Runner-Build

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

App Runner stellt Ihren Quellcode bereit, indem er ihn aus einem Quellcode-Repository liest. App Runner unterstützt zwei Quellcode-Repository-Anbieter: GitHubund Bitbucket.

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 verwenden AWS CLI , um einen Service zu erstellen oder zu aktualisieren, geben Sie das Quellverzeichnis in den Aktionen CreateServiceund 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 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 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

  • Python 3.8

  • Python 3.7

  • Python 3.11 (!)

Node.js – Informationen zur Veröffentlichung

  • Node.js 16

  • Node.js 14

  • Node.js 12

  • Node.js 18

Corretto — Informationen zur Veröffentlichung

  • Corretto 11

  • Corretto 8

.NET – Informationen zur Veröffentlichung

  • .NET 6

PHP – Informationen zur Veröffentlichung

  • PHP 8.1

Ruby – Informationen zur Veröffentlichung

  • Rubin 3.1

Go – Informationen zur Veröffentlichung

  • Go 1
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:

  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.

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

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

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

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

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

    2. pre-build-Befehle ausführen

      Die pre-build Befehle sind optional. Sie können nur in der apprunner.yaml Konfigurationsdatei angegeben werden.

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

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

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

  3. 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“ 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 neuen pre-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 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.