View a markdown version of this page

AWS Lambda MicroVMS-Kernkonzepte - AWS Lambda
Die wichtigsten KonzepteWie Lambda Ihr Image erstelltMicroVM-Lebenszyklus

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.

AWS Lambda MicroVMS-Kernkonzepte

AWS Lambda MicroVMS verwendet mehrere Ressourcentypen, die Sie erstellen und verwalten. Auf dieser Seite wird jeder Ressourcentyp beschrieben, wie Lambda Ihr MicroVM-Image zu einem Snapshot zusammenstellt, und der Lebenszyklus gibt an, den eine MicroVM zur Laufzeit durchläuft — die Grundlage für die Erstellung von Anwendungen mit MicroVMs.

Die wichtigsten Konzepte

MicroVM

Eine MicroVM ist eine Ressource, die eine isolierte Rechenumgebung für einen einzelnen Mandanten, eine Benutzersitzung oder einen Job darstellt. Auf jeder MicroVM wird ein Amazon Linux 2023-Betriebssystem mit Betriebssystemfunktionen ausgeführt, das einen nahezu sofortigen Start und Wiederaufnahme ermöglicht. MicroVMs empfangen Anfragen über eingehende HTTPS-Verbindungen und können im Leerlauf angehalten werden, wodurch der Speicher- und Festplattenstatus erhalten bleibt. Eine angehaltene MicroVM wird wieder aufgenommen, wenn der Datenverkehr zurückkehrt.

MicroVM-Image

Ein MicroVM-Image ist eine Ressource, die die Anwendungsumgebung einer MicroVM definiert. Wenn Sie ein Image erstellen, baut Lambda es in einen Snapshot ein, der einen nahezu sofortigen Start ermöglicht (siehe unten). Wie Lambda Ihr Image erstellt

Um ein MicroVM-Image zu erstellen, stellen Sie ein Zip-Paket mit den Artefakten Ihrer Anwendung bereit, das auf Amazon S3 hochgeladen wurde. Dockerfile Sie müssen ein Lambda-published verwaltetes Basis-Image als Grundlage verwenden — geben Sie es mit dem base-image-arn Parameter an. Your Dockerfile definiert die Anwendungsebenen, die Lambda auf der verwalteten Basis erstellt.

MicroVM-Images sind versioniert. Jede Version stellt einen einzelnen Build dar, der aus einem bestimmten Code-Artefakt und einem Basis-Image erstellt wurde. Eine Version durchläuft den Build-Status (PENDING→ IN_PROGRESS → SUCCESSFUL oderFAILED), und erfolgreiche Versionen können auf ACTIVE oder gesetzt werden. INACTIVE Einzelheiten zu Image-Status und Verwaltung finden Sie unterMicroVM-Images.

Netzwerkanschlüsse

Netzwerkkonnektoren sind Ressourcen, die steuern, wie der Datenverkehr Ihre MicroVM erreicht und wie Ihre MicroVM externe Dienste erreicht. Sie verknüpfen Connectors zur Laufzeit mit einer MicroVM, um den eingehenden und ausgehenden Zugriff unabhängig voneinander zu konfigurieren.

Build-time und Laufzeit-Connectors können unterschiedlich sein, sodass Ihre MicroVM während der Image-Erstellung und während der Laufzeit unterschiedliche Umgebungen erreichen kann.

Verwenden Sie Lambda-provided Standardwerte für den Zugriff auf eingehende Ports (mit JWE-Authentifizierung), den Shell-Zugriff und den öffentlichen Internetausgang. Erstellen Sie Ihren eigenen Netzwerkkonnektor, um ausgehenden Datenverkehr durch Ihre VPC zu leiten.

Wie Lambda Ihr Image erstellt

Wenn Sie ein MicroVM-Image erstellen oder aktualisieren, führt Lambda einen Build-Prozess durch, der einen Firecracker-Snapshot erstellt. Dieser Snapshot erfasst den vollständig initialisierten Zustand Ihrer Anwendung und ermöglicht den nahezu sofortigen Start und die Wiederaufnahme von MicroVMs, die von dort aus ausgeführt werden.

Der Build-Prozess:

  1. Lambda stellt mithilfe des von Ihnen angegebenen verwalteten Basis-Image eine neue MicroVM bereit.

  2. Lambda führt Ihre Dockerfile Anweisungen zur Installation von Abhängigkeiten und zur Konfiguration Ihrer Umgebung aus.

  3. Lambda startet Ihre Anwendung mit dem ENTRYPOINT Befehl oder. CMD

  4. Wenn Sie den /ready Hook aktiviert haben, wartet Lambda darauf, dass Ihre Anwendung die Bereitschaft signalisiert (HTTP 200).

  5. Lambda erfasst einen Snapshot des Festplatten- und Speicherstatus, einschließlich aller laufenden Prozesse.

