Read this on the main serverless docs site¶
AWS - Invoke¶
Invokes a deployed function. You can send event data, read logs and display other important information of the function invocation.
Note: Please refer to this guide for event data passing when your function uses the http event with a Lambda Proxy integration.
Options¶
--functionor-fThe name of the function in your service that you want to invoke. Required.--stageor-sThe stage in your service you want to invoke your function in.--regionor-rThe region in your stage that you want to invoke your function in.--qualifieror-qThe version number or alias to invoke your function in. Default is$LATEST.--dataor-dString data to be passed as an event to your function. By default data is read from standard input.--rawPass data as a raw string even if it is JSON. If not set, JSON data are parsed and passed as an object.--pathor-pThe path to a json file with input data to be passed to the invoked function. This path is relative to the root directory of the service.--contextPath, The path to a json file holding input context to be passed to the invoked function. This path is relative to the root directory of the service.--contextString data to be passed as a context to your function. Same like with--data, context included in--contextPathwill overwrite the context you passed with--contextflag.--typeor-tThe type of invocation. EitherRequestResponse,EventorDryRun. Default isRequestResponse.--logor-lIf set totrueand invocation type isRequestResponse, it will output logging data of the invocation. Default isfalse.
Provided lifecycle events¶
invoke:invoke
Invoke Local¶
Invokes a function locally for testing and logs the output. Keep in mind that we mock the context with simple mock data.
Options¶
--functionor-fThe name of the function in your service that you want to invoke locally. Required.--pathor-pThe path to a json file holding input data to be passed to the invoked function as theevent. This path is relative to the root directory of the service.--dataor-dString data to be passed as an event to your function. Keep in mind that if you pass both--pathand--data, the data included in the--pathfile will overwrite the data you passed with the--dataflag.--rawPass data as a raw string even if it is JSON. If not set, JSON data are parsed and passed as an object.--contextPathor-x, The path to a json file holding input context to be passed to the invoked function. This path is relative to the root directory of the service.--contextor-c, String data to be passed as a context to your function. Same like with--data, context included in--contextPathwill overwrite the context you passed with--contextflag.
Examples¶
AWS¶
This example will invoke your deployed function named functionName in region us-east-1 in stage dev. This will output the result of the invocation in your terminal.
Function invocation with data¶
Function invocation with custom context¶
Function invocation with context passing¶
This example will pass the json context in the lib/context.json file (relative to the root of the service) while invoking the specified/deployed function.
Function invocation with data from standard input¶
Function invocation with logging¶
Just like the first example, but will also outputs logging information about your invocation.
Function invocation with data passing¶
This example will pass the json data in the lib/data.json file (relative to the root of the service) while invoking the specified/deployed function.
Example data.json¶
Local function invocation with custom context¶
Local function invocation with context passing¶
This example will pass the json context in the lib/context.json file (relative to the root of the service) while invoking the specified/deployed function.
Limitations¶
Currently, invoke local only supports the Node.js, Python, Java and Ruby runtimes.
Resource permissions¶
Lambda functions assume an IAM role during execution: the framework creates this role, and set all the permission provided in the iam.role.statements section of serverless.yml.
Unless you explicitly state otherwise, every call to the AWS SDK inside the lambda function is made using this role (a temporary pair of key / secret is generated and set by AWS as environment variables, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY).
When you use serverless invoke local, the situation is quite different: the role isn't available (the function is executed on your local machine), so unless you set a different user directly in the code (or via a key pair of environment variables), the AWS SDK will use the default profile specified inside you AWS credential configuration file.
Take a look to the official AWS documentation (in this particular instance, for the javascript SDK, but should be similar for all SDKs):
- http://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/loading-node-credentials-shared.html
- http://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/loading-node-credentials-lambda.html
Whatever approach you decide to implement, be aware: the set of permissions might be (and probably is) different, so you won't have an exact simulation of the real IAM policy in place.