View a markdown version of this page

AWS Lambda MicroVMS-Kernkonzepte - AWS Lambda

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 werden die einzelnen Ressourcentypen beschrieben, wie Lambda Ihr MicroVM-Image in einen Snapshot aufbaut, und die Lebenszyklusstatus, die 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, sodass der Start und die Wiederaufnahme nahezu sofort möglich sind. 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 Verkehr zurückkehrt.

MicroVM-Image

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

Um ein MicroVM-Image zu erstellen, stellen Sie ein Zip-Paket bereit, das ein Dockerfile und Ihre Anwendungsartefakte enthält und auf Amazon S3 hochgeladen wurde. Sie müssen ein Lambda-published verwaltetes Basis-Image als Grundlage verwenden — geben Sie es mit dem base-image-arn Parameter an. Ihr Dockerfile definiert die Anwendungsebenen, die Lambda auf der verwalteten Basis aufbaut.

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

Netzwerkanschlüsse

Netzwerkanschlüsse sind Ressourcen, die steuern, wie der Datenverkehr Ihre microVM erreicht und wie Ihre microVM externe Dienste erreicht. Sie ordnen einer MicroVM zur Laufzeit Konnektoren zu, um eingehenden und ausgehenden Zugriff unabhängig voneinander zu konfigurieren.

Build-time und Runtime-Konnektoren können unterschiedlich sein, sodass Ihre microVM während der Image-Erstellung im Vergleich zur Laufzeit unterschiedliche Umgebungen erreichen kann.

Verwenden Sie Lambda-provided Standardwerte für den eingehenden Portzugriff (mit JWE-Authentifizierung), den Shell-Zugriff und den ausgehenden öffentlichen Internetzugang. Erstellen Sie Ihren eigenen Netzwerkconnector, um ausgehenden Datenverkehr durch Ihre VPC weiterzuleiten.

So erstellt Lambda Ihr Image

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

Der Erstellungsprozess:

  1. Lambda stellt mithilfe des von Ihnen angegebenen verwalteten Basis-Images 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 CMD Befehl ENTRYPOINT oder.

  4. Wenn Sie den /ready Hook aktiviert haben, wartet Lambda darauf, dass Ihre Anwendung 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 eindeutige Inhalte, nachdem die microVM den Lifecycle-Hook verwendet hat. /run Einzelheiten finden Sie im Abschnitt zur Snapshot-Kompatibilität unterMicroVM-Bilder.

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. Unterbrechen — 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 wurde abgeschlossen.
SUSPENDING MicroVM wird suspendiert. Der /suspend Hook wird ausgeführt. Festplatte und Speicher werden überprüft.
SUSPENDED MicroVM ist gesperrt. Der Status ist 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 freigegeben.
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 Zielstatus Auslöser
PENDING RUNNING Die Bereitstellung ist abgeschlossen, der /run Hook war erfolgreich.
RUNNING SUSPENDING Dauer des Leerlaufs überschritten oder expliziter suspend-microvm API-Aufruf.
SUSPENDING SUSPENDED /suspendDer Hook wurde abgeschlossen, der Speicher- und Festplattenstatus wurde ü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 eine Zeitüberschreitung eintritt, wechselt die MicroVM möglicherweise direkt zu, TERMINATING ohne jemals eine Verbindung herzustellen. RUNNING Implementieren Sie Timeout und Fehlerbehandlung in Ihren Hooks, um stille Ausfälle zu vermeiden.