Einführung in das Testen mit sam local start-api - AWS Serverless Application Model
Verwenden Sie dieselbe lokale Start-APIOptionenBewährte MethodenWeitere Informationen

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.

Einführung in das Testen mit sam local start-api

Verwenden Sie die AWS Serverless Application Model Befehlszeilenschnittstelle (AWS SAM CLIsam local start-apiUnterbefehl, um Ihre AWS Lambda Funktionen lokal auszuführen und über einen lokalen HTTP Serverhost zu testen. Diese Art von Test ist hilfreich für Lambda-Funktionen, die von einem Amazon API Gateway-Endpunkt aufgerufen werden.

Um es zu verwendensam local start-api, installieren Sie das AWS SAM CLI indem Sie die folgenden Schritte ausführen:

Vor der Verwendung empfehlen wirsam local start-api, sich mit folgenden Grundkenntnissen vertraut zu machen:

Verwenden Sie dieselbe lokale Start-API

Wenn du sam local start-api rennst, ist der AWS SAM CLI geht davon aus, dass Ihr aktuelles Arbeitsverzeichnis das Stammverzeichnis Ihres Projekts ist. Das AWS SAM CLI sucht zuerst nach einer template.[yaml|yml] Datei in einem .aws-sam Unterordner. Wenn sie nicht gefunden wird, AWS SAM CLI sucht nach einer template.[yaml|yml] Datei in Ihrem aktuellen Arbeitsverzeichnis.

Um einen lokalen HTTP Server zu starten

  1. Führen Sie im Stammverzeichnis Ihres Projekts Folgendes aus:

    $ sam local start-api <options>

  2. Das AWS SAM CLI erstellt Ihre Lambda-Funktionen in einem lokalen Docker Behälter. Anschließend wird die lokale Adresse Ihres HTTP Serverendpunkts ausgegeben. Im Folgenden wird ein Beispiel gezeigt:

    $ sam local start-api

Initializing the lambda functions containers.
Local image is up-to-date
Using local image: public.ecr.aws/lambda/python:3.9-rapid-x86_64.

Mounting /Users/.../sam-app/.aws-sam/build/HelloWorldFunction as /var/task:ro,delegated, inside runtime container
Containers Initialization is done.
Mounting HelloWorldFunction at http://127.0.0.1:3000/hello [GET]
You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions, changes will be reflected instantly/automatically. If you used sam build before running local commands, you will need to re-run sam build for the changes to be picked up. You only need to restart SAM CLI if you update your AWS SAM template
2023-04-12 14:41:05 WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://127.0.0.1:3000

  3. Sie können Ihre Lambda-Funktion über den Browser oder die Befehlszeile aufrufen. Im Folgenden wird ein Beispiel gezeigt:

    sam-app$ curl http://127.0.0.1:3000/hello
{"message": "Hello world!"}%

  4. Wenn Sie Änderungen an Ihrem Lambda-Funktionscode vornehmen, sollten Sie Folgendes beachten, um Ihren lokalen HTTP Server zu aktualisieren:

    • Wenn Ihre Anwendung kein .aws-sam Verzeichnis hat und Ihre Funktion eine interpretierte Sprache verwendet, AWS SAM CLI aktualisiert Ihre Funktion automatisch, indem ein neuer Container erstellt und dieser gehostet wird.

    • Wenn Ihre Anwendung über ein .aws-sam Verzeichnis verfügt, müssen Sie es ausführen, sam build um Ihre Funktion zu aktualisieren. Führen Sie dann sam local start-api erneut aus, um die Funktion zu hosten.

    • Wenn Ihre Funktion eine kompilierte Sprache verwendet oder wenn Ihr Projekt komplexe Paketierungsunterstützung erfordert, führen Sie Ihre eigene Build-Lösung aus, um Ihre Funktion zu aktualisieren. Führen Sie dann sam local start-api erneut aus, um die Funktion zu hosten.

Lambda-Funktionen, die Lambda-Autorisierer verwenden

Anmerkung

Diese Funktion ist neu in AWS SAM CLI Version 1.80.0. Informationen zum Upgrade finden Sie unter Aktualisierung des AWS SAMCLI.

Für Lambda-Funktionen, die Lambda-Autorisierer verwenden, AWS SAM CLI ruft automatisch Ihren Lambda-Authorizer auf, bevor Sie Ihren Lambda-Funktionsendpunkt aufrufen.

Im Folgenden finden Sie ein Beispiel für das Starten eines lokalen HTTP Servers für eine Funktion, die einen Lambda-Autorisierer verwendet:

$ sam local start-api
2023-04-17 15:02:13 Attaching import module proxy for analyzing dynamic imports

AWS SAM CLI does not guarantee 100% fidelity between authorizers locally
and authorizers deployed on AWS. Any application critical behavior should
be validated thoroughly before deploying to production.

Testing application behaviour against authorizers deployed on AWS can be done using the sam sync command.

Mounting HelloWorldFunction at http://127.0.0.1:3000/authorized-request [GET]
You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions, changes will be reflected instantly/automatically. If you used sam build before running local commands, you will need to re-run sam build for the changes to be picked up. You only need to restart SAM CLI if you update your AWS SAM template
2023-04-17 15:02:13 WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://127.0.0.1:3000
2023-04-17 15:02:13 Press CTRL+C to quit

Wenn Sie Ihren Lambda-Funktionsendpunkt über den lokalen HTTP Server aufrufen, AWS SAM CLI ruft zuerst Ihren Lambda-Authorizer auf. Wenn die Autorisierung erfolgreich ist, AWS SAM CLI ruft Ihren Lambda-Funktionsendpunkt auf. Im Folgenden wird ein Beispiel gezeigt:

$ curl http://127.0.0.1:3000/authorized-request --header "header:my_token"
{"message": "from authorizer"}%

Invoking app.authorizer_handler (python3.8)
Local image is up-to-date
Using local image: public.ecr.aws/lambda/python:3.8-rapid-x86_64.

Mounting /Users/.../sam-app/... as /var/task:ro,delegated, inside runtime container
START RequestId: 38d3b472-a2c8-4ea6-9a77-9b386989bef0 Version: $LATEST
END RequestId: 38d3b472-a2c8-4ea6-9a77-9b386989bef0
REPORT RequestId: 38d3b472-a2c8-4ea6-9a77-9b386989bef0    Init Duration: 1.08 ms    Duration: 628.26 msBilled Duration: 629 ms    Memory Size: 128 MB    Max Memory Used: 128 MB
Invoking app.request_handler (python3.8)
Using local image: public.ecr.aws/lambda/python:3.8-rapid-x86_64.

Mounting /Users/.../sam-app/... as /var/task:ro,delegated, inside runtime container
START RequestId: fdc12255-79a3-4365-97e9-9459d06446ff Version: $LATEST
END RequestId: fdc12255-79a3-4365-97e9-9459d06446ff
REPORT RequestId: fdc12255-79a3-4365-97e9-9459d06446ff    Init Duration: 0.95 ms    Duration: 659.13 msBilled Duration: 660 ms    Memory Size: 128 MB    Max Memory Used: 128 MB
No Content-Type given. Defaulting to 'application/json'.
2023-04-17 15:03:03 127.0.0.1 - - [17/Apr/2023 15:03:03] "GET /authorized-request HTTP/1.1" 200 -

Optionen

Kontinuierliche Wiederverwendung von Containern, um lokale Funktionsaufrufe zu beschleunigen

Standardmäßig ist der AWS SAM CLI erstellt jedes Mal, wenn Ihre Funktion über den lokalen HTTP Server aufgerufen wird, einen neuen Container. Verwenden Sie die --warm-containers Option, um Ihren Container automatisch für Funktionsaufrufe wiederzuverwenden. Dies beschleunigt die Zeit, die benötigt wird, um AWS SAM CLI um Ihre Lambda-Funktion für den lokalen Aufruf vorzubereiten. Sie können diese Option weiter anpassen, indem Sie das Argument eager oder lazy angeben.

  • eager— Container für alle Funktionen werden beim Start geladen und bleiben zwischen Aufrufen bestehen.

  • lazy— Container werden nur geladen, wenn jede Funktion zum ersten Mal aufgerufen wird. Sie bleiben dann für weitere Aufrufe bestehen.

Im Folgenden wird ein Beispiel gezeigt:

$ sam local start-api --warm-containers eager

Wenn Sie Ihren Lambda-Funktionscode verwenden --warm-containers und ändern:

  • Wenn Ihre Anwendung über ein .aws-sam Verzeichnis verfügt, führen Sie sam build den Befehl aus, um Ihren Funktionscode in den Build-Artefakten Ihrer Anwendung zu aktualisieren.

  • Wenn eine Codeänderung erkannt wird, AWS SAM CLI fährt den Lambda-Funktionscontainer automatisch herunter.

  • Wenn Sie die Funktion erneut aufrufen, wird AWS SAM CLI erstellt automatisch einen neuen Container.

Geben Sie ein Container-Image an, das für Ihre Lambda-Funktionen verwendet werden soll

Standardmäßig ist das AWS SAM CLI verwendet Lambda-Basisimages von Amazon Elastic Container Registry (AmazonECR), um Ihre Funktionen lokal aufzurufen. Verwenden Sie die --invoke-image Option, um auf ein benutzerdefiniertes Container-Image zu verweisen. Im Folgenden wird ein Beispiel gezeigt:

$ sam local start-api --invoke-image public.ecr.aws/sam/emu-python3.8

Sie können die Funktion angeben, die mit dem benutzerdefinierten Container-Image verwendet werden soll. Im Folgenden wird ein Beispiel gezeigt:

$ sam local start-api --invoke-image Function1=amazon/aws/sam-cli-emulation-image-python3.8

Geben Sie eine Vorlage an, die lokal getestet werden soll

Um eine Vorlage für das anzugeben AWS SAM CLI um zu referenzieren, verwenden Sie die --template Option. Die AWS SAM CLI lädt nur diese AWS SAM Vorlage und die Ressourcen, auf die sie verweist. Im Folgenden wird ein Beispiel gezeigt:

$ sam local start-api --template myTemplate.yaml

Geben Sie die Host-Entwicklungsumgebung Ihrer Lambda-Funktion an

Standardmäßig erstellt der sam local start-api Unterbefehl einen HTTP Server, der eine IP-Adresse verwendetlocalhost. 127.0.0.1 Sie können diese Werte anpassen, wenn Ihre lokale Entwicklungsumgebung von Ihrem lokalen Computer isoliert ist.

Verwenden Sie die --container-host Option, um einen Host anzugeben. Im Folgenden wird ein Beispiel gezeigt:

$ sam local start-api --container-host host.docker.internal

Verwenden Sie die --container-host-interface Option, um die IP-Adresse des Host-Netzwerks anzugeben, an das Container-Ports gebunden werden sollen. Im Folgenden wird ein Beispiel gezeigt:

$ sam local start-api --container-host-interface 0.0.0.0

Bewährte Methoden

Wenn Ihre Anwendung ein .aws-sam Verzeichnis hat, das nicht ausgeführt wirdsam build, stellen Sie sicher, dass es sam build jedes Mal ausgeführt wird, wenn Sie Ihren Funktionscode aktualisieren. Führen Sie dann sam local start-api den Befehl aus, um Ihren aktualisierten Funktionscode lokal zu testen.

Lokales Testen ist eine hervorragende Lösung für schnelles Entwickeln und Testen vor der Bereitstellung in der Cloud. Bei lokalen Tests wird jedoch nicht alles überprüft, z. B. die Berechtigungen zwischen Ihren Ressourcen in der Cloud. Testen Sie Ihre Anwendungen so oft wie möglich in der Cloud. Wir empfehlen sam sync die Verwendung, um Ihre Cloud-Test-Workflows zu beschleunigen.

Weitere Informationen

Eine Liste aller sam local start-api Optionen finden Sie untersam local start-api.