Anwendungscode für App Runner entwickeln - AWS App Runner
Informationen zur LaufzeitRichtlinien für die Codeentwicklung

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.

Anwendungscode für App Runner entwickeln

In diesem Kapitel werden Laufzeitinformationen und Entwicklungsrichtlinien behandelt, die Sie bei der Entwicklung oder Migration von Anwendungscode für die Bereitstellung berücksichtigen sollten. AWS App Runner

Informationen zur Laufzeit

Egal, ob Sie ein Container-Image bereitstellen oder App Runner eines für Sie erstellt, App Runner führt Ihren Anwendungscode in einer Container-Instance aus. Im Folgenden sind einige wichtige Aspekte der Laufzeitumgebung für Container-Instances aufgeführt.

  • Framework-Unterstützung — App Runner unterstützt jedes Image, das eine Webanwendung implementiert. Es ist unabhängig von der ausgewählten Programmiersprache und dem Webanwendungsserver oder Framework, das Sie verwenden, falls Sie eines verwenden. Der Einfachheit halber bieten wir plattformspezifische verwaltete Laufzeiten für verschiedene Programmierplattformen an, um den Prozess der Anwendungsentwicklung und die Erstellung abstrakter Images zu optimieren.

  • Webanfragen — App Runner bietet Unterstützung für HTTP 1.0 und HTTP 1.1 für die Container-Instances. Weitere Informationen zur Konfiguration Ihres Dienstes finden Sie unterEinen App Runner-Dienst konfigurieren. Sie müssen die Verarbeitung von sicherem HTTPS-Verkehr nicht implementieren. App Runner leitet alle eingehenden HTTP-Anfragen an die entsprechenden HTTPS-Endpunkte weiter. Sie müssen keine Einstellungen konfigurieren, um die Umleitung der HTTP-Webanfragen zu aktivieren. App Runner beendet das TLS, bevor Anfragen an Ihre Anwendungscontainer-Instance weitergeleitet werden.

    Anmerkung

    • Für die HTTP-Anfragen gilt ein Zeitlimit von insgesamt 120 Sekunden. Die 120 Sekunden beinhalten die Zeit, die die Anwendung benötigt, um die Anfrage einschließlich des Hauptteils zu lesen und das Schreiben der HTTP-Antwort abzuschließen.

    • Das Limit für das Lesen und Beantworten von Anfragen hängt von den Anwendungen ab, die Sie verwenden. Diese Anwendungen können ihre eigenen internen Timeouts haben, z. B. hat der HTTP-Server für Python, Gunicorn, ein Standard-Timeout-Limit von 30 Sekunden. In solchen Fällen überschreibt das Timeout-Limit der Anwendung das App Runner-Timeout-Limit von 120 Sekunden.

    • Sie müssen keine TLS-Verschlüsselungssammlungen oder andere Parameter konfigurieren, da App Runner ein vollständig verwalteter Dienst ist und die TLS-Terminierung für Sie verwaltet.

  • Zustandslose Apps — Derzeit unterstützt App Runner keine statusbehafteten Apps. Daher garantiert App Runner nicht, dass der Status über die Dauer der Verarbeitung einer einzelnen eingehenden Webanfrage hinaus bestehen bleibt.

  • Speicher — App Runner skaliert die Instanzen für Ihre App Runner-Anwendung automatisch entsprechend dem eingehenden Datenverkehrsvolumen nach oben oder unten. Sie können Auto-Scaling-Optionen für Ihre App Runner-Anwendung konfigurieren. Da die Anzahl der derzeit aktiven Instanzen, die die Webanfragen verarbeiten, vom eingehenden Datenverkehrsvolumen abhängt, kann App Runner nicht garantieren, dass die Dateien über die Verarbeitung einer einzelnen Anfrage hinaus bestehen bleiben können. Daher implementiert App Runner das Dateisystem in Ihrer Container-Instance als kurzlebigen Speicher, was bedeutet, dass die Dateien vorübergehend sind. Die Dateien bleiben beispielsweise nicht erhalten, wenn Sie Ihren App Runner-Dienst anhalten und wieder aufnehmen.

    App Runner stellt Ihnen 3 GB kurzlebigen Speicher zur Verfügung und verwendet einen Teil der 3 GB kurzlebigen Speicher für das gepullte, komprimierte und unkomprimierte Container-Image auf der Instanz. Der verbleibende flüchtige Speicher kann von Ihrem App Runner-Dienst verwendet werden. Dies ist jedoch kein dauerhafter Speicher, da er staatenlos ist.

    Anmerkung

    Es kann Szenarien geben, in denen die Speicherdateien über mehrere Anfragen hinweg bestehen bleiben. Wenn beispielsweise die nächste Anfrage auf derselben Instanz landet, bleiben die Speicherdateien bestehen. Die Persistenz von Speicherdateien über Anfragen hinweg kann in bestimmten Situationen nützlich sein. Wenn Sie beispielsweise eine Anfrage bearbeiten, können Sie Dateien zwischenspeichern, die Ihre Anwendung herunterlädt, falls future Anfragen sie möglicherweise benötigen. Dies könnte die future Bearbeitung von Anfragen beschleunigen, kann aber die Geschwindigkeitssteigerung nicht garantieren. Ihr Code sollte nicht davon ausgehen, dass eine Datei, die in einer früheren Anfrage heruntergeladen wurde, noch existiert.

    Verwenden Sie einen Service wie Amazon, um garantiertes Caching mit einem In-Memory-Datenspeicher mit hohem Durchsatz und niedriger Latenz zu gewährleisten. ElastiCache

  • Umgebungsvariablen — Standardmäßig stellt App Runner die PORT Umgebungsvariable in Ihrer Container-Instance zur Verfügung. Sie können den Variablenwert mit Portinformationen konfigurieren und benutzerdefinierte Umgebungsvariablen und Werte hinzufügen. Sie können auch sensible Daten, die in AWS Secrets Manageroder AWS Systems Manager Parameter Store gespeichert sind, als Umgebungsvariablen referenzieren. Weitere Hinweise zum Erstellen von Umgebungsvariablen finden Sie unterReferenzieren von Umgebungsvariablen.

  • Instanzrolle — Wenn Ihr Anwendungscode mithilfe der Service-APIs oder eines der AWS SDKs AWS Dienste aufruft, erstellen Sie mithilfe von AWS Identity and Access Management (IAM) eine Instanzrolle. Hängen Sie sie dann bei der Erstellung an Ihren App Runner-Dienst an. Nehmen Sie alle AWS Serviceaktionsberechtigungen, die Ihr Code benötigt, in Ihre Instanzrolle auf. Weitere Informationen finden Sie unter Instanzrolle.