Wenn Sie eine MicroVM ausführen, stellt Lambda sie aus diesem Snapshot wieder her. Ihre Anwendung wird aus dem vorinitialisierten Zustand wieder aufgenommen, ohne den Start zu wiederholen.

Wenn Ihre Anwendung während des Builds eindeutige Inhalte generiert (z. B. eindeutige IDs, Geheimnisse oder Netzwerkverbindungen), wird dieser Inhalt von allen MicroVMs gemeinsam genutzt, die auf derselben Image-Version ausgeführt werden. Um dies zu vermeiden, generieren Sie eindeutigen Inhalt, nachdem die MicroVM begonnen hat, den Lifecycle-Hook zu verwenden. /run Einzelheiten finden Sie im Abschnitt zur Snapshot-Kompatibilität unterMicroVM-Images.

MicroVM-Lebenszyklus

Zur Laufzeit durchläuft eine MicroVM die folgenden Phasen:

  1. Lauf — Du rufst an. run-microvm Lambda stellt die MicroVM aus dem Image-Snapshot wieder her, weist eine eindeutige ID zu und erstellt einen Endpunkt. Die MicroVM wechselt von zu. PENDING RUNNING

  2. Wird ausgeführt — Ihre Anwendung empfängt und verarbeitet Anfragen über ihre Endpunkt-URL.

  3. Aussetzen — Nach einer konfigurierbaren Leerlaufzeit (oder über die suspend-microvm API) wechselt die MicroVM SUSPENDING zuSUSPENDED. Speicher und Festplattenstatus bleiben erhalten.

  4. Fortfahren — Die MicroVM wechselt von SUSPENDED direkt zurück zu dem RUNNING Zeitpunkt, an dem der Verkehr eintrifft (fallsautoResumeEnabled=true) oder Sie anrufenresume-microvm.

  5. Beenden — Die MicroVM wechselt TERMINATING zu dem TERMINATED Zeitpunkt, an dem Sie anrufen terminate-microvm oder die maximale Dauer überschritten wird.

Zustände

In der folgenden Tabelle werden die einzelnen MicroVM-Zustände beschrieben. Diese Status ermöglichen es Ihnen, zuverlässige Anwendungen zu erstellen und eine angemessene Fehlerbehandlung zu implementieren.

Status Description
PENDING MicroVM wird bereitgestellt. Ressourcen werden zugewiesen und der Snapshot wird geladen.
RUNNING MicroVM ist aktiv und akzeptiert Datenverkehr über seine Endpunkt-URL. Der /run Hook ist abgeschlossen.
SUSPENDING MicroVM wird angehalten. Der /suspend Hook wird ausgeführt. Festplatte und Speicher werden überprüft.
SUSPENDED MicroVM ist angehalten. Der Zustand bleibt erhalten. Es fallen keine Rechengebühren an. Kann wieder aufgenommen oder beendet werden.
TERMINATING MicroVM wird beendet. Der /terminate Hook wird ausgeführt. Ressourcen werden veröffentlicht.
TERMINATED MicroVM wurde beendet. Diese ist ein Terminalstatus. Die MicroVM kann nicht wieder aufgenommen oder neu gestartet werden.

Zustandsübergänge

Die folgende Tabelle zeigt die gültigen Übergänge zwischen MicroVM-Zuständen und was die einzelnen Übergänge auslöst.

Ursprungszustand Zielzustand Auslöser
PENDING RUNNING Die Bereitstellung ist abgeschlossen, der /run Hook war erfolgreich.
RUNNING SUSPENDING Die Leerlaufdauer wurde überschritten oder es wurde ein expliziter suspend-microvm API-Aufruf ausgeführt.
SUSPENDING SUSPENDED /suspendHook abgeschlossen, Speicher- und Festplattenstatus überprüft.
SUSPENDED RUNNING Der Datenverkehr kommt an (autoResumeEnabled=true) oder ein expliziter resume-microvm API-Aufruf.
RUNNING TERMINATING Expliziter terminate-microvm API-Aufruf oder maximumDurationInSeconds überschritten.
SUSPENDED TERMINATING suspendedDurationSecondsüberschritten oder expliziter terminate-microvm API-Aufruf.
TERMINATING TERMINATED /terminateHook abgeschlossen, alle Ressourcen freigegeben.
Wichtig

Wenn Ihr /run Hook ausfällt oder ein Timeout auftritt, wechselt die MicroVM möglicherweise direkt zu dem Hook, TERMINATING ohne ihn jemals zu erreichenRUNNING. Implementieren Sie Timeout und Fehlerbehandlung in Ihren Hooks, um stille Ausfälle zu vermeiden.