Richtlinien für die Codeentwicklung

Beachten Sie diese Richtlinien, wenn Sie Code für eine App Runner-Webanwendung entwickeln.

  • Zustandslosen Code entwerfen — Gestalten Sie die Webanwendung, die Sie für Ihren App Runner-Dienst bereitstellen, so, dass sie zustandslos ist. Ihr Code sollte davon ausgehen, dass kein Status über die Dauer der Verarbeitung einer einzelnen eingehenden Webanfrage hinaus bestehen bleibt.

  • Temporäre Dateien löschen — Wenn Sie Dateien erstellen, werden sie in einem Dateisystem gespeichert und nehmen einen Teil der Speicherzuweisung Ihres Dienstes in Anspruch. Um out-of-storage Fehler zu vermeiden, sollten Sie temporäre Dateien nicht für längere Zeit aufbewahren. Richten Sie bei Entscheidungen zum Zwischenspeichern von Dateien die Speichergröße mit der Geschwindigkeit der Bearbeitung von Anfragen ab.

  • Instanzstart — App Runner bietet eine Startzeit von fünf Minuten. Ihre Instance muss auf ihren konfigurierten Listening-Ports auf Anfragen warten und innerhalb von fünf Minuten nach dem Start wieder funktionsfähig sein. Während der Startzeit wird App Runner-Instanzen eine virtuelle CPU (vCPU) basierend auf Ihrer vCPU-Konfiguration zugewiesen. Weitere Informationen zur verfügbaren vCPU-Konfiguration finden Sie unterVon App Runner unterstützte Konfigurationen.

    Nachdem die Instanz erfolgreich gestartet wurde, wechselt sie in einen Ruhezustand und wartet auf Anfragen. Sie zahlen auf der Grundlage der Startdauer der Instance, wobei die Mindestgebühr eine Minute pro Instance-Start beträgt. Informationen zu Preisen finden Sie unter AWS App Runner -Preise.